Edit comment LC-842 for Accessibility Guidelines Working Group

Quick access to

Previous: LC-799 Next: LC-545

Comment LC-842: Comment Shortname:; Commenter: Joe Clark <joeclark@joeclark.org>; Message-id:; Section of the document concerned:

or; Refinement of the section concerned:; Status:
assigned to; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
See article TO HELL WITH WCAG 2.0 at: http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0118.html; Related issues: (space separated ids); WG Notes: [EDITORZ] @@@ Fair statement to add to reponse? --> It should be noted that other W3C standards do not require conformance to other standards. Discussed in the 19 April 2007 telecon: resolution: accept as amended http://www.w3.org/WAI/GL/2007/04/19-wai-wcag-minutes.html {partial accept} @@Response to commenter:; Resolution: Given the format of the article it is difficult to know exactly what issues the comment would like the Working Group to address. We have attempted to extract issues from the article that apply to the Guidelines document. [THWW] 1. Exactly what a "page" is, let alone a "site," will be a matter of dispute. Response: We have replaced the term "Web unit" with "Web page". [THWW] 2. A future website that complies with WCAG 2 won't need valid HTML--at all, ever. (More on that later.) You will, however, have to check the DOM outputs of your site in multiple browsers and prove they're identical. Response: Validity is still not required (although it is the #1 recommended sufficient technique for meeting SC 4.1.1). Also, SC 4.1.1 has been changed to "Content implemented using markup languages has elements with complete start and end tags, except as allowed by their specifications, and are nested according to their specifications." There are no longer techniques based on DOM outputs. [THWW] 3. You can still use tables for layout. (And not just a table--tables for layout, plural.) Yes, this is correct. Although WCAG 2, like HTML 4.01, does not prohibit the use of layout tables, CSS-based layouts are recommended in order to retain the defined semantic meaning of the HTML table elements and to conform to the coding practice of separating presentation from content. [THWW] 4. Your page, or any part of it, may blink for up to three seconds. Parts of it may not, however, "flash." Reponse: This is correct. Short blinking to get attention is allowed as long as it doesn't last long. Flashing is also allowed if it is very small or not very intense. Flashing that is known to cause seizures however is not allowed. The glossary defines the difference between blink and flash: Blink: turn on and off between 0.5 and 3 times per second Note: The slower blink is in contrast with flashing, which refers to rapid changes in brightness which can cause seizures. See general flash threshold and red flash threshold. [THWW] 5. You'll be able to define entire technologies as a list of the specific Baseline Technologies meaning anyone without that technology has little, if any, recourse to complain that your site is inaccessible to them. Response: The term "baseline" has been replaced by "web technologies that are accessibility supported". We have clarified what needs to be true about user agent support (including AT) for a technology to be considered accessibility-supported. Of course users may challenge the assessment of whether a technology is accessibility-supported. [THWW] 6. You'll be able to define entire directories of your site as off-limits to accessibility (including, in WCAG 2's own example, all your freestanding videos). We have changed the wording to make this clearer. As with all W3C content technologies, you state what conforms. We are leaving to customers, organizations or policy makers to set policy about what a site is and how much of it must conform. [THWW] 7. If you wish to claim WCAG 2 compliance, you must publish a checklist of declarations more reminiscent of a forced confession than any of the accessibility policies typically found today. Response: The required information for a claim doesn't seem excessive or onerous: 1. The date of the claim 2. The guidelines title/version 3. The guidelines URI 4. The conformance level you are claiming 5. A list of the specific technologies you have relied upon (and are assuming are accessible) in making your claim 6. What it is that you are claiming conforms (which URIs). The rest of the points in a conformance claim are all optional. [THWW] 8. Not that anybody ever made them accessible, but if you post videos online, you no longer have to provide audio descriptions for the blind at the lowest "conformance" level. And only prerecorded videos require captions at that level. Response: this is correct. [THWW] 9. Your podcasts may have to be remixed so that dialogue is 20 decibels louder than lengthy background noise. (You don't have to caption or transcribe them, since they aren't "multimedia" anymore. However, slideshows are now officially deemed to be "video," which will come as a surprise to Flickr users.) Response: SC 1.4.5 (the background sound requirement) is a Level AAA requirement. If you want to make your podcasts very accessible you would not have loud background sounds behind your speech. If the podcast is just speech with no other significant sounds, then captions are not required but a transcript is (under 1.1.1 since it is non-text content). Slideshows that have audio would be multimedia. A slideshow without sound or interaction would not be multimedia. [THWW] 10. You can put a few hundred navigation links on a single page and do nothing more, but if you have two pages together that have three navigation links each, you must provide a way to skip navigation. Response: this is correct. [THWW] 11. You can't use offscreen positioning to add labels (e.g., to forms) that only some people, like users of assistive technology, can perceive. Everybody has to see them. Response: We have made this clearer. Labels are visible names on user interface elements. Names are sometimes visible and sometimes not, but are accessible to AT. Unless it is visually very obvious what a control is for, names should be visible (labels) to make the forms easier for people with cognitive disabilities. [THWW] 12. CSS layouts, particularly those with absolutely-positioned elements that are removed from the document flow, may simply be prohibited at the highest level. In fact, source order must match presentation order even at the lowest level. Response: CSS layouts are not prohibited. Source order must match presentation order only when it would change the meaning of the content to present it in a different order. [THWW] 13. Also at the highest level, you have to provide a way to find all of the following: 1. Definitions of idioms and "jargon" 2. Expansion of acronyms 3. Pronunciations of some words Response: this is correct. [THWW] 14. You also have to provide an alternate document if a reader with a "lower secondary education level" couldn't understand your main document. (In fact, WCAG 2 repeatedly proposes maintaining separate accessible and inaccessible pages. In some cases, you don't necessarily have to improve your inaccessible pages as long as you produce another page.) Response: Providing an alternate document is one option for satisfying SC 3.1.5. Providing supplemental information, such as illustrations or multimedia, would be another way. Or writing your content in simpler language in the first place. WCAG does not encourage separate accessible pages. WCAG 2 permits alternate versions of Web pages because it may be helpful to have a version of a page that is tailored for particular disabilities, particularly for cognitive, language, and learning disabilities. Alternate versions may also be used if an author is providing different versions for users with different user agent capabilities. In order to claim conformance, the alternative pages must provide equivalent information and an accessible mechanism for finding the conforming version. [THWW] What do the following terms really mean? authored unit authored component web unit parsed unambiguously programmatically determined Response: "authored unit", "authored component", and "parse unambiguously" have been removed from the guidelines. "Web unit" has been replaced by "Web page". "Programmatically determined" remains. It is a new term to express the ability for user agents including AT to access information. We have added examples to the definition to clarify. [THWW] Testability section: Response: The testability paragraph of the Conformance section now reads "All WCAG 2.0 success criteria are written to be testable. While some can be tested by computer programs, others require human testers for part or all of the test. When people who understand how people with different types of disabilities use the Web test the same content using the same success criteria, the same results should be obtained with a high level of confidence." [THWW] Testability - "you'll notice that even something as deceptively simple as that WCAG 1 guideline on clear and simple writing isn't there." Response: Testability is important so that an author can determine whether WCAG has been satisfied. The "Clear and simple" provision from WCAG 1.0 is not in WCAG 2.0 as a Success Criterion because there is no way for an author to tell whether language is "clear and simple". While there might be agreement that one version is simpler than another, how does an author know that the simpler version doesn't need to be simplified further? When does it reach "clear and simple". When is a page on string theory or quantum mechanics 'clear and simple'? This has been a tough area that the working group has wrestled with. The working group has tried to find ways to address this and related issues both through testable requirements and through advisory techniques. WAI is also exploring a separate activity to see what new techniques can be developed to address cognitive, language and learning issues, as well as to find ways to provide focused advice on just this area. This effort will look at how this is addressed throughout different parts of WAI's work. [THWW] Conformance levels Response: The description of conformance levels in WCAG 2 has been rewritten to clarify these issues: The word "levels" does not mean that some success criteria are more important than others. Each success criterion in WCAG 2.0 is essential to some users, and the levels build upon each other. However, even content that conforms at AAA (triple-A) may not be fully accessible to every person with a disability. *In general, Level A success criteria achieve accessibility by supporting assistive technology while putting the fewest possible limits on presentation. Thus people with a wide range of disabilities using a wide range of assistive technologies, from voice input and eye-tracking devices to screen readers and screen magnifiers, are able to access content in different ways. In other words, Level A success criteria support the ability of both mainstream and specialized user agents to adapt content to formats that meet their users' needs. * The success criteria in Level AA provide additional support for assistive technology. At the same time, they also support direct access to content by the many people who use conventional user agents without assistive technology. In general, Level AA success criteria place more limits on visual presentation and other aspects of content than the success criteria in Level A. *Level AAA success criteria increase both direct access and access through assistive technology. They place tighter limits on both presentation and content." [THWW]: Standards Response: The working group looked at the topic of standards compliance carefully over an extended period of time and concluded that requiring strict adherence to all aspects of specifications does not necessarily result in an increase in accessibility. For example, it is possible to create invalid pages that present no accessibility barriers. It is also possible in certain situations to enhance accessibility through the use of markup that is not part of the specification. The working group must work within its charter and only include things that directly affected accessibility. Some aspects of "use technologies according to specification" and validity do relate to accessibility. However, others do not. So requiring validity would take us beyond our charter. We do recommend it though and it is our #1 technique listed for conforming to SC 4.1.1. It should be noted that other W3C standards do not require conformance to other standards. [THWW]: Captioning and audio description for multimedia Response: It is difficult to tell what WCAG 2 changes you would like to see in this area, but it sounds as if you would like the requirement for audio description and captioning of live multi-media to be Level A requirements, while deploring the lack of support for these WCAG1 requirements. The feasibility of providing captions and audio description for all live content on the Web is a major question. We have received many comments on both sides of this issue. After reviewing them all and extensive discussions, the consensus of the working group was to go with the current provisions as a best fit to the issues.; (Please make sure the resolution is adapted for public consumption)