3.1.1 Language of Page:



***************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.1: Language of Page (Level A)

From Success Criterion 3.1.1:

The default human language of each Web page can be programmatically determined.

Intent from Understanding Success Criterion 3.1.1 in Understanding WCAG 2.0:

The intent of this Success Criterion is to ensure that content developers provide information in the Web page that user agents need to present text and other linguistic content correctly. Both assistive technologies and conventional user agents can render text more accurately when the language of the Web page is identified. Screen readers can load the correct pronunciation rules. Visual browsers can display characters and scripts correctly. Media players can show captions correctly. As a result, users with disabilities will be better able to understand the content.

The default human language of the Web page is the default text-processing language as discussed in Internationalization Best Practices: Specifying Language in XHTML & HTML Content. When a Web page uses several languages, the default text-processing language is the language which is used most. (If several languages are used equally, the first language used should be chosen as the default human language.)

Note: For multilingual sites targeting Conformance Level A, the Working Group strongly encourages developers to follow Success Criterion 3.1.2 as well even though that is a Level AA Success Criterion.

Specific Benefits of Success Criterion 3.1.1

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 or decoding words;

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

  • people who rely on captions for synchronized media.

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 each Web page”  with  “the non-web documents or software".

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

3.1.1 Language of Page: The default human language of the non-web documents or software can be programmatically determined. (Level A) 

Note: Where software platforms provide a "locale/language" setting, applications that use that setting and render their interface in that "locale/language" would comply with this success criterion. Applications that do not use the platform "locale/language setting" but instead use an accessibility supported method for exposing the human language of the {software} would also comply with this success criterion. Applications implemented in technologies where assistive technologies cannot determine the human language and that do not support the platform "locale/language" setting may not be able to meet this success criterion in that locale/language.


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

NEW APPROVED TEXT  (PROPOSAL 9 AS AMMENDED) With edits from WCAG 

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

Note: Where software platforms provide a "locale/language" setting, applications that use that setting and render their interface in that "locale/language" would comply with this success criterion. Applications that do not use the platform "locale/language setting" but instead use an accessibility supported method for exposing the human language of the software user interface would also comply with this success criterion. Applications implemented in technologies where assistive technologies cannot determine the human language and that do not support the platform "locale/language" setting may not be able to meet this success criterion in that locale/language.


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

Success Criterion 3.1.1: Language of Page (Level A)

From Success Criterion 3.1.1:

The default human language of each Web page can be programmatically determined.

Intent from Understanding Success Criterion 3.1.1 in Understanding WCAG 2.0:

The intent of this Success Criterion is to ensure that content developers provide information in the Web page that user agents need to present text and other linguistic content correctly. Both assistive technologies and conventional user agents can render text more accurately when the language of the Web page is identified. Screen readers can load the correct pronunciation rules. Visual browsers can display characters and scripts correctly. Media players can show captions correctly. As a result, users with disabilities will be better able to understand the content.

The default human language of the Web page is the default text-processing language as discussed in Internationalization Best Practices: Specifying Language in XHTML & HTML Content. When a Web page uses several languages, the default text-processing language is the language which is used most. (If several languages are used equally, the first language used should be chosen as the default human language.)

Note: For multilingual sites targeting Conformance Level A, the Working Group strongly encourages developers to follow Success Criterion 3.1.2 as well even though that is a Level AA Success Criterion.

Specific Benefits of Success Criterion 3.1.1

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 or decoding words;

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

  • people who rely on captions for synchronized media.

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

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



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

Success Criteria 3.1.1: The default human language of each Web page can be programmatically determined. (Level A)


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

The intent of this Success Criterion is to ensure that content developers provide information in the Web page that user agents need to present text and other linguistic content correctly. Both assistive technologies and conventional user agents can render text more accurately when the language of the Web page is identified. Screen readers can load the correct pronunciation rules. Visual browsers can display characters and scripts correctly. Media players can show captions correctly. As a result, users with disabilities will be better able to understand the content.

The default human language of the Web page is the default text-processing language as discussed in Internationalization Best Practices: Specifying Language in XHTML & HTML Content. When a Web page uses several languages, the default text-processing language is the language which is used most. (If several languages are used equally, the first language used should be chosen as the default human language.)

Note: For multilingual sites targeting Conformance Level A, the Working Group strongly encourages developers to follow Success Criterion 3.1.2 as well even though that is a Level AA Success Criterion.

Specific Benefits of Success Criterion 3.1.1:

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 or decoding words;

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

  • people who rely on captions for synchronized media.


<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 "each Web page" with "the electronic document or software".

Where software platforms provide a "local language" setting, applications that follow that setting would comply with this success criterion. Applications that do not follow the platform "local language setting" but instead use an assistive technology supported method for exposing the human language of the software user interface would also comply with this success criterion. Applications implemented in technologies where Assistive technologies cannot determine the human language and that do not support the platform "local language setting" may not be able to meet this success criterion.

                                                                                                                                   .
</ 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.              .
                                                                                                                                   .


New text discussed in WCAG WG on 9Aug12:

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

Note: Where software platforms provide a "locale/language" setting, applications that use that setting and render their interface in that "locale/language" would comply with this success criterion. Applications that do not use the platform "locale/language setting" but instead use an accessibility supported method for exposing the human language of the software user interface would also comply with this success criterion. Applications implemented in technologies where assistive technologies cannot determine the human language and that do not support the platform "locale/language" setting may not be able to meet this success criterion in that locale/language.

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




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

This applies directly as written, and as described in  INTENT  from Understanding WCAG 2.0  (above) with "Electronic Document substituted for "Web Page".

