3.1.2 Language of Parts:



***************NOTICE************************************************ 
                                                                                                       
  This work space is being phased out and is no longer kept        
  updated with the latest task force agreements. Please refer to  
  the most recent WCAG2ICT public draft at                                 
  http://www.w3.org/TR/wcag2ict/                                                  
                                                                                                       
************************************************************************* 


                                                                                                                               .
               <NEW TEXT TO SENT OUT FOR REVIEW #2                                     .
                                                                                                                               .

Success Criterion 3.1.2: Language of Parts (Level AA)

From Success Criterion 3.1.2:

The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text.

Intent from Understanding Success Criterion 3.1.2 in Understanding WCAG 2.0:

The intent of this Success Criterion is to ensure that user agents can correctly present content written in multiple languages. This makes it possible for user agents and assistive technologies to present content according to the presentation and pronunciation rules for that language. This applies to graphical browsers as well as screen readers, braille displays, and other voice browsers.

Both assistive technologies and conventional user agents can render text more accurately if the language of each passage of text is identified. Screen readers can use the pronunciation rules of the language of the text. Visual browsers can display characters and scripts in appropriate ways. This is especially important when switching between languages that read from left to right and languages that read from right to left, or when text is rendered in a language that uses a different alphabet. Users with disabilities who know all the languages used in the Web page will be better able to understand the content when each passage is rendered appropriately.

When no other language has been specified for a phrase or passage of text, its human language is the default human language of the Web page (see Success Criterion 3.1.1). So the human language of all content in single language documents can be programmatically determined.

Individual words or phrases in one language can become part of another language. For example, "rendezvous" is a French word that has been adopted in English, appears in English dictionaries, and is properly pronounced by English screen readers. Hence a passage of English text may contain the word "rendezvous" without specifying that its human language is French and still satisfy this Success Criterion. Frequently, when the human language of text appears to be changing for a single word, that word has become part of the language of the surrounding text. Because this is so common in some languages, single words should be considered part of the language of the surrounding text unless it is clear that a change in language was intended. If there is doubt whether a change in language is intended, consider whether the word would be pronounced the same (except for accent or intonation) in the language of the immediately surrounding text.

Most professions require frequent use of technical terms which may originate from a foreign language. Such terms are usually not translated to all languages. The universal nature of technical terms also facilitate communication between professionals.

Some common examples of technical terms include: Homo sapiens, Alpha Centauri, hertz, and habeas corpus.

Identifying changes in language is important for a number of reasons:

  • It allows braille translation software to follow changes in language, e.g., substitute control codes for accented characters, and insert control codes necessary to prevent erroneous creation of Grade 2 braille contractions.

  • Speech synthesizers that support multiple languages will be able to speak the text in the appropriate accent with proper pronunciation. If changes are not marked, the synthesizer will try its best to speak the words in the default language it works in. Thus, the French word for car, "voiture" would be pronounced "voyture" by a speech synthesizer that uses English as its default language.

  • Marking changes in language can benefit future developments in technology, for example users who are unable to translate between languages themselves will be able to use machines to translate unfamiliar languages.

  • Marking changes in language can also assist user agents in providing definitions using a dictionary.

Specific Benefits of Success Criterion 3.1.2

This Success Criterion helps:

  • people who use screen readers or other technologies that convert text into synthetic speech;

  • people who find it difficult to read written material with fluency and accuracy, such as recognizing characters and alphabets, decoding words, and understanding words and phrases;

  • people with certain cognitive, language and learning disabilities who use text-to-speech software;

  • people who rely on captions to recognize language changes in the soundtrack of synchronized media content.

Additional guidance when applying to Non-Web Documents and Software

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0 (above) replacing content”  with  “{non-web documents} or software".

This would make it:   (substituted text marked up as strong (bold), emphasis (italic) and black. )

3.1.2 Language of Parts: The human language of each passage or phrase in the {non-web documents} or software can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text. (Level AA)

Note: There are some software and {non-embedded content} technologies where there is no assistive technology supported method for marking the language for the different passages or phrases in the {non-embedded content} or software, and it would not be possible to meet this success criterion with those technologies.


<         PUBLIC COMMENTS ON THIS ITEM ARE ABOVE  >.   
 <  OUR RESPONSE TO PUBLIC COMMENTS ARE BELOW>

