- From: Loretta Guarino Reid <lguarino@adobe.com>
- Date: Fri, 20 Oct 2006 17:07:34 -0700
- To: <public-wcag-teamb@w3.org>, <public-wcag-teamc@w3.org>, <public-wcag-teama@w3.org>
- Message-ID: <EDC8DDD212FEB34C884CBB0EE8EC2D910282E9D5@namailgen.corp.adobe.com>
“Level-change” Sort Item
SC Current Level Requested level
1.2.1 1 2
1.2.2 1 2
1.2.5 3 2
1.2.7 3 1
1.3.4 2 1
1.3.5 2 1, 2
1.4.1 2 1
1.4.2 2 1
1.4.3 3 2
1.4.4 3 2
2.2.5 3 1, 2
2.2.6 3 2
2.3.2 3 2
2.4.3 2 1
2.4.4 2 1
2.4.5 3 1, 2
2.4.6 3 1, 2
2.4.7 3 1
2.4.8 3 1, 2
2.5.3 2 3
2.5.4 3 1
3.1.1 1 3
3.1.2 2 1, 3
3.1.3 3 2
3.1.4 3 1
3.1.5 3 2
3.2.5 3 1
4.2.4 3 2
****************************************************************************
Comment LC-1026
Sort Terms: conformance
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location: <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
Conformance schema - The documents say that all success criteria are essential to people with disabilities (see WCAG 2.0 under 'Conformance' - "The WCAG WG believes that all SC ..."), however by using the WCAG1 labelling system this change is not obvious. In addition to this, the Conformance section specifically states a hierarchical nature to the to the SC in WCAG2 by defining Level 1 as "achiev(ing) a minimum level of accessibility", Level 2 as "achiev(ing) an enhanced level of accessibility" and Level 3 as "achiev(ing) additional accessibility enhancements". The Conformance section is contradictory, because in the subsequent paragraph it says "Each checkpoint in WCAG 1.0 was assigned a "priority" according to its impact on accessibility... the system of checkpoints and priorities used in WCAG 1 has been replaced...". By using the subjective terms Priority 1 / A in WCAG2, the WG is implying that there is a hierarchical nature to the SC. People are used to the WCAG1 labelling system and will assume that by following all Level A SC that they are creating an accessible web site.
Proposed Change:
Merge Level 1 and Level 2 SC into one group called "Mandatory". Rename Level 3 to "Advisory" or "Optional"
Status: open
Comment LC-1280
Sort Terms: LEVEL-CHANGE
Document: WCAG 2.0 Guidelines
Submitter: Andrew Arch <andrew.arch@visionaustralia.org> Affiliation: Vision Australia
Comment Type: substantive
Location: <http://www.w3.org/TR/WCAG20/complete.html> (Guidelines)
Comment:
Comment: Many SC seem out of place at their specified levels. It seems many SC Levels have not been reconsidered since the November 2005 release whe the levels related to 'coding', 'design/appearance' and 'additional'. As this is no longer the basis for the Levels, then the SC need to be more closely re-examined as to the appropriate level they should fall under.
Proposed Change:
re-examine all SC in the light of the April 2006 Conformance Level definitions (cf Nov 2005 Levels definitions)
Status: open
Comment LC-1283
Sort Terms: LEVEL-CHANGE CAPTIONS and AUDIO DESCRIPTION
Document: WCAG 2.0 Guidelines
Submitter: Andrew Arch <andrew.arch@visionaustralia.org> Affiliation: Vision Australia
Comment Type: substantive
Location: <http://www.w3.org/TR/WCAG20/complete.html> (Levels)
Comment:
Comment: It is too easy to fail SC at Level 1 - most organisations I have worked with will not go to this length in most cases, hence will never be able to claim even "A" conformance. In fact, on most Government and corporate sites I have worked with, the provision of a transcript and/or a script gives all the information needed to substitute for the multimedia
Proposed Change:
Level 1 should have SC along the lines of "provide a transcript if spoken words only and no action" and "provide a script including the dialogue if video wit activity"
SC 1.2.1 & 1.2.2 should be moved up a level, and all other SC reconsidered as to the appropriate level.
Status: open
Working Group Notes: [TEAMA] [HOLD] [On hold, levels, CAPTIONS and AUDIO DESCRIPTION]
Discussed in the 10 August 2006 telecon:
resolution: send 1283 back to team A to addreess comments
http://www.w3.org/WAI/GL/2006/08/10-wai-wcag-minutes.htm
10 August survey results:
http://www.w3.org/2002/09/wbs/35422/20060810teama/results#x1283 <http://www.w3.org/2002/09/wbs/35422/20060810teama/results>
Resolution Working Notes - Unapproved:
{Reject.} Response: “Greetings Andrew. It may be the case that you are underestimating the value of captioned video as compared to a transcript. If a transcript script gives all the information needed to substitute for the multimedia for someone who is Deaf, then it should be sufficient for your wider audience, and posting the multimedia is not necessary at all. If the multimedia is important enough to be posted in addition to the transcript, then the multimedia is almost certainly important enough to be captioned.”
Comment LC-1332
Sort Terms: LEVEL-CHANGE CAPTIONING AGGREGATED
Document: WCAG 2.0 Guidelines
Submitter: Arun Ranganathan <arunranga@aol.com> Affiliation: Advisory Committee Representative to the W3C for AOL LLC
Comment Type: general comment
Location: media-equiv <http://www.w3.org/TR/WCAG20/complete.html> (Guideline 1.2 Provide synchronized)
Comment:
Comment (Including rationale for any proposed change):
The purpose of the following LC Comment is to highlight issues that we believe warrant further consideration by the Web Content Accessibility working group before assigning a Level 1 requirement to Guideline 1.2.1: "captions are provided for prerecorded multimedia," particularly as the WAI's Web Content Accessibility guidelines are used as the benchmark for web accessibility by government and other policy-making bodies.
AOL LLC fully understands and supports the need for captioned multimedia, and we do provide the same on several of our highly trafficked areas. AOL was the first commercial Internet Service Provider to offer captioned video. Today, we provide captions for two cartoon series "Princess Natasha" and "SKWOD" on KOL, AOL's online channel for kids ages 6-12, and on video help tutorials developed for the AOL 9.0 software. Additionally, we are currently testing delivery of captioned news and entertainment content through our video portal. We continue to work hard at this area, and plan on announcing further such developments as they take place.
Technologies such as SMIL, Microsoft's SAMI and Apple’s QuickTime all enable display of closed captions on multimedia, and tools like Caption Keeper from the WGBH Media Access Group can be used to repurpose Line 21 television caption data. However, AOL's research to date shows that the acquisition process and production model for the majority of video content distributed by commercial Internet portals such as AOL LLC does not support cost-effective and efficient processes for delivery of closed captions in a timely manner. A collaborative effort between the Internet industry, content producers and web accessibility experts is required to develop solutions before commercial web portals can fully conform to this Level 1 requirement to caption prerecorded multimedia. Guideline 1.2.1 assumes that the web site displaying the multimedia content is the producer of the content. What is not considered is the barriers created by the process of acquiring repurposed third party content, or who is responsible for captioning content produced by a third party and distributed via multiple web sites/services. While AOL LLC has made substantial progress towards captioning of our video content, there are three barriers inhibiting AOL LLC's goal of complete conformance to a Level 1 success criteria:
i. Internet production units of broadcast networks prepare the content for streaming before the content is captioned, usually in real time. For example, field packages produced for TV networks' nightly newscasts are often streamed before they air. As a result, Internet portals receive the video asset too far up stream in the content production workflow. This presents two possible scenarios:
- A content aggregator (Internet portal such as AOL's) needs to manually caption a video stream produced and owned by a separate content provider. Neither is this scalable, nor are vendor solutions robust enough at this point (e.g leveraging a programmed transcript which only provides the text of the audio, and excludes ambient sounds and time stamp data).
- Captions are added to the streaming video long after it has been published to the web site assuming the portal and partner repurpose the captions originally created during the TV broadcast. This is problematic as some videos have a very short shelf life.
ii. Lack of information on the whereabouts of existing caption files when broadcast content is repurposed for the Internet. There is an increasing amount of "video on demand" products online that allow people to view archives of current or old TV series, movies, music videos, short films, etc. It is very likely that most of the content has been captioned. Unfortunately there isn't a central database that Internet portals or content partners can search to locate the caption agency who captioned a particular season of a show. It is important to note that the content provider to the portal may not always be the content producer or the entity responsible for captioning the content for television.
iii. Need for a common delivery protocol. Commercial Internet portals receive video from many of the same content providers (broadcast networks, etc.). Internet production units are generally very small in terms of staff so delivering multiple text formats to multiple portals is not feasible. Solutions are required to ensure content providers can deliver caption data in an efficient, cost-effective manner. This is a solvable problem, but identifying solutions will require cooperation from many players.
AOL LLC proposes changing the Level 1 Success Criteria for Guideline 1.2, namely 1.2.1 and 1.2.2, to Level 2 Success Criteria. This change reflects the ground realities of being a content aggregator on the Web. This proposal is necessitated by the current reality that content aggregators on the Web partner with multiple content providers. Issues such as who is responsible for producing captions, delivery of caption text files and other barriers described above must be addressed before policy-making bodies can effectively leverage this guideline. Alternatively, we recommend adding language which recognizes the current barriers to wide scale availability of captions for prerecorded multimedia, and encourages development of solutions to resolve them.
Status: open
Working Group Notes: [TEAMA] [HOLD]
Comment LC-853
Sort Terms: Audio-Description -- Level-Change
Document: WCAG 2.0 Guidelines
Submitter: Tomoaki Kodaka <koda@pk9.so-net.ne.jp> Affiliation: NTT CLARUTY CORPORATION
Comment Type: general comment
Location: media-equiv <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):
The degree of the spread of audio description is different country to country.
I doubt that our situation in audio description is Level1 slightly, because the word “audio description” itself is not penetrated in my country. In Japan some volunteer groups add audio description to movies.
But it is not spread at the movie theater. It is desirable that all Web image content has audio description. But we don’t know what audio description is and how to produce it-this is our present situation. So I feel fear that image content is left out of the Web units intentionally, by we are detected Level1.It is sure that people who lost the sense of sight can’t get any information which is appeared by only animations. Images lacking in text alternatives don’t have information at all, while multimedia lacking in audio description has much information―lines, sounds and so on. When we hear the sound of train, we can guess the place is a station. We can understand people are angry or laughing by their tone.
It is fact that many blind men enjoy listening TV. Lacking in audio description is not a situation in which there is no information. But producing audio description takes time and money.Level1 is an obstacle for us. So I feel fear that image content is left out of the Scoping of conformance claims.
Proposed Change:
I hope that audio description is prescribed from Level2 and aimed at LevelAA as a following aim.
It will surely improve accessibility of image contents. I think.
Status: Resolved (resolved_no).
Working Group Notes: [TEAMA]
TOMOAKI'S RESPONSE TO MY EMAIL BELOW FOR CLARIFICATION
Hi Gregg
Thank you for your mail.
I’m sorry .I sent a reply too late.
- In Japan audio description is not spread at all.
So if you demand to meet 1.2.2(level1), many people who create Web content wi
ll be trouble.
I want to delete 1.2.2 from a prerequisite.
Thank you very much.
Sincerely,
Tomoaki
Gregg Vanderheiden wrote:
> Hi Tomoaki
> Can you clarify your proposed change?
> It is not clear what you are suggesting when you say:
> " I hope that audio description is prescribed from Level2 and aimed at LevelAA as a following aim. "
> We are not sure what you mean by "prescribed from level 2" and "aimed at level AA".
> - currently audio description is one way of meeting 1.2.2 (level 1)
> - it is required on level 2 in 1.2.3
> - it is therefore not required for conformance at Level A (though a text description of multimedia would be if it were not provided)
> - it is required for conformance at Level A
> Are you supporting this? Or are you suggesting a change? What change are you suggesting?
> Thank you very much.
> Sincerely,
> Gregg
> Co-chair
Discussed in the 10 August 2006 telecon:
accepted by unanimous consent
http://www.w3.org/WAI/GL/2006/08/10-wai-wcag-minutes.htm
Resolution - Pending Response:
[reject]
Audio description is not required at level 1. Either a "full text alternative for multimedia including any interaction" *or* an audio description is sufficent. We require Audio Description at Level 2. We could not leave out Audio Description from the guidelines because they are necessary for blind people.
There are two general techniques for making multimedia accessible to the blind: Audio Description (AD) and "full text alternative for multimedia including any interaction". Either technique is acceptable for Level 1 WCAG 2.0 conformance. Audio Description is required for Level 2. Both techniques are required for Level 3. This is a case where higher-level SC build upon the requirements of lower-level SC with the intention of having cumulative, progressively stronger, requirements.
Audio Descriptions were required at Priority 1 in the WCAG 1.0 which has been a standard since 1999 and was accepted by Keio in Japan. However, in the WCAG 2.0 we have allowed the option for "full text alternative for multimedia including any interaction" at level 1.
Comment LC-886
Sort Terms: Level-Change
Document: WCAG 2.0 Guidelines
Submitter: Monica Løland, The Danish Council of Organisations of Disabled People (DSI) <mol@handicap.dk> Affiliation: The Danish Council of Organisations of Disabled People (DSI)
Comment Type: substantive
Location: media-equiv-sign <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):
For deaf web users, there are two basic demands to be met to achieve full accessibility.
- Sign Language is the native language for the deaf, the first language on which thinking and communication is based. Danish is a foreign language learnt by reading and writing. Therefore information provided in sign language will always be preferable to information provided in Danish text. (A new survey states that half of the deaf population has no School leaving exams in Danish, since they were not able to meet the language demands. Døves uddannelses- og arbejdsmarkedsforhold. Castberggaard 2006)
- all information provided by sound, should also be provided visually.
Sign language interpretation is mentioned in Level 3 Success Criteria for Guideline 1.2. in the WCAG 2.0 Guidelines. This placing does not ensure full accessibility to the deaf community, since EU documents only have to meet the demands on Level 2.
Proposed Change:
Broadband Network (ADSL) gives new opportunities to send multimedia, and the guidelines should therefore see that these new opportunities is utilized to achieve full accessibility. Sign language interpretation should at least be a Level 2 Success Criteria.
Status: open
Working Group Notes: [TEAMA] [BB] [HOLD]
Resolution Working Notes - Unapproved:
{Reject} Response:
Thank your for comment Monica. The working group considered carefully the Levels assigned to all the 1.2 success criteria. Delivery of sign language interpretation is more specialized, and difficult as compared to text captioning. Even with proper tools, a web author cannot do this without special training and skills. Also some multimedia is fully useable at small size and marginal bandwidth setting and captions only marginally increase the demands. By comparison, sign language interpretation requires a relative large size, high resolution, and fast delivery rate. These aspects of sign language interpretation means that the technology cannot necessarily be applied to all Web content and makes the SC appropriate for Level 3.
Comment LC-892
Sort Terms: LEVEL-CHANGE
Document: WCAG 2.0 Guidelines
Submitter: Emmanuelle Gutiérrez y Restrepo <coordina@sidar.org> Affiliation: Sidar Foundation
Comment Type: general comment
Location: media-equiv-sign <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):
The National Confederation of Deaf Persons of Spain (CNSE)have requested to us that we support to obtain an improvement in the accessibility for the deaf people.
Being conscious of the differences between the languages of signs worldwide and the lack of equivalence with the languages spoken in each country, we considered that some reasonable advances by means of the following changes could be included.
Proposed Change:
Include the 1.2.5 in the Level 2 Success Criteria for Guideline 1.2
Status: open
Comment LC-1077
Sort Terms: LEVEL-CHANGE
Document: Understanding WCAG 2.0
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: substantive
Location: media-equiv-text-doc <http://www.w3.org/TR/UNDERSTANDING-WCAG20/>
Comment:
Transcripts: Why isn't this at Level 1? Shouldn't the equivalent information be provided at Level 1?
Proposed Change:
SC 1.2.7: Move to Level 1
Status: open
Comment LC-640
Sort Terms: level-change
Document: WCAG 2.0 Guidelines
Submitter: Lisa Seeman <lisa@ubaccess.com> Affiliation: Invited expert at W3C, UB access
Comment Type: substantive
Location: content-structure-separation-understanding <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
Comment (including rationale for proposed change):
this needs to be at level one because many sites are completely inoperable because of failure
Proposed Change:
move to level 1
Status: open
Working Group Notes: [TEAMC] [HOLD]
Original proposal: This was originally at Level 1 but was moved to Level 2 because of the principle that Level 1 should not affect design. See minutes of 19 January 2006 meeting <http://www.w3.org/WAI/GL/2006/01/19-wai-wcag-minutes.html#item10> <http://www.w3.org/WAI/GL/2006/01/19-wai-wcag-minutes.html> ;.
Response from Gregg: The rationale for this no longer applies since we have some Level 1 items that do change appearance. It is a strong guideline but not a barrier.
The minutes dont say it was at level 1. I actually believe it was at Level 3. We moved it to level 2 and said that we would consider moving it to level 1 after techniques are done. So it wasnt moved down from Level 1 as described in rationale.
Finally - it is not clear that you would have to change appearance to satisfy the SC. Couldnt you refer to the item using its name and put the name in Alt to title where it could be read by AT of anyone who cannot see the screen?
For Reference, the Minutes say:
Priority level of SC 1.3.5
resolution: ... move SC 1.3.5, "When content is arranged in a sequence that affects its meaning, that sequence can be programmatically determined" to level 2. When techniques are more complete, we will revisit the question of moving this to level 1.
Comment LC-1234
Sort Terms: level-change
Document: WCAG 2.0 Guidelines
Submitter: Kiyochika Nakamura <nakamura-kiyochika@mitsue.co.jp> Affiliation: Mitsue-Links Co., Ltd.
Comment Type: substantive
Location: <http://www.w3.org/TR/WCAG20/complete.html> (Level 2 Success Criteria for Guideline 1.3)
Comment:
Comment: This success criterion should be Level 1 because if it isn't satisfied, information could not be conveyed, at least for screen reader users. In the conformance section, a minimum level of accessibility is defined as a level 1 success criteria. Without this criterion, some important information might be conveyed to some users. So, I believe it is essential to achieve a minimum level of accessibility.
Proposed Change:
Move this success criterion to level 1.
Status: open
Working Group Notes: [TEAMC] [HOLD]
Which one? There are two Level 2 success criteria for 1.3. One on presentation effects and one on color.
Comment LC-1083
Sort Terms: level-change color/variations/programmatically
Document: Understanding WCAG 2.0
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location: content-structure-separation-understanding <http://www.w3.org/TR/UNDERSTANDING-WCAG20/>
Comment:
Move to Level 1: From what I understand, this is the equivalent of making sure information is not provided via colour alone, so why is it at Level 2?
Proposed Change:
Move 1.3.5 to Level 1
Status: open
Comment LC-873
Sort Terms: Level-Change CONTRAST
Document: WCAG 2.0 Guidelines
Submitter: Chris Ridpath <chris.ridpath@utoronto.ca> Affiliation: ATRC University of Toronto
Comment Type: substantive
Location: visual-audio-contrast <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):
There needs to be a SC for color contrast at level 1. Documents with very poor contrast between text and background do not provide even a minimum level of accesibility.
The guideline text starts with \"Make it easy...\" which means the user should not have to work to get color contrast. Highlighting text within the document to change the contrast is not easy for many people with disabilities and should not be taken as a method of meeting the SC.
This has been discussed recently on the WCAG list but there was no resolution so I\'m submitting this comment.
Proposed Change:
Create a SC for color contrast at level 1. The luminosity ratio should be similar to SC 1.4.1 - what is currently at level 2 (5:1).
Status: open
Comment LC-1085
Sort Terms: LEVEL-CHANGE
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location: visual-audio-contrast <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
Level 1: There should be Level 1 equivalents of 1.4.1 and 1.4.2.
Proposed Change:
Create new SC or move 1.4.1 and 1.4.2 to Level 1
Status: open
Comment LC-1237
Sort Terms: LEVEL-CHANGE
Document: WCAG 2.0 Guidelines
Submitter: Kiyochika Nakamura <nakamura-kiyochika@mitsue.co.jp> Affiliation: Mitsue-Links Co., Ltd.
Comment Type: substantive
Location: visual-audio-contrast-dis-audio <http://www.w3.org/TR/WCAG20/complete.html> (Level 2 Success Criteria for Guideline 1.4)
Comment:
Comment: This success criterion should be Level 1 because, for example, if it isn't satisfied and background audio interferes screen readers, information could not be conveyed. Also, even if a mechanism to turn off background audio is provided, some users could not find the mechanism because of its background audio, so it would be better that the success criterion itself was reconsidered.
Proposed Change:
Move this success criterion 1.4.2 to level 1. And possibly restates the criterion such that "do not play background audio without user request.
Status: open
Comment LC-1286
Sort Terms: LEVEL-CHANGE
Document: WCAG 2.0 Guidelines
Submitter: Andrew Arch <andrew.arch@visionaustralia.org> Affiliation: Vision Australia
Comment Type: question
Location: visual-audio-contrast <http://www.w3.org/TR/WCAG20/complete.html> (SC Levels)
Comment:
Comment: Under the new Conformance level definitions, I strongly suggest that 1.4.1 & 1.4.2 should be Level 1 and that 1.4.3 & 1.4.4 should be Level 2
Proposed Change:
reconsider the Levels the SC fall under - move them up a level
Status: open
Comment LC-1048
Sort Terms: level-change
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: substantive
Location: time-limits-postponed <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
2.2.5: This should be L1 or there should be a L1 equivalent.
Proposed Change:
For example, it should not be possible to update a page every ten seconds under L1 otherwise people using screen readers won't be able to access all the content before the page refreshes.
Status: open
Working Group Notes: [TEAMC] [HOLD]
ALS: LC-1288 also requests changing the level of 2.2.5. These should be resolved together. I think we discussed this and decided that this is not needed because it is a user agent responsibility to provide a mechanism for users to turn off page refreshes? It would be helpful to chase down the meeting minutes or mailing list discussions we had on this.
Related Issues:
1288 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1288> Comment LC-1049
Comment LC-1096
Sort Terms: level-change
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location: time-limits-server-timeout <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
2.2.6: This should be at Level 2. If someone is using an authenticated session and cannot complete the information before automatic logoff, then being able to continue after re-login is imperative in order to use the system. Otherwise the system is inaccessible
Proposed Change:
Move 2.2.6 to Level 1
Status: Resolved (resolved_no).
Working Group Notes: [TEAMC] [HOLD]
ALS: Agree that this is an issue. But Level 2 SC are things we believe can be applied to all websites. There are valid security reasons, however, where this cannot be done. I believe this is the reason the working group decided to put this at Level 3.
Discussed in the 28 September 2006 telecon:
Resolution: Accept LC-1096 as amended
http://www.w3.org/WAI/GL/2006/09/28-wai-wcag-minutes.html
Resolution - Pending Response:
{reject}
The working group has discussed this issue. The criteria for having something at Level 2 is that it must be something that can reasonably be applied to all Web content. But there are valid reasons, such as financial security or personal information where this cannot be done because it is against regulations to preserve any of this information once a session expires or is terminated. The working group therefore decided to put this requirement at Level 3.
Comment LC-1288
Sort Terms: level-change
Document: WCAG 2.0 Guidelines
Submitter: Andrew Arch <andrew.arch@visionaustralia.org> Affiliation: Vision Australia
Comment Type: substantive
Location: time-limits-postponed <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
Comment: This should be a level 2 SC - for many people with reading difficulties, or using AT, reading a page is a time consuming exersize, and page refreshes may not allow them to read to the end.
Proposed Change:
move this SC 2.2.5 up a level & consider strengthening it WRT content refreshing automatically
Status: open
Working Group Notes: [TEAMC] [HOLD]
ALS: LC-1048 also requests a level change for SC 2.2.5. These two should be resolved together. I think we discussed this and decided that this is not needed because it is a user agent responsibility to provide a mechanism for users to turn off page refreshes? It would be helpful to chase down the meeting minutes or mailing list discussions we had on this.
Sort Terms: LEVEL-CHANGE - 2.3.2 Make L2 LEVELS 2.3*
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: substantive
Location: seizure-three-times <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
2.3.2: This should be L2 or there should be a L2 equivalent
Proposed Change:
Create L2 equivalent
Status: open
Comment LC-1289
Sort Terms: descriptive-titles level-change
Document: WCAG 2.0 Guidelines
Submitter: Andrew Arch <andrew.arch@visionaustralia.org> Affiliation: Vision Australia
Comment Type: substantive
Location: navigation-mechanisms <http://www.w3.org/TR/WCAG20/complete.html> (Levels)
Comment:
Comment: Under the new Conformance level definitions, I strongly suggest that 2.4.3 should be a Level 1 SC & that 2.4.5 should be a Level 2 SC
Proposed Change:
adjust the levels of 2.4.3 & 2.4.5
Status: open
Working Group Notes: [TEAMB][HOLD]
@@ MU: I can also agree with this comment. But "titles" should be merged into the one SC.
Related Issues:
625 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=625>
626 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=626>
838 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=838>
839 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=839>
1052 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1052>
1141 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1141>
1291 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1291>
Comment LC-872
Sort Terms: link-text level-change
Document: WCAG 2.0 Guidelines
Submitter: Chris Ridpath <chris.ridpath@utoronto.ca> Affiliation: ATRC University of Toronto
Comment Type: substantive
Location: navigation-mechanisms-refs <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):
Success Criterion 2.4.4 should be at level 1 and is currently at level 2. Good link text is very important for people with visual impairments as well as people with cognitive impairments. Poor link text was identified as a key problem in the DRC report (http://www.drc-gb.org/PDF/2.pdf). Good link text is at least as important as skip-navigation links which is at level 1.
Proposed Change:
Move SC 2.4.4 to level 1.
Status: open
Comment LC-712
Sort Terms: link-text level-change
Document: WCAG 2.0 Guidelines
Submitter: Jaakko Vilen <jaakko.vilen@nordea.com>
Comment Type: substantive
Location: navigation-mechanisms-descriptive <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
I am doing a thesis study on electronic banking accessibility, and have found that the link texts should be clearly descriptive alone. The links are practically the most important element of most pages, and this criterion should therefore be given priority level 1. In electronic banking applications the same applies especially to (submit) buttons.
Proposed Change:
The Success Criterion 2.4.5 should have priority level 1.
Status: open
Working Group Notes: [TEAMB] [HOLD] It is covered by 2.4.8, which is Level 3.
(This isn't covered by 2.4.4 (since context may be required to interpret the link text for 2.4.4))
Comment LC-838
Sort Terms: level-change descriptive-titles
Document: WCAG 2.0 Guidelines
Submitter: Jon Gunderson <jongund@uiuc.edu> Affiliation: UIUC
Comment Type: substantive
Location: navigation-mechanisms-title <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):
I recommend this requirement be moved to SC1. If descriptions of an image are SC1, then are not descriptions or titles of a web page of equal importance? This should be merged with requirements of 2.4.5 and that descriptions/titles should be \"unique\" for collections of a web resources as part of the success criteria.
See UIUC Web Accessibility Best Practices:
http://html.cita.uiuc.edu/nav/title.php
Proposed Change:
I recommend this requirement be moved to SC1 and merged with the requirements of 2.4.5.
Status: open
Working Group Notes: [TEAMB] [HOLD]
@@ MU: See my comment on 625 and 626.
I'd like to know the reason why these SC(2.4.3 and 2.4.5) are divided into 2 SC and why these are L2 and L3, not L1.
JIS requires the descriptive and unique title as L1(Required).
# JIS has 2 levels of guidelines, "Required" and "Optional".
Resolution Working Notes - Unapproved:
SEE ACTIONS FOR LC-625
@@Part of response to commenter:
The success criterion does not require that titles be unique because the working group is concerned that requiring uniqueness will lead to titles that are not as descriptive and usable. It may be very difficult to create titles that are descriptive, unique, and reasonably short. For example, a Web unit that generates titles dynamically based on its content might need to include part of the dynamic content in the title to ensure that it was unique. We are also concerned that authors may make titles unique mechanically, such as by including a unique number in the title that is unrelated to the content. For these reasons, although we encourage unique titles in the techniques for this SC, we are not including uniqueness in the SC itself.
Related Issues:
625 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=625>
626 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=626>
839 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=839>
Comment LC-1052
Sort Terms: level-change descriptive-titles
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location: navigation-mechanisms-descriptive <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
2.4.5: This should be at Level 1. Descriptions, headings, labels etc are very important for both people who use screen readers and people with cognitive disabilities. Equivalent checkpoints in WCAG 1.0 are at Level AA
Proposed Change:
Move to Level 1
Status: open
Working Group Notes: [TEAMB][HOLD]
@@ MU: I can agree with this comment. Titles, headings, and labels should be descriptive so that the users could understand and navigate the web content. 2.4.5 should not be L3 at least. What do you think??
Resolution Working Notes - Unapproved:
Related Issues:
625 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=625>
626 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=626>
838 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=838>
839 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=839> Comment LC-625
Sort Terms: descriptive-titles level-change Set-of web-units
Document: WCAG 2.0 Guidelines
Submitter: Lisa Seeman <lisa@ubaccess.com> Affiliation: Invited expert at W3C, UB access
Comment Type: substantive
Location: navigation-mechanisms-title <http://www.w3.org/TR/WCAG20/complete.html> (Level 2 Success Criteria for Guideline 2.4)
Comment:
Comment (including rationale for proposed change):
Web units have titles, what is the advantage if the titles are not descriptive?
Proposed Change:
change to Web units have descriptive titles
Status: Resolved (resolved_yes).
Response Status: Resolution implemented
Working Group Notes: [TEAMB]
@@ MU: I agree with this comment. 2.4.3 requires just the page title and 2.4.5 requires the descriptive page title. Why don't we require the descriptive page title at L2 SC(2.4.3)? In my opinion, the non-descriptive page title means nothing. Additionally I'd like to put the descriptive page title to L1 SC. See also LC-626.
LGR: Background: the June 2005 WCAG2 draft had "Delivery units have descriptive titles". This was changed as a result of the 13 October 2005 Team B Survey, http://www.w3.org/2002/09/wbs/35422/20051012teamb/results#xdestitle <http://www.w3.org/2002/09/wbs/35422/20051012teamb/results> which was primarily focused on issues of what to say about document structure and making headings descriptive.
Discussed in the 24 August 2006 telecon:
Resolution: Team B Take back LC-625, LC-626: descriptive titles (look at G88)
http://www.w3.org/WAI/GL/2006/08/24-wai-wcag-minutes.htm
LGR: are there security issues with exposing sensitive personal information in Web unit titles?
Discussed in the 31 August 2006 telecon:
resolution: accept LC-625, LC-626, LC-1105, LC-1141, LC-1291: Descriptive titles as amended
action: Loretta to add language to the appropriate responses that explains why we are not adding "unique"
http://www.w3.org/WAI/GL/2006/08/31-wai-wcag-minutes.html
{accept}
DONE Change SC 2.4.3 to "Web units have descriptive titles."
DONE In the first sentence of the Intent section of SC 2.4.3, change "title" to "descriptive title".
DONE Delete technique G7: Associating a title with a Web page
DONE Remove from advisory techniques for SC 2.4.3: G88: Providing descriptive titles for Web units
DONE Change sufficient technique for Addressing Success Criterion 2.4.3 to "G88: Providing descriptive titles for Web units and associating a title with a Web unit USING a technology-specific technique below (for a technology in your baseline)
DONE Remove from SC 2.4.3 Examples:
#An audio file.
A podcast is associated with the title "Today's Tech Tips" by setting the id3 property of the .mp3 file.
#A video clip.
A video clip is associated with a title using the meta element in SMIL 1.0 or SMIL 2.0, plus the title attribute of the main par element in the SMIL file.
#An image.
A .JPEG image is associated with a title using EXIF metadata stored in the image file. (Note: Current user agents do not read this metadata.)
DONE Add example to How to Meet SC 2.4.3:
*A web application.
A banking application lets a user inspect his bank accounts, view past statements, and perform transactions. The web application dynamically generates titles for each Web unit, e.g., "Bank XYZ, accounts for John Smith" "Bank XYZ, December 2005 statement for Account 1234-5678".
DONE Change SC 2.4.5 to "Headings and labels are descriptive."
DONE Change SC 2.4.5 Intent section from "When titles and headings are clear and descriptive" to "When headings are clear and descriptive"
DONE Remove G88: Providing descriptive titles for Web units from sufficient techniques for SC 2.4.5
DONE Change Note on SC 2.4.5 to "Note: Headings and labels must be programmatically determined, per success criterion 1.3.1."
DONE Change Benefits of SC 2.4.5 to
"Descriptive headings and labels are especially helpful for users who have disabilities that make reading slow and for people with limited short-term memory. These people benefit when section headings make it possible to predict what each section contains.
This success criterion helps people who use screen readers by ensuring that labels and headings are meaningful when read out of context, for example, in a Table of Contents, or when jumping from heading to heading within a page.
This success criterion may also help users with low vision who can see only a few words at a time."
DONE Remove from SC 2.4.5:
Technology-Specific Techniques
HTML Techniques
* H64: Using the title attribute of the frame element
DONE Move the following resources from SC 2.4.5 to SC 2.4.3:
#Guidelines for Accessible and Usable Web Sites: Observing Users Who Work With Screen Readers. Theofanos, M.F., and Redish, J. (2003). Interactions, Volume X, Issue 6, November-December 2003, pages 38-51, http://doi.acm.org/10.1145/947226.947227.
#Writing Better Web Page Titles How to write titles for Web pages that will enhance search engine effectiveness.
Internal WD updated 1 September 2006.
Resolution - Pending Response:
We have changed SC 2.4.3 to "Web units have descriptive titles" and have also reflected this change in success criterion 2.4.5 and support documents for both success criteria.
Related Issues:
626 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=626>
838 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=838>
839 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=839>
1052 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1052>
1141 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1141>
1289 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1289>
1291 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1291>
Comment LC-1141
Sort Terms: descriptive-titles level-change
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location: navigation-mechanisms-title <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
SC: Change the SC to "Web units have descriptive titles". There is no point having random titles for pages -they should indicate the content
Proposed Change:
Rewrite the SC
Status: Resolved (resolved_yes).
Response Status: Resolution implemented
Working Group Notes: [TEAMB]
@@ MU: See the "Related issues".
Discussed in the 31 August 2006 telecon:
resolution: accept LC-625, LC-626, LC-1105, LC-1141, LC-1291: Descriptive titles as amended
action: Loretta to add language to the appropriate responses that explains why we are not adding "unique"
http://www.w3.org/WAI/GL/2006/08/31-wai-wcag-minutes.html
{accept}
SEE ACTIONS FOR LC-625
@@Response to commenter
Resolution - Pending Response:
We have changed SC 2.4.3 to "Web units have descriptive titles" and have also reflected this change in success criterion 2.4.5 and support documents for both success criteria.
Related Issues:
625 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=625>
626 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=626>
838 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=838>
839 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=839>
1052 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1052>
1289 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1289>
Comment LC-628
Sort Terms: level-change
Document: WCAG 2.0 Guidelines
Submitter: Lisa Seeman <lisa@ubaccess.com> Affiliation: Invited expert at W3C, UB access
Comment Type: substantive
Location: navigation-mechanisms-focus <http://www.w3.org/TR/WCAG20/complete.html> (Level 3 Success Criteria for Guideline 2.4)
Comment:
Comment (including rationale for any proposed change):
2.4.6 When a Web unit or authored component is navigated sequentially, components receive focus in an order that follows relationships and sequences in the content. [How to meet 2.4.6]
this should be level 1 as it often completely brakes the user interface
Proposed Change:
move SC 2.4.6 to level 1
Status: open
Comment LC-942
Sort Terms: level-change
Document: WCAG 2.0 Guidelines
Submitter: M.F. Laughton <adio@crc.ca> Affiliation: Government of Canada
Comment Type: substantive
Location: navigation-mechanisms-focus <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
When a Web unit or authored component is navigated sequentially, components receive focus in an order that follows relationships and sequences in the content. In our experience, failure to meet this criterion renders many "accessible" pages "unusable" in any practical sense.
Proposed Change:
SC 2.4.6 Should be a level 2 criteria
Status: open
Comment LC-473
Sort Terms: level-change link-text
Document: WCAG 2.0 Guidelines
Submitter: Roger Hudson <rhudson@usability.com.au>
Comment Type: substantive
Location: <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
Item Number: Success Criterion 2.4.4
Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):
Although the wording of SC 2.4.4 is convoluted, it is presumably a replacement for WCAG 1.0, Checkpoint 13.1 "Clearly identify the target of each link [Priority 2]". However 13.1 also required the link text to meaningful enough to make sense when read out of context, either on their own or as a sequence of links, and this does not appear to be the case with SC 2.4.4.
In my experience, many screen reader users extensively use the screen-reader facility that enables them to obtain a list of links on a page. This is often the preferred technique when looking for information on a site or undertaking a task, and in virtually all situations it is only effective when the link text indicates the link destination. While I believe it is possible with some screen readers to select an option that provides context from the surrounding text I have never seen this done. However, many times I have seen screen reader users become frustrated with links that contain only the words "more", "next" or "click here".
I believe it is very important for link text to provide a clear indication of the link destination. Also, the link text should make sense without the need to rely on surrounding contextual information or a title attribute within the link element.
Proposed Change:
I believe 2.4.4 should remain a level 2 SC, but should be rewritten to read, "The target or destination of each link should be clearly indicated by the link text."
Status: open
Working Group Notes: [TEAMB] [SM] [HOLD] "It is covered by 2.4.8, which is Level 3." (2.4.8 The purpose of each link can be programmatically determined from the link. [How to meet 2.4.8] )
Item Number: Success Criterion 2.4.4
Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):
Although the wording of SC 2.4.4 is convoluted, it is presumably a replacement for WCAG 1.0, Checkpoint 13.1 "Clearly identify the target of each link [Priority 2]". However 13.1 also required the link text to meaningful enough to make sense when read out of context, either on their own or as a sequence of links, and this does not appear to be the case with SC 2.4.4.
In my experience, many screen reader users extensively use the screen-reader facility that enables them to obtain a list of links on a page. This is often the preferred technique when looking for information on a site or undertaking a task, and in virtually all situations it is only effective when the link text indicates the link destination. While I believe it is possible with some screen readers to select an option that provides context from the surrounding text I have never seen this done. However, many times I have seen screen reader users become frustrated with links that contain only the words "more", "next" or "click here".
I believe it is very important for link text to provide a clear indication of the link destination. Also, the link text should make sense without the need to rely on surrounding contextual information or a title attribute within the link element.
Proposed Change:
I believe 2.4.4 should remain a level 2 SC, but should be rewritten to read, "The target or destination of each link should be clearly indicated by the link text."
Status: open
Working Group Notes: [TEAMB] [SM] [HOLD] "It is covered by 2.4.8, which is Level 3." (2.4.8 The purpose of each link can be programmatically determined from the link. [How to meet 2.4.8] )
Related Issues:
LC-712 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=LC-712>
Comment LC-1053
Sort Terms: level-change
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location: navigation-mechanisms-focus <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
2.4.6: This should be at Level 1. Order of information is very important to both people who use screen readers and people with cognitive disabilities.
Proposed Change:
Move to Level 1
Status: open
Comment LC-1054
Sort Terms: level-change
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location: navigation-mechanisms-location <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
2.4.7: This should be at Level 1. Determining the current location is sometimes very difficult for both people who use screen readers and people with cognitive disabilities
Proposed Change:
Move to Level 1
Status: open
Comment LC-1056
Sort Terms: LEVEL-CHANGE link-text
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location: navigation-mechanisms-link <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
2.4.4 & 2.4.8: 2.4.8 should move to Level 1 and replace 2.4.4. People who use screen readers often navigate through a page by tabbing from link to link and therefore can determine the content on the page. Allowing for link text to not describe the target of the link means that these users will find it difficult to navigate.
Proposed Change:
Move to Level 1 and delete 2.4.4
Status: open
Comment LC-944
Sort Terms: link-text level-change
Document: WCAG 2.0 Guidelines
Submitter: M.F. Laughton <adio@crc.ca> Affiliation: Government of Canada
Comment Type: substantive
Location: navigation-mechanisms-link <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
The purpose of each link can be programmatically determined from the link. "Meaningful" link text is no longer a high priority: it should be. Navigating via links benefits a large number of users including those using keyboard access, voice rec, alternate input and screen reading technology. It remains in many cases the only means that many users can navigate content in an efficient and useful manner.
Proposed Change:
SC 2.4.8 Should be a level 2 criteria
Status: open
Comment LC-839
Sort Terms: level-change descriptive-titles
Document: WCAG 2.0 Guidelines
Submitter: Jon Gunderson <jongund@uiuc.edu> Affiliation: UIUC
Comment Type: substantive
Location: navigation-mechanisms-descriptive <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):
If descriptions of an image are SC1, then are not descriptions of a web page titles and headings of equal importance?
Proposed Change:
Change to SC1. Consider merging with requirement of SC 2.4.3.
Status: open
Working Group Notes: [TEAMB] [HOLD]
@@ MU: See my comment on LC626 and LC838. See also 1052.
Resolution Working Notes - Unapproved:
SEE ACTIONS FOR LC-625
Related Issues:
625 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=625>
626 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=626>
838 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=838>
1052 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1052>
Comment LC-1321
Sort Terms: level-change
Document: WCAG 2.0 Guidelines
Submitter: Takayuki Watanabe, Makoto Ueki, and Masahiro Umegaki <nabe@lab.twcu.ac.jp> Affiliation: JIS WG2
Comment Type: substantive
Location: minimize-error-reversible <http://www.w3.org/TR/WCAG20/complete.html> (Level 2 Success Criteria for Guideline 2.5)
Comment:
Comment: Scope of SC 2.5.3 is limited and narrow. It deals with specific forms. Thus, it should be moved to L3.
Proposed Change:
Level 3 Success Criteria for Guideline 2.5
2.5.3 For forms that cause legal or financial transactions to occur, that modify or delete data in data storage systems, or that submit test responses, at least one of the following is true:
1. Actions are reversible.
2. Actions are checked for input errors before going on to the next step in the process.
3. The user is able to review and confirm or correct information before submitting it.
Status: open
Comment LC-1058
Sort Terms: level-change
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location: minimize-error-context-help <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
2.5.4: This should be Level 1. Context sensitive help is very important to people who use screen readers and people with cognitive disabilities.
Proposed Change:
Move to Level 1
Status: open
Comment LC-1143
Sort Terms: level-change
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location: minimize-error-context-help <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
2.5.4: This should be a Level 1 SC. Providing assistance when filling out information is very important to people with disabilities
Proposed Change:
Move 2.5.4 to Level 1
Status: open
Comment LC-622
Sort Terms: level-change natural-language
Document: WCAG 2.0 Guidelines
Submitter: Lisa Seeman <lisa@ubaccess.com> Affiliation: Invited expert at W3C, UB access
Comment Type: substantive
Location: meaning <http://www.w3.org/TR/WCAG20/complete.html> (Level 1 Success Criteria for Guideline 3.1)
Comment:
Comment (including rationale for proposed change):
The primary natural language is identified.
Why is this level 1? I have not seen an assistive technology and user not work at all because the language attribute is missing. this seems to be level 3
Proposed Change:
move 3.1.1 to level 3
Comment LC-623
Sort Terms: level-change language-changes
Document: WCAG 2.0 Guidelines
Submitter: Lisa Seeman <lisa@ubaccess.com> Affiliation: Invited expert at W3C, UB access
Comment Type: substantive
Location: meaning <http://www.w3.org/TR/WCAG20/complete.html> (Level 2 Success Criteria for Guideline 3.1)
Comment:
Comment (including rationale for proposed change):
changes in natural language is identified:
Is WCAG awere that this is huge amount of work? for lots of content this would be more work then the rest of WCAG put together (all the has English in for web site names and odd words..). On the other hand it seems typically understandable by the user as is, and not so important for the user..
Proposed Change:
move SC 3.1.2 to level 3
Status: open
Working Group Notes: [TEAMB] [HOLD] Proposal from team to be surveyed
[SM]Comment LC-760 points out that this may be useful for future versions of speech synthesizers to switch to different language modes.
There is a note in the "How To Meet" section of this SC "Note: This requirement does not apply to individual words or phrases that have become part of the primary language of the content."
From Christophe, 9/7/2006:
I have reviewed the comments and revised the response, but I have no information about the amount of work (when compared to other SCs) required by SC 3.1.2. I have asked about this on a German accessibility mailing list (WAI-DE), and I'm waiting for responses.
One of the things I read on the WAI-DE mailing list is that language markup can be important in compound words that contain parts borrowed from another language. For example, in a German text, "Webtechnik" can be interpreted as "web technology" (if "Web" is marked up as English) or as "weaving technique/technology" (without marking up a change in language). Similarly, "HTML-Tag" could be interpreted as "HTML tag" (markup) or "HTML day".
I also checked a few pages of organisations involved in web accessibility, and found the following results:
http://www.heritas.nl/overheritas_expertise.html
Language changes not marked up:
* sitecheck
* World Wide Web Consortium
* Web Content Accessibility Guidelines
* Participant in Good Standing
(No other changes in language.)
http://www.drempelsweg.nl/smartsite.dws?lettertype=&id=140
Language changes not marked up:
* Access All Areas
* content (three times)
* headers
* server-side image map (two times)
* client-side image map
* user agents
* scripts & applets are border cases
Only the first occurrence of W3C is marked up as an acronym; the start tag has a lang element with value 'en' for the English content of the title attribute. This is the only language change in the document that is actually marked up.
http://www.drempelvrij.nl/waarmerk
Language changes not marked up:
* toolbar (first occurrence is not marked up)
* Award (three times)
* commercial (maybe also part of Dutch; the term also occurs in two alt
attributes)
* Windows Media File
* releases
* accessibility (two times, including the URL at the bottom of the page)
The other language changes are marked up:
* toolbar (four times)
* Taskforce
* Web Content Accessibility Guidelines (two times)
http://www.anysurfer.be/nl/
This page contains a few French names and several English terms. Only changes to French are marked up.
The following changes to English are not marked up:
* Home (four times)
* sitemap
* AnySurfer (10 times, not counting occurrences in title and alt attributes)
* BlindSurfer (4 times, not counting occurrences in title and alt attributes)
* disclaimer (1 occurrence at bottom of page)
(Note: privacy has become part of Dutch.)
I'll get back when I get a response from the German mailing list.
Reviewed at the July 18, 2005 Team B meeting; send to survey.
Discussed in the 20 July 2006 telecon:
Resolution: refer LC-623 back to team B to address survey comments.
http://www.w3.org/2006/07/20-wai-wcag-minutes.html
@@ Christophe to review survey comments.
Resolution Working Notes - Unapproved:
{not accept}
@@ Response to commenter: This SC does not apply to individual words or phrases that have become part of the default language of the content, as outlined in the "How To Meet" section, so it applies to web site names but not to "odd words" generally. The group acknowledges that it can be a lot of work for some sites to meet this requirement, but prefers to keep it at Level 2.
Related Issues:
LC-760 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=LC-760>
LC-622 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=LC-622>
Comment LC-760
Sort Terms: level-change language-changes
Document: WCAG 2.0 Guidelines
Submitter: Jon Gunderson <jongund@uiuc.edu> Affiliation: University of Illinois
Comment Type: substantive
Location: meaning-other-lang-id <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
This should be success criteria 1 like in the Priority 1 WCAG 1.0 requirement. It is impossible for people using speech to guess at language changes. We have a lot of web based foreign language courses at UIUC and we have identified that speech users cannot determine when to manually switch their synthesizer languages, even when they know that there are more than one language on the resource. If changes in language are available modern screen readers will automatically switch the language of the synthesizer.
Proposed Change:
Move this requirement (3.1.2) to Success Criteria 1
Status: open
Working Group Notes: [TEAMB] [HOLD] Discussed at TeamB meeting 06/18/07, decided to leave for further discussion
Related Issues:
LC-623 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=LC-623>
Comment LC-1295
Sort Terms: level-change language-changes
Document: WCAG 2.0 Guidelines
Submitter: Andrew Arch <andrew.arch@visionaustralia.org> Affiliation: Vision Australia
Comment Type: substantive
Location: meaning-other-lang-id <http://www.w3.org/TR/WCAG20/complete.html> (Levels)
Comment:
Comment: What is the point of having 3.1.1 at Level 1, but 3.1.2 at Level 2? My screen reader will then just read the entire page in the web unit language!
Proposed Change:
Move 3.1.2 to Level 1
Status: open
Comment LC-945
Sort Terms: level-change
Document: WCAG 2.0 Guidelines
Submitter: M.F. Laughton <adio@crc.ca> Affiliation: Government of Canada
Comment Type: substantive
Location: meaning-idioms <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
A mechanism is available for identifying specific definitions of words or phrases used in an unusual or restricted way, including idioms and jargon. We feel that indiscriminate (and unfortunately wide-spread) use of such jargon is a greater barrier to understanding and using Web content than is implied by its relegation to level 3.
Proposed Change:
SC 3.1.3 Should be a level 2 criteria
Status: open
Comment LC-1059
Sort Terms: level-change
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location: meaning-located <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
3.1.4: If information is provided in an abbreviated form without expansion, then the content is essentially inaccessible to people that cannot interpret the abbreviation. People who use screen readers and people with cognitive disabilities often have difficulties interpreting abbreviations.
Proposed Change:
There should be a Level 1 version of this SC which requires that important abbreviated information is marked up, or expanded the first time it is used in a page
Status: open
Comment LC-569
Sort Terms: cognitive level-change
Document: WCAG 2.0 Guidelines
Submitter: Roger Hudson <rhudson@usability.com.au>
Comment Type: substantive
Location: meaning-supplements <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
I have two main concerns with 3.1.5:
First, the nominated Success Criterion is Level 3, which suggests that it is only necessary to \"achieve additional accessibility enhancements\" and does not need to apply to all Web resources (without any indication of the resources it should apply to).
Second, 3.1.5 concentrates solely on a persons reading ability, which is only one of the factors that can influence how well different people with cognitive disabilities or learning difficulties are able to understand a document. For example, what about people who can read well but have considerable difficulty negotiating a complex text-type or comprehending what is written? Or, the additional burden fully justified text and the use of long line lengths can place on many people with reading difficulties?
Proposed Change:
I suggest SC 3.1.5 be a Level 2 criterion at the minimum.
Status: open
Comment LC-887
Sort Terms: reading-level level-change
Document: WCAG 2.0 Guidelines
Submitter: Monica Løland, The Danish Council of Organisations of Disabled People (DSI) <mol@handicap.dk> Affiliation: The Danish Council of Organisations of Disabled People (DSI)
Comment Type: substantive
Location: meaning-supplements <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):
Success Criteria 3.1.5: “When text requires reading ability more that the lower secondary education level, supplemental content is available…” should be placed at level 2 instead of level 3. EU and many national governments meet WCAG conformance at level 2, which means that people with cognitive disabilities will not be granted full accessibility if 3.1.5 remains on Level 3. In WCAG 1.O checkpoint 14.1 was a level 1 criteria: “Use the clearest and simplest language appropriate for a site\'s content”.
Proposed Change:
Success Criteria 3.1.5: “When text requires reading ability more that the lower secondary education level, supplemental content is available…” should be placed at level 2 instead of level 3. EU and many national governments meet WCAG conformance at level 2, which means that people with cognitive disabilities will not be granted full accessibility if 3.1.5 remains on Level 3. In WCAG 1.O checkpoint 14.1 was a level 1 criteria: “Use the clearest and simplest language appropriate for a site\'s content”.
Status: open
Comment LC-1068
Sort Terms: change-of-context MAPPING LEVEL-CHANGE
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: substantive
Location: mapping <http://www.w3.org/TR/WCAG20/complete.html> (Checkpoint 10.1)
Comment:
Spawned windows: As mentioned in a previous comment, the SC this maps to outlaws change in context when a user does something, but doesn't outlaw change in context without user initiation.
Proposed Change:
Create a new SC outlawing changes in context without user initiation at Level 1 (I am happy to write this)
Status: open
Working Group Notes: [TEAMB][HOLD]
This should be outlawed by 3.2 is it?
if so we need to change mapping.
What are examples of changes of context not by user request: security-related reasons for changing context, like automatic log out. Monitoring a stream of data - a change of content but not context.
Resolution Working Notes - Unapproved:
@@Response to commenter:
SC 3.2.5, "Changes of context are initiated only by user request." outlaws changes of content without user initiation.
Comment LC-1144
Sort Terms: level-change
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location: consistent-behavior-no-extreme-changes-context <http://www.w3.org/TR/WCAG20/complete.html> (3.2.1 & 3.2.5)
Comment:
3.2.5 should be at Level 1. It is unclear to me why outlawing changes of context on user initiation is at Level 1(3.2.1) whereas this allows changes of context only on user initiation (3.2.5). They appear contradictory
Proposed Change:
Clarify the SC
Status: open
Comment LC-1065
Sort Terms: level-change 4.2.4: does not make sense. Shouldn't this be at Level 2?
Document: WCAG 2.0 Guidelines
Submitter: Gian Sampson-Wild <gian@tkh.com.au>
Comment Type: general comment
Location: accessible-alternatives-all-reqs <http://www.w3.org/TR/WCAG20/complete.html>
Comment:
4.2.4: This SC does not make sense. Shouldn't this be at Level 2?
Proposed Change:
Explain this SC
Status: open
Loretta Guarino Reid
lguarino@adobe.com
Adobe Systems, Acrobat Engineering
Received on Saturday, 21 October 2006 00:08:18 UTC