248 results found.
Item Number: Success Criterion 1.3.1
Part of Item:
Comment Type: TE
Comment (Including rationale for any proposed change):
It appears that SC 1.3.1 encompasses many separate guidelines that were specified in WCAG 1.0, including the requirement to associate data table cells with the appropriate row and column headings and requirements relating to the labelling and grouping of form controls. I presume part of the reason for combining such a diverse range of accessibility needs in single success criteria is the desire to have criteria that are "technology-independent".
In my experience, a lage proportion of the problems assistive technology users now experience when using web sites result from the sites failing comply with the WCAG 1.0 guidelines that are now nominally covered by SC 1.3.1. Nearly all web content is currently presented using (x)html and this is likely to continue to be the case for the foreseeable future. However WCAG 2.0, which is the normative document, provides web developers with no practical guidance or clues in how to avoid these problems.
The link "How to meet 1.3.1" leads to information in the "Understanding WCAG 2.0" document, which describes techniques for addressing the criterion. The "Understanding" document contains links to eleven HTML techniques, which are presented in yet another document, "Techniques for WCAG 2.0".
Frankly, I don't imagine many developers when faced with the prospect of preparing a data table will bother to troll through three documents in order to see why it is important to associate data cells with row and column headers in a non-visual way. On a related point, why don’t the "Understanding WCAG 2.0" HTML Techniques include the need to use TH for tables with single levels of row and column headers?
I am concerned that the failure to provide guidance in relation to crucial html issues in the WCAG 2.0 document will lead to a decline in awareness on the part of developers regarding their importance and this will contribute to a fall in the overall accessibility of websites and the web as a whole.
I believe the Working Group should get over their hang up with developing some sort of technology neutral standard and recognise that the way to bring the greatest accessibility gains to the greatest proportion of web users is by providing practical advice in how to improve the accessibility of (x)html sites.
Proposed Change:
In my view, WCAG 2.0 Guideline 1.3 should include success criteria for the specific issues that are addressed in the following WCAG 1.0 Checkpoints: 3.1, 3.5, 3.6, 5.1, 5.2, 5.5 and 12.4.
Since this is unlikely to happen, I would like to urge the Working Group to consider providing HTML example for each of the issues covered by the checkpoints above in the core WCAG 2.0 document so that SC 1.3.1 is able to provide the majority of web developers with a clear indication of how to meet this criterion.
If the normative guidelines include the HTML-specific success criteria, then tables, forms, headings, etc. could only conform to WCAG 2.0 if they are implemented in HTML. Tables, forms, headings, etc. implemented in any other technology, such as PDF, could not conform to WCAG 2.0. It is expected that many HTML developers will simply go directly to the HTML Techniques instead of starting with the guidelines document.
With regard to your specific recommendations on addressing WCAG 1.0 checkpoints 3.5, 3.6, 5.1, 5.2, 5.5 and 12.4, these checkpoints are addressed in the following WCAG 2.0 techniques:
- 3.5; H42: Using h1-h6 to identify headings http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H42
- 3.6; H48: Using ol, ul and dl for lists http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H48
- 5.1; H51: Using table markup to present tabular informationhttp://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H51
5.2; H43: Using id and headers attributes to associate data cells with header cells in data tables http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H43 AND H63: Using the scope attribute to associate header cells and data cells in data tables http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H63
- 5.5; H73: Using the summary attribute of the table element to give an overview of data tables http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H73
- 12.4; H44: Using label elements to associate text labels with form controls http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H44
With regard to the comment about why the Understanding WCAG 2.0 HTML
Techniques don't include the need to use TH for tables with single levels of row and column headers, this requirement is covered in technique H51: Using table markup to present tabular information
http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#H51
Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):
In the definition of "Web unit":
"identified by a single Uniform Resource Identifier (such as URLs)"
This is not only grammatically wrong but rather sloppy language for a specification.
Proposed Change:
"identified by a single Uniform Resource Identifier (URI)"
Consider whether to add a note stating that a URI is either a Uniform Resource Locator (URL) or a Uniform Resource Name (URN). Is this still correct?
We changed "identified by a single Uniform Resource Identifier (such as URLs)" to "identified by a single Uniform Resource Identifier (URI)."
Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):
Terminology used in related technical specifications should be consistent, unless there are compelling reasons to the contrary. There are no strong reasons why basic terminology in WCAG 2.0 should differ from ATAG, UAAG and indeed WCAG 1.0.
Proposed Change:
Change "principles", "guidelines" and "success criteria", respectively, to "guidelines", "checkpoints" and "provisions" throughout WCAG 2.0 and supporting documentation.
The elements in WCAG 2.0 differ from those in the other documents. Using the same terms would be misleading. For example what you suggest we list as checkpoints are guidelines in this document. The success criteria would be the closest thing to checkpoints but they would be under checkpoints with the labeling you propose, so the things you must check off would not be the checkpoints but what was under them. Also, we have a checklist that is success criteria. To label the guidelines as checkpoints but have different things be in the checklist would be confusing.
Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):
Should the sentence begin with "Content" or with "The content" (i.e., the content subject to WCAG 2.0 conformance)?
Proposed Change:
Change "Content" to "The content" if appropriate, making sure that it is consistent with wording used elsewhere (i.e., make the change consistently).
When the word "the" is used before a word it means that the writer is referring to the instance of this word that occurred previously. If we begin a success criterion with "the content" it would mean that we were referring to the the content in the previous sentence. This is not always true. In fact, in different places, there is a different use of the word content that preceeds it. Therefore "the content" is used before content only if the word content has already been introduced in the same sentence (or paragraph).
Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):
Principle 3 refers to "controls" ("content and controls"). Are "controls" the same as "user interface components within the content" mentioned in guideline 2? I think they are, or should be, the same and accordingly that the same terminology should be used.
Proposed Change:
Change "content and controls" in Principle 3 to "content and user interface components" or, perhaps better, "content (including any user interface components it contains)".
We are trying to avoid parentheticals in the princples so Principle 3 has been updated to read, "Principle 3: Understandable - Information and operation of user interface must be understandable by the user. "
Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):
The content (i.e., everything within the scope of conformance), can and in many instances will consist of multiple Web units.
Proposed Change:
Change "the Web unit" to "every Web unit", or "every Web unit within the content".
Success Criterion 3.1.1 has been changed to read, "The default human language of each Web page within the content can be programmatically determined."
Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):
The same as 3.1.1.
Proposed Change:
Change "the Web unit" to "Every Web unit" (or whatever language is chosen to clarify this).
"Web unit" is not needed here because the requirement applies to any type of content for which a claim would be made. Success Criterion 3.1.2 has been revised to read, "The human language of each passage or phrase in the content can be programmatically determined."
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: Important New Terms Used in WCAG 2.0
Part of Item:
Comment Type: GE
Comment (Including rationale for any proposed change):
Very simple really; WCAG guidelines language is too technical and very hard to follow, never mind tweaking a web page to adhere to these standards, if you want universality you should write in a accessible language.
Proposed Change:
use common understandable language for 2.0!
We understand that the language is technical in places. We have tried to make it as easy to read as possible while still being technology independent and accurate. It is very hard. We have made some changes again in response to last call comments. Suggestions are always welcome.
Item Number: (none selected)
Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):
The language used in the Last Call version of WCAG 2 is considerably more readable and understandable than that used in the previous draft. However, the desire for technological neutrality means that WCAG 2 provides very little practical guidance in how to improve the accessibility of websites. The supporting documents do contain specific examples and techniques, but in reality most site developers are very busy and not particularly interested in accessibility and so there is little chance of them searching out this information.
For example, I wonder how many people are likely to realise the need to use header elements appropriately is covered by 1.3.1, "Information and relationships conveyed through presentation can be programmatically determined, and notification of changes to these is available to user agents, including assistive technologies."
Proposed Change:
Since at this time most people use HTML, it would be useful to include specific HTML-related example of how to implement the guidelines in the core document. With reference to the example above, include the following (which is out of WCAG 1) “User header elements to convey document structure. For example, in HTML, use H2 to indicate a subsection of H1.
In an effort to make it clear what is normative and what is informative, we have kept all examples out of the guidelines themselves. We expect many texts to be developed that would do a better job of teaching the guidelines. We have had to focus our efforts on creating a clean and concise version of the guidelines. We have tried to put links to "how to meet" next to each guideline to make it easier without putting all the informative information directly into the guidelines.
We'd also like to bring your attention to the draft "WCAG 2.0 Quick Reference" document. The WCAG 2.0 Quick Reference is a summary of all WCAG 2.0 requirements (success criteria) and techniques sufficient to meet them. http://www.w3.org/WAI/WCAG20/quickref/
Item Number: Technology assumptions and the
Part of Item:
Comment Type: ED
Comment (Including rationale for any proposed change):
For the section prior to ...assumptions and the baseline... which isn't included in the items that can be commented on.
References are made to Level 1 2 3, then Note 1 that follows refers to Triple-A conformance. Prior to this though, there has been no mention of A, AA, AAA confomance rankings. Novices to the guidelines may not make the connection if it is not described explicitely. Not until much further down the page is the association made.
Proposed Change:
Perhaps a note explaining the association, or a reference to an anchor further down the page would be appropriate here.
We have completely rewritten the introduction and the conformance section, and conformance levels are now defined before they are used.
Part of Item: (none selected) Applicability
Comment Type: GE
Comment (including rationale for proposed change):
I believe the title "Techniques for WCAG 2.0" is misleading. As the document is about failures to correctly address accessibility, I believe the document should be retitled.
Proposed Change:
Retitle "Techniques for WCAG 2.0" as "Failures in Technique for WCAG 2.0".
We have added the subtitle "Techniques and Failures for WEb Content Accessibility Guidelines 2.0".
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
It is not at all clear how one would provide a regular expression to scope a claim that would apply to a whole site except one or two
diretories, e.g. the whole of http://www.example.com/ except /videos/
Proposed Change:
Add examples for less straight forward conformance scope regular expressions.
An example of both a boolean and a regular expression conformance claim has been added (see http://www.w3.org/TR/2007/WD-UNDERSTANDING-WCAG20-20070517/Overview.html#uc-239-head ):
Example 4: (using boolean logic) On 6 July 2008, http://example.com/ AND NOT (http://example.com/archive/ OR http://example.com/publications/archive/) conforms to Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2006/REC-WCAG20-YYYYMMDD/. Double-A (AA) conformance. The documented set of accessibility-supported content technologies used for this claim is ISA- AsCTset#1-2008 at http://ISA.example.gov/AsCTsets/AS2-2008.
Example 5: (using a regular expression) On 12 August 2008, http://www.example.com/(marketing|sales|contact)/.* conforms to Web Content Accessibility Guidelines 2.0 at http://www.w3.org/TR/2006/REC-WCAG20-YYYYMMDD/. Double-A (AA) conformance. The technologies that this content "relies upon" is: XHTML 1.0 Transitional. The technologies that this content "uses but does not rely upon" are CSS 1.0 and JavaScript 1.2.
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
The success criteria, stripped of the supporting documentattion, are amazingly concise - well done to all concerned.
Proposed Change:
(none)
Thank you. We appreciate you taking the time to fill out the comment form to include this feedback.
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.
Part of Item: Applicability
Comment Type: GE
Comment (including rationale for proposed change):
The relationship with the main WCAG document should be bi-directional, and the document should be able to "stand alone",especially if (as I was) you're working from a printed copy of the document.
Proposed Change:
Add relevant SC text to the start of each of the "Failure" sections.
Good idea. We have changed the title "Technique referenced from" to "Failure relates to" and put the following links under that title
* SC X.X.X
* How to Meet SC X.X.X
Part of Item: Related Techniques
Comment Type: GE
Comment (including rationale for proposed change):
To aid navigation of hardcopy versions of the document, removing the need to keep refering to the table of contents.
Proposed Change:
Add the relevant section numbers to the internal link texts in "Related Techniques".
We have changed references to "Related Techniques" so that they include the Number of the techniques (e.g. H45 ) along with the name.
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
I have reviewed the materials at this site and find that they are accurate.
Proposed Change:
From a user\'s and pedagogical perspective, can you simplify the documents so that they are easier for people to read? My students want to design accessible websites; however, they have difficulty interpreting the material at your site.
We have reworked the entire document to make it shorter and easier to read. This includes:
- Shortening the introduction
- Moving much of the discussion out of the guidelines and puttin it in the Understanding WCAG 2.0 document
- Shortening the conformance section and moving it after the guidelines
- Writing simpler guidelines
- Removing as many technical terms (jargon) as possible, replacing them with simpler language or their definitions
- Removing the nesting of definitions where we could (i.e. definitions that pointed to other definitions)
- Moving information about mapping between WCAG 1 and WCAG 2 to a separate support document (so it can be updated more easily)
- Creating a Quick Reference documents that has just the Guidelines, success criteria and the techniques for meeting the success criteria.
- Trying to word things in manners that are more understandable to different levels of Web expertise
- Adding short names/handles on each success criterion to make them easier to find and compare etc.
- Simplifying the conformance section
- Using plainer language wherever possible (e.g. – use “Web page� instead of “Web Unit�)
- Eliminating several new or unfamiliar terms. (authored unit, etc.)
- Making the whole document much shorter.
Part of Item:
Comment Type: ED
Comment (including rationale for proposed change):
Re the statement, \"Following these guidelines will also make your Web content more usable to many other users, including older users.\": Older users?! Really? How old? Over 40? 50? 60? Is there proof that \"older users\" need help using the Web just because they\'re over a certain age?
Proposed Change:
Delete this sentence.
Not all older people have disabilities. However, the percentage increases steadily and sharply with age. We have clarified this by changing the sentence to "Because many people develop vision, hearing, cognitive or motion impairments as they age, following these guidelines will make your Web content more usable by many older users."
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
My main objection to WCAG 2.0 is that it is simply too big. Brevity has been abandoned in favor of excessive, often pedantic, discussion. Developers coming to WCAG 2.0 will want immediate, accessible answers that address their problems. Instead, they must follow multiple links in order to gain information about even the simplest topics (e.g., text alternatives). It\'s often necessary to wade through lengthy explanations and rationalizations before arriving at useful information, and this information is frequently cloaked in roundabout language (\"baseline?\" \"Web unit?\") that never makes a direct point.
If the W3C releases WCAG 2.0 in anything resembling its current form-- not just the guidelines document, but the related documents as well, because WCAG 2.0 can\'t really be used without them-- it must then be prepared to defend this document from backlash by a perplexed, bewildered general public. WCAG 2.0 is longer and more labyrinthine than most other recommendations published by the W3C. What does that say about accessibility? It\'s hard to achieve? It\'s overly complex? It\'s a big pain in the neck? If the WAI wants these *voluntary* guidelines to be widely adopted, they must be re-written in a concise, direct manner.
Proposed Change:
We have reworked the entire document to make it shorter and easier to read. This includes:
- Shortening the introduction
- Moving much of the discussion out of the guidelines and puttin it in the Understanding WCAG 2.0 document
- Shortening the conformance section and moving it after the guidelines
- Writing simpler guidelines
- Removing as many technical terms (jargon) as possible, replacing them with simpler language or their definitions
- Removing the nesting of definitions where we could (i.e. definitions that pointed to other definitions)
- Moving information about mapping between WCAG 1 and WCAG 2 to a separate support document (so it can be updated more easily)
- Creating a Quick Reference documents that has just the Guidelines, success criteria and the techniques for meeting the success criteria.
- Trying to word things in manners that are more understandable to different levels of Web expertise
- Adding short names/handles on each success criterion to make them easier to find and compare etc.
- Simplifying the conformance section
- Using plainer language wherever possible (e.g. – use “Web page� instead of “Web Unit�)
- Eliminating several new or unfamiliar terms. (authored unit, etc.)
- Making the whole document much shorter.
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
Rationale: In my experience, simple magnification is not very helpful for reading web pages. Visual readers with print disabilities always need more. Now, lots of software labeled \"screen magnifier\" does more than magnify, but some products just zoom and that is not very helpful. In the WCAG 2.0 Glossary definition of Assistive Technology, the example of screen magnifier is the only remedy given for individuals with partial sight. There are no examples, other than screen readers, given for other print disabled readers who are sighted. I am afraid that developers who want to test WCAG 2.0 compliance will test against screen magnifiers (especially simple zoom magnifiers) and conclude they have met the needs of sighted users with print disabilities. The example does mention change in color, but there are many other style changes that assist visual reading. Also, motor limitations cause some print disability rather than the more common conditions, dyslexia or partial sight. So I suggest the following example. Note: I had no word for this type of technology so I just coined \"Visual Reading Assistants\". Examples of visual reading assistant products are: specialized style sheets, IBM\'s WebAdapt2Me and Home Page Reader and WYNN from Freedom Scientific. I talked to Phill Jenkins from IBM and he suggested \"Reading Assistive Technology\". That\'s good but might seem circular in the definition of assistive technology. There is a significant needs difference between readers with sight who have print disabilities and readers without sight. While screen readers work for both, sighted readers are never trained in Braille so visually accessible text represents the only static medium available for sighted readers with print disabilities. A static reading medium is necessary for serious literature that requires deep concentration. A non-aural medium is also necessary for deaf readers with print disabilities. Zoom technology does not comes close to addressing this need, so I don\'t want developers coming away with the impression that screen magnifiers solve the problem for this population.
Proposed Change:
Change to definition -- Assistive Technology... Example...
Visual Reading Assistants - Several products modify the document styles such as font size and color, spacing of lines, letters and words, and the font family. These products may also synchronize speech with text, reflow large text to fit the page and add keyboard navigations. They are used by print disabled readers who are sighted but who cannot read standard print formats owing to a variety of visual, perceptual or motor limitations.
We have revised the bullet on screen magnifiers in the definition of assistive technology to:
"screen magnifiers and other visual reading assistants, which are used by people with visual, perceptual and physical print disabilities to change text font, size, spacing, color, synchronization with speech, etc in order to improve the visual readability of rendered text and images;"
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html
Comment (including rationale for any proposed change):
Terms in the document often seem to mean something a bit different, until you read the definitions. As WCAG is often quoted the terms themselves should be as close to clear language as the can be without viewing the definitions.
Proposed Change:
change the term "programticly determined", to "supported by Assistive technology".
We have struggled to make the concept of "programmatically determined" and other terms used in the document as clear as possible. Unfortunately, "supported by assistive technology" captures only part of the meaning of programmatically determined. The author must also have provided the data in a form that makes information and relationships clear by using appropriate markup within the technology.
Note that the definition of programmatically determined has been amended to say "including assistive technology."
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
You have not provided long enough for public review of these guidelines. You\'ve had over 5 years to get them together. Can\'t you give us more than a month?
Proposed Change:
Give us more time to review the guidelines please.
We agreed. Three weeks of additional time was provided.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html
Comment (including rationale for any proposed change):
To get to CR (candidate recommendation we believe two things are required.
1, Concrete checkpoints or list of requirements
2, Tests that completion of the minimum requirements of success criteria at each level will make sites progressively usable for people with disabilities listed in the overview.
Proposed Change:
Create a list of "what to do" checkpoint
We have released the Quick Reference document (http://www.w3.org/WAI/WCAG20/quickref/) which provides a compact list of the success criteria (the checklist items for WCAG 2.0) with the techniques that are sufficient listed directly beneath them. Each technique has a test that can be used to confirm implementation.
If you mean that we need a checklist for getting to CR, there is a list of things that must be met in W3C Process Document.
With regard to your second point, this type of testing is beyond what can be done in CR. This would be an interesting research project but would require considerable funding.
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
To set the scene, I am your average garden-variety web developer. I am a simple soul, with college education, good English skills and above all, good HTML skills. I spend all day, every day, producing sites - for everything from the local dentist to the multi-million pound nation-wide high street chains.
WCAG 2 has disappointed me.
For a start, I just don\'t understand it. I am not stupid, but I just don\'t understand how it applies to what I build. How can I bear all that in mind when going through the stages of planning/building/testing a site?
It\'s going to take months to combine that into my daily routine and to be honest I cannot see the commercial benefit. Most of the sites I build, I make them WCAG 1 level 2 accessible out of good practice and for good karma. I like it; I enjoy the sense of responsibility I get from it. It sets me apart from the monkeys knocking sites out in the back bedroom.
WCAG 2 is so difficult, why would I bother? My customers do not care! If they do, then they will have to pay me a lot to have a compliant site, as the extra amount of time involved does not come for free.
If WCAG 2 was actually simple - a simple to understand a plain-English check list (i.e. - do you use PDF, see page 3, if not continue to page 4 > checklist) along with highly automated checking system, then we are going to see a lot more developers producing compliant sites. Just dream…an internet with more and more compliant web sites. Is that not what we all want?
Proposed Change:
We have reworked the entire document to make it shorter and easier to read. This includes:
- Shortening the introduction
- Moving much of the discussion out of the guidelines and puttin it in the Understanding WCAG 2.0 document
- Shortening the conformance section and moving it after the guidelines
- Writing simpler guidelines
- Removing as many technical terms (jargon) as possible, replacing them with simpler language or their definitions
- Removing the nesting of definitions where we could (i.e. definitions that pointed to other definitions)
- Moving information about mapping between WCAG 1 and WCAG 2 to a separate support document (so it can be updated more easily)
- Creating a Quick Reference documents that has just the Guidelines, success criteria and the techniques for meeting the success criteria.
- Trying to word things in manners that are more understandable to different levels of Web expertise
- Adding short names/handles on each success criterion to make them easier to find and compare etc.
- Simplifying the conformance section
- Using plainer language wherever possible (e.g. – use “Web page� instead of “Web Unit�)
- Eliminating several new or unfamiliar terms. (authored unit, etc.)
- Making the whole document much shorter.
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
I think 2.0 is bloated, and hard to understand. I can see on the one hand why it might need to be a bit more weighty than 1.0 because its scope is much wider (other formats besides HTML are considered). However, what they have come up with is exceedingly complex, convoluted, and not very comprehensible. Its not going to make promotion of accessibility any easier or more practical. In fact, it may have the opposite effect; people will avoid it like the plague, because they don\'t understand it, and they don\'t have time or energy to bother trying!
I\'m not sure exactly what this means in practical terms. I see large corporations saying \"we don\'t have time to deal with this\", and the \"little guys\" just won\'t be bothered at all.
Proposed Change:
I think that instead of trying to incorporate all technologies and all \"disabilities\" into one large framework, WAI should consider breaking it up by technology (HTML/web, PDF and other stand-alone \"document\" formats, etc). Of course, then we get into issues like \"well when will w3c address my xxx format\", but I think format-specific accessibility issues and techniques for addressing those issues are complex enough to warrent being addressed separately. There might also be a more general introductory document that tries to unify things a bit by highlighting the general accessibility issues common among all formats.
Breaking things down by disability might be useful, but again thorny issues arise like \"why hasn\'t the w3c addressed the needs of people with xxx disability\". Realistically, however, most accessibility issues relate to people with vision and hearing loss. Many solutions which address people with these disabilities will also address the needs of people with mobility impairments (input device independence). People with learning disabilities can also bennefit from guidelines not explicitly written for that group: if pages can be used via screen reader, then other intermediary software could use the same information to present the document in a way more conducive to folks with LD. In effect, making something usable by someone using a screen reader means that it is written in such a way that a software entity (in this case, a screen reader) can act as an intermediary in a way that preserves all the ritchness and semantics of the original document. If this is true, then we should be able to replace the screen reader with another software agent aimed at helping LD folks.
Again, the points here are that the spec is too bloated and complex because its scope is too wide. Any kind of modularization, either as outlined above, or by breaking it down some other way, is good.
We agree with the need to simplify the guidelines and have taken extensive steps to do so. Some of these include:
Easier language to understand
- Wrote simpler guidelines
- Removed as many technical terms (jargon) as possible replacing them with plainer language or, where possible, their definitions
- Eliminated several new or unfamiliar terms. (authored unit, etc.)
- Removed the term Baseline and replaced it with “web technologies that are accessibility supported� and then defined what it means to be accessibility supported.
- Removed the nesting of definitions where we could (i.e. definitions that pointed to other definitions)
- Tried to word things in manners that are more understandable to different levels of Web expertise
- Added short names/handles on each success criterion to make them easier to find and compare etc.
- Simplified the conformance
Shortening the document overall
- Shortened the introduction
- Moved much of the discussion out of the guidelines and put it in the Understanding WCAG 2.0 document
- Shortened the conformance section and moved it after the guidelines
- Moved mapping from WCAG 1 to a separate support document (so it can be updated more easily)
Creating a Quick Practitioner-oriented Summary / Checklist-like document
- Created a Quick Reference document that has just the Guidelines, success criteria and the techniques for meeting the success criteria.
With regard to creating a separate set of guidelines for different disabilities, we don't think that would be effective. Web authors have enough trouble without having to consult multiple documents in order to create one accessible site for people with disabilities.
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
As a practitioner with 10 years experince in advising site owners and developers on how to develop web sites that are accessible to the widest range of users using the widest range of technilogies, I find the following the following issues in WCAG2 highly problematic:
The introduction of a technology baseline; the concept of a baseline is in my opinion in itself in direct conflict with the idea of creating inclusive solutions; I fear that the baseline will be used widely to formally pass accessbility tests by omitting all potentially tricky technologies from the baseline. In my opinion, the baseline is a mistake that should be removed from the document. If the aim is to promote an inclusive envisonment, the whole notion of accepting lower standards in, say, private intranets is absurd as it will preent people with special needs to work in these environments.
The document is still heavily biased towards the visually impaired. By and large, other groups of people with special needs are in practice omitted from the substance of the guidelines. These include, but are not limited to, the deaf, dyslexic, people with reading difficulties, and the cognitively disabled. The standard remedy of demanding that all non-textual information also be represented as textual information is simply not enough.
The idea of granting triple-A conformance status to a web site if it passes half (randomly selected?) the level 3 success criteria does not make sense. It suggests either that the level 3 success criteria are irrelevant to the general accessibilily or that it is more important to be able to pass the test than to comply with the level 3 success criteria.
Proposed Change:
1. Omit the concept of a baseline from the document.
2. Accommodate other - and in many cases much larger - user groups than merely the visually disabled. Complement the text alternative requirement with requirements for other alternatives including simplified text and sign language.
3. Decide whether and which of the level 3 success criteria are important. Leave out the unimportant and make the rest mandatory for gaining triple-A conformance status.
1. The notion of baseline (now referred to as "accessibility-supported Web technologies") is not an attempt to weaken the guidelines or create less inclusive environments. It is a recognition that the level of support in browsers and assistive technology is constantly changing, and that any attempt to define "accessible technologies" based on the support available at the current time will deprive people with disabilities from the benefits of on-going innovation on the internet. For instance, we want all users to benefit from the use of CSS. At the time that WCAG1 was published, user agent support was not sufficient to include CSS in acceptable technologies.
2. We believe the guidelines address a wide range of physical disabilities, including deafness, hearing impairments, mobility impairment, and seizure disorders. The reliance on text is because it is the format that lends itself best to rendering in a wide variety of modalities. Text can be converted to speech, rendered on braille displays, or displayed visually. It may facilitate translation of text into different language levels at some point. This does not mean that providing a text representation solves all accessibility problems.
We have added language to the Introduction, the Conformance section, and the Quick Reference to highlight the fact that WCAG 2 only addresses some of the needs of people with cognitive, learning, and language disabilities, and to call out the need for more research in this area. WAI is exploring ways in which to support and encourage work in this important area.
We have added some best practices for cognitive, learning, and language disabilities as advisory techniques, and we have proposed 3 new success criteria in this area.
3. The definition of triple-A conformance has been changed to require all level AAA success criteria.
Part of Item: Applicability
Comment Type: GE
Comment (including rationale for proposed change):
I think it could be helpful for a web developer and evaluator to have the HTML techniques/failures sorted by what the techniques/failures are about, e.g. specific elements like img, area, etc. or concepts like lists, data tables, etc.
Proposed Change:
Add a list of HTML techniques/failures sorted by e.g. specific elements or concepts.
We agree. This is the purpose of the Application notes that are planned: to provide summaries that look at topics across the success criteria. If you are interested in helping with these please let us know. These are a future component that will be developed in conjunction with the Education and Outreach Working Group.
As a web developer who has not yet begun implementing accessibility
standards, I'm confused and daunted by the current proposed WCAG 2.0
standard. From what I have read so far, it is at times incomplete,
contradictory, and meaningless. I can't even begin to explain what's
wrong, because I can't even begin to understand what's right.
Please take some more time to re-evaluate this document. Don't give us a
standard we can't use.
Jason Gottshall
Developer
Knowlegis.net
--
Jason Gottshall
jgottshall@capitoladvantage.com
We have done an extensive rewrite of the guidelines with a focus on making them easier to understand and to remove any apparent conflicts.
We have also shortened and simplified them. Some of the things we have done include:
Easier language to understand
- Wrote simpler guidelines
- Removed as many technical terms (jargon) as possible replacing them with plainer language or, where possible, their definitions
- Eliminated several new or unfamiliar terms. (authored unit, etc.)
- Removed the term Baseline and replaced it with “web technologies that are accessibility supported� and then defined what it means to be accessibility supported.
- Removed the nesting of definitions where we could (i.e. definitions that pointed to other definitions)
- Tried to word things in manners that are more understandable to different levels of Web expertise
- Added short names/handles on each success criterion to make them easier to find and compare etc.
- Simplified the conformance
Shortening the document overall
- Shortened the introduction
- Moved much of the discussion out of the guidelines and put it in the Understanding WCAG 2.0 document
- Shortened the conformance section and moved it after the guidelines
- Moved mapping from WCAG 1 to a separate support document (so it can be updated more easily)
Creating a Quick Practitioner-oriented Summary / Checklist-like document
- Created a Quick Reference document that has just the Guidelines, success criteria and the techniques for meeting the success criteria.
Hopefully, this new version will much better meet your needs.
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:
Comment Type: TE
Comment (including rationale for proposed change):
The definition of "multimedia" is misleading. It says: "audio or video synchronized with another type of media and/or with time-based interactive components"
<http://www.w3.org/TR/WCAG20/appendixA.html#multimediadef>;
Thus anything not synchronized with something is no multimedia, e.g. video without subtitles, audio files etc. This leads to the conclusion there is no need to provide an alternative content for a media file as long it is not synchronized. Thus podcats, news on videos and live video streams will not be accessible for deaf and hard of hearing people, because the alternative version is omitted.
Proposed Change:
Change the definition in "any audio, video or animation file. It can be synchronized with another type of media and/or with time-based interactive components".
For audio only or video only files, it is Guideline 1.1 that applies rather than Guideline 1.2. Guideline 1.1 requires that all non-text content except multimedia have text alternatives. So audio only, and video only files would need text equivalents under 1.1 unless they were just for sensory experience.
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
I am greatly disturbed my the disparaging comments i have read here:http://www.sitepoint.com/blogs/2006/05/26/wcag-20-is-broken-leave-your-comments-now/
A quick scan of the document or quotes from it certainly adds evidence to the idea that there is really a corporate law suit protection agenda going on. In the UK we have a campaign body called plain english who award government and organisations for their clear use of language. My quick scan shows a woefully unclear use of language compared to version 1.0.
Please listen up to the more considered opinions you will be hearing / have heard.
Proposed Change:
revert to 1.0!
We have reworked the entire document to make it shorter and easier to read. This includes:
- Shortening the introduction
- Moving much of the discussion out of the guidelines and puttin it in the Understanding WCAG 2.0 document
- Shortening the conformance section and moving it after the guidelines
- Writing simpler guidelines
- Removing as many technical terms (jargon) as possible, replacing them with simpler language or their definitions
- Removing the nesting of definitions where we could (i.e. definitions that pointed to other definitions)
- Moving information about mapping between WCAG 1 and WCAG 2 to a separate support document (so it can be updated more easily)
- Creating a Quick Reference documents that has just the Guidelines, success criteria and the techniques for meeting the success criteria.
- Trying to word things in manners that are more understandable to different levels of Web expertise
- Adding short names/handles on each success criterion to make them easier to find and compare etc.
- Simplifying the conformance section
- Using plainer language wherever possible (e.g. – use “Web page� instead of “Web Unit�)
- Eliminating several new or unfamiliar terms. (authored unit, etc.)
- Making the whole document much shorter.
Part of Item: Applicability
Comment Type: GE
Comment (including rationale for proposed change):
None of the tests are expressed as testable statements. None of the tests have examples.
Tests already exist at:
http://www.w3.org/WAI/GL/WCAG20/tests/
Proposed Change:
Express the tests as testable statements. Include example files.
Use the existing tests.
Each of the techniques has a test procedure and an expected result from the procedure. We have test files (actually example files for pass and failure) for some of the techniques, most of which came from the location you cited http://www.w3.org/WAI/GL/WCAG20/tests/ There is now a joint task force with ERT WG that will be working on identifying or developing sample files for the other techniques.
The Social Security Administration welcomes the opportunity to comment on the proposed WCAG 2.0 standards. In general, SSA finds that the general content of the proposed standards addresses many shortcomings of the previous version of the standards. In addition, the baseline concept for establishing a testing environment provides excellent direction for accessibility and validation testing. However, SSA has some concerns that should be addressed before the final version is published.
§ The principles are broken down into 4 simple components – perceivable, operable, understandable and robust, which we agree is an excellent way to structure the standards at a high level. However, the explanations and further breakdown tend to be confusing and navigation through the 400 plus pages is unwieldy. As a result - it can be difficult to determine if appropriate standards exists to guide development activities.
§ Specific techniques for meeting the guidelines are very scientific and precise, however from a pragmatic perspective will be difficult to implement due to focus on mathematic calculations to address unfamiliar issues such as luminosity and audio levels.
§ Success criteria in some cases are very general and in need of further definition to support proper implementation (for example: minimal level of accessibility is defined as the target - but the criteria for meeting this requirement are not defined).
§ The guidelines do not address the following:
§ Alt text for images, links, etc. that are normally exposed by mouse over capabilities must also be accessible by the keyboard.
§ For error handling, there must be a way for users to know where errors are in a form and be able to navigate directly to the input in error.
§ Guidelines for creating HTML documentation and Help must be stated and Help using navigational techniques must also be documented for accessibility.
§ Informational text and instructions within web applications must have a focal point achieved by using tab indices of zero or some equivalent technique.
§ Applets and plug-ins used with web pages or applications must be referenced with specific guidelines for accessibility.
§ Standardized keyboard navigation through frames.
§ Search facility guidelines for navigation and focus.
§ Mark-up of textual information for carets and other pointers.
§ Avoiding conflicts between browser and web application commands.
§ In addition, we recommend the W3C address the following items at a later date:
§ Guidelines should provide additional guidance and examples are needed to address user navigation to errors once they are identified.
§ Guidelines should address keyboard access, however additional guidance is needed for when to assign hotkeys, defining logical tab order, hotkeys shown on buttons, and defining tab indices for text focus and search functionality. Also, guidance is needed to determine what is an acceptable number of keystrokes to perform the equivalent of one mouse action to provide comparable access.
§ Guidelines should address e-learning considerations, such as navigation, registration, administration, courseware, simulations, test taking, and reporting results.
§ Guidelines should address context sensitive help built into the HTML structure.
§ Guidelines should address table navigation for magnification users.
Respectfully,
Robert Baker
-----------------------------------------------------------------
§ The principles are broken down into 4 simple components – perceivable, operable, understandable and robust, which we agree is an excellent way to structure the standards at a high level. However, the explanations and further breakdown tend to be confusing and navigation through the 400 plus pages is unwieldy. As a result - it can be difficult to determine if appropriate standards exists to guide development activities.
§ Specific techniques for meeting the guidelines are very scientific and precise, however from a pragmatic perspective will be difficult to implement due to focus on mathematic calculations to address unfamiliar issues such as luminosity and audio levels.
§ Success criteria in some cases are very general and in need of further definition to support proper implementation (for example: minimal level of accessibility is defined as the target - but the criteria for meeting this requirement are not defined).
We agree with this assesment and have created the QUICK REFERENCE document (http://www.w3.org/WAI/WCAG20/quickref/). We believe that this will address your concern by putting the requirements and a succinct list of techniques for meeting them all in one document. The sufficient techniques are very concrete and have full descriptions, examples and tests associated with them.
With regard to the technique requiring calculation, we provide links to free tools that will automatically carry out the calculations and evaluate content for you. In the past we only said things like "use sufficent contrast" which provided no guidance and did not allow authors to ever determine if they had met the guideline or not.
-----------------------------------------------------------------
§ Alt text for images, links, etc. that are normally exposed by mouse over capabilities must also be accessible by the keyboard.
Keyboard operations requirement and alt text are already in the guideline at level A. Assuming content meets WCAG 2.0, it is the user agent that determines if alt text can be exposed by keyboard only. If a 'mouseover' event is used in scripting then SC 2.1.1 would require that moving the focus to the item by keyboard would also trigger the same action as mouseover. So the concern is either met (in one case) or a user agent issue (in the other case).
-----------------------------------------------------------------
§ For error handling, there must be a way for users to know where errors are in a form and be able to navigate directly to the input in error.
The working group considered adding this requirement as a success criterion, and decided not to because it is too specific to apply to all technologies and all environments. However, there are several advisory techniques provided that will help authors who wish to design more usable forms.
-----------------------------------------------------------------
§ Guidelines for creating HTML documentation and Help must be stated and Help using navigational techniques must also be documented for accessibility.
We agree that Help and documentation that is available *on the web* is web content and hence that it should conform to these Guidelines. Note that although the same issues appear for documentation and Help files for desktop applications, these guidelines do not address that content. However, we feel that attempting to single out specific examples of Web content is likely to lead people to believe that only the listed examples are covered.
-----------------------------------------------------------------
§ Informational text and instructions within web applications must have a focal point achieved by using tab indices of zero or some equivalent technique.
The working group believes that there are some instances where deliberately putting focus on something (like error messages) can be helpful, but that attempting to control the way a user interacts with all pages, especially where it may conflict with expected behaviors for forms or other user interface components, is problematic.
-----------------------------------------------------------------
§ Applets and plug-ins used with web pages or applications must be referenced with specific guidelines for accessibility.
Programmatic content (applets, etc.) are covered in several ways. If they are not accessibility supported, then conformance requirement6 requires that the inaccessible content do no harm and conformance requirement 4 requires that an accessible version also be provided.
If the technologies are accessibility supported, then SC 4.1.2 requires that the programmatic content be compatible with assistive technologies and be accessible. In addition, all of the other success criteria (such as keyboard operability) in the guidelines would also need to be met by the programmatic content.
The term "plug-in" is usually used for extensions to user agents, and is related to the definitions of "user agent" and "assistive technology". Guidelines related to the accessibility of plug-ins themselves can be found in the User Agent Accessibility Guidelines (http://www.w3.org/TR/UAAG10/).
-----------------------------------------------------------------
§ Standardized keyboard navigation through frames.
The success criteria in guideline 2.1 require that all content be operable via the keyboard. How user agents provide keyboard navigation through frames is a user agent issue.
-----------------------------------------------------------------
§ Search facility guidelines for navigation and focus.
While this can be helpful for improving the experience with Windows Narrator, more fully-featured screen readers have the ability to allow users to interact with all kinds of text. Users of those screen readers are used to the way they interact with structured pages, and don't need this extra help.
In addition, there are many issues for other types of users with this non-standard approach. For example,
1) Unexpected behavior for all users
2) Developers often attach events to paragraphs and other non-actionable elements when they have focus, and this is not compatible with AT.
3) This will be more difficult for sighted keyboard users, as they will have to tab through parts of the page that are not normally tabbable.
4) Confusing for experienced screen-reader users, because they expect that everything tabbable in a form is an editable field
5) Optimized for forms mode, but also used on non-form pages. This is very strange when in browse mode, because users expect to be able to tab to find links.
-----------------------------------------------------------------
§ Mark-up of textual information for carets and other pointers.
The user agent issue is, of course, outside of our guidelines and would be in the domain of the user agent guidelines. From a content perspective, any non-text content must have text equivalents under SC 1.1.1. Structure (lists etc.) must be programatically determinable under SC 1.3.1. Other use of characters that convey information required to understand and operate content should be addressed by SC 1.3.3 (formerly 1.3.5).
-----------------------------------------------------------------
§ Avoiding conflicts between browser and web application commands.
We will be adding an advisory technique titled "Avoiding use of common user-agent keyboard commands for other purposes."
-----------------------------------------------------------------
§ Guidelines should provide additional guidance and examples are needed to address user navigation to errors once they are identified.
There are advisory techniques for SC 2.5.3 that cover much of the SSA recommendations. They include.
-Validating form submissions on the server (future link)
-Re-displaying a form with a summary of errors (future link)
-Providing error notification as the user enters information (future link)
-Assisting the user in making corrections by providing links to each error (future link)
-Highlighting or visually emphasizing errors where they occur (future link)
-Supplementing text with non-text content when reporting errors (future link)
In addition, we are adding the following advisory techniques.
-"Placing focus in the field containing the error"
-"Avoiding use of the same words or letter combinations to begin each item of a drop-down list"
And we have linked this SC to the following advisory technique:
"Providing client-side validation and alert"
NOTE: "(future link)" is what we call all techniques that we have identified and are listed in our "Understanding WCAG" and our "Quick Reference" documents but have not yet been fully written up.
-----------------------------------------------------------------
§ Guidelines should address keyboard access, however additional guidance is needed for when to assign hotkeys, defining logical tab order, hotkeys shown on buttons, and defining tab indices for text focus and search functionality. Also, guidance is needed to determine what is an acceptable number of keystrokes to perform the equivalent of one mouse action to provide comparable access.
This type of topic would be handled in an application notes. We would love to write an Application Note “Enhancing Keyboard Access to Web Content� that would provide guidance on assigning hotkeys, defining logical tab order, defining hotkeys shown on buttons, and defining tab indices for text focus and search functionality. It might also discuss the topic of “number of keystrokes to perform the equivalent of one mouse action� but it won’t be able to define “comparable access� since it would differ so much based on individual abilities to point or create keystrokes. User agent support for access keys is so bad that developers have started looking for server-side solutions that allow users to define access keys (see http://juicystudio.com/article/user-defined-accesskeys.php and http://juicystudio.com/article/user-defined-access-keys-aspversion.php). If you are aware of a good paper or application note on this we would be most interested.
-----------------------------------------------------------------
§ Guidelines should address e-learning considerations, such as navigation, registration, administration, courseware, simulations, test taking, and reporting results.
We belive that all of the fundamental issues raised in making these applications accessible are included in the guidelines. The guidelines cover form controls, text, images, multimedia and programmatic elements (applets and the like). The EO group working with WCAG WG will be working on application notes to look at particular applications in the future and we expect that additional techniques in this area will become available in the future. However, the basics should already all be in place.
-----------------------------------------------------------------
§ Guidelines should address context sensitive help built into the HTML structure.
Thank you, we have added an advisory technique (which will be completed at later date) titled "Using the title attribute to provide context-sensitive help" and another titled, "Using scripts to provide context-sensitive bubble help."
-----------------------------------------------------------------
§ Guidelines should address table navigation for magnification users.
Success criterion 1.3.1 includes requirements related to the use of table markup. The working group believes that this is a user agent issue rather than a content issue.
If you have suggestions for techniques that would improve table navigation for screen magnification users, please submit them so we can include them. (Refer to the techniques submission form at http://www.w3.org/WAI/GL/WCAG20/TECHS-SUBMIT/).
Comment (including rationale for any proposed change):
(European) cultural diversity issues should be
addressed in more detail and be included as
conformance criteria (e.g. image texts)
Proposed Change:
WCAG 2.0 should provide at least cross-references to
other work addressing multicultural issues related to
accessibility, more than Japanese and Chinese
Many of the suggestions you provide appear to be cultural accommodations and the accessibility implications are not always clear. We have adapted some of your suggestions as advisory techniques for Guideline 3.1 and have added the following placeholder to How to Meet Guideline 3.1:
Setting expectations about auto-generated or user-contributed content (future link)
Comment (including rationale for any proposed change):
Accessibility of the mobile Web should be covered
better
Proposed Change:
Mobile Web accessibility issues should be more
detailed and the cross-referencing with the Mobile
Web Best Practices made more detailed
We are considering adding a section in Understanding WCAG 2.0 that would cover "other benefits". If we do we will include the benefits and similarities with Mobile Web in this section. There has been some discussion however, that we should not include broader benefits in the documents and that we should stick just to the accessibility issues. The "other benefits section" would allow us to keep the focus on disability while acknowledging the broader implications. Since this work would not affect the WCAG 2.0 Guidelines document, we have postponed making this decision.
Comment (including rationale for any proposed change):
Training and educational packages should be
developed for designers and developers
Proposed Change:
Should be developed and cover the typical segments
of designer groups
This is outside the scope (charter) of the WCAG working group. However we are working with the Education and Outreach (EO) working group that is developing such materials."
Comment (including rationale for any proposed change):
We would like to see WCAG 2.0 applied to as many
non-public (or "commercial") sites as possible
Proposed Change:
A starter package should be developed,
addressing basic accessibility issues
This is outside the scope (charter) of the WCAG working group. However, we are working with the Education and Outreach (EO) working group that is developing application notes. They are also planning on doing one on the basics for elementary web designers, and a one page Quick Tips like they did with WCAG 1.0.
Comment (including rationale for any proposed change):
We would like to see WCAG 2.0 applied to as many
non-public (or "commercial") sites as possible
Proposed Change:
The use of language and terminoology should be
simple and as free of technical jargong as possible
The navigation between the various documents
should be simplified (now far too complex)
We have reworked the entire document to make it shorter and easier to read. This includes:
- Shortening the introduction
- Moving much of the discussion out of the guidelines and puttin it in the Understanding WCAG 2.0 document
- Shortening the conformance section and moving it after the guidelines
- Writing simpler guidelines
- Removing as many technical terms (jargon) as possible, replacing them with simpler language or their definitions
- Removing the nesting of definitions where we could (i.e. definitions that pointed to other definitions)
- Moving information about mapping between WCAG 1 and WCAG 2 to a separate support document (so it can be updated more easily)
- Creating a Quick Reference documents that has just the Guidelines, success criteria and the techniques for meeting the success criteria.
- Trying to word things in manners that are more understandable to different levels of Web expertise
- Adding short names/handles on each success criterion to make them easier to find and compare etc.
- Simplifying the conformance section
- Using plainer language wherever possible (e.g. – use “Web page�? instead of “Web Unit�?)
- Eliminating several new or unfamiliar terms. (authored unit, etc.)
- Making the whole document much shorter.
Comment (including rationale for any proposed change):
It is unclear if and how WCAG 2.0 applies to sites
accessed in off-line mode (e.g. local, synchronized
Web sites)
Proposed Change:
Should be covered by adding at least a sentence in
the introductory chapters or, if possible, more
details.
WCAG 2.0 applies to Web content, and sites accessed in off-line mode are not on the Web. While there is clearly a lot of overlap in the accessibility issues in these two environments, this is outside the charter of the group. It is not clear what you mean by "local-synchronized site" If the local site is a mirror of an on-line site, then the local (off-line) site would be out of scope but the on-line site would be within scope and should meet WCAG.
Comment (including rationale for any proposed change):
A Table of Content should be added to all documents
to simplify THE navigation of printed documents
Proposed Change:
The question is how to add it for print-outs, supporting
page numbers
When the guidelines are complete, a print version (PostScript and PDF) will be available. This version will include a printable table of contents and references to printed page numbers.
Comment (including rationale for any proposed change):
ANEC would like to encourage the early translation of
the WCAG 2.0 documents to all official EU languages
Proposed Change:
The EC and their Translation services could be
approached and the W3C translation process, now
well in place, applied?
A number of unofficial translations have already been created for working drafts of WCAG 2.0 and are available on the working group's homepage at http://www.w3.org/WAI/GL/#translations. The W3C actively encourages individuals and organizations to participate in the process of creating translations.
Note: for those interested in creating translations, please see the W3C Translations page at http://www.w3.org/Consortium/Translation/. WCAG 2.0 translations are not currently indexed at this location. However, as the document matures we expect to include our translations in this location resource.
Comment (including rationale for any proposed change):
The comment provision form is not usable- see
this sheet
Proposed Change:
The Excel sheet needs considerable improvements
(e.g. text string input limitations)
Yes, Excel does give error messages if you try to type too much into a cell. It will take much more than it says it will. For those with long comments, we provided several methods for commenting. We also changed the instructions to make it clearer that comments can be sent in using the on line form, sheets or by sending an open email to the public comments list.
Part of Item: Description
Comment Type: TE
Comment (including rationale for proposed change):
Very broad. Should only be used when there is ambiguity. i.e. if there is only one image then OK to refer to it as \"see image below\".
Does the use of \"top\" (WCAG2 navigation buttons) fall under this? What about G74 that uses text \"Details in text following the chart:\"
Proposed Change:
Make it clear that this is needed only if there is ambiguity.
Note that we already have a failure (F1: Failure of SC 1.3.3 due to changing the meaning of content by positioning information with CSS) that addresses part of your comment.
With regard to ambiguity, even with only one image, if it is referred to by position, as in "see image below", it could be misleading as users may not find the image "below". Regarding links to the top of the page, the link does not violate this success criterion as it is not identified by or referred to by shape or position. The fact that the link targets the top of the page is a different issue not related to this success criterion, since it describes where the link will go, rather than instructing the user where to find something. Regarding G74, this does not violate the success criterion since the language used is "sequential" rather than "spatial" ("following", not "below"). A note was added to How to Meet 1.3.5 to clarify that aspect.
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
The text \"modify or delete data in data storage systems\" is very broad. Even submitting a search to Google will do this - Google will store info about your request.
Proposed Change:
Add text that describes data as important or non trivial to enter again.
We have revised this to read:
2.5.3 Error Prevention: For forms that cause legal commitments or financial transactions to occur, that modify or delete user-controllable data in data storage systems, or that submit test responses, at least one of the following is true:
1. Reversible: Transactions are reversible. [LC-1196]
2. Checked: Submitted data is checked for input errors before going on to the next step in the process.
3. Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the transaction.
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
Rationale: In the term programmatically determined, the concept of total determinism is not clear enough. There needs to be a clear difference between programmatically determined (recognized by a deterministic algorithm) and non-deterministically accessed by an AI heuristic --as in optical character recognition.
Proposed Change:
Change: In Introduction: Important New Terms Used in WCAG 2.0
Add to the description of programmatically determined…\"This means that the author is responsible for ensuring that the content is delivered in such a way that software can access it [with no chance of error]\". You could also say positively… [with perfect accuracy].
We have clarified the meaning of "programatically determined" in the section on Important New Terms Used in WCAG 2.0. See http://www.w3.org/TR/2007/WD-WCAG20-20070517/#new-terms .
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
(See LC 681 for complete submission)
The guidelines do not address the following:
§Informational text and instructions within web applications must have a focal point achieved by using tab indices of zero or some equivalent technique.
Proposed Change:
The working group believes that there are some instances where deliberately putting focus on something (like error messages) can be helpful, but that attempting to control the way a user interacts with all pages, especially where it may conflict with expected behaviors for forms or other user interface components, is problematic.
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
(See LC 681 for complete submission)
The guidelines do not address the following:
§Applets and plug-ins used with web pages or applications must be referenced with specific guidelines for accessibility.
Proposed Change:
Programmatic content (applets, etc.) are covered in several ways. If they are not accessibility supported, then conformance requirement6 requires that the inaccessible content do no harm and conformance requirement 4 requires that an accessible version also be provided.
If the technologies are accessibility supported, then SC 4.1.2 requires that the programmatic content be compatible with assistive technologies and be accessible. In addition, all of the other success criteria (such as keyboard operability) in the guidelines would also need to be met by the programmatic content.
The term "plug-in" is usually used for extensions to user agents, and is related to the definitions of "user agent" and "assistive technology". Guidelines related to the accessibility of plug-ins themselves can be found in the User Agent Accessibility Guidelines (http://www.w3.org/TR/UAAG10/).
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
(See LC 681 for complete submission)
The guidelines do not address the following:
§Mark-up of textual information for carets and other pointers.
Proposed Change:
---------------------------
SENT FOR CLARIFICATION
* Not sure on this one. If you mean graphic carets etc - they are covered under 1.1 which says that ALL non-text content must have text equivalents. If you mean text characters, -- well they are already text so I guess that isn't the problem. Does 1.1's requirement for text alternative for all graphics, and 1.3's requirement for content to be separable from presentation - (which would mean all bullets (lists) would need to be evident programmatically) - address your concern here? If not could you tell us more and give us an example that contains carets and other pointers so we can see what you mean?
CLARIFICATION RECEIVED
This is another extension of the issue with focal point. It is probably more of an issue with the user agent or browser. Browsers that supply an actual caret indicating where focus is can make web pages and applications easier to navigate like fat clients, word processors etc.
The user agent issue is, of course, outside of our guidelines and would be in the domain of the user agent guidelines. From a content perspective, any non-text content must have text equivalents under SC 1.1.1. Structure (lists etc.) must be programatically determinable under SC 1.3.1. Other use of characters that convey information required to understand and operate content should be addressed by SC 1.3.3 (formerly 1.3.5).
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
(See LC 681 for complete submission)
In addition, we recommend the W3C address the following items at a later date:
§ Guidelines should address e-learning considerations, such as navigation, registration, administration, courseware, simulations, test taking, and reporting results.
Proposed Change:
We belive that all of the fundamental issues raised in making these applications accessible are included in the guidelines. The guidelines cover form controls, text, images, multimedia and programmatic elements (applets and the like). The EO group working with WCAG WG will be working on application notes to look at particular applications in the future and we expect that additional techniques in this area will become available in the future. However, the basics should already all be in place.
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
(See LC 681 for complete submission)
In addition, we recommend the W3C address the following items at a later date:
§ Guidelines should address table navigation for magnification users.
Proposed Change:
Success criterion 1.3.1 includes requirements related to the use of table markup. The working group believes that this is a user agent issue rather than a content issue.
If you have suggestions for techniques that would improve table navigation for screen magnification users, please submit them so we can include them. (Refer to the techniques submission form at http://www.w3.org/WAI/GL/WCAG20/TECHS-SUBMIT/).
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
I found the definition of Assistive Technology a little unclear. The concept of retrieving data from host agents is difficult. Maybe the attached wording could help.
Assistive technology (in the context of this document)
a user agent that:
1. provides services beyond those offered by the host user agents to meet the requirements of users with disabilities. Additional services include alternative renderings (e.g., as synthesized speech or magnified content), alternative input methods (e.g., voice), additional navigation or orientation mechanisms, and content transformations (e.g., to make tables more accessible).
2.relies on services provided by one or more other \"host\" user agents. Assistive technologies communicate data and messages with host user agents by using and monitoring.APIs.
Note: In this definition the host user agents are user agents in the general sense of the term. The output of host user agents may not be easily read by any humans, but it may provide important services to assistive technologies like retrieving Web content from program objects or parsing markup into identifiable bundles.
Example: Examples of assistive technologies that are important in the context of this document include the following:
* screen magnifiers, which are used by people with visual disabilities to enlarge and change colors on the screen to improve the visual readability of rendered text and images;
* screen readers, which are used by people who are blind or have reading disabilities to read textual information through synthesized speech or braille displays;
* voice recognition software, which may be used by people who have some physical disabilities;
* alternative keyboards, which are used by people with certain physical disabilities to simulate the keyboard;
* alternative pointing devices, which are used by people with certain physical disabilities to simulate mouse pointing and button activations.
Note: This definition is based on User Agent Accessibility Guidelines 1.0 Glossary
Proposed Change:
Thank you for the suggestions for how to improve the definition of Assistive Technology. We have modified the definition based on your suggestions.
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
Prompted, I admit, by http://www.alistapart.com/articles/tohellwithwcag2
I\'m writing to express my disappointment with the WCAG 2.0 draft. The
content is uninspiring and I find the process to be little more than
railroading any public comment. Five years for the draft and a month to
comment? That\'s a rubber-stamp, not an opportunity.
As to the draft itself, then I find it almost worthless. It\'s as
worthless and irrelevant as WCAG 1 was.
I care deeply about web accessibility. As an \"accessibility geek\", I
also find myself in the frustrating position of knowing what to do, but
having repeated management pressure to do just the opposite.
Accessibility still isn\'t a real issue for commercial development and
it\'s leadership from the major bodies that\'s needed most, not developer
education. The information is already out there (Joe Clark, for
starters) and anyone who cares can easily be pointed towards it.
As this draft is though, it presents accessibility as an impossibility
complex matter that\'s about as dry as SGML parsing. There is no way I
can show this WCAG guideline to any sort of manager or commissioning
editor. It falls immediately into deathly dull technical issues couched
in impenetrable language and makes no real case to justify accessibility
as a worthy goal. Even as a technical description for implementors it\'s
almost worthless.
These have always been the failings of the WCAG guidelines. The 1 -> 2
process though has been little more than an updating and tidying
exercise when the document itself required a ground-up re-write. Or more
usefully, throwing away and simply replacing wuith Joe Clark\'s
well-known boook that does a much better job of all of it!
I\'m disappointed that the W3C has lent its name to this document. As a
counter-example I\'m continually surprised by the quality of the HTML
Recommendation and the subtlety of some design choices I\'m only just
realising the value of, even after using the DTD for years. It\'s a
paragon of _why_ a standards process driven by experts is such a great
thing, when it works. The WCAG guidelines though are everything that\'s
bad about the output of standards bodies. Obscure, over-complex,
partial, irrelevant, and basically inaccessible.
I would like to see this draft abandoned and the process re-started --
then a new draft developed, from scratch (or possibly lifted wholesale
from the canonical ref I\'ve already mentioned). This is a massive
change, but I see no possibility of turning the existing draft into
anything useful.
Proposed Change:
We received a great deal of input on the Last Call draft and have made a large number of changes, including a rewrite of much of the draft to make it easier to understand. We have also included a new Quick Reference document, http://www.w3.org/WAI/WCAG20/quickref/20070517/ , that provides a tool for practitioners who just want the bottom line on the requirements and the techniques for meeting them in different technologies. We also shortened the Guidelines document considerably.
Here are some of the things we have done.
Easier language to understand
- Wrote simpler guidelines
- Removed as many technical terms (jargon) as possible replacing them with plainer language or, where possible, their definitions
- Eliminated several new or unfamiliar terms. (authored unit, etc.)
- Removed the term Baseline and replaced it with “web technologies that are accessibility supported� and then defined what it means to be accessibility supported.
- Removed the nesting of definitions where we could (i.e. definitions that pointed to other definitions)
- Tried to word things in manners that are more understandable to different levels of Web expertise
- Added short names/handles on each success criterion to make them easier to find and compare etc.
- Simplified the conformance
Shortening the document overall
- Shortened the introduction
- Moved much of the discussion out of the guidelines and put it in the Understanding WCAG 2.0 document
- Shortened the conformance section and moved it after the guidelines
- Moved mapping from WCAG 1 to a separate support document (so it can be updated more easily)
Creating a Quick Practitioner-oriented Summary / Checklist-like document
- Created a Quick Reference document that has just the Guidelines, success criteria and the techniques for meeting the success criteria.
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
I for one do not have the time to read all of the WCAG 2 documents in
the 30-day review time-frame that has been provided. Having read Joe
Clark\'s comments at http://www.alistapart.com/articles/
tohellwithwcag2 and http://joeclark.org/access/webaccess/WCAG/ as
well as postings at http://technorati.com/tag/WCAG2. If only 10% of
the issues that are identified on these sites are true, then WCAG 2
is NOT ready for prime time. If it is true that web pages that meet
WCAG 2 need not be valid HTML/XHTML then that is utterly contrary to
the concept of web standards and is a HUGE step in the wrong
direction. I would hope that the WCAG 2 standards build on and
enhance the standards of WCAG 1 that many of us have worked hard to
promote in our work places. Other comments:
1. The provision to define a technology as a “baseline,� is not
useful unless there is either some way to make sure that the
technology is inherently accessible and/or that there are provisions
to provide alternate technologies to provide accessible versions of
the content where the baseline technology fails.
2. Being able to define entire directories of your site as off-limits
to accessibility should only be allowed when the content cannot be
made accessible.
3. The compliance \"levels\" do not seem to have become simpler.
Perhaps more cryptic. And I would like to see a move toward
enforcible standrads rather than merely guidelines (as in what was
attempted with the language of 508).
4. 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.
5. Source order must match presentation order even at the lowest
level ... why?
6. It would seem that WCAG 2 proposes maintaining separate accessible
and inaccessible versions of the same pages.
Again, I wish I had the time to drop my day-to-day tasks, stop
pushing for web standard design in our environment (including
accessible design) and devote my time to being able to read an
comment on the final WCAG 2 draft. However, the comments from folks
in the know and in the filed have not been encouraging. So, I
decided to drop a line and express my concerns and fears. SInce it
took years for the committee to reach this point, it would seem a
slightly longer review period to allow comment is in order. And one
would hope, if the public (those folks working to promote accessible
design) have real concerns about the standard, then the committee
needs to regroup and address those concerns, not publish a set of
guidelines that will not be accepted or used in practice ...
Proposed Change:
(thank you etc)
Extensive changes have been made in response to the comments received on the last draft of the guidelines.
{insert text regarding validity here}
### include replies from issues 829-834 here
Part of Item:
Comment Type: ED
Comment (including rationale for proposed change):
• If non-text content presents information or responds to user input, text alternatives serve the same purpose and present the same information as the non-text content. If text alternatives cannot serve the same purpose, then text alternatives at least identify the purpose of the non-text content.
Should this “If� better be a “Where�? General comment… I find myself wanting to see a “then� at the beginning of the consequence…
Proposed Change:
We agree that "where" could be used. We have chosen "if" however to keep a common format in the guidelines. We have added "then" to bullets #1, #3 and #4.
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
1.2.5 Sign language interpretation is provided for multimedia.
Why apparent bias towards sign language instead of other forms of manual communication?
Proposed Change:
Thank you for your new proposed definitions. We have revised the definitions to read:
sign language
a visual language using combinations of movements of the hands and arms, facial expressions, and body positions to convey meaning
sign language interpretation
translation of one language, generally a spoken language, into a sign language
Note: Most sign languages are independent languages that are unrelated to the spoken language(s) of the same country or region.
Part of Item:
Comment Type: ED
Comment (including rationale for proposed change):
Recommends deleting \"does not preclude\" from :
Note: This does not preclude and should not discourage the support of other input methods (such as a mouse) in addition to keyboard operation.
Proposed Change:
Note: This should not discourage the support of other input methods (such as a mouse) in addition to keyboard operation.
The two statements are distinct. We believe it is better to make both statements clear.
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
2.2.2 Content does not blink for more than three seconds, or a method is available to stop all blinking content in the Web unit or authored component.
If the claim is about Web units, then why does this refer to “or authored component.�??? Isn’t it redundant? If not then this really needs to be clarified. Same issue in later reference “authored� stuff…
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.
It seems to me that the term authored components does not belong in the normative part of the document unless the relationship between an authored component and a Web unit has been clearly defined in the glossary….!
Proposed Change:
We have changed the success criteria to use the term "Web page" instead of "Web unit or authored component".
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
4.2.1 At least one version of the content meets all level 1 success criteria, but alternate version(s) that do not meet all level 1 success criteria may be available from the same URI.
With all the effort to define terms like Web unit, authored unit, authored component, do we really need another term "content"?
Proposed Change:
The term "content" is important to define because it defines the scope of information that the WCAG guidelines can apply to. The term is used in multiple places throughout the guidelines and success criteria. We have, however, replaced the term "Web unit" with "Web page" and have reformulated the success criteria and glossary to remove both "authored unit" and "authored component" from the guidelines.
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
Many proposed edits to definitions, some editorial and some substantive, at
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006Jun/att-0043/S5-glossary-EGH-05Jun2006-01.doc
Proposed Change:
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
This document in its current form is an embarrasment to the W3C, and is a step backwards from the previous version. If made official, it will set back years of work by accessibility-focused web developers. Futhermore, by releasing this horrible standard you will hurt the prestige of the W3C as a standards organization; I for one will put significantly less stock in any body that produces works as flawed as this one. Please re-consider your plans to officially deploy this document, and send it back for some serious re-working.
Proposed Change:
There is so much wrong I don\'t even know where to begin ... Please see the excellent article by Joe Clark on A List Apart for more details:
http://www.alistapart.com/articles/tohellwithwcag2/
We received a great deal of input on the last call draft and have made a large number of changes including a rewrite of much of the draft to make it easier to understand. We have also included a new quick reference document that provides a tool for practitioners who just want the bottom line on the requirements and the techniques for meeting them in different technologies. We also shortened the Guidelines document considerably.
Here are some of the things we have done.
Easier language to understand
- Wrote simpler guidelines
- Removed as many technical terms (jargon) as possible replacing them with plainer language or, where possible, their definitions
- Eliminated several new or unfamiliar terms. (authored unit, etc.)
- Removed the term Baseline and replaced it with “web technologies that are accessibility supported� and then defined what it means to be accessibility supported.
- Removed the nesting of definitions where we could (i.e. definitions that pointed to other definitions)
- Tried to word things in manners that are more understandable to different levels of Web expertise
- Added short names/handles on each success criterion to make them easier to find and compare etc.
- Simplified the conformance
Shortening the document overall
- Shortened the introduction
- Moved much of the discussion out of the guidelines and put it in the Understanding WCAG 2.0 document
- Shortened the conformance section and moved it after the guidelines
- Moved mapping from WCAG 1 to a separate support document (so it can be updated more easily)
Creating a Quick Practitioner-oriented Summary / Checklist-like document
- Created a Quick Reference document that has just the Guidelines, success criteria and the techniques for meeting the success criteria.
Joe Clark also submitted his article as a comment. You may also want to review the working group's responses to that comment.
Comment (including rationale for any proposed change):
there is a need for more descriptive adjectives and phrases that put the responsibility of conformance with WCAG on the Web author (and not the user agent) by using valid accessibility features from their chosen baseline
Proposed Change:
new definition: determined from Web author-supplied data provided in a user-agent-supported manner, such as valid element tags and attributes, such that the user agents can extract and present this information to users in different modalities.
We have reworded the definition of programmatically determined to clarify that the data is provided by the author.
Comment (including rationale for any proposed change):
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0121
The objective of this technique is to describe how using blank characters, such as space, tab, line break, or carriage return, to format individual words visually can be a failure to present meaningful sequences properly. Blank characters have no appearance when rendered visually
Yes, they do. They're blank!
Proposed Change:
Thanks for pointing this out. We have dropped the sentence so that it reads "The objective of this technique is to describe how using blank characters, such as space, tab, line break, or carriage return, to format individual words visually can be a failure to present meaningful sequences properly. When blank characters are inserted to control letter spacing within a word, they may change the interpretation of the word or cause it not to be programmatically recognized as a single word."
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
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
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.
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
I do not have a specific change but am very concerned that it is understood and part of WCAG 2.0 that all resources should carry or refer to a description of their accessibility characteristics. Without such a description, the best resources will not be found and useful in some cases and in others, a resource that is not universally accessible will not be made available to someone who could use it even if others cannot.
Proposed Change:
I propose that the description of the resource be included as a requirement for the \'accessibility\' of the resource in order to make it accessible to those who can use it.
While the working group agrees that metadata describing the accessibility of a resource is beneficial for a number of reasons, requirements to include this information have not been included in WCAG 2.0. There are many reasons we do not require this including the fact that conformance claims are not always required, may not be available publicly and in some cases can not be made at all due to legal constraints.
Although we are not changing WCAG conformance, we recognize the value of what you request. Therefore, the WG plans to provide techniques for generating conformance claims as well as guidance about the various strategies for providing accessibility metadata that are available today in various WCAG 2.0 supplemantary materials.
This approach allows us to revise recommendations about accessibility metadata over time to adapt to changing technologies and recommendations related to generating and providing this information.
Part of Item:
Comment Type: ED
Comment (including rationale for proposed change):
1. Editorial: Refer to How to meet 1.1.1
• If the purpose of non-text content is to confirm that content is being operated by a person rather than a computer, different forms are provided to accommodate
multiple disabilities.
Comment: Do you mean ‘multiple’ disabilities or ‘different’ disabilities / ‘various kinds of disabilities’?
Proposed Change:
Replace ‘multiple’ disabilities with ‘different’ disabilities / ‘various kinds of disabilities’
The bullet has been revised to read:
If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided and alternative forms in different modalities are provided to accommodate different disabilities.
Part of Item:
Comment Type: ED
Comment (including rationale for proposed change):
Punctuational correction
Proposed Change:
Replace semi-colons with comma as suitable in list item that reads:
• If non-text content is multimedia…
Semicolons have been changed to commas.
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
The definition really does not add much else and one less term will reduce the length and perceived complexity of the docs.
Proposed Change:
The term ‘pure decoration’ need not be defined. Instead word it to say:
… is purely for decoration or
Is solely for decoration
wherever the term \'pure decoration\' is used as in 1.1.1
There is much danger in people calling things decorative that have function or convey information. The definition helps to make this clearer than just the term as you suggest.
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
The terminology for \"authored unit\", \"authored component\", \"web unit\" seems rather excessive, and potentially confusing. Can it be simplified with fewer (and perhaps more natural) terms?
Proposed Change:
We have replaced the term "Web unit" with "Web page" and have reformulated the success criteria and glossary to remove both "authored unit" and "authored component" from the guidelines.
Part of Item:
Comment Type: ED
Comment (including rationale for proposed change):
Refer to the term ‘full multimedia text alternative including any interaction ’ :
The term needs to be re-worded to be more meaningful and correct. Consider:
‘text alternative for multimedia ‘
Or
‘text alternative for interactive multimedia ‘
SORRY: I submitted this yesterday (June 14) but used the word \'equivalents\' instead of \'alternative\' as I really intended
Proposed Change:
Refer to the term ‘full multimedia text alternative including any interaction ’ :
The term needs to be re-worded to be more meaningful and correct. Consider:
‘text alternative for multimedia ‘
Or
‘text alternative for interactive multimedia ‘
Its description in the glossary should be
‘document including correctly sequenced descriptions of all visual settings, actions, and non-speech sounds combined with descriptive transcripts of all dialogue. This also applies to multimedia-based interactions, if any, with the user.‘
Our current "full multimedia text alternative" term could be confusing. 'Text alternative for multimedia' doesn't work because we already require one of those in SC 1.1.1 but it is just a label. ‘Text alternative for interactive multimedia ‘ doesn't work because this applies to all multimedia, not just interactive multimedia. We are therefore changing it to "full text alternative for multimedia including any interaction."
The success criterion now reads, "1.2.2 Audio descriptions of video, or a full text alternative for multimedia including any interaction, are provided for prerecorded multimedia."
Part of Item:
Comment Type: ED
Comment (including rationale for proposed change):
The term \'user agent\' has been defined to include assistive technologies in the UAG as well as in the WCAG glossary. So why use the term \'user agents including assistive technologies\' throughout the document? It occurs several times throughout all the WCAG docs. Restrict it to \'user agents\' and it will reduce length of the docs and verbosity that a screen reader has to endure.
Proposed Change:
Restrict it to \'user agents\' and delete \'including assistive technologies\'.
Although the definition of user agent includes assistive technologies, the definition blurs the distinction between support for users with disabilities that is provided directly by the user agent and support that is provided by an external service that interacts with a user agent that does not provide that support directly. Within WCAG, we use assistive technology to refer to the latter sort of service. We call out support for assistive technology explicitly so that programmatically determinable information is available to assistive technology, and not just to the host user agent. We agree that this can make the language awkward and longer but we think the distinction is important for clarity.
Part of Item:
Comment Type: GE
Comment (including rationale for proposed change):
http://www.w3.org/WAI/WCAG20/quickref/
This reference document is highly accessible in
my hardware and software environment, and the
material is well organized, offering a
summary of each technique with a link to the full
explanation in the techniques documents.
I am confident this reference will be useful to
content developers who want to know how to apply
the guidelines with their chosen technologies,
wish to avoid working through lengthy techniques
documents, but find the application of the
high-level success criteria in the normative
document not to be straightforwardly obvious.
Proposed Change:
Consider whether to add a view in which all the
glossary definitions in the guidelines are
(optionally, of course) inserted into the body of
the document, as in the \"key terms\" sections of
\"Understanding WCAG 2.0\".
Consider also whether to publish the PHP source
code of the quick reference in case developers
want to install it on their intranets.
I would further suggest that when WCAG 2.0
reaches the Candidate Recommendation stage, a
prominent link be provided from the normative
guidelines document to the Quick Reference. For
many developers, I expect, the Quick Reference
will be the preferred means of reading the
guidelines.
All of the definitions are linked to directly from the words in the Quick Reference. Clicking on any term will take you to the relevant item in the glossary. The glossary itself is quite long, so we do not want to include it directly in the Quick Reference.
We have added links from the Guidelines to the Quick Reference. The How To Meet links for the success criteria now take the reader to the Quick Reference instead of the Understanding document.
With regard to the source code - we will be consider this in conjunction with the EO working group as the Quick Reference becomes stable.
Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):
As a person who provides accessibility training to web designers, I\'m afraid that many of the folks I work with, all of whom are strapped for time and want quick-and-dirty recommendations (just tell me what to do!), would not have the patience to deal with the daunting girth of WCAG 2.0. This has grown enormously since I saw it last, and as I\'m trying to wade now through the complete WCAG 2.0 package, including supporting documents, I\'m frankly overwhelmed by the amount of information that\'s presented here. I think this has more to do with presentation than with content, and could be remedied with very few changes to the actual content that\'s being presented.
Here\'s an example: I\'m coding in HTML and I want to find the WCAG 2.0 - recommended technique for marking up alt text on decorative images. Here are the steps required for me to find what I\'m looking for:
1. Open the WCAG 2.0 normative doc.
2. 4 principles - I select the most relevant.
3. 4 guidelines - I select the most relevant.
4. Four Level 1 success criteria - I read them all and find a relevant success criterion, but still don\'t have a specific solution.
5. I follow the \"How to meet 1.1.1\" link, expecting to find techniques
6. Instead of techniques, the first thing I find is a repeat of the Level 1 success criteria. Didn\'t I alredy read this?
7. Not one to give up easily, I read on, past a dozen or so definitions of key terms, a lengthy \"Intent of this success criteria\" section, then finally arrive at a section headed \"Techniques for Addressing Success Criterion 1.1\".
8. Now I have an introductory paragraph, a paragraph of instructions, and five situations that take a while to read through. My particular situation is Situation E, but after reading it I still don\'t have a technique that I can apply. (I\'m also distracted in this section by the word USING always appearing in caps - is this done to enhance readability? For me it has the opposite effect).
9. At last I arrive at \"Technology-Specific Techniques\", which is where I find the answer I was looking for. As a sighted user with no known cognitive disabilities and past experience with both WCAG 1.0 and 2.0, the entire exercise took about 20 minutes.
I suspect that at this late stage in WCAG 2.0\'s development cycle, all of that verbiage between Step 1 and Step 9 is important, and is not going away. However, it was *not* important for my purposes.
So, the problem: How can all of this information be made available, but be optional to users? I think a more useful WCAG 2.0 would be one that is simple and straightforward, with all information only a click or two away.
Proposed Change:
I can think of two ways to address this problem.
1. Provide more links to the various components of the \"How to\" sections in the Understanding document. Instead of showing me the success criteria (again), and the key terms, and the scenarios, and the techniques, link to each of these sections, so I can choose whether or not to see them.
Personally I would even prefer to have this information linked directly from the normative document, thus I could get to Techniques in only a single click rather than two. However, that may have a tendency to clutter up the normative document.
2. Develop a WCAG 2.0 Wizard. Present nothing but the four guidelines on the opening page. Each time I select something, I\'m presented with additional options. Without adding intelligence to this application, a wizard wouldn\'t reduce the number of steps, but it would greatly reduce the amount of noise and make the WCAG 2.0 experience less daunting.
The number of steps could be reduced by adding intelligence to the wizard. Perhaps a keyword search, supplemented with some additional options to help filter the results (e.g., search any of the following: All WCAG 2.0 documents, Success Critera only, HTML Techniques only, CSS Techniques only, etc.)
Thank you for your comment. We had a similar concern. We think we have addressed this issue with the Quick Reference. It provides all the guidelines and success criteria along with sufficient techniques to meet them. The full technique descriptions are thus just one click away. You can find it at www.w3.org/WAI/WCAG20/quickref/.
There are also plans in conjunction with Education and Outreach Working group to develop an application note providing the basics for making accessible content in HTML.
See article TO HELL WITH WCAG 2.0 at: http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0118.html
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.
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
The documents are unreadable
Every attempt has been made to make WCAG 2.0 and the related documents listed above as readable and usable as possible while retaining the accuracy and clarity needed in a technical specification. Sometimes technical terms are needed for clarity or testability.
In fact, at 72 pages and 20,800 words, the WCAG 2 main document is half a book's length and is studded with jargon. Informed people with no disability whatsoever will find it hard to understand. The Working Group has failed to deliver a standards document that can be understood unto itself without reference to two other documents (notably the WCAG 2).
We received a great deal of input on the last call draft and have made a large number of changes including a rewrite of much of the draft to make it easier to understand. We have also included a new quick reference document that provides a tool for practitioners who just want the bottom line on the requirements and the techniques for meeting them in different technologies. We also shortened the Guidelines document considerably.
Here are some of the things we have done.
Easier language to understand
- Wrote simpler guidelines
- Removed as many technical terms (jargon) as possible replacing them with plainer language or, where possible, their definitions
- Eliminated several new or unfamiliar terms. (authored unit, etc.)
- Removed the term Baseline and replaced it with “web technologies that are accessibility supported� and then defined what it means to be accessibility supported.
- Removed the nesting of definitions where we could (i.e. definitions that pointed to other definitions)
- Tried to word things in manners that are more understandable to different levels of Web expertise
- Added short names/handles on each success criterion to make them easier to find and compare etc.
- Simplified the conformance
Shortening the document overall
- Shortened the introduction
- Moved much of the discussion out of the guidelines and put it in the Understanding WCAG 2.0 document
- Shortened the conformance section and moved it after the guidelines
- Moved mapping from WCAG 1 to a separate support document (so it can be updated more easily)
Creating a Quick Practitioner-oriented Summary / Checklist-like document
- Created a Quick Reference document that has just the Guidelines, success criteria and the techniques for meeting the success criteria.
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
label
text, image, or sound that is presented to a user to identify a component within Web content
Apparently it's possible to label something solely with a sound. Doesn't a sound, like an image, then require a text equivalent? Don't you always end up with text? And doesn't this ban the use of video or multimedia as a label? I'm not proposing such a thing, but it seems no less palatable than using an image or a sound as a label.
Thanks for catching. "Sound" shouldn't be there and was removed. And labels are not limited to text and images.
It now reads:
label
text, or other component with a text alternative, that is presented to a user to identify a component within Web content
Note: See also [name].
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
sign-language interpretation
translation of spoken words and other audible information into a language that uses a simultaneous combination of handshapes, facial expressions, and orientation and movement of the hands, arms, or body to convey meaning
One may translate only spoken words? Under WCAG, it becomes illegal to translate from one sign language to another. It also becomes illegal to do what Canada's Copyright Act [7]permits - translate a written work into sign language.
We cannot find anything in the guidelines that prohibits sign language to sign language translation. The definition of sign language interpretation in WCAG 2.0 clearly does not prohibit it. It simply defines the term as used in the success criteria. The success criteria make requirements but do not in any way prevent or forbid translation of one sign language into another.
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
text
sequence of characters[INS: [.] :INS] Note: Characters are those included in the Unicode/ISO/IEC 106464 repertoire.
One may use only characters in Unicode. Given that several scripts are [8]unencoded in Unicode, this may present a problem. Some East Asian languages are more robustly published with legacy encodings even if that is ""improper."" I repeatedly tried to explain to the Working Group that all that matters is a defined and understandable character encoding.
We have changed the definition of text and non-text so that it is clear that we don't preclude the use of non-Unicode encodings as long as AT can handle them (i.e. they can be 'programmatically determined').
text: http://www.w3.org/TR/2007/WD-WCAG20-20070517/#textdef
non-text content: http://www.w3.org/TR/2007/WD-WCAG20-20070517/#non-text-contentdef
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
text alternative
programmatically-determined text that is used in place of non-text content, or text that is used in addition to non-text content and referred to from the programmatically-determined text
Hence a title attribute absolutely is a text equivalent. An image with empty alt plus a title containing what would otherwise be the alt text will pass WCAG 2. (There is some overlap here with UAAG, which can be interpreted to allow presentation of title text instead of regular or alt text.)
The use of title alone (with empty alt text) would not constitute alternate text and would not be sufficient for use as a text alternative. If the alt attribute were empty, it would be stating that the image was decorative and did not need alternate text.
Speaking Technically, programmatically determined means that it is supported by assistive technology. A null alt attribute value is an indication to assistive technology that it should be ignored. Since a title attribute would not be presented by assistive technology if the alt text were empty, it would not be programmatically determined text.
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
used in an unusual restricted way
words used in such a way that users must know exactly what definition to apply in order to understand the content correctly
As opposed to when? When is it possible to misunderstand the definition yet still ""understand the content correctly""?
We have modified the definition slightly to clarify that that this situation applies to situations where words are used in ways where multiple definitions may apply and which definition to use may be unclear to the user.
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
variations in presentations of text
changes in the visual appearance or sound of the text, such as changing to a different font or a different voice
Web authors now have to worry about sound of text? How, exactly? We don't control people's screen readers. (Does this mean we have to find a way to mark up intonation and prosody in our podcasts? How, exactly?)
SC 1.3.4 has been folded into SC 1.3.1, in order to clarify that text variations are one of many types of design that must be semantically identified. SC 1.3.2 is thus more clearly specifically about the non-semantic aspect of the visual design specific to color. As a result, the definition has been removed from the document.
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
We are starting to gather implementation examples during this Last Call review process. Implementation examples are examples of pages or sites that conform to the proposed WCAG 2.0 at various levels of conformance.
I don't see any evidence that the Working Group is ""starting to gather"" anything. I don't see evidence that they're looking for or soliciting ""implementation examples,"" which in any event are virtually nonexistent. WCAG 2, after all, wasn't released in anything resembling a final version until late April 2006. There hasn't been time for authors, even if they wished to comply with WCAG 2, to take measures to do so. (Then there is the fact that there is no payoff for authors to comply with a specification that, first of all, isn't final yet and, second of all, that they may seriously disagree with.)
The Implementation phase begins with the completion of Last Call. We are however already talking to companies and individuals regarding implementations. To make this clearer, we have added the following sentence:
"For those interested in contributing to this effort, please contact Michael Cooper, W3C staff contact to the WCAG WG."
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
The first public Working Draft of WCAG 2.0 was published 25 January 2001. Since then, the WCAG WG has published nine Working Drafts, addressed more than 1,000 issues, and developed a variety of support information for the guidelines.
Exactly how these 1,000 issues were ""addressed"" is open to dispute. Start with the use of a Mozilla Bugzilla database as a front end for bug reports. It's a remarkably inaccessible form, and baffling even to a nondisabled expert. It's true that many, possibly hundreds, of bug reports were remedied by rewriting the spec, but it's also true that many bug reports were simply ignored (with responses that boiled down to ""We don't agree this is a bug"").
At time of writing, WCAG Bugzilla had [10]27 open bugs.
All comments received on the 27 April 2006 Last Call Working Draft have been tracked in a separate database (not bugzilla), and responses written for all the comments. The explanations may include how the working group has modified the spec to address the comment, why the working group feels the issue is outside the scope of the spec, or why the working group does not agree with the commenter.
From http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0119.html
Nobody can understand what the hell a ""Web unit"" is. In the following explanation -
A Web unit conforms to WCAG 2.0 at a given conformance level only if all content provided by that Web unit (including any secondary resources that are rendered as part of the Web unit) conforms at that level.
- what happens if I have a page full of thumbnail images, each with correct alt text as required and each of which links to an image file of a larger version of the picture? Since the image by itself has no HTML or other markup, it's impossible to write an alt text for it. Is this not a ""secondary resource""? If it isn't, does it not then constitute a ""Web unit"" unto itself? Since Web units that are simple image files cannot be made accessible, doesn't WCAG 2 essentially ban freestanding image files?
(We are later told that linking to nonconforming content ""is not prohibited"" - gee, thanks - but only if ""the content itself is [INS: [not] :INS] a Web unit within the set of URIs to which the conformance claim applies."" Hence if my freestanding image is still hosted on my site, I have to make it comply with my conformance claim, which at the very least requires a text equivalent, in turn meaning I have to wrap the image file in HTML. But by the time you the site visitor have selected and loaded that expanded image, you will already have had a chance to read the alt text on the thumbnail image.)
We have revised the guidelines and eliminated the word "Web unit" in favor of "Web page." We have defined "Web page" (see http://www.w3.org/TR/2007/WD-WCAG20-20070517/#webpagedef ):
Web page
a resource that is referenced by a URI and is not embedded in another resource, plus any other resources that are used in the rendering or intended to be rendered together with it
Note: Although any "other resources" would be rendered together with the primary resource, they would not necessarily be rendered simultaneously with each other.
Example 1: When you enter http://shopping.example.com/ in your browser you enter a movie-like interactive shopping environment where you visually move about a store dragging products off of the shelves around you into a visual shopping cart in front of you. Clicking on a product causes it to be demonstrated with a specification sheet floating alongside.
Example 2: A Web resource including all embedded images and media.
Example 3: A Web mail program built using Asynchronous JavaScript and XML (AJAX). The program lives entirely at http://mail.example.com, but includes an inbox, a contacts area and a calendar. Links or buttons are provided that cause the the inbox, contacts, or calendar to display, but do not change the URL of the page as a whole.
Example 4: A customizable portal site, where users can choose content to display from a set of different content modules.
In the situation that you describe, the freestanding images would constitute separate Web pages and would need to conform to WCAG or not be included in a claim. Putting it in an HTML page would be an easy way to make it accessible if that was desired.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006Jun/0133.html
Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):
The success criteria are not stable in the future, and do not capture everything that you need to do. They are the testable aspects of current conformance
I think this limitation needs to be emphasized. Specificly
Success criteria by themselves do not neccesarily mean that the point of the guidleine was achieved-
Proposed Change:
Change the name consistently or currently testable criteria
Since the success criteria are the set of testable statements that can be used in determining conformance to WCAG 2.0, the working group felt that the addition of "consistently" or "currently" would not be helpful in clarifying this issue. However, we have modified the the last paragraph of "The Four Principles of Accessibility" to clarify that meeting the success criterion may not fully address the general principles and guidelines that they relate to, and that additional advisory techniques are provided to go further.
The Understanding WCAG 2.0 document also makes this clear and lists the advisory techniques for guidelines and success criteria. This gives the working group the option of making techniques available to authors that make it possible to go above and beyond the conformance requirements and more completely address the intent of the guidelines and principles.
http://lists.w3.org/Archives/Public/public-comments-wcag20/2006Jun/0136.html
Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):
These are the steps or tasks that have been identified to make script based interfaces operable. This is taken from http://www.w3.org/WAI/PF/GUI/roleTaxonomy-20060508.html and was well researched. Without any one of these tasks many interfaces will not be accessible.
My I suggest that we review WCAG to test if these steps are suffiently included and WACG does require each task as described hear. For
for example
3.1.3 Information and relationships conveyed through presentation can be programmatically determined, and notification of changes to these is available to user agents, including assistive technologies.
Does that include all the group identification as necciasy
Anyway, hope this is useful
steps or tasks are as follows......
3.1 How To Build Applications Using Roles
This section is informative.
3.1.1 Step 1: Use your native mark up as well as you can
Use the semantic elements that are defined in the native markup language. For example, if you are using [XHTML] it is better to use the [XHTML] checkbox than to use a div element with role checkbox. Because properly used [XHTML] content is already repurposible, roles are best used when the mark up language does not support all the semantics that you need. When a role is used the semantics and behavior of the element are overridden by the role behavior.
3.1.2 Step 2: Find the right roles
Set roles to make sure elements behave predictably and that correctly describes the behavior of each element within your application (unless elements behaviors are fully described by the native markup language). Roles for interactive elements should support all the states that the element could use.
3.1.3 Step 3: Look for groups
Look for groups within a page, and mark them using the most appropriate role that best describes their usage.
For example: a region of the page that is contains a group of elements that are likely to change through an AJAX application could be tagged as a \"liveregion\".
3.1.4 Step 4: Build relationships
Look for relationships between groups and mark the using the most appropriate property or attribute.
Sometimes the relationships can be made clear via the native mark up language, such as the label tag in [<a href=\"#ref_HTML\">HTML</a>].
Sometimes this can be implied via the DOM. For example, when a well marked up list contains list items it is known that they belong to the containing list. In such cases you do not need to set additional properties to make that explicit.
In other cases use the states and adaptable properties module to state relationships. For example: if a container A contains search results, and container B contains the search controls, the mark each container as a region and set the aaa:controledby property in region B to region A.
3.1.5 Step 5: Set properties
Set properties until the behavior of the element is defined.
Control the behavior of the element using device independent events, states, and properties.
Extra states and properties have been provided by the States and Adaptable Properties Module. For example: If the user is required to fill in a form element set the aaa:required property to true.
An important addition in the States and Adaptable Properties Module is new extensions of TABINDEX. Now, with the TABINDEX change, the author is allowed to give any element keyboard focus (and not just form elements or anchors). In this paradigm shift, the user experience should be to use tabbing or keyboard mnemonics to move focus to widgets on the web page and then use the arrow keys to navigate the object.
Example: building a tree view in XHTML 1.0
This section is informative.
A basic tree view allows the user to select different list items and expand and collapse embedded lists. Arrow keys are used to navigate through a tree, including left/right to collapse/expand sub trees. Double clicking with mouse also toggles expansion.
Step one: Look at your native mark up language
There is no a tree element in [XHTML] 1.0 that supports our behavior including expansion, so we will need to use roles. Therefore, our first step is setting roles.
Step two: Finding the right roles
Our tree will need roles that support embedded list behavior and expandable/collapsible embedded lists. The roles that support tree behavior for a tree are:
Tree: the main container element for our treeA form of a Select (or, generally, of a list having groups inside groups) - where sub trees can be collapsed and expanded.
Treegroup: This is a group of sibling tee items that have a common parent. Intended use is for creating groups of treeitems within a tree container.
Treeitem: An option item of a tree. This is an element within a tree which may be expanded or collapsed.
Step three and four: Look for groups and build relationships
Tree relationships can be made simply via the Dom and logical structure of your page.
A tree element will be the main container containing all other elements in the tree.
Each selectable item in the tree will be a treeitem
When a tree item contains a embedded list of tree items they will be all embedded in a treegroup. A treegroup should be contained inside the tree item that is the parent item.
Tree relationships are like list relationships in [XHTML]. A treegroup and tree elements act like list containers (OL and UL). A tree item acts like a list item (li) in [XHTML].
Because treeitems and treegroups are commonly both use div elements it is recommended to ad a comment next to closing treeitems that contain embedded tree groups
<div x2:role=\"wairole:tree\" >
<div x2:role=\"wairole:treeitem\" >Veggies
<div x2:role=\"wairole:treegroup\">
<div x2:role=\"wairole:treeitem\">Green
<div x2:role=\"wairole:treegroup\">
<div x2:role=\"wairole:treeitem\">Asparagus</div>
<div x2:role=\"wairole:treeitem\">Kale</div>
<div x2:role=\"wairole:treeitem\" >Leafy
<div x2:role=\"wairole:treegroup\">
<div x2:role=\"wairole:treeitem\">Lettuce</div>
<div x2:role=\"wairole:treeitem\">Kale</div>
<div x2:role=\"wairole:treeitem\">Spinach</div>
<div x2:role=\"wairole:treeitem\">Chard</div>
</div>
</div> ---close leafy
<div x2:role=\"wairole:treeitem\">Green beans</div>
</div>
</div> ---close green
<div x2:role=\"wairole:treeitem\">Legumes</div>
<div x2:role=\"wairole:treeitem\" >Yellow
<div x2:role=\"wairole:treegroup\">
<div x2:role=\"wairole:treeitem\">Bell peppers</div>
<div x2:role=\"wairole:treeitem\">Squash</div>
</div>
</div> ---close yellow
</div>
</div> ---close veggies
</div> ---close tree
Sometimes a tree structure is not explicit via the Dom and logical structure of a page. In such cases the relationships must still be made explicit using the properties module.
Example:
<div x2:role=\"wairole:treeitem\" aaa:haschild=yellowtreegroup�>Yellow<div>
..
<div id=\"yellowtreegroup\" x2:role=\"wairole:treegroup\">
<div x2:role=\"wairole:treeitem\">Bell peppers</div>
<div x2:role=\"wairole:treeitem\">Squash</div>
</div>
Although this is allowed it may affect performance
Step 5: Use properties
Control the behavior of the element using Events and states,
For example, use the aaa name space with supporting scripts to control what tree elements are expanded
<div tabindex=\"-1\" x2:role=\"wairole:treeitem\" aaa:expanded=\"true\">Yellow</div>
And use events to device independent events with supporting javascripts to handle user interaction.
<div x2:role=\"wairole:tree\" tabindex=\"-1\"
onfocus=\"return treeItemFocus(event);\"
onclick=\"return treeItemEvent(event);\"
ondblclick=\"return treeItemEvent(event);\"
onkeydown=\"return treeItemEvent(event);\"
onkeypress=\"return treeItemEvent(event);\">
Then create javascript support to control the event driven behavior or the application.
Proposed Change:
During the development of WCAG 2.0 the Working Group made certain that the success criterion do not prevent the use of Dynamic Web Content Accessibility techniques. We believe that each of the steps you cite are covered by one of the success criterion listed below:
1.3.1: Information and relationships conveyed through presentation can be programmatically determined, and notification of changes to these is available to user agents, including assistive technologies.
2.1.1: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
4.1.1: 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.
4.1.2: For all user interface components, the name and role can be programmatically determined, states, properties, and values that can be set by the user can be programmatically determined and programmatically set, and notification of changes to these items is available to user agents, including assistive technologies.
The steps in your example map to one or more success criteria:
Step 1: Use your native mark up as well as you can is covered by SC 1.3.1, 4.1.1, and 4.1.2
Step 2: Find the right roles is covered by 4.1.2,
Step 3: Look for groups is covered by 1.3.1, 4.1.1, and 4.1.2. Although these success criteria do not explicitly mention groups, they do cover relationships. This satisfies the group requirement for current technologies such as HTML which do not allow for the addition of specific group roles but do convey the meaning of groups through specific elements such as lists. Dynamic Web Content Accessibility techniques can be used to add roles to HTML when Dynamic Web Content Accessibility technologies are included the baseline.
Step 4: Build relationships is covered by 1.3.1, 4.1.1, and 4.1.2. Again, this may not be as explicit as you would like but is supported by current technologies.
Step 5: Set properties is covered by 4.1.2.
Any requirements for keyboard support are covered by 2.1.1 and 2.1.2.
Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):
Whilst WAI has been a political success, the WAI model (reliant of WCAG, ATAG and UUAG) is fundamentally flawed and has quite clearly failed. The individual guidelines themselves are flawed, as we are seeing with the move to WCAG 1.0.
In addition, the WAI guidelines, which seek to address *Web* accessibility can act to the detriment of wider accessibility, which may be addressed at an operating system level, for example, or by other approaches, such as that taken by the IMS AccessForAlll approach.
It should also be noted that IMS has a different definition of disability to WAI, which is based on a social model, rather thab WAI\'s medical model. It is unfortunate that the WAI approach is based on a model which is not universally applicable.
However rather than seeking to develop a more open and user-focussed approach, WCAG 2 takes a very technical approach which is difficult to understand. It also fails to allow for a diversity of approaches to accessibility.
This is very worrying, as WAI should be seeking to develop a broad model which will provide a solid foundation for building accessibility. Attempting to build a standard on the flawed approach of WCAG 2.0 will be counter-productive for accessibility and undermine the work of W3C.
It should also be noted that an over-prescriptive appoach can (is) leading to continued use of provietary solutions (e.g. on Intranets) as there is less of a legal reliance to make non-Web applications accessible.
For further information see:
Contextual Web Accessibility - Maximizing the Benefit of Accessibility Guidelines, <http://www.ukoln.ac.uk/web-focus/papers/w4a-2006/>;
Forcing Standardization or Accommodating Diversity? A Framework for Applying the WCAG in the Real World, <http://www.ukoln.ac.uk/web-focus/papers/w4a-2005/>;
Proposed Change:
My proposals:
o Withdraw WCAG 2.0
o Produce an errata for WCAG 1.0
o Develop an open approach/model for accessibility
o Be explicit in \'difficult\' examples of applications of WAI guidelines (e.g. Podcasting)
WCAG was chartered with specific goals and requirements (see <http://www.w3.org/TR/wcag2-req/>;http://www.w3.org/TR/wcag2-req/).
WCAG 2.0 works within the same framework as WCAG 1.0, so it is not clear how withdrawing WCAG 2.0 and producing an errata for WCAG 1.0 would address your issues with the WAI model being inappropriate.
Although WAI specifically addressed only web accessibility, other standards efforts look at web and non-web accessibility, and we have worked closely with those standards bodies to ensure that WCAG is as consistent and harmonious with them as possible. We do not believe they are in conflict.
With regard to the other aspect of your comment dealing with WAI model being inadequate that topic is beyond our charter. We have forwarded your comments to the WAI director so that you can take up your discussion with her if you like.
Part of Item:
Comment Type: question
Comment (including rationale for proposed change):
Please define or point to criteria for \"high inter-rater reliability\". This is important for developing evaluation procedures based on WCAG 2.0 (especially evaluation procedures that can be repeated with the same results for the same content, although, after reading http://www.socialresearchmethods.net/kb/reltypes.htm and http://www2.chass.ncsu.edu/garson/pa765/reliab.htm, inter-rater reliability is not the same thing as test-retest reliability).
There was an action item for research on inter-rater reliability (http://www.w3.org/2005/04/27-wai-wcag-minutes.html#item02) but I don\'t know what came out of it.
Proposed Change:
Inter-rater reliability is the extent to which multiple evaluators of a task or performance give identical ratings. This is often measured by Cohen's kappa, where 0 indicates agreement due to chance alone and 1 indicating perfect agreement. See http://www.measurementexperts.org/instrument/term_pocket_terms.asp
Test-retest refers to the ability of the same person to come up with the same results each time they rate something.
Inter-rater reliability is a tougher standard than test-retest.
We no longer use this term in WCAG 2.0. Instead, we have revised this section to say "The same results should be obtained with a high level of confidence when people who understand how people with different types of disabilities use the Web test the same content."
Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):
The note to SC 3.1.2 reads: \"This requirement does not apply to individual words or phrases that have become part of the primary language of the content.\": this is a problem for foreign words in a passage or quote that is not in the primary language.
This wording was introduced in the June 2006 Working Draft; before that, it read \"This does not include use of foreign words in text where such usage is a standard extension of the language,\" but I believe this was changed because the term \"foreign\" was considered problematic.
Proposed Change:
Rephrase the note to: \"This requirement does not apply to individual words or phrases that have become part of the language of the immediately neighbouring text.\"
We have revised the note to read, "This requirement does not apply to individual words. It also does not apply to proper names, to technical terms or to phrases that have become part of the language of the context in which they are used."
Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):
In general DSI would like to point out that some of the new terms and their definitions makes the language used in WCAG 2.0 difficult to understand, especially for foreigners and consequently difficult to translate into other languages.
Proposed Change:
Simplify the language and carefully explain new terms.
We have reworked the entire document to make it shorter and easier to read. This includes:
- Shortening the introduction
- Moving much of the discussion out of the guidelines and puttin it in the Understanding WCAG 2.0 document
- Shortening the conformance section and moving it after the guidelines
- Writing simpler guidelines
- Removing as many technical terms (jargon) as possible, replacing them with simpler language or their definitions
- Removing the nesting of definitions where we could (i.e. definitions that pointed to other definitions)
- Moving information about mapping between WCAG 1 and WCAG 2 to a separate support document (so it can be updated more easily)
- Creating a Quick Reference documents that has just the Guidelines, success criteria and the techniques for meeting the success criteria.
- Trying to word things in manners that are more understandable to different levels of Web expertise
- Adding short names/handles on each success criterion to make them easier to find and compare etc.
- Simplifying the conformance section
- Using plainer language wherever possible (e.g. – use “Web page� instead of “Web Unit�)
- Eliminating several new or unfamiliar terms. (authored unit, etc.)
- Making the whole document much shorter.
Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):
WCAG 2.0, addresses almost all the open issues against the previous working draft. WCAG 2.0 working draft Guidelines and success criteria are more robust and testable. We\'ve reviewed the draft and have the following suggestions:
Proposed Change:
*The issues of multiple disabled persons should be specified in the Draft.
*All the imperative sentences should be changed to declarative sentences for the easiness of reference.
*Check for the proper usage of the words, ‘Criteria’ (plural) and ‘Criterion’(singular).
*Splitting of words should be avoided for the proper understanding of the users who are using assistive technologies like screen readers and we would like to add this issue to WCAG 2.0.
Regarding multiple disabilities: We aren't specifying disabilities in the guidelines themselves. In the support documents we refer to people by characteristics they may have. Thus a single person may be referred to in different places for having different disabilities. Also, disability pairs like deaf-blindness that have particular significance we try to mention where they are specifically addressed. If you see additional places where we missed a disability-pair, please let us know.
Regarding imperatives: The guidelines (which are general directives) are all imperatives. However all of the success criteria are declaratives. We are keeping the guidelines as imperatives so that they are not confused with the success criteria and so that people do not try to assess them as testable when they are meant to be directive.
Regarding Criteria/Criterion: Thank you. We hope to have caught them all and fixed them. I'm sure we have them all in the guidelines themselves now. If you see any in any of the support documents, just drop us a note any time.
Regarding splitting of words: The working group believes this issue is covered by success criterion 1.3.3, "When the sequence of the content affects its meaning, that sequence can be programmatically determined." Specifically, F32: Failure of SC 1.3.3 due to using white space characters to control spacing within a word (http://www.w3.org/TR/WCAG20-TECHS/Overview.html#F32) illustrates situations where the use of blank characters to visually format individual words will make it difficult for users of assistive technology to understand the content.
Congratulations on your Last Call.
One comment that you may have received from others: If the
principles [1] were maintained outside the guidelines [2], then
the guidelines might be easier to find and comprehend. The
guidelines would then have thirteen whole numbers.
Maybe [1] could say which guidelines developed from which
principle. Below is just a text outline. I wonder if the spec
adheres to its subject -- the guidelines -- if implementers may
find the guidelines easier to follow over time.
Hope this helps.
For [1]:
========
* Principle 1: Content must be perceivable (Guidelines 1-4).
* Principle 2: Interface components in the content must be
operable (Guidelines 5-9).
* Principle 3: Content and controls must be understandable
(Guidelines 10-11).
* Principle 4: Content should be robust enough to work with
current and future user agents (including
assistive technologies) (Guidelines 12-13).
For [2]:
========
* Guideline 1: Provide text alternatives for all non-text content.
* Guideline 2: Provide synchronized alternatives for multimedia.
* Guideline 3: Ensure that information and structure can be
separated from presentation.
* Guideline 4: Make it easy to distinguish foreground information
from its background.
* Guideline 5: Make all functionality operable via a keyboard
interface.
* Guideline 6: Allow users to control time limits on their reading
or interaction.
* Guideline 7: Allow users to avoid content that could cause
seizures due to photosensitivity.
* Guideline 8: Provide mechanisms to help users find content, orient
themselves within it, and navigate through it.
* Guideline 9: Help users avoid mistakes and make it easy to correct
mistakes that do occur.
* Guideline 10: Make text content readable and understandable.
* Guideline 11: Make the placement and functionality of content
predictable.
* Guideline 12: Support compatibility with current and future user
agents (including assistive technologies).
* Guideline 13: Ensure that content is accessible or provide an
accessible alternative.
[1]
http://www.w3.org/TR/2006/WD-WCAG20-20060427/intro.html#overview-design-principles
[2] http://www.w3.org/TR/2006/WD-WCAG20-20060427/guidelines.html
Best wishes for your project.
The working group considered making this change to the numbering scheme. However, we felt that it is important to have a different numbering scheme between WCAG 1.0 and WCAG 2.0 since both sets of guidelines are likely to be in use in various contexts at the same time.
it would be useful to read an example of web unit that is NOT a web page.
We have replaced the term "Web unit" with "Web page" and have modified the section on new terms to describe our use of the term "Web page" in greater detail. We have also added an example of content that may not immediately be recognized as a "Web page." See http://www.w3.org/TR/2007/WD-WCAG20-20070517/#webpagedef .
Web page
a resource that is referenced by a URI and is not embedded in another resource, plus any other resources that are used in the rendering or intended to be rendered together with it
Note: Although any "other resources" would be rendered together with the primary resource, they would not necessarily be rendered simultaneously with each other.
Example 1: When you enter http://shopping.example.com/ in your browser you enter a movie-like interactive shopping environment where you visually move about a store dragging products off of the shelves around you into a visual shopping cart in front of you. Clicking on a product causes it to be demonstrated with a specification sheet floating alongside.
Example 2: A Web resource including all embedded images and media.
Example 3: A Web mail program built using Asynchronous JavaScript and XML (AJAX). The program lives entirely at http://mail.example.com, but includes an inbox, a contacts area and a calendar. Links or buttons are provided that cause the the inbox, contacts, or calendar to display, but do not change the URL of the page as a whole.
Example 4: A customizable portal site, where users can choose content to display from a set of different content modules.
in note 1 you refer to triple A but that concept has not been yet defined
Thank you for catching this. We have completely rewritten the conformance section, and triple A is now defined before it is used.
if content is “info communicated to user� then it does not include code and markup. IMO a person senses, perceives, understands signals sent over some medium by a physical device, and decides, plans an action, and acts physically on some device. Information can only be “sent� or “received� in this way (up to now). Code and markup is being sent to the user agent, which contributes to trasforming them into signals. But code is never information, as long as a web user is involved.
Thank you for pointing this out. The new definition is now:
"information and sensory experience to be communicated to the user by means of a user agent, as well as code or markup that define the structure, presentation, and interactions associated with those elements"
say that “information� is defined below
The meaning here is the common meaning of the word. Per a rule to not keep words in glossary that are used in their standard dictionary defined way, we have removed 'information' from our glossary.
i don't think that's a proper and useful definition; arithmetic theory is a collection of facts and inferential rules; but I wouldn't say that saying “1+1 equals 2� is providing information.
Proposed Change:
at least refer to what others said about it; eg Bateson defined information as “the difference that makes a difference�
The meaning here is the common meaning of the word. Per a rule to not keep words in glossary that are used in their standard dictionary defined way, we have removed 'information' from our glossary.
is a smiley nontext content?
Yes:
- if it is an image, it is non-text content
- if it is in characters, it is ASCII art - which is also non-text content per definition in the glossary.
“content that changes the meaning of a web unit�? but a web unit is defined as “a collection of information ...� and content as “information to be communicated� how can a content change the meaning of other content? It surely can (eg adding a “not� in front of a sentence might change its meaning). Is this what 321 wants to prevent?
Web pages do indeed contain content. And if that content changes to other content (with a different meaning) at a time that is unexpected, it can be missed or generate confusion. This is what we are referring to. With regard to your specific question about adding the word "not" to a page: That is an interesting example. Normally, changing a single word on a page would not be considered a change of context. However, if the individual has read past that point and the addition of the word changes the meaning of the whole page (for example from supporting or agreeing with something to disagreeing with it) then it would indeed be a change of context to the user and it would be covered here for obvious reasons.
a “small class of input�? any gesture (which is by nature time-dependent) that requires a mouse by definition cannot be done with a keyboard. Similarly for a pointing pen (like signing on a screen). or using a joystick to fly a virtual airplane. I think that as long as the user clicks with the mouse then that can be reasonably easy and similarly be implemented with keyboard interaction. Clicks and movements (like in drag and drop) somewhat less easily and similarly.
Thank you for pointing out the ambiguity of the wording. The SC wording has been changed to:
2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)
Note: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path dependent input but the underlying function (text input) does not.
Note: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.
In Understanding 2.1.1, we added: The phrase "except where the underlying functionality requires path dependent input" is included to separate those things that cannot reasonably be controlled from a keyboard.
Most actions carried out by a pointing device can also be done from the keyboard (for example, clicking, selecting, moving, sizing). However, there is a small class of input that is done with a pointing device that cannot be done from the keyboard in any known fashion without requiring an inordinate number of keystrokes. Free hand drawing, watercolor painting, and flying a helicopter through an obstacle course are all examples of functions that require path dependent input. Drawing straight lines, regular geometric shapes, re-sizing windows and dragging objects to a location (when the path to that location is not relevant) do not require path dependent input.
"The document states: ""The author is responsible for ensuring that the content is delivered in such a way that software can access it.""
""Software"" is confusing here. What type of software are you referring to?"
Proposed Change:
Change
""The author is responsible for ensuring that the content is delivered in such a way that software can access it.""
to
""The author is responsible for ensuring that the content is delivered in such a way that user agents and assistive technologies can access it.""
We have revised this sentence to read as follows:
This means that the content is delivered in such a way that user agents, including assistive technologies, can access the information.
Definition of "programmatically determined" is confusing.
Proposed Change:
Proposal for definition of ""programmatically determined"":
""available through content markup (element name, attributes, or properties) or style sheet properties in the case of markup languages or through accessibility APIs in the case of GUI applications.
Note: User agents can extract this information from content markup and style sheet properties and make it available to an assistive technology through programmatic means such as through the DOM or accessibility API. Accessibility APIs may be defined by the technology owner or in a publicly documented alternative recognized as explicitly supporting accessibility.
We have not changed the definition to distinguish between markup and non-markup languages, but we have added several examples to the definition to highlight the use of direct access and access via accessibility APIs.
The definition of Web unit may not work for SVG.
We have modified the term "Web unit" to be "Web page" and have updated the definition, http://www.w3.org/TR/2007/WD-WCAG20-20070517/#webpagedef .
Web page
a resource that is referenced by a URI and is not embedded in another resource, plus any other resources that are used in the rendering or intended to be rendered together with it
Note: Although any "other resources" would be rendered together with the primary resource, they would not necessarily be rendered simultaneously with each other.
Example 1: When you enter http://shopping.example.com/ in your browser you enter a movie-like interactive shopping environment where you visually move about a store dragging products off of the shelves around you into a visual shopping cart in front of you. Clicking on a product causes it to be demonstrated with a specification sheet floating alongside.
Example 2: A Web resource including all embedded images and media.
Example 3: A Web mail program built using Asynchronous JavaScript and XML (AJAX). The program lives entirely at http://mail.example.com, but includes an inbox, a contacts area and a calendar. Links or buttons are provided that cause the the inbox, contacts, or calendar to display, but do not change the URL of the page as a whole.
Example 4: A customizable portal site, where users can choose content to display from a set of different content modules.
The title for principle 4 does not fit the requirements. Also, future user agents may not render the old content. The principle just does not make sense.
Proposed Change:
Change principle 4 to "Content must be interoperable with assistive technologies."
We have revised Principle 4 to fit the requirements more accurately.
SVG is not likely to be compliant in its current form.
It is the working group's opinion that this is best handled from the SVG end and doesn't impact the WCAG document itself. From our discussion I take it you agree but that you were just pointing this out in an informative way and are not asking for action on the part of the WCAG WG.
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.
Rather than attempting to explain this term, the authors provide a link to the definition in "XML Schema Part 2: Datatypes, Appendix F". The "definition" in the XML Schema is incomprehensible to the majority of us. Presumably the purpose of including a word in the glossary is to render it understandable to people who don't already understand it.
Proposed Change:
Please explain it in layman's terms and provide the link to XML Schema only as a supplemental reference.
We have completely rewritten the Conformance section. The format of this description is no longer specified. The corresponding required component is now:
4. A description of the URIs that the claim is being made for, including whether subdomains are included in the claim.
We have added examples to illustrate the use of boolean and regular expressions in a conformance statement.
Some of the suggestions made in this submission - if not implemented in W2 - will possibly find inclusion in a future version of the Government of Canada's "Common Look and Feel Policy" for federal Web sites either as standards (requirements) or guidelines (optional/best practices). Unfortunately, this will lead to a "disharmonization" [sic] of standards which is in no-one's best interest.
We have considered your suggestions (and all the others that we have received) very carefully, and have tried hard to address your issues, either in the guidelines or in advisory techniques.
We agree that harmonization among accessibility standards is highly desirable.
This customizable "view" of WCAG 2.0 is far and away the best thing the working group has done for the average end user. We hope this resource continues to be developed and maintained. It is likely to be the main entry point to W2 for many of our users. The opportunity to bypass inapplicable content is irresistable.
Proposed Change:
The same paradigm should be used for future support materials created by the GL working group and/or the Education and Outreach working group.
Thank you.
it is our plan to continue this resource and we also figured that it would be the primary entry point for developers.
A sympathetic reading suggests what you want to mean, but this text does not say it.
As rendered, text is represented by glyphs, not Unicode characters. Unicode characters are integer index values into the catalog of characters.
And the critical property is the independence of any structure beyond the stream arrangment of the characters, as demonstrated by the fact that the character sequence is effective in conveying the intended understanding. The sequence of characters in the encoded form is not suffucient. This has been recognized and expressed by the "as rendered" language. But you need to make the cognitive effectiveness aspect of the test more overt.
When natural language is written down, it is often encoded in alphabetical writing systems or scripts. Other forms of communication such as mathematical notations and symbolic identifiers have re-used the characters, or bits and pieces of these writing systems, which have been atomized into recombinant elements by the invention of movable type.
This issue clearly illustrates the superiority of stating separate requirements on the as-rendered representation of the content and on the as-communicated representation thereof.
Proposed Change:
Try:
"Text content is content which conveys its intended meaning when rendered in a sequence of glyphs recognizable as representing the characters from some writing system.
"Content where character sequences are used to form a symbolic code to reconsrtruct media or action scripts, such as the Base64 encoding of a GIF format image, or an ECMASCRIPT imperative instruction set, are to be considered non-text content. Likewise, character sets where the glyphs must be presented in a particular two-dimensional arrangment such as ASCII art are to be considered non-text content."
Add separate encoding requirement:
Text content is to be conveyed from the author's automation to the user's automation [in accordance with | in a mannter interoperable with] the Character Model for the World Wide Web (CharMod).
Consider lifting language from the IMS accessibility metadata documents. IIRC that is where I got this concept.
The working group is trying hard to use language that is as simple as possible. We have revised the definitions of "text" and "non-text content" as follows:
text
sequence of characters that can be programmatically determined, where the sequence is expressing something in human language
non-text content
any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language
Note: This includes ASCII Art (which is a pattern of characters) and leetspeak (which is character substitution).
Part of Item:
Comment Type: editorial
Comment (including rationale for proposed change):
Editorial suggestions
Proposed Change:
note: some similar suggestions for other appendices and so any changes should be synched
suggestion: unbold \"Note:\" and \"Example:\" (rationale: with them bold my eye is drawn from the bold term to the bold Note or Example, bypassing the actual definition. also makes it harder to skim the terms )
suggestion: remove the numbers from the notes and examples -- e.g., instead of \"Note 1:\", \"Note 2:\", \"Note 3:\" just have \"Note:\", \"Note:\", Note:\".. (rationale: simplifies, makes more friendly and less engineering-like and formal)
suggestion: consider putting the referenced terms in regular font style, not italic (rationale: simplify visual design). consider using standard link colours for terms
suggestion: consider removing [brackets] from references. (rationale: simplifies visual design. also some people will not know what the brackets mean and will waste cognitive processing trying to figure it out.)
suggestion: Consider deleting one of the “normative�?s -- from the <h1>: \"Appendix A: Glossary (Normative)\" or from the first sentence: “This section is normative.�? If leave first sentence, change to “Appendix A: Glossary is normative.�?
suggestion: clean up top matter (\"Quick Table of Contents\" extraneous? \"Appendix A: Glossary (Normative)\" repetitive with <h1> and links to self)
question: should the <title> and the <h1> match, or be more similar?
suggestion: unbold \"Note:\" and \"Example:\" (rationale: with them bold my eye is drawn from the bold term to the bold Note or Example, bypassing the actual definition. also makes it harder to skim the terms )
response: We have unbolded both "Note:" and "Example:" throughout.
suggestion: remove the numbers from the notes and examples -- e.g., instead of \"Note 1:\", \"Note 2:\", \"Note 3:\" just have \"Note:\", \"Note:\", Note:\".. (rationale: simplifies, makes more friendly and less engineering-like and formal)
response: Numbering notes is a common practice within standards and makes them easier to reference, so we have decided to keep the numbers. Note that the numbering only appears when multiple notes are present.
suggestion: consider putting the referenced terms in regular font style, not italic (rationale: simplify visual design). consider using standard link colours for terms
response: We have removed the italics from the terms, but have retained the link colors to make it easier to differentiate between links to the glossary and links to other locations.
suggestion: consider removing [brackets] from references. (rationale: simplifies visual design. also some people will not know what the brackets mean and will waste cognitive processing trying to figure it out.)
response: We have removed the square brackets from the links to "How to Meet" at the end of each success criterion. However, the use of square brackets for references (links to the references appendix) is part of the W3C style (http://www.w3.org/2001/06/manual/#References).
suggestion: Consider deleting one of the “normative�?s -- from the <h1>: \"Appendix A: Glossary (Normative)\" or from the first sentence: “This section is normative.�? If leave first sentence, change to “Appendix A: Glossary is normative.�?
response: We have removed the parentheticals "(Informative)" and "(Non-Normative)" from the appendices and have replaced occurrences of non-normative with informative throughout. We have also included links to the glossary definition of informative in the glossary where appropriate.
suggestion: clean up top matter (\"Quick Table of Contents\" extraneous? \"Appendix A: Glossary (Normative)\" repetitive with <h1> and links to self)
question: should the <title> and the <h1> match, or be more similar?
response: The guidelines are no longer split into multiple pages, so the quick TOC and variations between <title> and <h1> are no longer an issue.
Part of Item:
Comment Type: editorial
Comment (including rationale for proposed change):
Editorial suggestions
Proposed Change:
note: some similar suggestions for other appendices and so any changes should be synched
suggestion: Edit first paragraph -- will help with specific suggestions – e.g., “The Web Content Accessibility Guidelines 2.0 Checklist serves as an appendix to Web Content Accessibility Guidelines 2.0 [WCAG20]�? is unnecessary given the title; explain where the “[How to meet]�? links go. Keep in mind that this page will be pointed to, printed, and used as a separate document. Add pointer to Overview of WCAG 2.0 Documents www.w3.org/WAI/intro/wcag20 (which will explain “For many readers, the Checklist provides a quick reference and overview to the information in WCAG 2.0.�? and so probably delete it here.)
suggestion: Use “Informative�? rather than “Non-Normative�? and link “informative�? to the glossary definition. Consider deleting one of them – either from the <h1> or from the first sentence. If leave first sentence, change to “Appendix B: Checklist is informative.�?
suggestion: within table, align top (note with my configuration (Opera at 150%) I see nothing in the first 2 columns at the top of the first table)
suggestion: remove hover colour (rationale: adds unnecessary complexity, complicates colour coding because highlight colour is same at Level 2 colour) note: in Opera 8.5 Windows the entire row is highlighted
suggestion: put a column heading on the first column (“Level�?) and underneath it use either “Level #�? or just “#�? (rather than current “L#�?)
suggestion: remove line under Guideline (rationale: adds visual complexity, unnecessary since all that is under it is table)
suggestion: consider putting the referenced terms in regular font style, not italic (rationale: simplify visual design) consider using standard link colours for terms
suggestion: consider putting the success criteria numbers in regular font style, not italic (rationale: simplify visual design)
question: why not include [Understanding] links for the guidelines?
suggestion: clean up top matter (\"Quick Table of Contents\" extraneous? \" Appendix B: Checklist�? repetitive with <h1> and links to self)
question: should the <title> and the <h1> match, or be more similar?
The checklist has been removed from the WCAG 2.0 appendices. However, a number of the issues raised here have been addressed in responses to suggestions made in other issues. We have also added "Understanding Guideline X.X" links to the guidelines.
This requirement is mis-filed in the current outline. This is a control issue, a matter of keeping actions under the user's command. If it were an orientation issue (principle 3) one could repair by announcing context changes. That is not enough. In the current outline it belongs with Principle 2.
Proposed Change:
re-flow this requirement under what the user can do, not what they can understand.
This success criterion is included because the unexpected change of context is disorienting, not because it introduces barriers to operation.
Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):
Editorial suggestions
Proposed Change:
note: some similar suggestions for other appendices and so any changes should be synched
suggestion: Use “Informative�? rather than “Non-Normative�? and link “informative�? to the glossary definition. Consider deleting one of them – either from the <h1> or from the first sentence. If leave first sentence, change to “Appendix C: Acknowledgements is informative.�?
suggestion: remove “C.1�? and “C.2�? from the <h2>s (rationale: simpler, friendlier, less formal)
suggestion: clean up top matter (\"Quick Table of Contents\" extraneous? \" Appendix C: Acknowledgements\" repetitive with <h1> and links to self)
question: should the <title> and the <h1> match, or be more similar?
question: should WCAG WG be spelled out? (yes, if consider this separate document, no if consider this a section of large document where it is spelled out in first reference)
suggestion: consider linking WCAG WG to www.w3.org.WAI/GL/
suggestion: Use “Informative�? rather than “Non-Normative�? and link “informative�? to the glossary definition. Consider deleting one of them – either from the <h1> or from the first sentence. If leave first sentence, change to “Appendix C: Acknowledgements is informative.�?
response: We have removed the parentheticals "(Informative)" and "(Non-Normative)" from the appendices and have replaced occurrences of non-normative with informative throughout. We have also included links to the glossary definition of informative in the glossary where appropriate.
suggestion: remove “C.1�? and “C.2�? from the <h2>s (rationale: simpler, friendlier, less formal)
response: We have removed the heading numbering for the appendices.
suggestion: clean up top matter (\"Quick Table of Contents\" extraneous? \" Appendix C: Acknowledgements\" repetitive with <h1> and links to self)
question: should the <title> and the <h1> match, or be more similar?
response: The guidelines are no longer split into multiple pages, so the quick TOC and variations between <title> and <h1> are no longer an issue.
question: should WCAG WG be spelled out? (yes, if consider this separate document, no if consider this a section of large document where it is spelled out in first reference)
suggestion: consider linking WCAG WG to www.w3.org.WAI/GL/
response: We have added a paragraph to this appendix that both spells out the acronym and links to the working group's home page.
Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):
Editorial suggestions
Proposed Change:
note: some similar suggestions for other appendices and so any changes should be synched
suggestion: Use “Informative�? rather than “Non-Normative�? and link “informative�? to the glossary definition. Consider deleting one of them – either from the <h1> or from the first sentence. If leave first sentence, change to “Appendix D: Comparison of WCAG 1.0 checkpoints to WCAG 2.0 is informative.�?
suggestion: within table, align top (note with my configuration (Opera at 150%) I see nothing in the left column at the top of the first table)
suggestion: combine “New Level 1 requirements in WCAG 2.0 not mapped above�?, “New Level 2…�? and “New Level 3…�? into “WCAG 2.0 Success Criteria not mapped above�? (already have the level at the end of each success criteria) (rationale: groups information better by topic instead of splitting topics across multiple sections)
suggestion: Change column heading “WCAG 2.0 Success Criteria�? to “WCAG 2.0�? since that column includes some techniques and other info
suggestion: capitalize “Checkpoints�? in headings (including <h1>)
suggestion: consider putting the referenced terms in regular font style, not italic (rationale: simplify visual design) consider using standard link colours for terms
suggestion: consider putting the success criteria numbers in regular font style, not italic (rationale: simplify visual design)
suggestion: clean up top matter (\"Quick Table of Contents\" extraneous? \"Appendix D: Comparison of WCAG 1.0 checkpoints to WCAG 2.0\" repetitive with <h1> and links to self)
question: should the <title> and the <h1> match, or be more similar?
The mapping has been removed form the WCAG document itself. Since you and the EOWG WCAG 2.0 Materials Support Task Force will be involved in the creation of transition materials, we are forwarding your comment back to you for consideration in future versions of the mapping. Thanks for taking this on.
Part of Item:
Comment Type: editorial
Comment (including rationale for proposed change):
Editorial suggestions
Proposed Change:
note: some similar suggestions for other appendices and so any changes should be synched
suggestion: Use “Informative�? rather than “Non-Normative�? and link “informative�? to the glossary definition. Consider deleting one of them – either from the <h1> or from the first sentence. If leave first sentence, change to “Appendix E: References is informative.�?
suggestion: clean up top matter (\"Quick Table of Contents\" extraneous? \" Appendix E: References\" repetitive with <h1> and links to self)
question: should the <title> and the <h1> match, or be more similar?
question: WCAG20 reference is circular. not sure why it’s there?
suggestion: Use “Informative�? rather than “Non-Normative�? and link “informative�? to the glossary definition. Consider deleting one of them – either from the <h1> or from the first sentence. If leave first sentence, change to “Appendix E: References is informative.�?
response: We have removed the parentheticals "(Informative)" and "(Non-Normative)" from the appendices and have replaced occurrences of non-normative with informative throughout. We have also included links to the glossary definition of informative in the glossary where appropriate.
suggestion: clean up top matter (\"Quick Table of Contents\" extraneous? \" Appendix E: References\" repetitive with <h1> and links to self)
question: should the <title> and the <h1> match, or be more similar?
response: The guidelines are no longer split into multiple pages, so the quick TOC and variations between <title> and <h1> are no longer an issue.
question: WCAG20 reference is circular. not sure why it’s there?
response: We have removed this reference.
Principle is "First, Do no Harm." Compare with Hippocratic Oath. This is a safety requirement, it comes before access requirements, and is not an access requirement.
Proposed Change:
Introduce separate principle for safety and move this guideline to it. Make it the first, before others. Remove all obstacles to implementing this provision severable from the rest.
This does not change conformance to the guidelines any and therefore has no actual impact on Web content. There is no suggestion for any other success criteria under this principle. It does not seem like a sufficient justification to create a whole new principle with one guideline with 2 success criteria. We have decided to keep this under Ability to Operate section for practical and logistical reasons.
This is a general usability practice.
Proposed Change:
Reorganize to address overlap with general usability in a positive way.
See other comments on organization and explanation.
There is some overlap with general usability, but we are staying away from usability as any organizational principle due to strong feelings that WCAG should not address general usability issues that do not affect people with disabilities disproportionately.
The definition in the Glossary makes the similarity test for things that are to be identified alike too narrow. It says identical result; that is much too narrow. This equivalence class should be made as broad as possible until it starts to degrade the user's ability to predict the system response from the prompt material. For example, context-sensitive help will be identified in the context menu simply as 'help' although the precise results are different for each context. This minimizes the vocabulary the user has to learn. The class of like-identified action opportunities defines the actual concept; the question is how the user's interpretation of the prompt material -- the concept identification -- matches this.
Proposed Change:
Move to section under the education and usability principle "repetition builds recall". In other words, address usability explicitly in the development of the set of provisons, don't just make a vague disclaimer that doesn't admit how what we do say is straight from usability, but applied to mitigating PWD risks of funtion failure, task failure or interminable task times.
We have revised the introduction text to read, "The guidelines do not include standard usability recommendations except where they have a significantly greater impact on people with disabilities than on other people." We have also changed "identical" to "same" in the definition of "same functionality".
Beyond this, we are not using usability as an organizing principle and are not addressing usability explicitly.
Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):
Organizing by WCAG 1.0 Priorities makes it quite difficult to process the information. Topics (such as forms, tables) are split across different sections and tables. Checkpoints are not in order.
If it was organized as in WCAG 1.0 (that is, numerically), it would be much easier to both understand the differences in how topics are addressed, and to find individual checkpoints.
Proposed Change:
Organize as is in WCAG 1.0, that is, numerically, rather than grouping by priorities.
The mapping has been removed from the WCAG document itself. Since you and the EOWG WCAG 2.0 Materials Support Task Force will be involved in the creation of transition materials, we are forwarding your comment back to you for use in future versions of the mapping.
Thanks for taking this on.
Part of Item:
Comment Type: editorial
Comment (including rationale for proposed change):
Having an empty Quick Table of Contents is confusing
Proposed Change:
Eliminate the Quick Table of Contents, unless subsections are added so that a Quick TOC is needed.
The guidelines are no longer split into multiple pages, so the quick TOC is no longer in use.
Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):
It is initially unclear that this comparison table is complex, showing both correspondences and differences between WCAG 1.0 and WCAG 2.0.
Proposed Change:
Clarify by:
- adding an explanation in the introduction to the comparison table that this is a complex comparison, showing both the correspondences and the differences between WCAG 1.0 checkpoints and WCAG 2.0 success criteria; and
- adding an additional column to the table, identifying whether the correspondence shown is a parallel reference, a difference, a gap, etc.
The mapping has been removed from the WCAG document itself so that it will be easier to maintain over time and to reflect new techniques as they come out. The working group will work in coordination with the EOWG WCAG 2.0 Materials Support Task Force in the creation of transition materials and will consider these comments when the mapping is updated.
Part of Item:
Comment Type: editorial
Comment (including rationale for proposed change):
People may need to use the comparison table in very different ways, but the current organization of the mapping table does not easily allow for that. Also, some users may not initially realize the various ways it can be helpful, or may misunderstand it as solely as mapping table, or gap table, etc.
Proposed Change:
Clarify purpose & uses of the table by:
1. Adding a column for keywords, and enable multiple views of the comparison table, for instance:
-- sequencing by WCAG 2.0 success criteria
-- sequencing by WCAG 1.0 checkpoint number
-- sequencing by level
-- sequencing by keyword
2. Adding a few very brief use-cases as a mini-introduction, to highlight what this comparison table can be used for; for example:
-- if you are currently using WCAG 1.0, and want to see what the corresponding provision might be in WCAG 2.0;
-- if you are already using WCAG 2.0, but need to demonstrate conformance to WCAG 1.0;
-- if you need to compare what is required under a given priority or level of conformance;
-- if you need to find how a certain issue, such as color contrast, is handled in both WCAG 1.0 and WCAG 2.0
The mapping has been removed from the WCAG document itself so that it will be easier to maintain over time and to reflect new techniques as they come out. The working group will work in coordination with the EOWG WCAG 2.0 Materials Support Task Force in the creation of transition materials and will consider these comments when the mapping is updated.
Part of Item:
Comment Type: editorial
Comment (including rationale for proposed change):
The title \"Comparison of WCAG 1.0 checkpoints to WCAG 2.0\" of this appendix is unclear; similarly, the heading of the left column is unclear.
Proposed Change:
Change the title of this appendix to: \"Comparison of WCAG 1.0 Checkpoints and WCAG 2.0 Success Criteria,\" and add a more explicit heading (e.g. \"WCAG 1.0 Checkpoint\") to the left column.
The mapping has been removed from the WCAG document itself so that it will be easier to maintain over time and to reflect new techniques as they come out. The working group will work in coordination with the EOWG WCAG 2.0 Materials Support Task Force in the creation of transition materials and will consider these comments when the mapping is updated.
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:
Comment Type: editorial
Comment (including rationale for proposed change):
The comparison table is complex, and is consequently currently difficult to read with screen magnification, and also via screen reader. Simple linearization may not help much because of the complexity of the table.
Proposed Change:
Add extensive orientation notes to an accessible version. Check readability with magnification and with speech or braille output. [Note: an EOWG participant may send more specific suggestions.]
The mapping has been removed from the WCAG document itself so that it will be easier to maintain over time and to reflect new techniques as they come out. The working group will work in coordination with the EOWG WCAG 2.0 Materials Support Task Force in the creation of transition materials and will consider these comments when the mapping is updated.
Part of Item:
Comment Type: editorial
Comment (including rationale for proposed change):
The format of the explanatory text following the success criteria is difficult to follow, as the linked text is overly marked up with underline, color, italics (which increase reading difficulty), and on-hover highlights.
Proposed Change:
Eliminate the italics and possibly also the on-hover highlights.
We have removed the italics from the terms and have removed the square brackets from the links to "How to Meet SC X.X.X." The on-hover highlights on links are assigned by base.css which is a required W3C Style.
Part of Item:
Comment Type: editorial
Comment (including rationale for proposed change):
It is difficult to understand the logical relationship in success criteria 1.1.1, because of the \"one of the following\" phrasing.
Proposed Change:
Use the \"at least one of the following\" phrasing from 2.2.1 and 2.5.3; and check for clarity and consistency of logical relationships throughout the rest of the success criteria.
Success Criterion 1.1.1 was reworded. The bullets are now mutually exclusive, so the term "at least" is no longer necessary.
Part of Item:
Comment Type: editorial
Comment (including rationale for proposed change):
The term \"time-out\" (also written as \"timeout\" in the same section) is not a familiar term for many readers.
Proposed Change:
Add a glossary entry for \"time-out.\"
We have updated SC 2.2.1 to use the term "time limit" instead of "time-out".
Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):
The term \"conformance\" is not necessarily a well understood term for many readers, and its use in the definition of \"normative\" therefore makes the definition of \"normative\" difficult to understand.
Proposed Change:
Add a definition for conformance, consistent with the definition of the EOWG definition of \"conforms,\"
http://www.w3.org/WAI/glossary/basic.html#conform
to the WCAG 2.0 glossary, and reference it in the definition of \"normative.\"
We have added the term to the glossary as follows:
conformance
satisfying all the requirements of a given standard, guideline or specification
Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):
Consider dropping the top numbering level. Going from three numbering levels (1.1.1.) down to two (1.1.) would make the guidelines feel less complex and less “daunting�? (quote from usability testing participant :).
Add the Principles in the supporting documents, as they do provide nice framing and grouping for the guidelines.
Proposed Change:
* Leave the Principles as they are in /TR/WCAG20. Remove the first numbering from all guidelines and success criteria, e.g.:
- Guideline 1 Provide text alternatives for all non-text content
- Success Criteria 1.1 For all non-text content, one of the following is true
* Add the Principles into “Understanding�?
* Consider including the Principles in the Quick Ref and Checklist.
The working group considered making this change to the numbering scheme. However, we felt that it is important to have a different numbering scheme between WCAG 1.0 and WCAG 2.0 since both sets of guidelines are likely to be in use in various contexts at the same time.
Part of Item:
Comment Type: substantive
Comment (including rationale for proposed change):
The definition for assistive technology is difficult to understand because it gives the restrictive before the general meaning; also, it may be too restrictive, in describing legacy assistive technologies (for instance, some screen readers now are creating their own DOM separate from the mainstream browser).
Proposed Change:
EOWG recommends eliminating part (1) of the definition. (Note: We think that this would work *because* your definition of user agent is broad enough to already cover some of the functions of some assistive technologies.)
Response: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0405.html
We have changed the order of the items in the definition to make the restriction less confusing. We feel it is important to keep the restriction that assistive technology depends on a host user agent so that the success criteria require support for external assistive technology and can't just be satisfied by mechanisms that are internal to the user agent. However, we have added a note that host user agents may provide direct support for users with disabilities.
Part of Item:
Comment Type: editorial
Comment (including rationale for proposed change):
Some of the Glossary items are hard to follow because of the Notes.
Proposed Change:
EOWG recommends integrating the Notes back into the main definitions, and linking back to the main use of the defined term in the guidelines.
We don't want to change the format away from the format we are using for definitions, where the definition can substitute for the word or phrase. We will be adjusting the spacing, however, so that the notes are tucked up against the definitions rather than looking like they are separate entities. This also allows the notes to be formatted for easier understanding for many of the definitions.
Regarding the suggestion to link back to the main use of terms, many terms are used many times and there isn't really a main use to link back to.
Part of Item:
Comment Type: editorial
Comment (including rationale for proposed change):
The mouse-over highlighting color adds confusion
Proposed Change:
EOWG suggests removing it.
Agree. It has been removed.
Part of Item:
Comment Type: editorial
Comment (including rationale for proposed change):
The \"L1\" is unclear.
Proposed Change:
Change \'L1\' to \'Level 1\' etc, and add a heading of \'Level\' to the first column
We have added a heading of "Level" to the first column as proposed and have replaced L1, L2, L3 with the appropriate level.
Part of Item:
Comment Type: editorial
Comment (including rationale for proposed change):
Some readers may not realize that you can save the checklist and add comments to the fourth column as a report.
Proposed Change:
In the 'blurb' explaining what the checklist is for, explain that it is intended that you can save the document and add comments to the fourth column as a report.
Alternatively, provide a simpler table and also a downloadable (RTF) document for evaluation reporting and annotation purposes.
The checklist has been removed form the WCAG document itself. At this point there are no longer any checklists, just the Quick Reference. Since you and the EO working group will be involved in the creation of Checklists in the future we are forwarding your comment back to EO for use in that work.
Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):
EOWG approved the following comments prepared by Shawn Henry. Background first, on distribution of material among WCAG 2.0 and supporting documents:
1. WCAG 2.0: Purpose is a stable reference for policies, etc. Keep it as simple and succinct as possible. Clearly point to other documents for important information, such as more info on baseline (which is done in current draft). Leave out any historical info and such (take out some of what is there now).
2. Checklist: Purpose is quick list for people who already know WCAG 2.0 and just need to check off that they’re remembering everything when doing an evaluation, for example. [Other common uses?] (Note that it’s *not* useful as an overview for newbies.)
3. “Understanding�? [or other title]: Purpose is *the* document that most people will use most of the time. Note that since all the guidelines and success criteria are in here I think few people will even look at /TR/WCAG20. [Do you agree?]
* @@
4. Techniques: Purpose is details for implementing. Assume developers are the only target audience. [correct?]
5. Overview (w3.org/WAI/intro/wcag20): Purpose is simple, friendly, directive front door to WCAG 2.0 docs. I think almost all references to WCAG 2.0 (for example, links in other WAI Resources, slides, and such) should point to this overview.
6. [About Baselines]: Eliminate this document. Put the pertinent information about baselines in “Understanding�?, as there’s no reason to send people to yet another document for this information. The non-pertinent info that’s there now could go in 7 below.
7. [something like Background, or WG Notes, or History, or QA or�?¦]: Purpose is to communicate reasons why things were done, address some concerns or issues, and such. For example, move to here most of the “Background�? section from About Baselines, “Why wasn't UAAG used as baseline?�?, and why 2.0 Levels different from 1.0 Priorities (currently in WCAG20 Conformance).
8. [Application Notes] Purpose is to help developers working on a specific thing, such as images, links, forms, data tables. (Brief description is under http://www.w3.org/WAI/intro/wcag20.php#related) Note that I think these should cover just the basics, and point back to "Understanding" & "Techniques" for the more complex issues.
9. [Plain-Language Version WCAG 2.0 "101" WCAG 2.0 "for Dummies" WCAG 2.0 Intent] Purpose is for the average person to be able to understand the basics of WCAG 2.0. I imagine taking each guideline and success criteria and providing it in an understandable way. Perhaps this is mostly pulling out the information from the “Intent�? section of "Understanding". Note that this is problematic as it would have to be carefully and clearly positioned, since it would *not* cover all the issues.
10. [Quick Tips] Purpose is something short that touches on the basics to help people get started on accessibility " to fit on a business-card-sized handout.
Proposed Change:
The main change from what is in the current WCAG 2.0 documents and above is moving out of the main /TR/WCAG20 document Comparison with WCAG 1.0, explanatory examples, and other details. In addition to simplifying the normative doc, this puts the explanatory information where it can be updated to reflect changes over time as necessary. It also limits the need for repetition across documents (e.g., now some information in /TR/WCAG20 Conformance is repeated in About Baselines, and not at all in Understanding). I think it also would ensure that people don’t miss important information. (Since it becomes clear that the /TR/WCAG20 only contains the standards, and all other info is in Understanding.)
Based on above, I propose moving the following sections out of /TR/WCAG20 Conformance:
I. Move into a new "Baselines" section of "Understanding":
a. Under Who sets baselines?:
"
...
There are several reasons for this. First, what is appropriate in a baseline may differ for different environments. For example, in the case of content that will be viewed only by employees of a particular company, it may be possible to assume that user agents support more advanced technologies if the company provides the necessary user agents (including assistive technology) to all employees. For public Websites, however, a more conservative level of technology may be all that can be reasonably assumed. Baselines may also vary by jurisdiction. Finally, the level of technology that can be assumed to be supported by accessible user agents will certainly change over time.
Some examples of baselines:
Example 1: A government site that provides information to the public. A government agency publishes information intended for the general public. The specified baseline includes only technologies that have been widely supported by more than one accessible and affordable user agent for more than one release. The government periodically changes the baseline it requires for developers of public sites to reflect the increasing ability of affordable user agents (including assistive technology) to work with newer technologies.
Example 2: A particular government provides high level accessible user agents to all citizens who need them. A government provides all citizens with user agents that support newer technologies. The government is thus able to specify a baseline that includes these newer technologies for all of its Websites for its citizens since the government can assume its citizens' user agents can handle the technologies.
Example 3: A private intranet. An organization (public or private) provides its employees with the information technology tools they need to do their jobs. The baseline for intranet sites used only by employees includes newer technologies that are supported only by the user agent that the organization provides for its employees. Because the company controls the user agents that will view its internal content, the author has a very accurate knowledge of the technologies that those user agents (including assistive technologies) support.
Note: In the examples above, the baseline is not specified in terms of specific user agents but rather in terms of the Web content technologies that are supported and enabled in those user agents (including assistive technologies).
"
b. All of Examples of conformance claims:
"
Examples of conformance claims
Example 1: On 23 March 2005, http://www.wondercall.example.com conforms to W3C's WCAG 2.0, Conformance Level A. The baseline for this claim is XHTML 1.0. The specification that this content "relies upon" is: HTML 4.01. The specifications that this content "uses but does not rely on" are: CSS2, and gif. This content was tested using the following user agents and assistive technologies: Firefox 1.5 on Windows 2000 SP4 with Jaws 7.0, Firefox 1.5 on Windows XP SP 2 with Jaws 7.0, IE 6.0 on Windows 2000 SP4 with Jaws 4.51, IE 6.0 on Windows 2000 SP4 with Jaws 7.0, and Firefox 1.5 on Windows XP SP2 with Jaws 7.0, Safari 2.0 with OS X 10.4.
Example 2: On 5 May 2006, "G7: An Introduction" http://telcor.example.com/nav/G7/intro.html conforms to W3C's WCAG 2.0. Conformance Level Double-A. The following additional success criteria have also been met: 1.1.2, 1.2.5, and 1.4.3. The baseline for this claim is UDBaseline#1-2006 at http://UDLabs.org/Baseline#1-2006.html. The specification that this content "relies upon" is: XHTML 1.0 (Strict), and Real Video. The specifications that this content "uses but does not rely on" are: JavaScript 1.2, CSS2.
Example 3: On 21 June 2007, http://example.com/nav and http://example.com/docs conform to W3C's WCAG 2.0, Conformance Triple-A. The baseline is ISA-Baseline#2-2007 at http://ISA.example.gov/Baselines/BL2-2007. The specifications that this content "relies upon" are: XHTML 1.0 (Strict), CSS2, JavaScript 1.2, jpeg, png. " The technologies this content has been tested with can be found at http://example.com/docs/WCAG20/test/technologies.html.
"
c. All of Content that conforms to WCAG 1.0:
"
Content that conforms to WCAG 1.0
This Working Draft of WCAG 2.0 builds upon WCAG 1.0 and reflects feedback received since the publication of WCAG 1.0 in May 1999.
The Web Content Accessibility Guidelines Working Group is working to ensure that organizations and individuals who are currently using WCAG 1.0 (which remains stable and normative at this time) will be able to smoothly transition to WCAG 2.0. For more information about the similarities and differences between WCAG 1.0 Checkpoints and WCAG 2.0 Guidelines and success criteria, please refer to the (draft) Mapping between WCAG 1.0 and the WCAG 2.0 Working Draft.
Authors whose content currently conforms to WCAG 1.0 may wish to capitalize on past accessibility efforts when making the transition to WCAG 2.0. A qualified conformance statement could allow them this flexibility. For example, a conformance claim might include the following statement: "Materials with creation or modification dates before 31 December 2006 conform to WCAG 1.0. Materials with creation or modification dates after 31 December 2006 conform to WCAG 2.0."
"
II. Move to Document #7 [Background, or WG Notes, or History, or Q&A] above:
"This method of grouping success criteria differs in important ways from the approach taken in WCAG 1.0. Each checkpoint in WCAG 1.0 was assigned a "priority" according to its impact on accessibility. Thus, Priority 3 checkpoints appeared to be less important than Priority 1 checkpoints. The WCAG Working Group now believes that all success criteria of WCAG 2.0 are essential for some people. Thus, the system of checkpoints and priorities used in WCAG 1.0 has been replaced by success criteria under Levels 1, 2, and 3 as described above. Note that even conformance to all three levels will not make Web content accessible to all people."
These are excellent suggestions. Below is a partial list of the actions taken to address these, and a couple of things that we have not addressed.
#9 - a simple version. We have a draft but do not want to confuse people by releasing it at this time. Once the main document is out we want to work with EO to complete this.
#10 Quick Tips. EO did a great job of this last time. We would like to help you to do this rather than do one ourselves. We think this would be good to do in conjunction with the SIMPLE version above.
The 12 guidelines are a good starting point.
We have reworked the entire document to make it shorter and easier to read and understand with different levels of expertise. This includes
Easier language to understand
- Wrote simpler guidelines
- Removed as many technical terms (jargon) as possible replacing them with plainer language or, where possible, their definitions
- Eliminated several new or unfamiliar terms. (authored unit, etc.)
- Removed the term Baseline and replaced it with “web technologies that are accessibility supported�? and then defined what it means to be accessibility supported.
- Removed the nesting of definitions where we could (i.e. definitions that pointed to other definitions)
- Tried to word things in manners that are more understandable to different levels of Web expertise
- Added short names/handles on each success criterion to make them easier to find and compare etc.
- Simplified the conformance
Shortening the document overall
- Shortened the introduction
- Moved much of the discussion out of the guidelines and put it in the Understanding WCAG 2.0 document
- Shortened the conformance section and moved it after the guidelines
- Moved mapping from WCAG 1 to a separate support document (so it can be updated more easily)
Creating a Quick Practitioner-oriented Summary / Checklist-like document
- Created a Quick Reference document that has just the Guidelines, success criteria and the techniques for meeting the success criteria.
Part of Item:
Comment Type: editorial
Comment (including rationale for proposed change):
The \"Quick Table of Contents\" at the start of the introduction section is confusing; it\'s unclear whether this is for the section or for the whole document.
Proposed Change:
Clarify that the intro section is part of a set of pages. Please see detailed comment and suggestions on re-wording at: http://lists.w3.org/Archives/Public/w3c-wai-eo/2006AprJun/0109.html
We have removed the multi-part version of the guidelines, so the "Quick Table of Contents" is no longer present. However, we will take these recommendations into consideration as we develop other views of the WCAG 2.0 supporting materials.
Part of Item:
Comment Type: editorial
Comment (including rationale for proposed change):
The confusion between the Intro page & the whole WCAG 2.0 continues in the \"Related Documents\" subsection
Proposed Change:
Clarify there that \"this document\" refers to the whole set of WCAG 2.0 pages. E.g., these are the things w/in WCAG 2.0, and then these are the things outside of WCAG 2.0 (or the WCAG 2.0 TR doc)
We have completely revised this section of the Introduction and believe that this issue has been addressed.
Part of Item:
Comment Type: editorial
Comment (including rationale for proposed change):
The amount of jargon in the introduction makes it less helpful than possible as introductory material; for instance, "conformance", "success criteria", "how to meet links", "intent",
"sufficient techniques", "baseline assumptions."
Proposed Change:
Copyedit for increased use of plain English explanations; and/or introduce the jargon later in the introduction.
We have reworked the entire document to make it shorter and easier to read. This includes:
- Shortening the introduction
- Moving much of the discussion out of the guidelines and puttin it in the Understanding WCAG 2.0 document
- Shortening the conformance section and moving it after the guidelines
- Writing simpler guidelines
- Removing as many technical terms (jargon) as possible, replacing them with simpler language or their definitions
- Removing the nesting of definitions where we could (i.e. definitions that pointed to other definitions)
- Moving information about mapping between WCAG 1 and WCAG 2 to a separate support document (so it can be updated more easily)
- Creating a Quick Reference documents that has just the Guidelines, success criteria and the techniques for meeting the success criteria.
- Trying to word things in manners that are more understandable to different levels of Web expertise
- Adding short names/handles on each success criterion to make them easier to find and compare etc.
- Simplifying the conformance section
- Using plainer language wherever possible (e.g. – use “Web page�? instead of “Web Unit�?)
- Eliminating several new or unfamiliar terms. (authored unit, etc.)
- Making the whole document much shorter.
Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):
Editorial suggestions for http://www.w3.org/TR/WCAG20/guidelines.html
Proposed Change:
Consider:
* Move <h1> before the Contents list
* Delete “WCAG 2.0 Guidelines�? at the top, which links to itself and is redundant with <title> and <h1>
* Remove line under from “Quick Table of Contents�? and change to something like “Page Contents�?
* In “This section is normative.�? sentence, link “normative�? to glossary definition.
* Re-consider this <title> and <h1> in relationship with http://www.w3.org/TR/WCAG20/Overview.html <title> and <h1>
* When there are no Success Criteria at a level, combine the current heading and sentence into a single heading, e.g.:
instead of:
<h4>Level 2 Success Criteria for Guideline 1.1
<p>(No level 2 success criteria for this guideline.)
have:
<h4>(No Level 2 Success Criteria for Guideline 1.1)
* Put “See also�? links in regular font style, not italic (rationale: simplify visual design). (example: “For multimedia, see also Guideline 1.2 Provide synchronized alternatives for multimedia.�?)
* Consider putting the referenced terms in regular font style, not italic (rationale: simplify visual design). consider using standard link colours for terms
* Consider putting the success criteria numbers in regular font style, not italic (rationale: simplify visual design)
* Move <h1> before the Contents list
* Delete “WCAG 2.0 Guidelines�? at the top, which links to itself and is redundant with <title> and <h1>
* Remove line under from “Quick Table of Contents�? and change to something like “Page Contents�?
* Re-consider this <title> and <h1> in relationship with http://www.w3.org/TR/WCAG20/Overview.html <title> and <h1>
response: The guidelines are no longer split into multiple pages, so the quick TOC and related comments above are no longer an issue.
* In “This section is normative.�? sentence, link “normative�? to glossary definition.
response: We have added the link as proposed.
* When there are no Success Criteria at a level, combine the current heading and sentence into a single heading, e.g.:
instead of:
<h4>Level AA Success Criteria for Guideline 1.1
<p>(No level AA success criteria for this guideline.)
have:
<h4>(No Level AA Success Criteria for Guideline 1.1)
resposne: We have removed the <h4> for empty level AA and AAA sections and replaced with "(No Level X SC for GL X.X)." The reason for not including these as headers was to avoid situations where users would could navigate to headers which contained no content.
* Put “See also�? links in regular font style, not italic (rationale: simplify visual design). (example: “For multimedia, see also Guideline 1.2 Provide synchronized alternatives for multimedia.�?)
response: We have removed the italics from these references.
* Consider putting the referenced terms in regular font style, not italic (rationale: simplify visual design). consider using standard link colours for terms
response: We have removed the italics from the terms, but have retained the link colors to make it easier to differentiate between links to the glossary and links to other locations.
* Consider putting the success criteria numbers in regular font style, not italic (rationale: simplify visual design)
response: We have removed the italics for the SC numbers and handles.
Part of Item:
Comment Type: editorial
Comment (including rationale for proposed change):
The penultimate paragraph (\"Several success criteria require...\") is difficult to understand and contains more detail than seems necessary or appropriate for an introduction.
Proposed Change:
Copyedit to clarify and simplify.
We have rewritten the paragraph to be simpler and we have removed the examples of transformations that could be performed by user agents.
Part of Item:
Comment Type: general comment
Comment (including rationale for proposed change):
Suggest re-focusing documents
Proposed Change:
Rough thoughts on content and positioning of the different WCAG 2.0 documents and change suggestions below (revised somewhat since < http://lists.w3.org/Archives/Public/w3c-wai-eo/2006AprJun/0091.html>;).
Note: Some of the changes below have already been discussed within the WCAG WG and are planned, and some are my own ideas that have not yet been discussed and are likely to continue to evolve.
High level summary:
- Take all but the minimum out of the /TR/WCAG20 pages, especially moving out a lot of the text from Introduction and Conformance, and moving Checklist and Comparison (“mapping�?) Appendices
- Make /TR/WCAG20 the formal reference only, and direct all informative pointers to the Overview doc, and from there to the UI (next point)
- Create a user interface (UI) to access the “atoms�? of Understanding and Techniques as needed, rather than the primary interaction being through /TR/WCAG20 to the middle of a large docs
Details:
1. /TR/WCAG20: Purpose is formal Technical Specification/W3C Recommendation/Standard that is stable and referenceable. Keep it as simple and succinct as possible. Include only the minimum needed for the actual technical specification. Clearly point to other documents for important information, such as more info on baseline.
Note: Encourage all general references to WCAG to go to the Overview doc <www.w3.org/WAI/intro/wcag20>, and only formal references in policies and such to point to /TR/WCAG20 (and there to also point to the Overview doc as informative).
Changes & Rationale:
The main change I suggest is moving out of the main /TR/WCAG20 Introduction and Conformance pages the Comparison with WCAG 1.0, explanatory examples, and other details. In addition to simplifying the normative doc, this puts the explanatory information where it can be updated to reflect changes over time as necessary. It also limits the need for repetition across documents (e.g., now some information in /TR/WCAG20 Conformance is repeated in About Baselines). I think it also would ensure that people don’t miss important information (since it becomes clear that the /TR/WCAG20 only contains the standards, and all other info is in Understanding).
* Move all information explanatory information not necessary for the technical specification, such as what is listed under “Based on above, I propose moving the following sections out of /TR/WCAG20 Conformance:�? in http://lists.w3.org/Archives/Public/w3c-wai-eo/2006AprJun/0091.html
* Move “Appendix B: Checklist�?. Now that the guidelines are so nicely free of extraneous information (i.e., moved extra information that was within the guidelines themselves in WCAG 1.0 to “Understanding 2.0�?), this checklist is not needed as part of /TR/WCAG20. Now http://www.w3.org/TR/WCAG20/appendixB.html pretty much equals http://www.w3.org/TR/WCAG20/guidelines.html and is therefore redundant. (See more with #@@ below)
* Move “Appendix D: Comparison of WCAG 1.0 checkpoints to WCAG 2.0�? from the formal /TR/WCAG20 doc and make it a supporting doc. (See above for rationale, including that it can be more easily edited if outside of the /TR/WCAG20 Recommendation.)
2. Overview </WAI/intro/wcag20>: Purpose is clear, friendly, directive intro and map to WCAG 2.0 docs.
Note: Encourage all general references to WCAG to point to the Overview doc www.w3.org/WAI/intro/wcag20 (and only formal references in policies and such to point to /TR/WCAG20).
Changes:
* Edit to be more effective in this purpose. (Action, Shawn)
3. WCAG 2.0 Quick Reference www.w3.org/WAI/WCAG20/quickref/: List of requirements and techniques, customizable to make as short and focused as needed for specific situations. This may evolve into the primary tool/doc that most people use most of the time as the main page to WCAG 2.0 information.
Changes:
* Consider additional customization options, such “[ ] Show Common Failures�? to be able to turn them off and shorten the doc.
* Perhaps design this to also replace the Checklist, e.g. by adding:
[ ] Show Techniques
[ ] Include Comment column and checkbox
* Evaluate usability for possible UI improvements.
4. [Checklist </TR/WCAG20/appendixB.html>]: Purpose is quick list for people who already know WCAG 2.0 and want a short list to check off that they’re remembering everything when doing an evaluation, for example. [Other common uses?]
Changes & Rationale:
See under #1 about it being redundant with http://www.w3.org/TR/WCAG20/guidelines.html. The WCAG 1.0 Checklist was very useful as a quick reference and overview of 1.0 guidelines for newbies. This WCAG 2.0 Checklist is not. We already made a Quick Reference, and we might make something for newbies.
I wonder if we want to provide this 2.0 Checklist at all? Perhaps the benefit some people will get from it is not worth the complication of having yet another WCAG 2.0 document? If we do keep it, I think it should be carefully positioned for what it is and what it is not, and not detract from the other documents that might meet most needs better.
5. “Understanding�? [or other title]: Purpose is to provide details for people who want to understand the guidelines in depth.
Changes & Rationale:
* Consider changing title. (I think others have provided rationale and suggestions.)
* Move into this document details on Conformance and Baseline.
* Add brief explanations of the Principles.
* Add pointer to Overview doc near front.
* Develop UI that lets people easily get the “atoms�? of info that they want at a time, and navigate between atoms here, from Techniques, and other related documents as appropriate.
6. Techniques: Purpose is details for implementing. Developers are the main target audience.
Changes:
* Develop UI that lets people easily get the “atoms�? of info that they want at a time, and navigate between atoms here, from Understanding, and other related documents as appropriate.
7. [Application Notes] Purpose is to help developers working on a specific thing, such as images, links, forms, data tables. (Brief description is under http://www.w3.org/WAI/intro/wcag20.php#related) Note that I think these should cover just the basics, and point back to “Understanding�? & “Techniques�? for the more complex issues.
8. [Web Accessibility Basics] (document not yet defined) Purpose would be for the average Web developer to be able to understand the basics of Web accessibility under WCAG 2.0. An easy-to-understand list of what one needs to do for a simple site with HTML and CSS.
(Acknowledge that this would have to be very carefully and clearly positioned, since it would not cover all the issues.)
9. [Quick Tips] Purpose is something short that touches on the basics to help people get started on accessibility – to fit on a business-card-sized handout.
10. [About Baselines]: Eliminate this document. Put the pertinent information about baselines in “Understanding�?, as there’s no reason to send people to yet another document for this information. The non-pertinent info that’s there now could go in 11 below.
11. [something like Background, or WG Notes, or History, or FAQ, or…]: Purpose is to communicate reasons why things were done, address some concerns or issues, and such. For example, from About Baselines move to here most of the “Background�? section and “Why wasn\'t UAAG used as baseline?�?.
12. [Transition from WCAG 1.0 to WCAG 2.0] (document not yet defined) Not sure if a single document, or series of documents?
Changes:
* Move “Comparison of WCAG 1.0 checkpoints to WCAG 2.0�? from /TR/WCAG20 appendix to here
* Move why 2.0 Levels different from 1.0 Priorities (currently in WCAG20 Conformance) to here
We believe we have substantially addressed these issues with revisions to the introduction, conformance section, and appendices.
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.
Issues with commenting - It is difficult to accurately comment on WCAG2 when the documents that are needed to understand WCAG2 are not normative and are not complete. For example, one cannot interpret a SC without referring to techniques, yet these are not normative. There has been a lot of people saying WCAG2 is difficult to understand, yet they cannot rely on the UW or TD documents as these are neither normative or complete. The WG could vote to significantly change these documents, thereby significantly changing the meaning of particular success criteria, without ever allowing comments from the public. In a perfect world neither the UW or TD documents would be required in order to understand WCAG2 but taking into account the difficulty most people are having with interpreting WCAG2, these documents are becoming mandatory reading.
Proposed Change:
Allow for a subsequent 'Last Call' when all documents are complete, and specify that WCAG2 must be read and interpreted in conjunction with UW and TD documents
In order to be technology neutral but accurate and testable the guidelines themselves need to be written in language that sometimes can be abstract or technical. We recognize that this can make them difficult to understand. We have spent much time trying to figure out how to make them as simple to understand as possible while keeping them accurate and clear. We have also been very careful to be sure that the guidelines themselves contain what is required. Information in the non-normative documents can never require anything that is not already required by the language in the normative document. Thus the guidelines can stand on their own in terms of 'interpretability'. However we have also created extensive support documentation to help make them easier to understand and to include examples and specific techniques for meeting them.
The Understanding WCAG documents and techniques documents will continue to evolve because technologies and user agent support continue to evolve, so that new sufficient techniques can emerge as assistive technology and other user agent support improves over time. It is important that these documents remain non-normative so that they can be changed as our collective knowledge grows.
It is very useful to read the ancillary documents to better understand the document. The ancillary materials may aid comprehension but are not in fact normative. The ancillary materials have been filled in since the time of the comment, and while not fully complete, are being republished at the same time in order to provide non-normative explanatory information to aid comprehension.
Definition of accessibility - In the Baseline document (under the heading 'If the WCAG does not set the baseline, then how can we be sure that a site will be accessible?) it says "No site or content is ever completely accessible". In the Conformance document it says "Note that even conformance to all three levels will not make web content accessible to all people." I strongly object to these statements. All content can be made accessible. In some cases, content may not be accessible, but if the problems were identified it could be made accessible. As the main body representing accessibility I think it reprehensible that we have these statements.
Proposed Change:
Remove the statements. Merge Level 1 and Level 2 SC into one group called 'Mandatory'. Rename Level 3 to 'Advisory' or 'Optional'
The statements you refer to are meant to reflect the reality that not all Web content can be made accessible to all people. One of the lessons learned with WCAG 1.0 was that, for some individuals, even content that meets WCAG 1.0 AAA did not overcome the accessibility barriers faced by those with certain combinations of disabilities or with certain types of severe disabilities.
Regarding the proposal to combine levels A and AA as mandatory and rename level AAA to advisory or optional, the working group has received a great deal of feedback on both sides of this issue. We have chosen three levels because we feel it provides the best options for the different users of the guidelines.
Definition: "For all non-text content one of the following is true…if non-text content is pure decoration, or used only for visual formatting, or if it is not presented to users, it is implemented such that it can be ignored by assistive technology". What is the definition of assistive technology? If one assistive technology behaves one way and another assistive technology another, then how should this SC be followed?
Proposed Change:
Redefine this SC
Assistive technology is defined in the Glossary at http://www.w3.org/WAI/GL/WCAG20/appendixA.html#atdef .
Technology-specific techniques define sufficient mechanisms for marking non-text content so that it will be ignored by AT. If there are differences in behavior among different AT, these should be noted in the User Agent notes for that technique.
Term: success criteria - The term "Success Criteria" is not explained in the "Important new terms used in WCAG 2.0" section of the WCAG2 document
Proposed Change:
The term "Success Criteria" should be added to the "Important new terms used in WCAG 2.0" section of the WCAG2 document
We have added a paragraph to this section that describes the term. See http://www.w3.org/TR/2007/WD-WCAG20-20070517/#overview-sc .
3.2.1 & 2.2.5: From my reading, 3.2.1 outlaws changes of context when a component receives focus, but 2.2 allows changes in content for no reason (only outlawing at L3)
Proposed Change:
Rewrite SC 3.2.1 and 2.2.5
While it is possible that the result of a time limit expiration may be a change in context or content, success criterion 2.2.1 and 3.2.1 (both at level A) work together to ensure that both unexpected changes in context as the result of a component receving focus (3.2.1) and changes in content resulting from a time-out (2.2.1) will not occur unexpectedly. While exceptions to success criterion 2.2.1 for real-time events and activities where timing is essential exist, guideline 2.2 does not allow changes in content for no reason.
WCAG 2 Quick Reference: While this is an excellent idea, it violates 3.2.1
Proposed Change:
Ensure that all the W3C WCAG 2 documents comply with at least L1 of WCAG2
Quick Reference has two places where it changes content.
One is the expanding check boxes at the top. This causes changes in content - but not changes in context. It is the working groups specific intent that the types of changes represented by the Quick Reference be allowed. In fact the Quick Reference was designed to provide an example of what was not a change of context but only a change of content.
The second part is the changing of the full document contents. This does change the meaning of the page and would constitute a change of context. This addresses the success criterion by providing information in advance that explains how this changes. We have recently also changed the introductory text to better reflect what happens as you change the settings at the top.
Images for markup: Seeing as this WCAG1 checkpoint does not map to a particular SC, does this mean that WCAG2 allows images to be used instead of markup, for example, images of text, instead of CSS-manipulated text? Or images for bullets instead of marked up bulleted lists?
Proposed Change:
Clarify the mapping of 3.1.
The mapping has been removed from the WCAG document itself and will now be included in the WCAG 1.0 to WCAG 2.0 transition materials. This will make it easier to update the mapping as new techniques are developed.
The working group will work in coordination with the EOWG WCAG 2.0 Materials Support Task Force in the creation of transition materials and will consider these comments when the mapping is updated.
To answer your question, WCAG 2.0 does not prohibit the use of images of text provided that they have text alternatives. There is, however, an advisory technique that advises against the use of images of text in order to acheive a desired visual effect. Success criterion 1.3.1 lists the use of <ol>, <ul> and <dl> for lists as a sufficient technique. Other techniques could be used, but text alternatives would have to make the information and relationships conveyed through this use of images clear.
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)
The mapping has been removed from the WCAG document itself. The working group will work in coordination with the EOWG WCAG 2.0 Materials Support Task Force in the creation of transition materials and will consider these comments when the mapping is updated. We intend to add SC 2.2.1 to the mapping for WCAG 1.0 Checkpoint 10.1.
The working group believes that the ability for user agents and AT to suppress and/or notify users about pop-up windows, along with the four success criterion (3.2.1, 3.2.2 3.2.5 and 2.2.1) address the concerns about changes in context without user initiation. Because there is some functionality that cannot be supported without asynchronous changes of context, SC 3.2.5 is a level AAA success criterion.
Properly positioned labels: 10.2 no longer maps to any particular SC. Although this checkpoint was included in WCAG1 to assist people who use screen readers, prior to the uptake of explicit labelling, this is still a very important SC for people who use magnifiers and people with cognitive disabilities.
Proposed Change:
Create a new SC the equivalent of 10.2 (I am happy to write this)
Assistive technology has advanced since the WCAG 1.0 guidelines were released. As long as the label is explicitly associated with a field, assistive technologies can present the information to the user in an understandable manner. However, since visual positioning can be important, especially for pages translated into other languages, we have added an advisory technique to Success Criterion 1.3.1 and Guideline 3.2 titled "Positioning labels to maximize predictability of relationships."
Note: The mapping has been removed from the WCAG document itself. The working group will work in coordination with the EOWG WCAG 2.0 Materials Support Task Force in the creation of transition materials and will consider these comments when the mapping is updated.
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.
Intent vs Benefits: These two sections are essentially the same
Proposed Change:
Either differentiate the two sections more, or merge them
We have combined these two sections.
Script: The techniques and examples are very script heavy. It appears, to a casual reader, that the W3C is advocating scripting above other technologies, such as PDF, XHTML or CSS.
Proposed Change:
Ensure that techniques and examples are evenly spread over a variety of technologies
The examples have to match the technologies. The scripting examples are only used where we are trying to demonstrate dynamic content. Scripting is the most common method for this. If you have other examples you think could be included, please submit them. We are always looking for additional good examples.
There are examples in the Intent section
Proposed Change:
All examples should be in the Examples or Failures section
The examples in this item are not examples of the success criterion or meeting the success criterion but rather examples of what we mean by one of the terms in the success criterion. So these particular examples can't go in the examples section.
One required component of a conformance claim is "Scope of the claim (a URI, list of URI's, or a set of URIs defined by a regular expression)," and the examples each include a single URI. This, the Examples, and the Conformance Notes all fail to clarify whether citing a single URI implies conformance is claimed for that one web page (or equivalent), or all pages referenced by it, or all pages "beneath it" on the server. For example, does claiming conformance for http://telcor.example.com/nav/G7/intro.html mean that conformance is claimed just for that one page, or for all the pages it links to, or all the pages in the /nav/G7/ directory on the server, including or not including subdirectories? I suggest clarifying this and also including an example of a claim for an entire Web site or multi-page portion thereof.
We have completely rewritten the Conformance section. The format of this description is no longer specified. The corresponding required component is now:
4. A description of the URIs that the claim is being made for, including whether subdomains are included in the claim.
We have fixed the existing examples to clarify that the first applies to the entire site and the second applies only to the specific page. We have added examples to illustrate the use of boolean and regular expressions in a conformance statement.
The example conformance claims list things like jpeg as 'specifications that this content "relies upon"'. How can jpeg ever be a relied upon specification since the guidelines require Web pages to be usable even when the images are turned off?
Proposed Change:
Remove JPEG from list of "specifications that this content relies upon", or else clarify what is meant by including it.
"Relies upon" means that it is used in this content and must be supported by the user agent in order to claim conformance. If jpeg were used to satisfy SC 3.1.5 by providing an illustration as supplemental content, then jpeg would be relied upon.
The guideline reads, "Any information that is conveyed by color is also visually evident without color." This wording clearly implies that it is acceptable to convey information by contrast, a technique that is discussed in other criteria but overlooked both here and its Understanding. Is the intent here to make sure information is visually evident without perceiving color and contrast, or to say that conveying information by contrast alone is acceptable? I suspect the former. If the latter, we should provide guidance for 1.3.2 on minimum acceptable contrast between items when color/contrast is used alone to denote differences in type, state, etc., just as we do for differences between foreground and background elsewhere. Even if the former, such guidance on the use of contrast would be valuable as a Level 2 or Level 3 criterion.
Proposed Change:
Change to read "Any information that is conveyed by color or contrast is visually evident even if any color and contrast cannot be perceived.."
We have combined SC 1.3.1 and 1.3.4 into a level A criterion that reads, "1.3.1 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." We have also revised SC 1.3.2 to read, "1.4.1 Use of Color: Any information that is conveyed by color differences is also visually evident without the color differences."
The working group believes that the revised level A criterion addresses your concerns regarding the use of conveying information via contrast alone.
2.2.2 requires content to not blink for more than three seconds or a method be available to stop all blinking in the Web unit or authored component. Many Web sites display GIF images that are provided by a third-party (e.g. advertisements, or user-contributed photos); are such sites required to ensure that none of those are animated GIFs, in case some blink? Is it sufficient for the authors to define a baseline that includes user agents that allow the user to stop blinking on the current Web unit (e.g. pressing ESC)?
You ask two questions:
1)Yes, aggregators are responsible for the content they aggregate. If the aggregator wants to claim conformance at level AA, there must be no third party images integrated into the content which violate this success criterion.
2)It would be sufficient to use a technology for which user agents are available which allow the user to freeze the technology (as is the case of GIFs). This is the 2nd sufficient technique under SC 2.2.2.
4.1.2 includes the phrase "available to user agents, including assistive technologies", but other criteria say "available to user agents" without the "including assistive technologies". The phrase is not strictly required since we define user agents as including assistive technologies; you may feel it's useful to re-emphasize that here, but if that's the case, wouldn't it also be warranted in those criteria that say "programmatically..." by adding "including assistive technology" to the definitions of programmatically set and programmatically determined?
Proposed Change:
Delete the phrase ", including assistive technologies", to read "For all user interface components, the name and role can be programmatically determined, values that can be set by the user can be programmatically set, and notification of changes to these items is available to user agents."
Although the definition of user agent includes assistive technologies, the definition blurs the distinction between support for users with disabilities that is provided directly by the user agent and support that is provided by an external service that interacts with a user agent that does not provide that support directly. Within WCAG, we use assistive technology to refer to the latter sort of service. We call out support for assistive technology explicitly so that programmatically determinable information is available to assistive technology, and not just to the host user agent.
In SC 4.1.2, it is a particularly important distinction for the notification of changes to user interface components. Information can be programmatically determined without requiring notification of changes. This would require constant polling of the content to notice changes. For many technologies, the host user agent is implementing the change, so it is automatically notified, but assistive technology needs explicit notification.
Definition of ACRONYM is defined incorrectly as an "abbreviation made from the initial letters", but it should be "abbreviation made from non-contiguous letters of a name or phrase". These are usually the initial letters, but not always; the name being abbreviated is usually made up of more than one word, but not always; and the acronym sometimes contains extra letters that don't occur in the original phrase, but are added in to aid in pronunciation.
Proposed Change:
Change to "abbreviation made from non-contiguous letters of a name or phrase".
We have revised the definition to read, "abbreviated form made from the initial letters or parts of other words (in a name or phrase) which may be pronounced as a word."
Definition of API is defined as "definitions of how communication may take place between applications", but that should be "between application or software components", as most API are used between components that are not applications, and we don't want to limit our discussion to only those API that are between one application and another.
Proposed Change:
Change to "definitions of how communication may take place between applications or software components".
Application Programming Interface (API) is now defined:
"definitions of how communication may take place between applications".
See http://www.w3.org/TR/2007/WD-WCAG20-20070517/#apidef .
Definition of AUTHORED UNIT should be reviewed to make sure that it agrees, at a technical level, with the committee's intention. Currently it seems ambiguous about whether a Web unit is one type of authored unit, or whether an authored unit must consist of more than one Web units. Similarly, it is ambiguous about whether a subset of the content on a Web unit (e.g. a paragraph) written by a separate author than the surrounding content, is an authored unit. Finally, it clearly implies that a set of Web units written by multiple authors but intended to be used together as a set would not be an authored unit. Are those all correct interpretations?
We have reformulated the success criteria and glossary to remove both "authored unit" and "authored component" from the guidelines.
3.2.2 On Input: Changing the setting of any user interface component
does not automatically cause a change of context unless the user has been advised of the behavior before using the component.
Definition of CONTENT currently reads ""information to be communicated to the user by means of a user agent"" and has a Note which reads ""This includes the code and markup that define the structure, presentation, and interaction, as well as text, images, and sounds that convey information to the end-user."".
Content is defined as being limited to ""information"", but the definition of ""information"" seems to exclude purely decorative elements and elements who purpose is to create a specific sensory experience; both of those are distinguished from informational content in the document, but seem to clearly be part of the content. That should be acknowledged here.
(Content also include controls whose purpose is to gather input from the user, but I guess we don't need to call those out since they must also have some presentation.)
Similarly, the Note seemt to say that scripts included in a Web page are part of the content, but these don't fit into the definition of ""information"" as they might respond to user input or other triggers, without having any presentation of their own. Thus, the Note seems to contradict the definitions themselves.
It is unfortunate that the document defines ""information"", ""purely decorative elements"", and content ""designed to create a specific sensory experience"" as mutually exclusive, with no term that currently includes them all. I believe that ""content"" should be that term, but it would require broadening the definition of ""content"" beyond just ""information"" or broadening the definition of ""information"".
Proposed Change:
Change to "information and decorative or sensory elements to be communicated to the user by means of a user agent, as well as code or markup that define the stucture, presentation, and interactions associated with those elements".
We have updated the definition, but have used slightly different wording. The definition now reads, "information and sensory experience to be communicated to the user by means of a user agent, as well as code or markup that define the structure, presentation, and interactions associated with those elements"
Definition of INITIALISM should make it clear that initialisms are not pronounced as words; if they are, they would be acronyms instead of initialisms. (At least, that's how I've heard it explained.)
Proposed Change:
Add "Note: Initialisms are generally read as strings of individual letters rather than being pronounced as words."
The draft has been updated as proposed.
Definition of NATURAL LANGUAGE is "language used by humans to communicate", but this is so broad that Fortran would be included, as it is a way humans communicate with software.
Proposed Change:
Change to read "language used by humans to communicate with one another".
The guidelines now use "human language" instead of "natural language". The definition of human language is "language that is spoken, written or signed (visually or tactilely) by humans to communicate with one another".
Definitions of TEXT and NON-TEXT CONTENT is ambiguous about whether an image of text is text or non-text content. Please add clarification. This is a problem because most success criteria are written assuming that "text" is parsable by assistive technology (i.e. not just a picture of characters) (e.g. "text alternatives"), but others seem to only require that "text" be readable by humans (i.e. it can be just an image of characters) (e.g. captions on DVDs).
Proposed Change:
Add to the definition of non-text content, "Note: This includes images of words and characters that may look like text when viewed with human sight but are not programmatically accessible."
The definition of text and non-text have been changed to remove any ambiguity that the text must be programmatically determinable (see http://www.w3.org/TR/2007/WD-WCAG20-20070517/#textdef and http://www.w3.org/TR/2007/WD-WCAG20-20070517/#non-text-contentdef ).
text
sequence of characters that can be programmatically determined, where the sequence is expressing something in human language
non-text content
any content that is not a sequence of characters that can be programmatically determined or where the sequence is not expressing something in human language
Note: This includes ASCII Art (which is a pattern of characters) and leetspeak (which is character substitution). .
Definition of PRESENTATION says "rendering of the content and structure in a form that can be perceived by the user". This is not technically correct, as (a) it could render just the content, not the structure, (b) it is a form *designed* to be perceived by *a* user. With the current definition, if the user is blind, nothing on the display counts as presentation.
Proposed Change:
Change to read "rendering of the content and structure in a form designed to be perceived by the user".
The definition has been changed to: "rendering of the content in a form to be perceived by users".