NEW APPROVED TEXT

Additional guidance when applying to Electronic Documents and Software Aspects of Products

"This applies directly as written, and as described in INTENT from Understanding WCAG 2.0  (above) replacing "content" with "electronic document or software"

Note: There are some software and document technologies where there is no assistive technology supported method for marking the language for the different passages or phrases in the document or software, and it would not be possible to meet this success criterion with those technologies.
 


                                                                                                                                   .
               <TEXT AS SENT OUT FOR REVIEW ON  JULY 27TH                             .
                                                                                                                                   .

Success Criterion 3.1.2: Language of Parts (Level AA)

From Success Criterion 3.1.2:

The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text.

Intent from Understanding Success Criterion 3.1.2 in Understanding WCAG 2.0:

The intent of this Success Criterion is to ensure that user agents can correctly present content written in multiple languages. This makes it possible for user agents and assistive technologies to present content according to the presentation and pronunciation rules for that language. This applies to graphical browsers as well as screen readers, braille displays, and other voice browsers.

Both assistive technologies and conventional user agents can render text more accurately if the language of each passage of text is identified. Screen readers can use the pronunciation rules of the language of the text. Visual browsers can display characters and scripts in appropriate ways. This is especially important when switching between languages that read from left to right and languages that read from right to left, or when text is rendered in a language that uses a different alphabet. Users with disabilities who know all the languages used in the Web page will be better able to understand the content when each passage is rendered appropriately.

When no other language has been specified for a phrase or passage of text, its human language is the default human language of the Web page (see Success Criterion 3.1.1). So the human language of all content in single language documents can be programmatically determined.

Individual words or phrases in one language can become part of another language. For example, "rendezvous" is a French word that has been adopted in English, appears in English dictionaries, and is properly pronounced by English screen readers. Hence a passage of English text may contain the word "rendezvous" without specifying that its human language is French and still satisfy this Success Criterion. Frequently, when the human language of text appears to be changing for a single word, that word has become part of the language of the surrounding text. Because this is so common in some languages, single words should be considered part of the language of the surrounding text unless it is clear that a change in language was intended. If there is doubt whether a change in language is intended, consider whether the word would be pronounced the same (except for accent or intonation) in the language of the immediately surrounding text.

Most professions require frequent use of technical terms which may originate from a foreign language. Such terms are usually not translated to all languages. The universal nature of technical terms also facilitate communication between professionals.

Some common examples of technical terms include: Homo sapiens, Alpha Centauri, hertz, and habeas corpus.

Identifying changes in language is important for a number of reasons:

  • It allows braille translation software to follow changes in language, e.g., substitute control codes for accented characters, and insert control codes necessary to prevent erroneous creation of Grade 2 braille contractions.

  • Speech synthesizers that support multiple languages will be able to speak the text in the appropriate accent with proper pronunciation. If changes are not marked, the synthesizer will try its best to speak the words in the default language it works in. Thus, the French word for car, "voiture" would be pronounced "voyture" by a speech synthesizer that uses English as its default language.

  • Marking changes in language can benefit future developments in technology, for example users who are unable to translate between languages themselves will be able to use machines to translate unfamiliar languages.

  • Marking changes in language can also assist user agents in providing definitions using a dictionary.

Specific Benefits of Success Criterion 3.1.2

This Success Criterion helps:

  • people who use screen readers or other technologies that convert text into synthetic speech;

  • people who find it difficult to read written material with fluency and accuracy, such as recognizing characters and alphabets, decoding words, and understanding words and phrases;

  • people with certain cognitive, language and learning disabilities who use text-to-speech software;

  • people who rely on captions to recognize language changes in the soundtrack of synchronized media content.

Additional guidance when applying Success Criterion 3.1.2 to Electronic Documents and Software Aspects of Products:

The WCAG2ICT Task Force has not yet produced additional guidance for Success Criterion 3.1.2.



                                                                                                                                   .
         </ END OF 
TEXT AS SENT OUT FOR REVIEW ON  JULY 27TH    >            .
                                                                                                                                   .

Success Criteria 3.1.2: The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text. (Level AA)


Intent of WCAG Success Criteria 3.1.2  (Quoted from Understanding WCAG 2.0)