The  language of the document Page  can be "programmatically determined"  using just  the text on the page.  Except for rare languages the language of a file can be determined by software without special markup.  For those rare situations, the document can be labeled in their filename (e.g.  foobar-en.doc)

(see Introduction for how to interpret "content")

Additional guidance when applying to Software Aspects of Products

For software, if the language is determinable for the package as a whole it would apply all parts since they are all part of one entity. If some contexts of use change the language then this would fall under 3.1.2.

Proposal #2 (Loïc Martínez) ========================

Additional guidance when applying to Electronic Content and Electronic Documents 
This applies directly as written, and as described in INTENT from Understanding WCAG 2.0  (above) with "document" substituted for "Web Page".

The language of the document can be "programmatically determined" in several ways:
  • If the document format provides a mechanism to programmatically expose the default human language, by using such mechanism.
  • If the document format does not provide a mechanism to programmatically expose the default human language, by having software automatically determine the language of the document by just analyzing the text on the page. This works for most human languages today.
  • If the document format does not provide a mechanism to programmatically expose the default human language and the language cannot automatically be identified by software, by labelling the human language in the filename (e.g. foobar-en.txt).

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


Additional guidance when applying to Software Aspects of Products
This applies directly as written, and as described in INTENT from Understanding WCAG 2.0  (above) with "software product" substituted for "Web Page".

In most cases, applications use the human language (locale) as defined in the platform software. In those situations the human language is programmatically determinable with no need of specific action by the developers.


Proposal #3 (Gregg Van based off of Loic )  (removed sufficient techniques and moved to one title) ========================

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 product" substituted for "Web page".

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

In most cases for software, applications use the human language (locale) as defined in the platform software. In those situations the human language is programmatically determinable with no need of specific action by the developers.

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 #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 user interface context" substituted for "Web Page".

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

For software, there are some platforms and software types where there is no assistive technology supported method for marking the language for the different "user interface contexts" or for marking that the application doesn’t match the “local” language, as marked in the platform, and it would not be possible to meet this success criterion with those platforms or software types.

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 product" substituted for "Web Page".

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

For software, there are some platforms and software types where there is no assistive technology supported method for marking the language for the <ins>different parts of the user interface</ins> <del>"user interface contexts"</del> or for marking that the application doesn’t match the “local” language, as marked in the platform, and it would not be possible to meet this success criterion with those platforms or software types.

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 (Gregg -- no 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 "Web Page".

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

For software, most all platforms have a 'local language' setting and most all apps will follow that setting.  For those application that do not follow the 'local language setting" there are some platforms and software types where there is no assistive technology supported method for indicating this. In that case the software that does not follow the local language setting may not be able to meet this SC.

Proposal #7 (Andi Snow-Weaver -- friendly edits to proposals #5 & #6) 


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 "each Web page" with "the document or software user interface".

Where software platforms provide a "local language" setting, applications that follow that setting would comply with this success criterion. Applications that do not follow the platform "local language setting" but instead use an assistive technology supported method for exposing the human language of the software user interface would also comply with this success criterion. Not all software technologies support a method to programmatically expose the human language of the software user interface. Applications implemented in such technologies that do not support the platform "local language setting" may not be able to meet this success criterion.


Proposal #8 (Andi with new sentence replacing last two -- from meeting) ========================

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 "each Web page" with "the electronic document or software".

Where software platforms provide a "local language" setting, applications that follow that setting would comply with this success criterion. Applications that do not follow the platform "local language setting" but instead use an assistive technology supported method for exposing the human language of the software user interface would also comply with this success criterion. Applications implemented in technologies where Assistive technologies cannot determine the human language and that do not support the platform "local language setting" may not be able to meet this success criterion. 



DISCUSSION POINTS, OPINIONS, ISSUES, NOTES etc. 

---- Proposal explanation -----

Proposal #2 (Loïc Martínez)

  • Documents. I have started with the TRACE proposal, but have changed it to separate the three possibilities (explicit mechanism in the document format, implicit automatic identification of the human language and coding of the language in the file name). Then I have added a last paragraph to refer to an issue that we discussed in the M376 team: some documents may use different languages for output and input purposes and both languages should be programmatically determinable.
  • Software. I believe that this SC should apply to the software entity as a whole and not to individual interaction contexts. So the first paragraph suggests to reinterpret "web page" as "software product". In addition, I have added a second paragraph with text coming from the M376 proposal in which we explain that in many cases the language of the software product is the same language as the underlying platform and thus no specific action is required from developers. Another possibility would be to explain the variants of "programmatically determinable language" for software in a similar way to the explanation for content and documents.


---- 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.  Must this be done for each window?  Or just at the app level?  What does “page” mean?

Comment on Issue1: See contribution language.



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

For Software
In most cases, applications use the human language (locale) as defined in the platform software. In those situations the human language is programmatically determinable with no need of specific action by the developers.



 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 may not have this capability.

For Software


Where ICT provides its own speech output: 5.1.4.7 “Spoken languages” addresses the same needs


2010 ANPRM Text (22 March 2010)
506 Readability
506.1 General.  Text content shall conform to 506.
506.2 Language of Document.  The default human language of each document shall be programmatically determinable.


Teitac Report (3 April 2008)
3-G: Human Language
When supported in the technologies of electronic documents, the default human language of electronic document must be PROGRAMMATICALLY DETERMINABLE.
Note:  In order to achieve this provision, text encoded in data operated on by the software would need to be associated with sufficient information to identify both the primary language of the text, and the language of any sections or the text that are in another language from the primary language, that the software can obtain as readily as it can obtain the text itself.

Comments