0 open issues were found.
0 pending issues were found.
127 closed issues were found.
517, 519, 542, 556, 559, 561, 575, 591, 592, 593, 594, 595, 596, 597, 654, 655, 660, 717, 782, 783, 784, 785, 786, 787, 788, 789, 790, 791, 792, 793, 794, 795, 796, 797, 798, 1525, 833, 937, 938, 948, 964, 975, 980, 985, 986, 992, 1016, 1017, 1018, 1019, 1072, 1073, 1074, 1075, 1077, 1078, 1079, 1080, 1081, 1082, 1083, 1086, 1087, 1088, 1089, 1091, 1092, 1093, 1095, 1099, 1100, 1101, 1102, 1103, 1104, 1105, 1106, 1107, 1108, 1109, 1110, 1111, 1112, 1113, 1114, 1115, 1116, 1117, 1118, 1119, 1120, 1121, 1122, 1123, 1124, 1125, 1126, 1127, 1128, 1129, 1130, 1131, 1132, 1133, 1135, 1136, 1137, 1138, 1139, 1146, 1147, 1260, 1308, 1326, 1327, 1375, 1376, 1377, 1378, 1379, 1380, 1381, 1382, 1405, 1406, 1407, 1535
Part of Item: Intent
Comment Type: ED
Comment (Including rationale for any proposed change):
In the GL list Wendy posted the following explaination that i think would be good to add to the intent section to explain. John suggested an edit which is also included.
Proposed Change:
WCAG 1.0 says "If you can't avoid building stairs, build an elevator." It doesn't say anything about making the elevator easy to find or get to. SC 4.2.1 of WCAG 2.0 says, "If you can't avoid building stairs, provide an elevator at the main entrance, along with the stairs."
Thank you for reminding us to include this important distinction. The idea that "If you can't avoid building stairs, build an elevator." was in WCAG 1.0. WCAG 2.0 wants to ensure that making the elevator easy to find (or get to) is also important. SC 4.2.1 of WCAG 2.0 has been updated to include, "The idea behind this success criterion is; "If you can't avoid building stairs, provide an elevator that is just as easily found."
Part of Item: Techniques
Comment Type: GE
Comment (Including rationale for any proposed change):
Refer to paragraphs under Advisory Techniques for Guideline x.x starting with "Specific techniques for ..." and ending with "more accessible to more people."
Comment:
The fact that there are two categories is already stated in the introductory content at the start of the doc. The paragraph that follows this heading is unnecessarily repetitive.
Proposed Change:
Consider replacing with headings like:
- Advisory Techniques for Guideline x.x (general, not criteria specific)
- Advisory Techniques for Guideline x.x (criteria specific)
(If there are none under either category, a single word following the heading saying, “None�, is sufficient). The recommendation made is consistent with other headings like: Technology-Specific Techniques
The intent is that users jump to these "Understanding Guideline x.x" modules directly from the guidelines. As a result, they will not have read the introduction. Thus the redundancy in this paragraph with text that is in the introduction.
We think retitling " Advisory Techniques for Guideline X.X" is a good idea and have retitled it to " Advisory Techniques for Guideline X.X (not success criteria specific)"
Regarding just putting "none" we don't want people to think there are no advisory techniques, and since this doc may be broken into separate docs for each success criteria, we want to keep directions as to where to look for the other advisory techniques.
Item Number: How to Meet Success Criterion 3.1.5
Part of Item: Intent
Comment Type: GE
Comment (Including rationale for any proposed change):
The statement "help people with reading disability" in the intent section of the How to meet 3.1.5 section is incorrect. The ability to comprehend high level language is not related to reading disability. Reading disability is strictly associated at a more general level with lessened ability to mentally convert visual textual information, into verbal auditory information (phonemic awareness). There is no concept of sematic disability associated with reading disability. By definition, a person with a reading disability does not have a sematic processing disability, with normal or above normal intelligence. There are several references throughout the HowTo document that refer to reading disability as an inability to understand. These statements need to be removed. They are not true (see: howto 3.1.6). Reading disability does not affect a person's ability to understand.
Proposed Change:
Remove references to to simplified language being an accomodation for those with a reading disability.
We have revised the descriptions of the benefits of different success criteria for people with cognitive disabilities by using descriptions that are based on functional limitations.
Part of Item: Related Resources
Comment Type: TE
Comment (including rationale for proposed change):
Should consider adding the following reference in the related resources area.
http://www.w3.org/TR/turingtest/
Proposed Change:
Should consider adding the following reference in the related resources area.
http://www.w3.org/TR/turingtest/
The working Group agrees and has added http://www.w3.org/TR/turingtest/ to the Related Resources section of "How to Meet SC 1.1.1".
Part of Item: Techniques
Comment Type: ED
Comment (including rationale for proposed change):
The following Examples are currently associated with 1.3.2:
Situation A: If the color of particular words is used to indicate information.
Ensuring that color encoded information is also available in text.
Including a text cue whenever color cues are used
The above are too broad for 1.3.2 and should be associated only with 1.3.4.
Proposed Change:
Move the above to 1.3.4.
Add example of using colored text that is also bold and italic as a way to satisfy 1.3.2.
We have added a technique to Situation A in "How to meet 1.3.2" that reads, "Ensuring that when text color is used to convey information, the text style is visually differentiated without color."
Part of Item: Intent
Comment Type: TE
Comment (including rationale for proposed change):
May want to add advisory technique to skip over non-baseline content.
Proposed Change:
Add the optional/advisory techniques to skip over non-baseline content.
We have added an advisory technique "Providing a mechanism to skip non-accessibility-supported content" to Conformance Requirement 6.
Part of Item: Examples
Comment Type: TE
Comment (including rationale for proposed change):
"breadcrumb trail" is no more an obvious term than many others in the glossary.
Proposed Change:
Add glossary entry for "breadcrumb trail".
We agree that the term needs explaining. The glossary only includes terms that are used in the guidelines. However, the term breadcrumb trail is in a link to a technique titled "Providing a Breadcrumb Trail". Clicking on this link takes you to the technique description that begins with a description of exactly what a breadcrumb trail is and includes several examples.
Comment (including rationale for any proposed change):
Reasons of why using sign language videos are wrong.
Proposed Change:
Replace it with: "The intent of this success criterion is to enable people who are deaf or hard of hearing and who are fluent in the sign language to understand whole texts. Many people, especially native signers, find it easier to follow sign language than to read the text, since the text are often a second language to them."
The intent section for 1.2.5 has been revised to read:
The intent of this success criterion is to enable people who are deaf or hard of hearing and who are fluent in a sign language to understand the content of the audio track of multimedia presentations. Written text, such as that found in captions, is often a second language. Some individuals will require sign language interpretation to gain full access to the multimedia content.
Comment (including rationale for any proposed change):
The technical notes are not wrong, but misleading. One can get the impression that sign language videos are only necessary if there are captions in videos. This does not meet the reality.
Proposed Change:
Please delete this notes.
Captions are required for all multimedia at level AA (1.2.1 Captions are provided for prerecorded multimedia., 1.2.4 Captions are provided for live multimedia. ) It is helpful to discuss why signed language interpretation is needed even though captions are already available in any multimedia being considered at level AAA.
Comment (including rationale for any proposed change):
The technique "Providing a synchronized video of the sign language interpreter that can be displayed in a different viewport or overlaid on the image by the player." can be deleted. There is no need for a different viewport. The video can be placed in the same viewport, either on the same page or in an own page.
Proposed Change:
Replace this with "If the sign language interpreter expresses a content of a video you can include a sign language interpreter in the corner of the video stream. For best comprehensibility only use this technique in videos with fullscreen size."
The technique you propose would also be sufficient, so we have added it. We did not eliminate the option on the part of the author to put it into a new viewport (which could be independently scaled) because that would also be sufficient. The new technique is titled
"Providing a new page that has the video with the sign language interpretation of the audio track." You are welcome to write up this technique if you like and submit it using our technique submission form at http://www.w3.org/WAI/GL/WCAG20/TECHS-SUBMIT/. If you do not we will try to create the technique from the notes you sent.
Comment (including rationale for any proposed change):
The technique "Including a sign language interpreter in the corner of the video stream" is only sensible for fullscreen videos, otherwise the signer is too small and not understandable.
Proposed Change:
Replace this with "Provide a video with a sign language interpreter expressing the text contents without restrictions."
The technique was adapted from TV and you are right that resizable windows on a computer screen may make the signer unreadable. But this is a user agent issue. All videos players should have a mechanism to play videos full screen. So usually it would be up to the user to maximize the screen.
However, we have added the following note to the technique G54.
Note: If the video stream is too small, the sign language interpreter will be indiscernible. When creating a video steam that includes a video of a sign language interpreter, make sure there is a mechanism to play the video stream full screen in the baseline technology. Otherwise, be sure the interpreter portion of the video is adjustable to the size it would be had the entire video stream been full screen."
Comment (including rationale for any proposed change):
The thesis "People whose primary language is a sign language sometimes have limited reading ability" is not always true. The reading ability of native signers is broad, from low to top. The focus on captions is not meeting the reality. Many native signers are able to understand captions. The focus has to move to the complete content, i.e. the texts.
Proposed Change:
Replace it with "These individuals may not be able to read and comprehend the textual contents and thus require a sign language interpretation to gain access to the multimedia content."
We have adopted your recommendation into the intent sections for SC 1.2.5 with a slight revision to indicate that this isn't true for all. It now reads as follows:
'The intent of this success criterion is to enable people who are deaf or hard of hearing and who are fluent in the sign language to understand the content of the audio track of multimedia presentations. Written text, such as that found in captions is often a second language to them. Some of these individuals may not be able to read and comprehend the textual content of captions or may not be able to read it quickly enough and thus require a sign language interpretation to gain access to the multimedia content.'
Comment (including rationale for any proposed change):
The thesis "Some people who communicate using sign language and are proficient readers may have impaired vision which may make it difficult to read the captions on the screen. A sign language interpretation may be easier to view." is misleading: Captions are zoomable, a video with a signer is not zoomable to meet impaired vision.
Proposed Change:
Suggestion: Delete it.
Your comment has been adopted and the bullet about vision impaired people reading captions has been deleted from the benefits section of how to meet SC 1.2.5.
Comment (including rationale for any proposed change):
The note "Different sites may address...sufficient by the working group" is a little bit misleading in case of deaf people.
Proposed Change:
Please add to the note that in case of deaf people it is wrong to think about deaf people as human beings not able to understand "texts above upper secondary education level". It is not about cognitive impairments, it is about linguistic matters. It is just that many deaf people understand sign language better than written language, because sign language is their mother tongue. With sign language "texts above upper secondary education level" are more understandable for deaf people.
Thanks you for your suggestion. We have replaced the sentence
"For sites designed for people who are deaf a sign language version of the page may be most useful for users who cannot understand the text well."
with the sentence
"For some people who are deaf, a sign language version of the page may be easier to understand than a written language version since sign language may be their first language."
Part of Item: Common Failures
Comment Type: TE
Comment (including rationale for proposed change):
While there are two HTML techniques about labeling form controls--\"H44 (Using label elements to associate text labels with form controls)\" and \"H65 (Using the title attribute to identify form controls when the label element cannot be used)\"--there is no common failure about _not_ labeling form controls. This also applies to 4.1.2.
Proposed Change:
Add a common failure about not labeling form controls.
SC 4.1.2 and SC 1.1.1 require that form controls have names. The name may be provided in a way that is not a (visible) label.
SC 1.3.1 requires that if a form control has a label, then the association between the label and the form control can be programmatically determined.
To encourage the use of labels when appropriate, we have added an advisory technique to SC 1.3.1 and SC 4.1.2:
Providing labels for all form controls that do not have implicit labels (future link)
Part of Item: Common Failures
Comment Type: TE
Comment (including rationale for proposed change):
While there are common failures about _inappropriate_ text alternatives (F30) and omitting the alt attribute _for decorative non-text content_, namely img and applet per test procedure (F38), there is no common failure about not having a text alternative for img, area, input[@type=\'image\'] in general (alt attribute).
If there is no alt attribute, F30 does not apply. If the non-text content is not decorative only, F38 does not apply.
applet and object is a different case. As the text alternative is the text content of these elements (or in case of applet the alt attribute), there is always at least an empty text alternative.
Proposed Change:
Add a common failure about omitting the alt attribute for img, area, input[@type=\'image\'] in general.
We have added a failure technique as you suggested.
Part of Item: Techniques
Comment Type: GE
Comment (including rationale for proposed change):
In the document \"About Baseline and WCAG2.0\" it states
\"They would use the HTML 4.01 techniques described as “sufficient� in Understanding WCAG 2.0. (Authors may further enhance the user experience by also using additional HTML techniques listed as “advisory� (optional) in Understanding WCAG 2.0.)\"
The sections with advisory techniques are clearly labeled as \"Additional Techniques (Advisory) for x.x.x\"
The techniques deemed as sufficient requires that you read the paragraph under the title \"Techniques for Addressing Success Criterion x.x.x\" which does says \"Each numbered item in this section represents a technique or combinations of techniques that the WCAG Working Group deems to be sufficient to meet success criterion x.x.x as long as the technologies used are in the baseline you are using.\"
Proposed Change:
Clearly mark the \'sufficient\' techniques in the document to aid understanding both documents.
Yes - we see that problem. Take a look at the Quick Reference document at http://www.w3.org/WAI/WCAG20/quickref/. We have rearranged the techniques to make them clearer and avoid the problem you cite both here and in Understanding WCAG 2.0.
Part of Item: Examples
Comment Type: GE
Comment (including rationale for proposed change):
It is not clear from the success criteria that greyed-out inactive element would pass 1.3.2.
Proposed Change:
Add simple example that grey-out inactive elements are visually distinguishable from normal active elements.
We have added an example of disabled form elements to How To Meet Success Criterion 1.3.2.
Comment:
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0120.html
Endorsement of "non-W3C technologies"
A deficiency of WCAG 1 was its chauvinism toward anything not invented by the W3C. They pretty much didn't want you to use any "non-W3C technologies"; there's a whole [3] guideline telling you not to. WCAG 2 tries to be technology-neutral. In so doing, it authorizes the use of "HTML" that was never ratified by a specification, notably embed.
While this is the only reliable method to include multimedia on a Web page (still, in 2006), is univerally understood by graphical browsers, and can easily be made legal via a custom DTD, it still isn't real HTML. I find its inclusion curious given WAI's ideology of yore. (Elsewhere, the Understanding document lists the blink element as a failure method. That isn't real HTML either, thankfully.)
3. http://www.w3.org/TR/WAI-WEBCONTENT/#gl-use-w3c
WCAG 2.0 was carefully written to be technology neutral and to allow non-W3C technologies to be used. As you noted, the guideline talking about using W3C technolgies is from WCAG 1.0 not WCAG 2.0. It was one of the aspects of WCAG 1.0 that we specifically did not bring forward.
With regard to embed, as you point out, "this is the only reliable method to include multimedia on a Web page (still, in 2006), is univerally understood by graphical browsers". This is why it is included. It is one example of non-W3C technology. The guidelines allow a wide range of others.
Comment:
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0120.html
Device-independence?
A Web page has a field that automatically updates with the latest headlines in a rotating fashion. There is a slider that allows the user to slow the update rate by as much as 10.
A slider? That requires a mouse, not to mention full vision.
The example in How to meet 2.2.1 has been changed to:
A Web page has a field that automatically updates with the latest headlines in a rotating fashion. There is an interactive control that allows the user to extend the length of time between each update to as much as 10 times the default. The control can be operated with either a mouse or a keyboard.
Comment:
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0120.html
Time limits
In circumstances where a sign-language interpreter may be relating audio content to a user who is deaf, control over time limits is also important.
Then that isn't an issue of Web content anymore. Hiring a human aide to make a site accessible to you is no longer our problem.
Using a human aide is similar in this instance to using a screen reader,
in that it is an accommodation that may cause the user to need more time. Therefore, we think it is an appropriate benefit for the time limits success criterion.
Comment:
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0120.html
Flashing (but not blinking)
A movie with a scene involving very bright lightning flashes is scripted so that the lightning only flashes two times.
Yes, WAI wants you to rewrite your script.
The example has been rewritten to avoid the implication that this criterion would require rewriting a script. The example now reads:
A movie with a scene involving very bright lightning flashes is edited so that the lightning only flashes three times in any one second period.
Comment:
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0120.html
Text alternatives
[INS: [For n] :INS] on-text content that is multimedia... it is important that users know what it is when they encounter it on a page so they can decide what action if any they want to take with it. A text alternative that describes the multimedia and/or gives its title is therefore provided.
How do I do that with, say, embed, which permits no fallback content? (Of course there's noembed, but, since all graphical browsers understand embed, noembed content will never be displayed. In any event, there is no actual or official specification for embed and especially noembed.) Does this not mean I have to label each video in plain text?
We have moved the technique on using noembed with embed to advisory. General techniques are available which describe alternative methods on providing text alternatives for EMBED.
Comment:
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0120.html
Text alternatives
Providing what description is possible is also desired. If the intent of the author in creating the content - or the intent of the page author in putting the content on the page - is known and can be described, this is also very useful
"Intent of the page author"? What is this talking about?
We have updated that paragraph to remove references to "intent of the page author".
Comment:
Text alternatives
Linking to live textual information, e.g., if it is a traffic Webcam, linking to a site that provides textual traffic reports
If my Webcam is pointed out my window and depicts my obscure street or intersection, exactly how am I going to locate a traffic-report site that covers my neighbourhood? And how is that actually "equivalent" given that a sighted visitor can watch traffic in real time, while a "textual traffic report" has to be written and published post-facto and can never keep up?
We agree that it would not be practical to provide a live textual equivalent to your personal webcam that is providing a view of your neighborhood streets. It might be possible, however, for a municipality to provide a link to traffic reports which are useful to users who can't see the webcam image. Since it is not correct to call a regional traffic report an "equivalent" for a webcam of a particular intersection, however, we have changed the title of this technique to be more accurate.
Note also that this is an advisory technique. It is not in any way required by WCAG. It is just something extra that people can do to make things more accessible where it applies.
Comment:
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0120.html
Text alternatives
And now, the biggest failure of the section on text equivalents. I've been warning WCAG Working Group about this topic for years. The fact that the following example made it this far into the writing process demonstrates that the Working Group simply will not accept reality.
A data chart: A bar chart compares how many widgets were sold in June, July, and August. The short label says, "Figure one - Sales in June, July and August." The longer description identifies the type of chart, provides a high-level summary of the data comparable to that available from the chart, and provides the data in a table. It is obviously a lost cause to try to explain to WCAG that diagrams and data are not interchangeable. We create diagrams because data are too hard to understand. To use an analogy over again, diagrams and data are like a suitcase that can be unpacked but not easily repacked. If data were understandable by themselves, we wouldn't make a chart. I can assure the Working Group that giving nondisabled people a really nice chart and disabled people a table with 10,000 or more data points does not constitute equality in any sense. Moreover, some data can be understood only if transformed (as by plotting on a logarithmic scale), which is the sort of thing that simply cannot be expressed understandably in numbers. I am aware that the National Braille Association has authorized WAI to publish parts of its training manual concerning the rendition of charts and graphs in audiobooks. I have seen no evidence that those techniques are viable on the Web. Given that they seem to work fine for audiobooks, I would be interested to see any such evidence.
The working group agrees that it may not always be possible or practical to provide access to the data. We also require a long description for this type of chart. We did not however mention that in the example - and that was an oversight. We have updated the example text to explain that a high-level summary of the data and applicable trends is provided in the long description.
The example has been revised as follows:
A bar chart compares how many widgets were sold in June, July, and August. The short label says, "Figure one - Sales in June, July and August." The longer description identifies the type of chart, provides a high-level summary of the data, trends and implications comparable to those available from the chart. Where possible and practical, the actual data is provided in a table.
Comment:
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0120.html
Multimedia
People who are deaf, are hard of hearing, or who are having trouble understanding audio information for any reason can read the text presentation or (in the future) have it translated and presented as sign language by assistive technology.
No such vapourware technologies of text-to-sign translation will be available and reliable during the lifetime of WCAG 2. (If you think otherwise, here's something for you: Can you make it work in Quebec Sign Language?)
Similarly:
Captions may be generated using real-time text translation service (stenographic or, in the future, speech-to-text with corrections).
Who's gonna do those corrections (in real time, no less)? And at what point in the "future" will this be developed? The existing technique of speaker-dependent speech recognition, known as voicewriting, could be included here if defined properly.
We have updated these notes as follows:
"People who are deaf, are hard of hearing, or who are having trouble understanding audio information for any reason can read the text presentation. Research is ongoing regarding automatic translation of text into sign language."
"Captions may be generated using a real-time text translation service." (removed parenthetical)
Comment:
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0120.html
Providing open captions that are embedded directly in the video stream
"Embedded"? As by using embed? What are they trying to get at here? Burned-in open captions (a nice, easy, understandable terminology that could be used) or encoded captions that always display even if the viewer doesn't want them (a much rarer case, similar to forced subtitles on DVD)?
We changed the wording from "Providing open captions that are embedded directly in the video stream" to "Providing open (always visible) captions"
Comment:
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0120.html
Providing closed captions using any readily-available media format that has a video player that is free of charge and supports closed captioning
Funny... Jaws isn't free. Why are we restricted to the usage of free players when accessibility software in other contexts is expensive?
We have removed, "is free of charge and" from item 3 of SC 1.2.4
Comment:
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0120.html
I appreciate the fact that my work is cited in this document - [4]Best Practices in Online Captioning and [5]Standard Techniques in Audio Descriptions (sic - it's actually singular). I note, though, that the only contributors to these "Related Resources" that merit a real byline are the National Braille Association and... Gregg Vanderheiden, dear coleader of the WCAG Working Group
The title has been corrected. All author names have been removed from resource references.
Comment:
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0120.html
+ An audio file begins playing automatically when a page is opened. However, the audio can be stopped by the user by selecting a "silent" link at the top of the page.
+ An audio file begins playing automatically when a page is opened. However, the audio can be stopped by the user by selecting a "silent" link at the top of the page.
Why does this section not cover the more typical scenario, a Flash splash page with sound that plays and then stops, or that plays and can be turned off only by a hard-to-find control, often at the bottom of the page? (I've also seen such controls appear only after the sound has finished playing.)
We have added examples with Flash player - using approaches that would fit in section on examples of how to do this as follows:
- A Flash splash page with sound that plays and then stops in less than 3 seconds.
- A Flash splash page with sound that plays automatically includes a control at the top that allows users to turn the sound off.
Comment:
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0120.html
A sequence is meaningful if the order of content in the sequence cannot be changed without affecting its meaning. The order of words in sentences and sentences in paragraphs, for instance, is always meaningful.
Not in free-word-order languages, though many of those do tend to converge on certain preferred word orders.
We have removed the sentence about word order because that subject was not intended to be covered by 'How to Meet Success Criterion 1.3.3'.
Comment:
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0120.html
Ensure that numerals or other look alike glyphs are not used in place of letters
There goes your l33tspeak, h4xorz! (\/\/C4G iz teh sux0r @nyw@y111oneoneone)
The working group does not consider leetspeak to be accessible. We have moved the advisory technique from SC 1.3.4 to SC 1.1.1, where it was changed into the following techniques and failures:
* Failure of SC 1.1.1 due to using look-alike glyphs to represent text without providing a text alternative.
* Providing text alternatives for strings where look-alike glyphs are used in place of letters (e.g. Leetspeak).
* Failure of SC 1.1.1 due to using ASCII art without providing a text alternative.
* Providing text alternatives for ASCII art.
We have also updated the note to the definition of non-text content so that it reads: 'This includes ASCII Art, which is a pattern of characters, and leetspeak, which is character substitution.'
Comment:
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0120.html
Failure of SC 1.3.5 due to using a non-text mark alone to convey information
Note: Glyphs are non-text marks.
This is insane. Unicode [6]defines glyph as:
1. An abstract form that represents one or more glyph images.
2. A synonym for glyph image. In displaying Unicode character data, one or more glyphs may be selected to depict a particular character.
In Web content, glyphs are text marks.
http://www.w3.org/WAI/GL/2006/07/10-wcag-teamc-minutes#item06 Michael to propose additional information about what glyphs are and are not, and what would be relevant to to this failure condition
The definition of a "glyph" includes representations of text characters, punctuation, and pictorial and decorative character symbols. It was not the intention to exclude text representations. The title of the failure has been modified to refer instead to "graphical symbols", the note has been removed, and the description in F26 has been modified to clarify this point.
Comment:
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0120.html
Using an image for "0m" (circle mark) or "×" (cross mark) instead of text and providing alternative text for the image which describes the meaning of its mark
Those circle and cross marks are text. Even the Understanding document itself uses them as such. (The "cross mark" is incorrectly chosen. What is depicted is a [7]multiplication symbol.) WAI may wish to look at Unicode characters like U+2611 BALLOT BOX WITH CHECK.
We have reworded the technique title to distinguish between an image of a graphical symbol and a font glyph that happens to have the same appearance but a different meaning.
Part of Item: Techniques
Comment Type: general comment
Comment (including rationale for proposed change):
Web safe colors, web friendly colours
The access Working group GOC has recently made a requirement for web friendly colours.
They believe that some versions of magnifiers (older) only handle web safe or web friendly colours and then they dither non friendly colours. They believe that the dithering process will affect contrast. For instance, a light background that is not safe might get dithered darker, and a dark foreground might be dithered lighter. And the combination could cause lower overall contrast in older user agents.
Proposed Change:
Discuss why or why not web safe/friendly is an issue.
Add something like:
Note: some older user agents are limited to web friendly, web safe colours. If older user agents in your baseline, use web friendly/safe colours.
The group does not have any evidence of significant accessibility issues arising from the use of non-safe web colours. The Web-safe colour palette is the 216-colour intersection of the 256-colour palettes of the Windows and Mac OS of the 1990's. Neither Windows nor Mac uses those palettes by default, nor do Unix variants, so this concern appears to have been overcome by technology advances.
5. Source order must match presentation order even at the lowest
level ... why?
SC 1.3.3 does not require that the source code order match the presentation order, it requires that it be possible to programmatically determine at least one sequence of the content that makes sense. Making the source code order match the presentation order (assuming the presentation order makes sense) would be a sufficient technique, at least in HTML. However, if the technology supports it, other techniques to achieve this objective would also be sufficient, some of which are listed. Source code order is not currently listed as a sufficient technique and has specifically been de-emphasized by the Working Group.
The Dynamic Web Accessibility Adaptable States and Properties module includes a describedby property which provides help text to describe the object. This maps to platform accessibility APIs as well.
Proposed Change:
Add an XHTML technique that demonstrates using Dynamic Web Content Accessibility "describedby" property.
We have created a technique titled, "Using Accessible Rich Internet Application describedby property to provide a descriptive, programmatically determined label". This is an advisory technique for Success Criteria 1.3.1, 2.4.4 and 2.4.5. It can be moved to a sufficient technique when Accessible Rich Internet Application specifications reach W3C recommendation status and are well supported.
Users who are filling out forms need a mechanism to indicate whether form elements are required. This is addressed in XForms and Dynamic Web Accessibility by indicating if a form field is required or invalid. If the user does not know a field is required form submissions will fail and the user must repeat the process.
Proposed Change:
Add an XHTML technique to How to meet 1.3.1 that demonstrates using Dynamic Web Content Accessibility attribute of required=""true"".
Such a technique could also be useful in meeting GL 2.5 but there is no success criteria to relate it to. It could be an advisory technique under ""Understanding guideline 2.5"" or listed as a related technique under the GL 2.5 success criteria.
Thank you for the suggestion. We have created an advisory technique for SC 1.3.1 on how to use the Dynamic Web Content Accessibility 'required' attribute to programmatically mark a form field as required. This is an advisory technique until the Dynamic Web Content Accessibility specification reaches recommendation status.
Part of Item: Examples
Comment Type: editorial
Comment (including rationale for proposed change):
It would be helpful to show working examples of the code sample given. This would be useful in other places in the document as well. I don\'t want to create HTML files for each example.
Proposed Change:
Create the working examples.
This is already true for some of our examples. We intend to continue to create working examples and convert examples to working examples as we continue to develop the Techniques document(s) and other support materials.
We have added a note to the status section of the techniques draft to clarify our plans to include working examples.
Part of Item: Intent
Comment Type: substantive
Comment (including rationale for proposed change):
Highlighting information should also be mentioned. Many people highlight text using just a span and it is a cue to visusal users but not to computer devices.
Proposed Change:
Add highlighting to the list that includes emphasising, headers, strong, etc. I recommend that highlighting is a special form of em tag using css.
SC 1.3.1 and 1.3.4 have been combined to read "Information and relationships conveyed through presentation can be programmatically determined or are available in text, and notification of changes to these is available to user agents, including assistive technologies." The How To Meet document for this combined success criterion does include highlighting via a background color in the intent section. In addition, another example about highlighting has been added to Technique G115: Using semantic elements to mark up structure.
Part of Item: Intent
Comment Type: substantive
Comment (including rationale for proposed change):
Multimedia documents are not mentioned. There are many flash documents that have a constantly moving background which is highly distracting.
Multimedia should also be mentioned with luminosity and other sections. It may, however, be out of the scope of the document.
Proposed Change:
Include multimedia in the recomendations so people will not be in compliance if they use obnoxious moving backgrounds.
This is covered by Success Criterion 2.2.3. The background would need to be paused unless it were essential.
Part of Item: Intent
Comment Type: general comment
Comment (including rationale for proposed change):
A few other pointers that should be included.
-Don\'t use the same term/word/sentince to symbolize a link if they go different places
-show links have been visited
-don\'t recommend to repeat the same text over and over hard on screen readers.
Proposed Change:
Add the aditional pointers.
Success criterion 3.2.4, "Components that have the same functionality within a set of Web pages are identified consistently." means that links that go to the same place should have the same description. If links that go to different places have the same description, then the description is not sufficient to determine the purpose of the link. The Intent section of How To Meet SC 2.4.4 points this out: "Links with the same purpose and destination are associated with the same description (per Success Criterion 3.2.4), but links with different purposes and destinations are associated with different descriptions."
Showing links that have been visited is a User Agent responsibility, and is required by Checkpoint 10.2 of the User Agent Accessibility Guidelines (Highlight selection, content focus, enabled elements, visited links). Success Criterion 4.1.2 has been modified to require that the state of interactive controls be programmatically determined, so that user agents can satisfy this requirement.
Avoiding unnecessary text repetition is an issue that the working group has struggled with. Often, text repetition is introduced by the desire to have link descriptions that make sense when read out of context. SC 2.4.4 permits links to have descriptions that depend on their context, so that contextual information won't have to be repeated.
Part of Item: Intent
Comment Type: general comment
Comment (including rationale for proposed change):
Also applies to other sections.
The content must be identical. If you allow people to use mutliple versions, you must tell them that they have to keep the two identical because it is an easy way to create discrepancies and then there is an information gap. I would rather have one accessible version that exists.
Proposed Change:
While we agree that a single accessible version is desirable, the working group recognizes that there can be good reasons for providing multiple versions. The author may wish to provide different versions that use different sets of technologies, or may wish to provide versions that are tailored for people with particular disabilities.
To make it clearer that the content must be equivalent, we have revised the definition of alternate version:
"version that provides all of the same information and functionality in the same natural language and is as up to date as any of the non-conformant content"
In addtion, we have revised the conformance section on alternate versions:
Alternate Versions: If the Web page does not meet all of the success criteria for a specified level, then a mechanism to obtain an alternate version that meets all of the success criteria can be derived from the nonconforming content or its URI, and that mechanism meets all success criteria for the specified level of conformance. The alternate version does not need to be matched page for page with the original (e.g. the alternative to a page may consist of multiple pages). If multiple language versions are available, then conforming versions are required for each language offered.
Part of Item: Intent
Comment Type: general comment
Comment (including rationale for proposed change):
I would add another section to 3.1 that alows users to increase or decrease the text size through the browser or the website. Or the text will work with multiple default text sizes. I think this is a bigger deal than screen readers and zooming in. Most 50 people have bad eyesight and don\'t know how to use windows zoom, but can be taught the make text bigger trick and have it as a large size by default. This breaks some websites and makes the content un-usable.
Proposed Change:
Add a section under 3.1 that allows users to increase the text size a reasonable amount and still have the website readable/usable/etc.
Although resizing is primarily a user agent function, we have added new success criteria to address the author's responsibility for supporting text resizing:
Level AA: Visually rendered text can be resized without assistive technology up to 200 percent and down to 50 percent without loss of content or functionality.
Level AAA: Visually rendered text can be resized without assistive technology up to 200 percent and down to 50 percent without loss of content or functionality and in a way that does not require the user to scroll horizontally.
Part of Item: Intent
Comment Type: general comment
Comment (including rationale for proposed change):
It would be extremely useful to have an easy way to refer to specific guidelines and success criteria. Trying to refer to them by numbers or their long text is awkward. More importantly, it is a significant barrier to common Web developers being able to communicate about them, and it makes the guidelines even more esoteric.
I propose including “shortnames�? or “handles�? in the “Understanding�? doc. I understand that it is quite difficult to do. I think it is OK for them to not be technically accurate, and instead make them easy and use common terminology, e.g.,:
- “Alt-text�? for “Guideline 1.1 : Provide text alternatives for all non-text content�?
- “Multimedia alternatives�? for “Guideline 1.2 : Provide synchronized alternatives for multimedia�?
- “Separate content and presentation�? for “Guideline 1.3 : Ensure that information and structure can be separated from presentation�?
- “Contrast�? for “Guideline 1.4 : Make it easy to distinguish foreground information from its background�?
I understand the concerns with shortnames/handles being used inappropriately; however, I think the benefits far outweigh the risks.
Also, I think that putting these in the “Understanding�? doc and not the /TR/WCAG10 doc helps some with concerns about them not being insufficient to convey the full meaning of the long text.
Proposed Change:
Include shortnames/handles for each guideline and success criteria (and principle while you’re at it since those are easy :).
We have included short handles in the draft to make the success criterion easier to reference.
Part of Item: Intent
Comment Type: editorial
Comment (including rationale for proposed change):
reposting the comment at:
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006Jun/0225.html
due to incorrect paste of comment.
(Helpful detail in \"Understanding WCAG 2.0.\" EOWG sends its compliments)
Unclear purpose of document.
Proposed Change:
The Introduction needs an opening statement along the lines of \"this is not an introductory document - it is a detailed description of the guidelines and their success criteria\" and adds a pointer to the \"Overview\"
document for people requiring a simple introduction.
Thank you. We have added the following paragraph to the Introduction.
WCAG 2.0 itself is a technical standard designed primarily for Web developers and designers, authoring tool developers, evaluation tool developers, and others who need a technical standard for Web accessibility. Due to the technical and technology-independent nature of the guidelines and success criteria, and because they say what needs to be done rather than how to do it, it may sometimes be difficult to use the guidelines or success criteria for specific advice for a particular technology (e.g. HTML, XHTML, JavaScript etc)."
Part of Item: Intent
Comment Type: editorial
Comment (including rationale for proposed change):
The title of \"Understanding WCAG 2.0\" continues to be a concern for EOWG, because of several possible misinterpretations.
Proposed Change:
EOWG recommends adding an exlanatory subheading to the document. Suggestions include:
a. Your guide to meeting the requirements of WCAG 2.0
b. A guide to How to Meet the Web Content Accessibility Guidelines 2.0
c. A definitive guide to meeting WCAG 2.0
d. The authoritative, encyclopaedic and indispensable guide to WCAG2.0
e. A guide to learning and implementing WCAG 2.0
f. A guide to understanding and using WCAG 2.0
We have added a subheading that reads, "A guide to understanding and implementing WCAG 2.0."
Part of Item: Intent
Comment Type: editorial
Comment (including rationale for proposed change):
For each guideline & success criteria, provide a couple of word summary, rather than just a number. Sometimes referred to as \"shortname\".
Proposed Change:
We have included short handles in the draft to make the success criterion easier to reference.
Part of Item: Intent
Comment Type: editorial
Comment (including rationale for proposed change):
Proposed Change:
Please add explanations of the four principles to the Understanding document.
We have added a section to Understanding WCAG 2.0 titled, "Understanding the Four Principles of Accessibility." which includes additional explanation.
Advisory techniques: There should not be any advisory techniques unless they are linked to a particular SC. Having advisory techniques linked to a GL only, means that the level (A, AA or AAA) is not specified.
Proposed Change:
Move all GL advisory techniques to specific SC
Because WCAG 2.0 success criteria are written as testable statements, it is not always possible to associate techniques that are difficult to test or subjective in nature with success criterion. However, the working group feels that it is important to make these technqiues available for authors who are interested in improving the accessibility of their content beyond the minimum conformance requirements. Note that regardless of association with a success criterion or guideline, whether an author chooses to implement advisory technqiues does not impact the level of conformance claimed.
Add failure: Add a failure where a long description is not descriptive enough
Proposed Change:
I am happy to create this failure
Thank you for the suggestion. We have created a Failure Technique for Success Criterion 1.1.1 titled, "Failure of 1.1.1 due to providing long description for non-text content that does not serve the same purpose or does not present the same information."
Example 3: Why isn't a long description required?
Proposed Change:
Add to example that a long description is required which gives the same information as the image
Since the animation is fully explained in text a longdesc would be redundant and end up having the user who is blind listening to the description twice. So the alternate text provides a short description and mentions that the animation is described in the text that follows it.
Example 6: Add another alt text example "Shaking a world leader's hand can subtly affect the distribution of power in the relationship" and "Shaking hands is a purely Western artifice"
The Working Group feels that your first proposed example reveals an opinion and is thus not appropriate alternative text for the situation described in the photograph. While the second alternative may be true, it does not sufficiently describe the image. We have not updated the example with these additional