The intent of this Success Criterion is to ensure that user agents can correctly present content written in multiple languages. This makes it possible for user agents and assistive technologies to present content according to the presentation and pronunciation rules for that language. This applies to graphical browsers as well as screen readers, braille displays, and other voice browsers.

Both assistive technologies and conventional user agents can render text more accurately if the language of each passage of text is identified. Screen readers can use the pronunciation rules of the language of the text. Visual browsers can display characters and scripts in appropriate ways. This is especially important when switching between languages that read from left to right and languages that read from right to left, or when text is rendered in a language that uses a different alphabet. Users with disabilities who know all the languages used in the Web page will be better able to understand the content when each passage is rendered appropriately.

When no other language has been specified for a phrase or passage of text, its human language is the default human language of the Web page (see Success Criterion 3.1.1). So the human language of all content in single language documents can be programmatically determined.

Individual words or phrases in one language can become part of another language. For example, "rendezvous" is a French word that has been adopted in English, appears in English dictionaries, and is properly pronounced by English screen readers. Hence a passage of English text may contain the word "rendezvous" without specifying that its human language is French and still satisfy this Success Criterion. Frequently, when the human language of text appears to be changing for a single word, that word has become part of the language of the surrounding text. Because this is so common in some languages, single words should be considered part of the language of the surrounding text unless it is clear that a change in language was intended. If there is doubt whether a change in language is intended, consider whether the word would be pronounced the same (except for accent or intonation) in the language of the immediately surrounding text.

Most professions require frequent use of technical terms which may originate from a foreign language. Such terms are usually not translated to all languages. The universal nature of technical terms also facilitate communication between professionals.

Some common examples of technical terms include: Homo sapiens, Alpha Centauri, hertz, and habeas corpus.

Identifying changes in language is important for a number of reasons:

  • It allows braille translation software to follow changes in language, e.g., substitute control codes for accented characters, and insert control codes necessary to prevent erroneous creation of Grade 2 braille contractions.

  • Speech synthesizers that support multiple languages will be able to speak the text in the appropriate accent with proper pronunciation. If changes are not marked, the synthesizer will try its best to speak the words in the default language it works in. Thus, the French word for car, "voiture" would be pronounced "voyture" by a speech synthesizer that uses English as its default language.

  • Marking changes in language can benefit future developments in technology, for example users who are unable to translate between languages themselves will be able to use machines to translate unfamiliar languages.

  • Marking changes in language can also assist user agents in providing definitions using a dictionary.

Specific Benefits of Success Criterion 3.1.2:

This Success Criterion helps:

  • people who use screen readers or other technologies that convert text into synthetic speech;

  • people who find it difficult to read written material with fluency and accuracy, such as recognizing characters and alphabets, decoding words, and understanding words and phrases;

  • people with certain cognitive, language and learning disabilities who use text-to-speech software;

  • people who rely on captions to recognize language changes in the soundtrack of synchronized media content.


<End of material Quoted from Understanding WCAG 2.0>


Additional guidance when applying to Electronic Documents and Software Aspects of Products

"This applies directly as written, and as described in INTENT from Understanding WCAG 2.0  (above) replacing "content" with "electronic document or software"

There are some software and document technologies where there is no assistive technology supported method for marking the language for the different passages or phrases in the document or software, and it would not be possible to meet this success criterion with those technologies.

NOTE: Inheritance is one common method.  For example a document or application provides the language that it is using and it can be assumed that all of the text or user interface elements within that document or application will be using the same language unless it is indicated.

                                                                                                                                   .
</ END OF TASK FORCE CONSENSUS CONTENT FOR APPLICATION NOTE >.
              (only EDITORS should make edits above this line.                                      .
     -- and then only after text is approved by consensus by the Task force.              .
                                                                                                                                   .


From WCAG WG meeting on 9Aug12:

"This applies directly as written, and as described in INTENT from Understanding WCAG 2.0  (above) replacing "content" with "electronic document or software"

Note: There are some software and document technologies where there is no accessibility supported method for marking the language for the different passages or phrases in the document or software, and it would not be possible to meet this success criterion with those technologies.



The Note below was removed (as per WCAG WG), BUT Peter Korn has the action (#178) to suggest language along these lines to WCAG WG (not this TF), focused on "nested elements", for Understanding:

NOTE: Inheritance is one common method.  For example a document or application provides the language that it is using and it can be assumed that all of the text or user interface elements within that document or application will be using the same language unless it is indicated.

<         CONSENSUS WAS REACHED ON THIS ITEM.   
 Place any "Post-Consensus"  notes, including notes from public, ABOVE THIS NOTICE / >


In the 17Aug12 WCAG2ICT TF meeting survey feedback, Mike Pluke wrote:

The WCAG text is a good interpretation of the SC intent when applied to documents and software. Any additional text would begin to change the intent.

Because support for language of parts is so rare for document and software technologies, M376 have said that 3.1.2 "need not be considered" for documents and software.

We might consider highlighting more generally in the initial part of the document/report that, WCAG being built for the web it assumed a certain amount of platform support for things that may not be present in any given software platform or any given document technology - some of which may be per-requisites for some SCs (like this one).












PROPOSALS FOR  CONSENSUS TEXT =================

Insert your proposals for the text to go above.  Label each Proposal separately.  Trace has provided a startup proposal for each.   Below is a template.  Please copy it and leave a template behind for others to add their proposal.
 

Proposal #1 (Trace Center) ========================

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above) with the word “document” substituted for Web Page..

Documents created with document formats that do not support tagging language for parts of the document (where the language changes) – would not be able to meet this SC.
 (see Introduction for how to interpret "content")

Additional guidance when applying to Software Aspects of Products

This applies directly as written and as described in INTENT from WCAG (above) with the word “interaction context” substituted for Web Page. 

Software created with technologies that do not allow language tagging for contexts of use within the software may not be able to meet this SC if there are different languages intermixed within the software. 

Note that a language menu is just one context of use, and each item would not need to be labeled for this SC. 

Note that a single widget is not a context of use.


Proposal #1REVISED (Trace Center) ========================

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above) with the word “document” substituted for "content".

Documents created with document formats that do not support tagging language for parts of the document (where the language changes) – would not be able to meet this SC.

With software, this is unlikely to occur. It is much more common in text.   But if software did include foreign language words or phrases there are few programming environments today that allow tagging of those phrases to mark their language.  If the words were not covered in the exceptions, and the programming language/environment did not allow a programmatic way to indicate the language, then it would not be possible for that software to meet this success criterion given the language recognizing abilities of todays Assistive technologies.   This may change in the future however." 


PLUS Ask WCAG to include the following in the INTENT for 3.1.2
The names of languages, in their native language, are considered technical terms.  Although marking them with language tags is recommended, it would not be required by this SC.  For example, a menu listing each language in that language would not need to be marked up with language tags, though it is recommended. 



Proposal #2 (Loïc Martínez) ========================
Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0  (above).

Note that some document formats can use separate human languages for output and input purposes. In such cases both languages should be programmatically determinable.

Documents created with document formats that do not support tagging language for parts of the document (where the language changes) – would not be able to meet this SC.

This success criterion does not apply in general to software user interfaces, as it would require tagging language for parts of the user interface (individual user interface elements or even fragments of text inside user interface elements), and that is not always feasible in current platforms.


Proposal #3 (Andi Snow-Weaver) ========================

Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above) with “document or software” substituted for "content".

Documents that contain passages or phrases in multiple languages that are created with document formats that do not support specifying the language for parts of the document would not be able to meet this SC.

It is rare that a software user interface contains user interface elements in multiple languages and few software platforms support the ability to identify the language of an individual user interface element. But if the software user interface does include words or phrases in multiple languages that do not qualify for the exceptions and is implemented in a programming environment that does not support a way to programmatically identify the language of a user interface element, then it would not be able to meet this SC.


PLUS Ask WCAG to include the following in the INTENT for 3.1.2
The names of languages, in their native language, are considered technical terms.  Although marking them with language tags is recommended, it would not be required by this SC.  For example, a menu listing each language in that language would not need to be marked up with language tags, though it is recommended.


Proposal #4 (Gregg, Mike, Loic) ========================
Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0  (above) with “document or software” substituted for "content"

Note that some document formats can use separate human languages for output and input purposes. In such cases both languages should be programmatically determinable.

There are some software and document technologies where there is no assistive technology supported method for marking the language for the different passages or phrases in the document or software, and it would not be possible to meet this success criterion with those technologies.

NOTE: Inheritance is one common method.  For example a document or application provides the language that it is using and it can be assumed that all user interface contexts within that document or application will be using the same language unless it is indicated. 


Proposal #5 (Peter Korn, based on #4 above but without "UI Context") ========================
Additional guidance when applying to Electronic Documents and Software Aspects of Products

This applies directly as written, and as described in INTENT from Understanding WCAG 2.0  (above) with “document or software” substituted for "content"

Note that some document formats can use separate human languages for output and input purposes. In such cases both languages should be programmatically determinable.

There are some software and document technologies where there is no assistive technology supported method for marking the language for the different passages or phrases in the document or software, and it would not be possible to meet this success criterion with those technologies.

NOTE: Inheritance is one common method.  For example a document or application provides the language that it is using and it can be assumed that all <ins>of the text or user interface elements</ins> <del>user interface contexts</del> within that document or application will be using the same language unless it is indicated. 



Proposal #6 ( FROM meeting --  this is #5 above with first sentence changed and insert/del applied and sentence about input removed since it is beyond SC) ========================
Additional guidance when applying to Electronic Documents and Software Aspects of Products

"This applies directly as written, and as described in INTENT from Understanding WCAG 2.0  (above) replacing "content" with "electronic document or software"

There are some software and document technologies where there is no assistive technology supported method for marking the language for the different passages or phrases in the document or software, and it would not be possible to meet this success criterion with those technologies.

NOTE: Inheritance is one common method.  For example a document or application provides the language that it is using and it can be assumed that all of the text or user interface elements within that document or application will be using the same language unless it is indicated. 



Proposal #x (Submitter) ========================
Additional guidance when applying to Electronic Documents and Software Aspects of Products


DISCUSSION POINTS, OPINIONS, ISSUES, NOTES etc. 

Note that M376 work identifies 3.1.2 as one of two “success criteria that do not apply for user interfaces of software”. See Draft EN 301 549 V0.0.4 (2012-04) Table 4, p. 30.

---- Proposal explanation -----

Proposal #2 (Loïc Martínez)

(Note: I''ve combined documents+software as suggested by Gregg).

In the M376 work we did the following:

  • For electronic content and documents we accepted 3.1.2 as applicable, but we wrote an explanation highlighting two issues:
    • First, in some electronic documents it is possible to have different languages for output (content rendered) and input (user interface elements receiving content provided by the user). We agreed that we needed an applicability note explaining that.
    • Second, we also agreed to have an exception for formats not supporting language coding at all, as that exception existed in the 2010 ANPRM (In "506.3 Language of Passage or Phrase" it started with "When supported by the technology"
  • For software we had many discussions about the general applicability of 3.1.2 to non-web software. Our agreement was that per-element language coding was not widely supported in current platforms and so we finally agree to consider 3.1.2 as not applicable to user interfaces of non-web software.

Taking this into account, my proposal has been:

  • For electronic content and documents I've mostly taken TRACE proposal, but removing the reference to how to interpret "web page" (as it is not needed in 3.1.2.) and adding a paragraph for the issue on input and output purposes.
  • For software I have written a paragraph explaining that this SC dos not apply, in general. It is a similar paragraph of the one proposed for 2.4.5 multiple ways.

---- ISSUES-----

RE - Documents

Issue1:  If it is possible to encode language in doc., it should be done.  [what about where not?]

Comment on Issue1:See contribution language.

 

RE - Software

Issue1: Some UI toolkits support association a LANG attr. with the component.  If so, must it be used by all software?

Comment on Issue1: See contribution language.


 From M376 -   Draft EN "European accessibility requirements for public procurement of ICT products and services"


    For Electronic Documents
This success criterion only applies when the document format supports programmatically exposing the default human language for both input and output purposes. Formats such as plain ASCII text do not have this capability.


2010 ANPRM Text (22 March 2010)
506.3 Language of Passage or Phrase.  When supported by the technology, the human language of each passage or phrase in the content shall be programmatically determinable.
EXCEPTION:  The human language for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text, shall not be required to be programmatically determinable.



Teitac Report (3 April 2008)
3-H: Language of Parts
When supported in the technology of electronic documents, the human language of each passage or phrase in electronic documents must be PROGRAMMATICALLY DETERMINABLE.

Comments