Reviews of 22 August 2002 WCAG 2.0 WD

On 22 August 2002, a public working draft of WCAG 2.0 was published. At the end of September, a Request for Review was sent to the WAI-IG. Similar requests were sent privately to contacts of the WCAG WG.

This request asked for general input and included the following 3 questions:

1. In general, is this WCAG 2.0 Working Draft easy to understand? Please identify sections or phrases that are difficult to understand. Please suggest alternative wording for the Working Group to consider.
2. The priority structure of this WCAG 2.0 Working Draft differs from WCAG 1.0. Is this structure easy to understand? Would it be effective?
3. If your site or organization already uses WCAG 1.0, do you think it would be difficult to migrate from WCAG 1.0 to WCAG 2.0? What would make it easier? Please note that the Working Group is developing supporting documents, such as technology-specific techniques documents, for WCAG 2.0.

This document attempts to organize the comments received on the 22 August 2002 WCAG 2.0 Working Draft. The comments received that pose larger issues are linked to their corresponding issue in the issues list.

Summary of comments sent to the WCAG WG mailing list

• Jon Gunderson, 23 Sept 2002 - concerned about scaling and stylizing text. (Jon joined us on the dd mm 2002 telecon to discuss the issue)
• Bob Regan, 25 Sept 2002 - answers the 3 review questions. Feels "it will be much harder to meet minimum level conformance under WCAG20" (issues x, y, z were discussed at the dd mm telecon)
• Bill Mason, 28 Aug 2002 -
  • comments on the success criteria for checkpoints 1.1, 1.2, and 1.5.
  • says, "if there are no such [things that need an assertion that the site has been reviewed] in the site, I have nothing to state. And therefore without a statement (as I currently read the draft) I cannot claim level 2 success."
• Jukka Korpela, 1 Oct 2002
  • Structure is confusing. Makes suggestions to clarify.
  • Separate what is required from how to conform.
  • The success criteria that state "the site has a statement asserting that the content has been reviewed and..." are not useful.
• Jonathan Chetwynd, 01 Oct 2002
  • Agrees with Bob Regan that, "it would be great if there was a simple, non-technical explanation of the guidelines"
  • In "Overview of Design Principles," comments on "someone who does not read well..."
  • Guideline 1
  • Checkpoints 2.2, 3.4
• Ian Jacobs, 06 Oct 2002 - comments on:
  • The conformance model
  • The status section and the Introduction
  • Checkpoints: 1.1, 1.2, 1.3, 1.5, 2.2, 3.1, 3.2, 3.3, 3.4, 3.6, 4.3, 5.3, 5.4
  • (issues x, y, z were discussed at the dd mm telecon)
• Aaron Leventhal, 07 Oct 2002 - likes benefits and use of 5 categories. suggests addition to benefits of 2.1.
• WWAAC (via David Poulson and Colette Nicolle), 4 Nov 2002 - comments on:
  • in general
    • says, "No specific mention is made of the possible value of creating page abstracts and summaries to help those who have limited capacity for reading large amounts of text."
    • there could be more guidance about facilitating navigation through links.
  • User Needs
  • Guidelines: 3, 4
  • Checkpoints: 1.2, 1.4, 1.5, 2.1, 2.3, 3.1, 3.2, 3.3, 3.5, 4.3, 5.1
• Olivier Thereaux, 18 Oct 2002
  • Lack of use of language from RFC 2119 (must, should, may)
  • Suggests adding " you have met Cp.X at the minimum level, and" as the first success criteria under level 2, and " you have met Cp.X at the minimum level and level 2, and" at level 3.
  • Comments on checkpoints: 3.2, 3.6
  • There are still HTML-specific statements. e.g., "navigation bars" in 3.4.
• George Kerscher, 20 Oct 2002 - specific comments and proposals for changes to: a statement in "Overview of Design Principles," 1.1, 1.3, 2.2, 3.1
• Diane Dent, 21 Oct 2002 - identifies typo in checkpoint 1.2.
• Blaire Bundy, 21 Oct 2002
  • Supports the structure, use of adjective with each guideline, wording. Some specific quotes:
    • Finds, "the wording, organization and layout of WCAG 2.0 to be much more understandable than WCAG 1.0"
    • The adjectives associated with each guideline "makes the guideline more digestible and the overall document more comprehensible"
    • The structure is an improvement "especially for new users, Perceivable | Operable | Navigable are good jumping-off points."
    • The draft "makes a better attempt at satisfying multiple audiences"
    • "I anticipate that those who are familiar with 1.0 should quickly adapt to 2.0."
  • In "Audience" link to an appropriate EOWG working draft rather than the work of the EOWG.
• Terry Thompson, 21 Oct 2002 -
  • Checkpoints should make sense when quoted out of context. Specific checkpoints of concern: 1.5, 2.1, 3.1, 5.4
  • Too much informative info in the document. Move to another document, keep only normative info.
  • Some language that is used is difficult to understand or is ambiguous. e.g. use of "form" in Guideline 1.
  • To help transition from 1.0 to 2.0, use similar language style, e.g. state checkpoints in imperative and visual style, e.g., boxes around guidelines.
  • Conformance suggestions.
  • Comments on checkpoints: 2.3, 3.6, 4.2, and 5.2
  • Skip navigation checkpoint?
• Mark Schult, 21 Oct 2002 - comments on checkpoints: 1.1, 1.4, 2.2, 3.6, and 4.1
• Sun (via Earl Johnson), 27 Oct 2002 - comments on:
  • In General:
    • Each checkpoint should have a brief statement of "why am i doing this" (use 1.5 as a model)
    • Informative info stands out more than the normative (since it has a box around it). Checkpoint should stand out so that user can skim.
    • Need technology-specifics.
  • Overview of Design Principles
  • Checkpoints: 1.1, 1.2, 1.3, 1.5, 2.1, 2.3, 3.1, 3.2, 3.5, 3.6, 4.2, 4.3, 5.1, and 5.3
• IBM (via Andi Snow-Weaver), 29 Oct 2002 - comment on:
  • front matter
  • checkpoints: 1.1, 1.2, 1.4, 1.5, 2.1, 2.2, 2.3, 3.1, 3.3, 3.4, 3.5, 3.6, 4.1, 4.2, 4.3, 5.1, 5.2, 5.3, 5.4
  • Glossary
• SAP (via Audrey Weinland), 31 Oct 2002
  • Reviewed with "web applications" in mind. In general, feel this draft refers to Web sites rather than Web apps.
  • Questions about conformance, suggestions for clarifying the scheme.
  • Concerned that understandable is a usability issue not an accessibility issue.
  • Concerned that with regards to the "Robust" checkpoints that web apps can not conform with everything out there.
  • Comment on checkpoints: 1.1, 1.2, 1.3, 1.4, 1.5, 2.1, 2.3, 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 4.1, 4.2, 4.3, 5.2, 5.3, 5.4
• anonymous, 05 Nov 2002 (on 28th August version)

Summary of comments sent to the WAI IG mailing list

• Carol Foster, 27 Sept 2002 - wants something that explains "If you currently meet WCAG 1.0, here is what is needed to meet the minimum level of WCAG 2.0". Something like the checkpoint mapping, but cut down to cover WCAG 2.0 minimum level only.
• Kynn Bartlett, 27 Sept 2002 - agrees with Carol, calls it an "upgrade roadmap."

General comments

• In an ideal world, each checkpoint requirement would reflect a user need documented in "How People with Disabilities use the Web", and would like to that document. Even if that is not done, it is worth ensuring that all the needs documented therein are met by the requirements. Ian Jacobs, 06 Oct 2002
• No mention of the possible value of creating page abstracts and summaries to help those who have limited capacity for reading large amounts of text. Checkpoint 4.3 covers the annotation of 'complex, abbreviated or unfamiliar information with summaries and definitions', but this is not the same as using abstracts and summaries for all web pages. This could be particularly useful for symbol users or those with poor reading skills. Note: this is also related to the whole issue of providing meta content for pages that can be accessed if required, i.e. keywords, titles, abstracts. WWAAC (via David Poulson and Colette Nicolle), 4 Nov 2002
• many guidelines are still quite HTML oriented, e.g "navigation bars" in Cp3.4. If one of the goals of WCAG2.0 is to leave HTML for more generic grounds, it might be necessary to move html specific checkpoint wording to the examples. Olivier Thereaux, 18 Oct 2002
• I think it's also important that the guidelines and checkpoints in and of themselves be meaningful, without necessarily referring to the techniques documents or even to the success criteria. I suspect that it will not be uncommon for the checkpoints to be cited apart from their context in the WCAG 2.0 document, and many end users will refer to these abridged documents. Or, many users will refer to the actual WCAG 2.0, but as busy people they will only skim the guidelines and checkpoints, not read all the detail. Maybe a usability test is in order: present target users with the checkpoints out of context, and assess whether they understand them.

  Terry Thompson, 21 Oct 2002

• As a normative document, the WCAG 2.0 should restrict itself to normative content. Definitions, Benefits, and Examples sections, if informative rather than normative should be extracted from this document and referenced via hyperlink. As is, there is too much informative/clarifying content within each guidelines' definition - It's difficult to appreciate the document's structure. Terry Thompson, 21 Oct 2002
• The first informative information that would be helpful seeing in all checkpoints is a one short paragraph answer to "what does this do and why am I doing this?" (something along the lines of the Note for checkpoint 1.5 is a good example of what this intro should contain and the max length it should be). This information would potentially be better placed right after the checkpoint versus placing it in the checkpoint's informative section. Sun (via Earl Johnson), 27 Oct 2002
• The requirements (for each level in 2.0) are less technology-specific than 1.0. It would be helpful if each checkpoint had at least 2 examples provided in he illustrative section. Sun (via Earl Johnson), 27 Oct 2002
• We reviewed this with Web-based applications in mind. In general, we feel that these guidelines have Web sites in mind and are not always applicable to Web-based software. For example, the Purpose section states that the document "outlines design principles for creating accessible Web sites." SAP (via Audrey Weinland), 31 Oct 2002
• It was not entirely clear whether documents are covered by these guidelines, meaning file formats like Powerpoint files (.PPT), Word document files (.DOC), Adobe files (.PDF), etc. If not, they should be, since most Web sites and even Web apps often include documents in non-HTML formats. SAP (via Audrey Weinland), 31 Oct 2002
• There appear to be many checkpoints that are focused on usability, not accessibility per se. It would be good if the guidelines included a definition of accessibility. In our opinion, if the user can get to it, find out what it is, and activate it, we consider it accessible. The primary focus should really be on whether the user can complete the task/function. How *easy* it is to use, or how quick it is to find or use it, in our opinion belongs in the realm of usability, not accessibility. For example, a Web application may be produced quickly and not be easily usable by anybody, disabled or non-disabled. Following these guidelines would force the company to make it easy to use. Should that really be the intention of these guidelines? We don't think so, particularly considering the fact that many U.S. states use the WCAG guidelines as the basis for their legal requirements, and this would in effect legislate usability. SAP (via Audrey Weinland), 31 Oct 2002
• The WCAG checkpoints are geared towards a much broader user base than our Web apps are geared towards. We have to assume a certain level of cognitive ability for users to use our Web apps. And since they are our customers, not the general public, shouldn't that be allowed? Also, the checkpoints seem to be geared more towards learnability than accessibility or usability per se, but SAP expects our users to receive training and extensive documentation, which should cover much of the learnability aspects already. Finally, we sometimes have to sacrifice some learnability in our Web apps in order to make the screen faster to use for trained people, i.e. for productivity reasons. We really need checkpoints that are focused on accessibility, not usability or learnability. SAP (via Audrey Weinland), 31 Oct 2002
• Do these guidelines apply equally to mobile Web applications, like those that might run on a cell phone? SAP (via Audrey Weinland), 31 Oct 2002

Conformance

"The site has been reviewed..."

• What level of conformance can a site claim if the review is not applicable? Example: I meet level 3 in all criteria except Checkpoint 3.5. This checkpoint at level 2 requires me to state that the user is warned of essential inconsistent or unpredictable responses. If there are no such responses in the site, I have nothing to state. And therefore without a statement (as I currently read the draft) I cannot claim level 2 success. Now, what level of conformance can the site claim as a whole? Level 3 because 3.5 does not apply to me? Level 1+ because I have not achieved level 2 in this checkpoint? I believe this whole area needs to be clarified in the draft. Bill Mason, 28 Aug 2002
• Requiring a review is somewhat debatable; it does not relate to accessibility itself. Requiring that a specific statement is made on a Web site about a review could be worse than meaningless. Jukka Korpela, 1 Oct 2002
• Ian Jacobs (6 Oct 2002) commented on this and the group discussed at the 10 Oct 2002 telecon. Afterwards, Gregg (14 Oct 2002) proposed to the list to remove these statements from Level 1 and Level 2 success criteria. There is debate about using this strategy at Level 3 although it seems to make sense if it is machine-readable. There still seems to be some misunderstanding within the group about the machine-readability of EARL (it is designed to be machine-readable).
• If a site seeks Level 2 compliance, it could potentially have to include ten separate statements of conformity. While statements of conformity provide measurable criteria on checkpoints that may otherwise be difficult to measure, measurability may come at the expense of true accessibility. Whether or not a site claims to be accessible has nothing to do with whether it is in fact accessible. Therefore, I don't think statements of conformity belong in a set of guidelines where the primary function is to provide a working definition of "Web accessibility". Terry Thompson, 21 Oct 2002
• Who is supposed to review this? The person who produced the site? Some sort of review committee? Where do you put the statement? Is there supposed to be a single statement page, or does every page with media have to have a separate statement? Won't that add a lot of noise? SAP (via Audrey Weinland), 31 Oct 2002

Suggestions for simplifying conformance

• ...the "success criteria" are partly redundant, partly just guidelines at an even more concrete level (so that they could be presented as Specific Guideline 1.1.1, etc.). I think this should be explained, and the wording and presentation style modified accordingly. The "levels" should not appear at all. Instead, some informative notes could be added about the practical impact and implementability of some guidelines when applicable. And definitions should normally be given at (or before) the first occurrence of a term or abbreviation, and could often be merged into running text. Jukka Korpela, 1 Oct 2002
• The guidelines should be kept as separate from the question whether compliance to them can be verified objectively, and in particular whether it can be verified programmatically. Otherwise there will be strong bias towards objective verifiability, neglecting extremely important factors that cannot be objectively verified (such as using the simplest language suitable, or adding illustrations when needed, or giving informative error messages). Jukka Korpela, 1 Oct 2002
• Shorten checkpoint titles to make them easy to say and remember. Ian Jacobs, 06 Oct 2002
• Drop the term "success criteria" and explain the structure as:
  • N guidelines.
  • Each guideline has M checkpoints.
  • Each checkpoint may have P provisions.
  • Each provision has a priority. Ian Jacobs, 06 Oct 2002 He provides examples in his message. (at the 10 Oct 2002 meeting, decided to invite Ian to a meeting to explain and discuss)
• call them "Priority 1/2/3" for consistency with previous WAI Guidelines. If the definition of "Priority" need to be changed in WCAG 2.0, change it, but there's no need to invent a new term for prioritization. Ian Jacobs, 06 Oct 2002 (at the 10 Oct 2002 meeting, decided to invite Ian to a meeting to explain and discuss)
• Many web content developers and policy makers are looking for a binary set of guidelines - either it's accessible, or it isn't. The WCAG 1.0 priority structure led to much confusion as users tried to grapple with whether "accessible" meant Priority 1, 2 or 3. The Access Board, when questioned as to which of their standards is most important, consistently assumes the position that "all are equal". Given the current working draft, I think WCAG 2.0 could possibly attain a binary set of success criteria.

  Of the 21 checkpoints, only 15 have any Level 2 success criteria, and of these, eight are simply "statements of conformity" (see answer 2b). Only nine checkpoints have Level 3 success criteria, and only five have any content under the "additional ideas" heading. Terry Thompson, 21 Oct 2002

Conformance levels and "additional ideas"

• I think a level that represents an undefined range of what criteria are met will not help people. I don't support "2-" either. Ian Jacobs, 06 Oct 2002
• Level 1 v. Level A. Is there a reason for changing conformance level titles from "Double-A" to "2"? Ian Jacobs, 06 Oct 2002
• Don't include in the guidelines as people may think it's part of conformance. Refer to the UAAG 1.0 structure ("doing more"). Ian Jacobs, 06 Oct 2002
• Please provide the full rationale for naming level 1 "Minimum." Olivier Thereaux, 18 Oct 2002
• Olivier Thereaux, (18 Oct 2002)

  you will have successfully met Cp.X at the minimum level if...
  you will have successfully met Cp.X at level 2 if
  - foo

  could read

  you will have successfully met Cp.X at the minimum level if...
  you will have successfully met Cp.X at level 2 if
  - you have met Cp.X at the minimum level, and
  - foo

Exclusions and inclusions

• I strongly recommend considering the mechanisms used in UAAG 1.0 to identify normative inclusions and exclusions. This is already done explicitly in WCAG 2.0's checkpoint 1.2 ("exception ..."). It is also done implicitly elsewhere. For instance, in checkpoint 1.2, the bullet "if the Web content is real-time video with audio, real-time captions are provided unless the content is a music program that is primarily non-vocal." The "unless" part is a normative exclusion and should be identified as such. Ian Jacobs, 06 Oct 2002

Quality Assurance issues

The QAWG produced Checklist for Specification Guidelines. Olivier Thereaux, (18 Oct 2002) reviewed WCAG 2.0 for conformance to the QA Specification Guidelines.

• Although, RFC 2119 vocabulary (must, should, may) is not used it seems that strict and otpional requirements are clearly differentiated. (QASG checkpoint 13.1 Use conformance key words. [Priority 1]).
• A machine-readable version of the guidelines does not exist.
• The guidelines do not seem to be authored using a structured language such as XMLSpec.
• In the absence of RFC 2119 vocab and machine-readable markup the conformance section, albeit well written, would benefit from an explanation of this choice (maybe with a mapping of your presentation vs a "usual" MUST/MAY example).

Making conformance claims

• In the Conformance section of the Introduction clarify, "If they meet all of the criteria for Level 2 or Level 3 ***in addition to Level 1*** they can claim conformance at those levels." SAP (via Audrey Weinland), 31 Oct 2002
• The guidelines say, "It is possible and recommended that sites report specifically which criteria they have met within each of the guidelines and checkpoints...method not yet determined." Like a VPAT or a checklist of some sort? This is a key issue for us, since it's not easy to figure out where or how to report this information in a Web app. SAP (via Audrey Weinland), 31 Oct 2002
• How do you ensure that you've satisfied a criterion? Are you supposed to guarantee that every page conforms? What is the method of testing/coverage required? Also, if you do Level 3 for a checkpoint, but you don't do Levels 1 or 2, could you claim that you're compliant with Level 3? SAP (via Audrey Weinland), 31 Oct 2002

Introduction and Front Matter

re: version info/logo/top of page

• Add a link to errata ala new comm team policy. refer to p3p example. IBM (via Andi Snow-Weaver), 29 Oct 2002
• Add a link to related documents (e.g., checklists, techniques, etc.) so that all of the related documents can be easily found as they are created and changed. It should sort them all out and present them is a logical manner and not depend on the reader to have to read and gather bits and pieces along the way from each WAI recommendation to construct the organization and relationships. IBM (via Andi Snow-Weaver), 29 Oct 2002
• at the top of the page include a link to the table of contents to skip past the front matter. IBM (via Andi Snow-Weaver), 29 Oct 2002

re: Status

• a paragraph (or a link to a paragraph) that explains the relation of WCAG 2.0 to WCAG 1.0. Ian Jacobs, 06 Oct 2002

re: "Introduction"

• (in Overview of Design Principles) someone who cannot read well probably wants a precis, and an illustration. publishers have known this for hundreds of years. having the text read suits blind users, a different category. (this is an example of the author-programmer assuming that what is most easily doable is what is wanted.) Jonathan Chetwynd, 01 Oct 2002
• odd to have an adjective as the first word in the title. Ian Jacobs, 06 Oct 2002
• What is meant by "technology-specific"? Does technology mean "format specification such as XHTML" or "mobile device"? Ian Jacobs, 06 Oct 2002
• Propose adding additional subsections (ala UAAG 1.0):
  • Relation to WAI accessibility guidelines
  • Known limitations of this document
  • Relation to general authoring guidelines and other specifications
  • Security considerations Ian Jacobs, 06 Oct 2002
• (in Overview of Design Principles) it says, "Someone who cannot see will want to hear or read through braille information that is usually presented visually." suggest instead

  "Someone who cannot see will want to hear or read with refreshable braille the information that is usually presented visually." George Kerscher, 20 Oct 2002

• the addition of an adjective associated with each guideline makes the guideline more digestible and the overall document more comprehensible. Blaire Bundy, 21 Oct 2002
• (in the "Audience" section) link to an appropriate/friendly work of the EOWG, rather than to the work of EOWG. http://www.w3.org/WAI/EO/ is not a page for first time users. Blaire Bundy, 21 Oct 2002
• (in Overview of Design Principles) it says, "A structured database or metadata collection where the data is intended for use by another machine and thus requires no interface lies outside the scope of these guidelines." The other machine could be software, how about changing "machine" to "service" Should "user" be added to "no interface"? Sun (via Earl Johnson), 27 Oct 2002

Comments specific to guidelines

Guideline 1 - Perceivable

• "those aspects that cannot be expressed in words." Could someone please expand on this? do we have an example? seems unlikely, but what was the thought that went into this? seems a confusing and unnecessary qualification. Jonathan Chetwynd, 01 Oct 2002
• The use of the word "form" is ambiguous. Since "form(s)" has a specific technological meaning, a suitable replacement word should be used here. Possible alternatives: "...presented in ways that can be perceived..." "...presented such that they can be perceived..." Terry Thompson, 21 Oct 2002

Guideline 3 - Navigable

• There could be more content on facilitating navigation through hyperlinks. Mention is made of ensuring labels are meaningful, but there may be other advice that could be useful e.g. numbers of links on pages, navigating hyperlinks, and how to refer to internal and external links. Could be useful to have something about navigation through tables and frames? WWAAC (via David Poulson and Colette Nicolle), 4 Nov 2002
• One of the Sec 508 standards is "Skip Navigational Links", which corresponds with checkpoint 13.6 in WCAG 1.0. According to the Checkpoint Mapping Between WCAG 1.0 and WCAG 2.0 Working Draft, this checkpoint maps to "Core Techniques", and otherwise does not appear in the actual normative document. I think this is a critical accessibility issue, and should have a presence either as a checkpoint under Guideline 3 ("Navigable"), or at least as a Minimum Criterion, perhaps under checkpoint 3.3. Terry Thompson, 21 Oct 2002

Guideline 4 - Understandable

• The issue of top loading page content could also be raised again here. The WWAAC project is working on specific success criteria and advisory recommendations for making the content understandable for people with communication or cognitive impairments. WWAAC (via David Poulson and Colette Nicolle), 4 Nov 2002
• We feel this is more of a usability issue, not an accessibility issue. In fact, the guidelines in this section seem to require that pages be intuitive. That would be a difficult requirement for some Web apps to meet, since they can be complex due to the nature of the task being performed. And it brings up the question of where training fits in. Users generally need training before they can use Web apps, and that training provides much of the understanding. Finally, how do you measure understandability? This could be a very subjective thing. SAP (via Audrey Weinland), 31 Oct 2002
• The complexity of some enterprise Web apps presupposes a certain level of cognitive ability. Furthermore, to make Web apps understandable for users, companies train their users. SAP (via Audrey Weinland), 31 Oct 2002

Guideline 5 - Robust

• It's not easy for a Web app to conform with everything on the market. There are currently no standards between screen readers, for example. Even Internet Explorer doesn't support certain standard HTML controls (such as the long description tag). How do we take these issues into account? Are there minimum requirements to work with specific assistive technologies? For example, would JAWS have a list of things we need to do to be compatible with them? We need to know what to do/what not to do. Wouldn't it be enough to ensure that we provide one method of access for each disability, as Section 508 specifies? SAP (via Audrey Weinland), 31 Oct 2002
• One reason SAP doesn't support all browsers is because some browsers don't meet our requirements in terms of things like performance, etc. We implement our apps in a controlled, corporate environment, not in a public environment. We are able to tell our customers that they need to use XYZ browser with SAP Web apps; it's a marketing decision whether we will target other browsers as well. So a guideline that mandates that we support other browsers does not make sense for us. SAP (via Audrey Weinland), 31 Oct 2002

Comments specific to checkpoints

Checkpoint 1.1

Two proposals are currently in play. The first has been discussed and accepted but not yet incorporated into a draft. The second has not yet been accepted.

Current proposal (part a)- Mat Mirabella, 07 Nov 2002

Checkpoint 1.1 For all non-text content provide a text equivalent, or, if the content cannot be expressed in words, provide an identifying text label.

+ success criteria

Discussed at 07 Nov 2002 telecon - minutes, highlights

Comments this proposal attempts to address

Bill Mason, 28 Aug 2002

• If the ''non-text content...can not be expressed in words" but success is defined as having "a descriptive label [that] presents all of the intended information and/or achieves the same function of the non-text content", then you've expressed the content in words.

Sun (via Earl Johnson), 27 Oct 2002

• Success Criteria 2: What does "descriptive label" mean? Is it "provide a longer description", more, or otherwise? The subbullet doesn't give guidance, having it would be helpful (e.g. point to a specific informative Example).

IBM (via Andi Snow-Weaver), 29 Oct 2002

• Checkpoint 1.1 begins with the phrase "For all non-text content that CAN be expressed in words". Worded this way, the checkpoint does not apply to "non-text content that can not be expressed in words".
• min. level: the sub-bullet under item 2 seems to belong with item 1. Item 2 states that non-text content that cannot be expressed in words should have a descriptive label as its text equivalent. The sub-bullet goes on to say that the text equivalent should fulfill the same function, present all the intended information, and achieve the same function as the non-text content. How is this possible if the non-text content cannot be expressed in words in the first place?
• Level 2 success criteria should be moved to Level 3.

Current proposal (part b) - Wendy Chisholm, 02 Dec 2002

Comments this proposal attempts to address

Bill Mason, 28 Aug 2002

• Example 1 has a right arrow icon whose text equivalent is "Next Slide" but the ALT tag for the image reads only "Next".

George Kerscher, 20 Oct 2002

level 3 currently has no criteria. I suggest: Some sites that want to conform think they have to provide the textual information each time it is presented. This becomes intrusive to using the site. For example, they use a graphical bullet (image) for their lists. The image is a picture of the corporate logo. This is described in 10 words. The user each times hears, "This is the corporate logo showing a heart with an arrow through it." There should be instructions that provide this information once and after that, probably just bullet.

Mark Schult, 21 Oct 2002

Proposes to reprioritize the current items so that level 3 has identifiable goals.

Sun (via Earl Johnson), 27 Oct 2002

• "Benefits" bullet#2: Suggest dropping this "or have it translated and presented as sign language," the text "reading the text" makes the point.
• "Examples" #4: Change "described in words" to "read"

IBM (via Andi Snow-Weaver), 29 Oct 2002

• The focus of this checkpoint should be about the content, not the method delivered. Applets and "programmatic objects" should be removed from the definition of non-text content because they are the delivery method and are covered in checkpoint 5.4. If applets or programmatic objects "deliver" non-text content such as graphics, audio, or video, then that non-text content should have a text equivalent - transcripts for audio, captions and descriptions for video, etc. Scripts should also be removed because they deliver content. The content delivered is what needs to be part of the success criteria no matter how it is delivered.

Checkpoint 1.2

Proposals

• John Slatin, 05 Sep 2002 - success criterion 1, minimum level
• John Slatin, 31 Oct 2002 - definitions and notes
• Andi Snow-Weaver, 08 Nov 2002 - level 3 success criteria (per discussion at 07 Nov 2002 telecon and threads on the mailing list)

Bill Mason, 28 Aug 2002

Minimum success criteria: Point 2 exempts news and emergency information from captioning, yet below in Example 2 a news story about an emergency is captioned.

Ian Jacobs, 06 Oct 2002

1. Normative exclusions appear in provisions 2, 4, and after 6. (refer to comments on exclusions and inclusions)
2. "for all live broadcasts that are professionally produced." The term "professional" is subject to much interpretation. Does this mean "high quality" or "for money"?

WWAAC (via David Poulson and Colette Nicolle), 4 Nov 2002

minimum level success criteria #1: Wording of this section is unwieldy and difficult to follow.

Diane Dent, 21 Oct 2002

level 2 success criterion seems to be missing a word.

Sun (via Earl Johnson), 27 Oct 2002

"Success criteria", #5 in "Minimum": The way it currently reads suggests there are 2 conditions #5 is meant to cover. Should the sentences be split into separate bullets or does this rewrite capture #5's point - "if the Web content is real-time non-interactive video (e.g. a Webcam of ambient conditions), provide an accessible alternative that achieves the purpose of the video and that conforms to checkpoint 1.1, or a link is provided to content elsewhere which conforms to checkpoint 1.1 (e.g. a link to a weather Web site)."

IBM (via Andi Snow-Weaver), 29 Oct 2002

• Level 2 success criteria
  • item #1 should be moved to Level 3
  • Item 3 ends with the phrase "... view only the captions, the captions with the audio, or both together." "Both together" is the same as "the captions with the audio". It should be: "only the captions, only the audio, or both together".
• Benefits: The Note ends with a sentence that sounds like a success criteria: "Where possible, provide content so that it does not require dual, simultaneous attention or so that it gives the user the ability to effectively control/pause different media signals."

SAP (via Audrey Weinland), 31 Oct 2002

• miminum level, #1: Is this point talking about replacing the existing soundtrack with an alternate audio, or having an alternate audio available in addition to the existing soundtrack?
• minimum level, #2: Why is captioning considered the minimum? For non-real-time, wouldn't transcripts be OK? At least in cases where the video is not conveying majorly important information, for example if it's a video of an executive speaking at a conference.
• Same questions as IBM about level 2 #3 (both together is the same as captions with the audio).
• Same question as Ian about meaning of "professionally"
• level 3, #1: How is {a text document (a "script")...} different from a transcript? This would be much easier to meet than the current minimum criteria

Checkpoint 1.3

Ian Jacobs, 06 Oct 2002

"any information that is conveyed through presentation formatting". What does "presentation formatting" mean?

George Kerscher, 20 Oct 2002

I suggest: That we suggest that headings are marked up with heading tags, paragraphs are marked with paragraphs, etc. Try to use the semantically correct element for the content you are trying to present.

Sun (via Earl Johnson), 27 Oct 2002

#1 in "Minimum Level": What is the text "conveyed through presentation formatting" refering to or talking about? An example would be helpful, e.g. "conveyed through presentation formatting, e.g. video, ..."

SAP (via Audrey Weinland), 31 Oct 2002

• Are groupings considered structure? For example, in SAP Web apps, there are screen elements called group boxes. A group box is a grouping of other elements (such as checkboxes, input fields, etc.) on the screen in a box with a title. Would these be considered structure or presentation?
• minimum level #1: What does it mean to convey presentation through structure? Does it mean, for example: Use tags for the presentation formatting instead of using hard-coded formatting? Does all layout information have to be described textually?
• minimum level #2: "through assistive technology compatible markup": Which assistive technology specifically? All of them? Only some of them? They all do things differently, so compatibility is an issue. How would you check that you meet this criterion?

Checkpoint 1.4

WWAAC (via David Poulson and Colette Nicolle), 4 Nov 2002

• minimum level success criteria #1: Could be useful to define what is meant by "seriously interfere"
• Example 2: Missing value- assumed to be 20db for consistency.

Mark Schult, 21 Oct 2002

rather than disallowing background content behind the foreground content, require a mechanism (via CSS or via HTML) that allows the user to turn the background off. This is implied by the statement "background picture or pattern can be easily removed", but I feel "easily removed" is overly subjective.

IBM (via Andi Snow-Weaver), 29 Oct 2002

• Minimum success criteria
  • Both items include the phrase "seriously interfere". This is very subjective. It sounds like rationale, not success criteria.
  • The requirement at this level should be that the author should implement the content using methods that allow the user to turn off the background image or turn off background audio.
• Level 2 success criteria
  • there should be no criteria at this level. These should be moved to level 3.
  • A simulator for "major types of color blindness" is a testing tool, not a success criteria. The guidelines should specify the exact criteria to be met similar to the one defined in level 3 for background sounds in audio content.. A simulator may exist or may be developed that automates the process of evaluating against the success criteria but but the tool itself should not be the success criteria.
• Level 3 success criteria
  • the criteria at this level should result in a choice of either you don't have background images/audio or your images/audio meet criteria that are not a problem (pass color blind criteria, background sounds at least 20 db lower than foreground content, etc.)
  • for the audio criteria, is there a time consideration here? For example, if the background sound is not 20 db lower than the foreground content but it only lasts for a second, is that a problem?

SAP (via Audrey Weinland), 31 Oct 2002

• minimum level #2: "prepared audio presentations" What does "prepared" mean? Not real-time? How does/do personalization/user settings affect this? If you provide personalization, do you meet the requirement, or does the default setting in the Web app have to comply?
• level 2 #1: "have been run through a simulator" Which simulator, and how do we use it? We've used one before, and it did not recognize the SAP color palette. It would take a lot of work to pre-screen for potential "problem screens." This should be a Level 3 criterion unless sample testing is enough, because otherwise it is a very tall order for a Web app.

Checkpoint 1.5

Bill Mason, 28 Aug 2002

• Level 2 success criteria: Point 2 calls for abbreviations and acronyms to be identified "where they occur". Later, checkpoint 4.3 will call for identification only in the first instance where they appear.
• Example 2: W3C is an abbreviation, not an acronym. At the top of the draft in the copyright line, W3C is correctly tagged <abbr>.

Ian Jacobs, 06 Oct 2002

1. The first provision belongs in XAG 1.0, not WCAG 2.0. I don't see it in the 3 Oct 2002 XAG 1.0 draft. I suggest that the WCAG WG request that XAG include something like: "Text formats must be based on Unicode."
2. I think WCAG 2.0 should include a requirement that any XML format that the author uses must conform to XAG 1.0 (e.g., using a relative priority scheme in the manner of ATAG 1.0). I think it will be possible to avoid mutual dependencies. (describes model for how XAG, WCAG, UAAG, and ATAG should relate)
3. "the primary natural language of the content is identified at the page level". That is unclear to me; I don't think "page" is the right term, though I understand the idea.

WWAAC (via David Poulson and Colette Nicolle) , 4 Nov 2002

• minimum level success criteria #1: Is a definition of Unicode needed here?
• minimum level success criteria #2: 'Disambiguation' is a bit ambiguous!

Terry Thompson, 21 Oct 2002

re: to writing checkpoints to make sense out of context: Without reading success criteria, I never would have guessed that this checkpoint refers to natural language. Perhaps the solution is to mention some of the specifics (e.g., natural language, abbreviations and acronyms, etc.) within the language of the actual checkpoint.

Sun (via Earl Johnson), 27 Oct 2002

• #1 in Level 2 is more stringent than #1 Level 3. Should these be swapped?
• The "Note" is informative. Should it be renamed and placed into the informative box? Or maybe make it the opening explanatory statement for the checkpoint (see general comment #1)?

IBM (via Andi Snow-Weaver), 29 Oct 2002

the levels of success criteria for this checkpoint should fall along the lines of 1 - the content is encoded properly, 2 - the language of the page is identified, 3 - you expand on abbreviations, acronyms, passages that need more explanation. Thus,

• Level 1 is okay
• Level 2 success criteria should be moved to Level 3
• Level 3 success criteria should be moved to Level 2
• the problem with acronyms and abbreviations is how the speech synthesizers speak the acronym, not so much how it is expanded. A subcommittee/WG needs to be established to identify the various scenarios and apply some logic as to what the author should do, what the AT/browser should do, what the synthesizer should do, and what the user should do. How the acronym is pronounced should be part of aural cascading style sheets, which is not well defined in this scenario.

SAP (via Audrey Weinland), 31 Oct 2002

• level 2 #2: What does "are clearly identified" mean? Do you mean: Use markup to identify that this is an abbreviation or acronym?
• level 3 #1: Does this mean to use the language tag in HTML, for example?
• include a definition of Unicode

Checkpoint 2.1

Aaron Leventhal, 07 Oct 2002

Add to Benefits: physically disabled users that cannot use pointing devices or speech input. For example, users with ALS who use single switches to simulate keystrokes.

WWAAC (via David Poulson and Colette Nicolle) , 4 Nov 2002

• minimum level success criteria #: Could be made clearer i.e. user agents and event handlers may be too technical for some readers. Checkpoint 2.1 is particularly difficult to follow.
• Benefits: The illustrated benefit is probably not such a good example as speech input is only appropriate in a limited number of cases. A better example would be that keyboard mapping for functions allows specialist switch input devices to work with the applications

Terry Thompson, 21 Oct 2002

Maybe what confuses me here is the prepositional phrase on the end ("to the content or user agent"). Is it necessary? What else would a user be providing character input into other than the content, user agent, or both? As I think about it though, I'm confused by this entire checkpoint. Is this not placing an emphasis on character-accessibility over mouse accessibility? Why not "device-independence"?

Sun (via Earl Johnson), 27 Oct 2002

• Suggest rewording "Minimum Level" to "content uses only event handlers that are designed so that, at a minimum, they are operable through character input." The current wording can be interpreted as meaning an event handler can not also support mouse input (i.e. that it must be a keyboard event handler only).
• From Level 2: what is a "more abstract event"? Same question applies if the wording for this should be "more abstract event handler".

IBM (via Andi Snow-Weaver), 29 Oct 2002

The Character input definition refers to a character set called the W3C Character Model. Are the tab and arrow keys part of this character set? link to where this character model is defined.

SAP (via Audrey Weinland), 31 Oct 2002

level 2 #1: This item is not clear as currently worded and needs rewording. Does it mean to use device-independent event handlers? If so, say that instead. Otherwise, clarify. What is a "more abstract event"? "Used" how?

Checkpoint 2.2

Jonathan Chetwynd, 01 Oct 2002

"due to the nature of real-time events or competition."

following the golf buggy test case, this may be an unnecessary qualification. LDD + CD users need games that are adjusted to their abilities. In reality the video games market has rapidly, over the past 10 years, moved towards a situation where game skills are not an integral part of enjoyment. rather we need to emphasise this aspect, ie that: "game skills are not an integral part of enjoyment." however this is probably more properly part of a script techniques document.

Ian Jacobs, 06 Oct 2002 Proposes rewriting as:

2.2 Allow control of time limits

1. Allow users to control any time limits on their reading, interaction or responses unless control is not possible due to the nature of real-time events or competition.

Sufficient techniques:

1. Allow the user to turn off any timed interaction and carry out that interaction manually. [Priority 1]
2. Allow the user to adjust the time limit over a wide range which is at least 10 times the average user's preference. [Priority 1]
3. And so forth.

Ian Jacobs, 06 Oct 2002

1. This checkpoint sounds like a user agent requirement, not an author requirement. How does the author know that the user is allowed to deactivate the time limits? This is strictly a UA functionality, even if it's specified in a format.
2. There's another aspect of this requirement that belongs in XAG: The format must ensure that:
   • Timing can be specified in a manner that the user agent can recognize (e.g., in markup, not in scripts).
   • The format spec should also tell user agents to conform to UAAG 1.0, checkpoint 2.4.

George Kerscher, 20 Oct 2002

it says, "A news site causes its front page to be updated every 1/2 hour." Do you mean every 1/2 minute?

Mark Schult, 21 Oct 2002

Level 2 or Level 3 compliance of Checkpoint 2.2 would seem to be the avoidance of all time limits to reading or interaction. Since this condition is already qualified by "unless control is not possible due to the nature of real-time events or competition", it seems that high-level compliance should simply be avoidance of this technique as unnecessary.

IBM (via Andi Snow-Weaver), 29 Oct 2002

• we should not provide success criteria for scenarios that are excluded by the checkpoint itself
• Item 1d concerns time limits that are due to real-time events. The checkpoint excludes these types of time limits with the phrase "...unless control is not possible due to the nature of real-time events"
• Item 1e concerns time limits that are part of competitive activity. The checkpoint excludes these types of time limits with the phrase "... unless control is not possible due to the nature of .... competition".

Checkpoint 2.3

WWAAC (via David Poulson and Colette Nicolle) , 4 Nov 2002

Benefits: 'Distractibility problems' could be reworded to say 'individuals who are easily distracted'.

Terry Thompson, 21 Oct 2002

How problematic would it be to extend the high end of the dangerous flicker rate to 55Hz, rather than 49Hz, in order to be consistent with Sec 508 standards?

Sun (via Earl Johnson), 27 Oct 2002

On #3 in Level 2: if it is kept as a criteria consider changing it to a Level 3 criteria.

IBM (via Andi Snow-Weaver), 29 Oct 2002

• Minimum success criteria
  • Since all success criteria must be testable, and item 1b implies that 1a cannot be tested, item 1a should not be included as a success criteria.
  • Also, what is the rationale for specifying the range between 3 and 49? Section 508 specifies a range between 2 and 55. We don't know the rationale for that either but do we have specific reasons for making WCAG different?
• Level 2 success criteria: Items # 1 and # 2 should be moved to Level 3.

SAP (via Audrey Weinland), 31 Oct 2002

"content was not designed to flicker (or flash) in the range of 3 to 49 Hz." Could you include a visual example?

Checkpoint 3.1

Ian Jacobs, 06 Oct 2002

The first provision assumes that the format includes paragraphs; some formats do not include paragraphs. XAG should ensure that important elements can receive titles and descriptions. Then, WCAG 2.0 should say "Use the format's available markup for titles, descriptions, captions and audio descriptions.")

WWAAC (via David Poulson and Colette Nicolle) , 4 Nov 2002

success criteria: Could be useful to include top loading of page content here as well, i.e. putting most important information or summaries of content at the top of pages.

George Kerscher, 20 Oct 2002

I am not sure that people understand what we mean by structure. Somewhere higher up in the document a description of structure should be given. There is also mention of hierarchy, but what does that mean in W3C/XHTML terms? Are we talking about organization into headings, or nested div or what. I normally produce documents that use headings as headings are intended to be used and it is this high level structure that makes the organization useful for me. What I mean by a heading is something that is marked up as a h1 through h6. I don't think this is specific in the guidelines -- it almost looks like this was specifically avoided; was it?

Terry Thompson, 21 Oct 2002

I'm having a hard time envisioning a document that has no structure. Do you mean "appropriate structure", "proper structure", "specification-supported structure", or something else entirely?

Sun (via Earl Johnson), 27 Oct 2002

• For Minimum Level: shouldn't table structure (row, column) and basic role (data, header) also be required?
• The Note is a good recommendation (guidance), consider moving it to the informative portion of the checkpoint and renaming it to Recommendation (or Guidance). Or maybe the Note should be in "Minimun Level" or "Level 2" (which would address comment a. above).

IBM (via Andi Snow-Weaver), 29 Oct 2002

• Level 2 success criteria: probably not possible to determine whether you have done what is "possible". May be okay to do what you think is "appropriate". This criteria is very subjective and should be moved to Level 3.
• Level 3 success criteria: item # 2 on diagram is just repeating the checkpoint. What is the criteria that makes a diagram have structure? reading order?

SAP (via Audrey Weinland), 31 Oct 2002

• How does this checkpoint apply to screens in a Web app? Something analagous needs to be added for application structure. Would menus satisfy the structure checkpoint? Also, this checkpoint seems to be about usability, not accessibility. Imposing structure through these guidelines regulates usability. The point we feel is most valid here is Level 3, #1, which should be the minimum requirement.
• All of the benefits appear to be usability benefits, not accessibility benefits.
• Example 2: This implies images are supposed to have structure too, like documents. Why would structure be mandatory here? If the author is not trying to provide information about the structure of the bike, but rather display the bike as a whole, how is that a problem? Also, it would be really helpful here to see a visual example of what the example would look like.

Checkpoint 3.2

Ian Jacobs, 06 Oct 2002

• "content is constructed such that users can control the presentation of the structural elements" does not belong in WCAG 2.0. there is a XAG component ("ensure control is possible") and a UAAG component ("allow control").
• The Note describes a limitation of this document. This should appear in the introduction, in the (new) section "Limits of this document."

WWAAC (via David Poulson and Colette Nicolle) , 4 Nov 2002

success criteria: Difficult to follow could be reworded?

Olivier Thereaux, 18 Oct 2002

level 2 criterion: the use of "display" for any rendering device (visual, audio, ...) seems potentially misleading. I may have missed other uses of "display" as a generic rendering device, or a definition of "display", but I think it would be better to not use "display" for any other context than visual.

Sun (via Earl Johnson), 27 Oct 2002

• From Level 3: it is unclear what this is talking about: "alternate presentation formats are available to vary the emphasis of the structure." Are the Examples in the informative section all examples of this? Consider defining what "alternate presentation formats" means in the informative section.
• On Note #1: it is guidance or a recommendation. Consider renaming it to Guidance or Recommendation and placing it in the informative section.
• On Note #2:ls the note really a requirement, should it state it is?
• On Note #2: it refers to Checkpoint 2.2. What is the connection between 2.2 (timed response) and 3.2 (emphasize structure)? Should it be pointing at 5.3 instead?
• On Note #2 it is guidance or a recommendation. Consider renaming it to Guidance or Recommendation and placing it in the informative section.

SAP (via Audrey Weinland), 31 Oct 2002

• How does this checkpoint apply to Web app screens?
• Minimum level #1: What is meant by "the other structural elements"?
• level 2 #2: What does it mean for the structural emphases to be distinct? Also, what are the major display types we would have to do this for? We need a list.
• level 3 #1: Would this replace the minimum criteria, or would it be in addition to the minimum?
• additional ideas #4: What does "not salient enough" mean? How do you measure that?

Checkpoint 3.3

Ian Jacobs, 06 Oct 2002

Define "layer"

WWAAC (via David Poulson and Colette Nicolle) , 4 Nov 2002

Definitions: site navigation mechanisms Could also mention use of 'breadcrumb trails' to assist site navigation. I.e. providing information on pages to show the individual where they have come from in the structure of the site.

IBM (via Andi Snow-Weaver), 29 Oct 2002

Minimum success criteria: Item 1 would be clearer if we said "three or more layers" instead of "more than two layers"

SAP (via Audrey Weinland), 31 Oct 2002

What are the layers in a Web application? What would constitute a layer in a Web-based wizard? Is a layer horizontal or vertical in the structure? This checkpoint does not seem to apply very well to Web apps. If there is a Submit button, for example, why should it be duplicated with a navigation link? What about Web sites where content is displayed dynamically based on the user's profile, etc.? A site map would be difficult to make. This seems to us to be a usability checkpoint, not accessibility. The benefits listed all point to usability.

Checkpoint 3.4

Jonathan Chetwynd, 01 Oct 2002

At the beginning of each link is an icon of an arrow with the text equivalent, "Link will open in new window."

this seems to assume a text link. Could we have a working example? with a graphic? I've not been able to find a suitable way to do this for a graphic site....

Ian Jacobs, 06 Oct 2002

• Seems vague. Proposes xag component: require markup for navigation groups (not just single links). then Authors should use that markup for navigation groups. Authors specify that, when rendered graphically, a navigation group, whenever it is available, be rendered in the same place(s) in the viewport.
• There is an inevitable subjective component to this requirement: Be consistent except where it's appropriate to diverge.

IBM (via Andi Snow-Weaver), 29 Oct 2002

Level 2 success criteria: should be moved to Level 3.

SAP (via Audrey Weinland), 31 Oct 2002

• Again, a usability issue, not an accessibility issue.
• Minimum level #1: What is considered "key"? This is subjective. Key elements need to be defined. What does "are otherwise predictable" mean? Can you give an example? Some SAP Web app screens have tabstrips and trees that include links. Would these have to comply with this guideline?
• additional ideas #2: Why "or"? Should specify which: the whole site or a section of a site.
• additional ideas #3: Similar user interface components within what scope? In a Web app, would this be components within a single transaction or function, or would it be components within the whole application? What about a suite of applications?
• additional ideas #4: What exactly is meant by headers here?
• benefits #1: Usability benefit, not accessibility. Being able to find something is accessibility. Being able to predict where it can be found is usability.
• benefits #2: One could read this point to mean that every page should be different. Not sure that makes as much sense in a Web app, where a lot of the areas on the screen, like navigation, are consistent from screen to screen.

Checkpoint 3.5

WWAAC (via David Poulson and Colette Nicolle) , 4 Nov 2002

• Consistent and predictable responses: Could be worth adding something about consistent labelling of controls and functions performed in different parts of the application. Even though this would most probably fit under the 'Operable' Guideline, it is still also relevant here. Point is not clearly made.
• Examples: Not very clear from wording, this should be expanded as well.

Sun (via Earl Johnson), 27 Oct 2002

• The informative Benefits: the Note looks like a benefit. Consider changing it from a Note to a Benefit bullet.
• Sun answer to Reviewers Note question: expand and clarify them to acheive consistancy in style with how all other Examples are presented.

IBM (via Andi Snow-Weaver), 29 Oct 2002

• Level 2 success criteria should be moved to Level 3.
• Definitions: mechanisms that cause extreme changes in context
  • the first bullet should read simply "opening a new browser window". That is the definition of an extreme change in context whether it is expected or not. Our guideline is that this change should be done in a predictable way so that it is not unexpected.
  • the second bullet should simply read "a change of speaker in an auditory presentation". Again, that is the definition of the extreme change in context. The guideline is that there should be a caption or visual cue so that the user understands it.
• benefits
  • the user agent knows when it is opening a new window and can inform the user. HPR does this. IE can be configured to do it. The author should only be required to code it correctly.
  • The "Note" seems like a further elaboration of the first benefit bullet. It should be incorporated into that bullet.
• examples
  • Example 3 is an example of NOT meeting the checkpoint. It should be removed or reworked to be an example of meeting the checkpoint.

SAP (via Audrey Weinland), 31 Oct 2002

• How far in advance does the warning need to come? Does telling the user during training about what certain responses will be cover this checkpoint? What about telling them in the documentation? If something in a Web app is unpredictable, it's usually unpredictable for non-disabled as well as disabled users. Furthermore, what is the true usability goal here: usability or learnability?
• What should the predictability be based on? Industry standards? The user's learned expectations within that Web app? For example, in some SAP Web apps, the user can tab to text. This may not be expected by new SAP users who use screen readers and are used to not being able to tab to anything but interactive elements, but new users have provided us with positive feedback on this feature, as it ensures they receive information about everything on the screen.
• minimum level #1: Could you include a more pertinent example too, like a Web app or an e-commerce site or something, not just mystery games or tests?
• additional ideas #2: What does this mean for companies like ours? That we cannot do any new or innovative design?
• additional ideas #3: Would providing this information during training satisfy this point? We agree that basic browser navigation behavior should be followed, but we don't agree that it needs to be regulated through guidelines like these.
• example 4: no explanation given

Checkpoint 3.6

Ian Jacobs, 06 Oct 2002

"If an error is detected..." By whom? This sounds like a user agent requirement, not an authoring requirement.

Olivier Thereaux, 18 Oct 2002

The title for checkpoint 3.6 talks about "graceful recovery" from errors but the text for the 3 levels do not seem to include this concept. It may be a good idea to introduce the idea of "fallback behaviour", etc.

Terry Thompson, 21 Oct 2002

Minimum level success criteria: "If an error is detected, feedback is provided to the user identifying the error". Since a common current problem is the use of inaccessible client-side scripting techniques for form validation, perhaps this should state the obvious, e.g., "...feedback is provided to the user identifying the error in a way that is [accessible/perceivable in accordance with Guideline 1/something similar]".

Mark Schult, 21 Oct 2002

better define "error". It seems that unforeseen errors are the constant bane of electronic interfaces and therefore one can rarely say with confidence that they've predicted and trapped for every error condition. Perhaps you also want to specify that if an unhandled error condition is reported after the site is purported to having compliance, statements asserting compliance must be updated.

Sun (via Earl Johnson), 27 Oct 2002

• In #1 Level 3: is this saying "use a combobox whenever possible," or more, or different. It's hard to tell what needs to be done to what to fulfill this requirement.
• In #2 Level 3: change it to a Level 2 requirement?
• In #4 Level 3, change it to a Minimum Level requirement?

IBM (via Andi Snow-Weaver), 29 Oct 2002

• Graceful recovery should be removed from the checkpoint or defined in the definitions section.
• Level 2 success criteria should be moved to Level 3.
• Level 3 success criteria: Item 4b ends with the phrase "in advance". In advance of what? It seems like some of these criteria are error prevention and recovery methods that would have to be used in order to claim success criteria at Level 2.

SAP (via Audrey Weinland), 31 Oct 2002

• We're not sure we see the link to accessibility here. Again, it seems to be more of a usability issue.
• minimum level #1: This only meets one of the checkpoint's goals: provide graceful recovery. What about minimizing errors?
• level #3 #1:Is this intended to say that if it's possible to allow the user to select from a list, that should be done AND users should be allowed to input text directly? Or is it intended to say that if it's possible to allow the user to select from a list, that should be provided INSTEAD of direct text input? We feel it should be the latter, not the former.
• level #3 #3: Our Web apps have input fields and text boxes everywhere, on practically every screen. This sort of spell checking would negatively affect system performance. Also, our apps support many different languages, so we would require spell checkers for each language. It's not clear how this is an accessibility issue.

Checkpoint 4.1

Mark Schult, 21 Oct 2002

I suggest that Level 1 is the intent and attempt to write "clearly and simply". Level 2 is a statement affirming that such an attempt has been made and includes contact information for suggestions on improving the clarity and simplicity. Level 3 could then be the delivery of content in alternate levels of clarity and simplicity (that criteria of course being problematic to gauge).

IBM (via Andi Snow-Weaver), 29 Oct 2002

• Partial list of items being explored - In Item 10, find a better example than "haven't seen you in a coon's age"
• There is a lot of work going on in the working group attempting to define objective criteria for this checkpoint. It seems that the working group has been wrestling with this for a long time. Perhaps it is time to set a deadline for completing this. If the working group cannot reach consensus on objective success criteria by the end of the deadline, this checkpoint should be removed or moved to an informative section.

SAP (via Audrey Weinland), 31 Oct 2002

• What cognitive disabilities are covered here? What is the goal for each disability? While our Web apps could be used by people with some cognitive disabilities, they could not be used by people with all types of cognitive disabilities.
• Partial list of items... #3: What should be considered "key" pages or sections? Who decides that?
• Partial list of items... #4: Points 3 and 4 would be an additional burden for us to implement in our Web apps. Plus, summaries would cause maintenance headaches.
• Partial list of items... #5 & 6: Wouldn't 5 and 6 be considered issues of style? How can you regulate style?
• Partial list of items... #7: Does this mean, for example, use the HTML title tag, or are we talking about the title in the content section of a page?
• Partial list of items... #8:This would require a lot of effort to implement in Web apps like ours. We might have three group boxes on a screen, each of which has its own Submit button specific to that group box. But we would still use the text "Submit" for each button. If this is made into a criteria, it should be a Level 3.
• Partial list of items... #9: Where would we put these in a Web app? Would a glossary of terms be good enough? SAP has a lot of specialized terminology, and each industry that our applications address has a lot of its own specialized terminology as well.
• Partial list of items... #10: If you have to explain such language usage, why would you use it in the first place? Again, this is a style issue that we don't feel should be regulated.
• Partial list of items... #11: This one would be better to use than Point 10 or Point 12.

Checkpoint 4.2

Terry Thompson, 21 Oct 2002

Examples 3 and 5 - This may seem trivial, but there is no mention that the child in Example 3 received permission to display the bicycle plant's company logo, nor that Grandpa in Example 5 received permission to include a short music clip, assuming the clip is stored locally. In recommending that Web content developers include graphics where they previously would not have done so, there is potential for inadvertently facilitating an increase in copyright violations. You should avoid language that in any way justifies this, even in examples or other supporting documentation.

Sun (via Earl Johnson), 27 Oct 2002

This appears to be a different way of saying what Checkpoint 1.1 says, why is this checkpoint needed? If it's really not a mirror, should checkpoint 1.1 be mentioned someplace in the text for this checkpoint?

IBM (via Andi Snow-Weaver), 29 Oct 2002

• we recommend that the working group set a deadline for developing objective success criteria for this checkpoint. If the working group cannot reach consensus on objective success criteria by the end of the deadline, this checkpoint should be removed or moved to an informative section.
• The definition of non-text content does not fit what we mean by non-text content in this checkpoint. It makes it sound like we are recommending that people supplement text with ASCII art, for example. Do we really mean illustrations here? We used that term in the informative note on this checkpoint.
• We need more rationale here as to why adding non-text content to text is a good idea.

SAP (via Audrey Weinland), 31 Oct 2002

• Minimum level #1: Deciding whether it is "appropriate" is very subjective. How would you measure whether this checkpoint had been met? What are "key" pages or sections, and who defines that?
• level 2 #1: It's not clear what the difference is between this level and Level 3. Please clarify.
• benefits: focus on Web sites. What about Web apps?
• benefits note: This note is asking a lot of designers. It essentially asks them to know about all different kinds of cognitive disabilities.

Checkpoint 4.3

Ian Jacobs, 06 Oct 2002

"Content is considered complex if the relationships between pieces of information are not easy to figure out." I don't find this definition helpful.

WWAAC (via David Poulson and Colette Nicolle), 4 Nov 2002

Examples of complex information: What is meant by 'several layers'?

Sun (via Earl Johnson), 27 Oct 2002

Does "use longdesc if conditions warrant" fall under this checkpoint? It would be very helpful to have multiple examples that illustrate what this checkpoint means by "annotate."

IBM (via Andi Snow-Weaver), 29 Oct 2002

Minimum success criteria: Item 1 says acronyms and abbreviations should be defined the first time they appear. Does this mean the first time they appear on a page or on a site?

SAP (via Audrey Weinland), 31 Oct 2002

• minimum level #1: The first time they appear on a page? On the site (or Web app)? How can you know where the user has started, in order to determine whether this is the first time they are encountering the acronym or abbreviation? It might require redesigning screens, because of the limitations on screen space. Particularly in Web apps like ours, meeting this checkpoint would be very resource-consuming.
• additional ideas #2: We did not understand this point. Could you give an example?
• additional ideas #3: Not sure what this point means. What is "semantic markup"?

Checkpoint 5.1

WWAAC (via David Poulson and Colette Nicolle), 4 Nov 2002

Comments on reviewer's note (about accessibility of protocols). This issue was recently closed. The note should be removed.

Sun (via Earl Johnson), 27 Oct 2002

Sun thinks the mention of protocols is relevant and desireable (especially when a link also points to an appendix entry that names protocols that support accessibility). Content providers/developers ought to be helped by pointing to where they can find more specific information for ensuring that when they use non-W3C technologies in web content they are using or choose technologies that have access support built into them (e.g. Java/Swing, PDF, realtime video, etc.).

IBM (via Andi Snow-Weaver), 29 Oct 2002

• Minimum success criteria
  • items #2 and #3 are not needed here. Checkpoint 5.4 covers programmatic interfaces.
  • what does it mean in item 3 to use accessibility features if available? If accessibility features are not available, can I use the technology or not?
  • in answer to the question asking if protocols are relavant to this checkpoint, yes "protocols" are relevant and should be included.
• In Example 2, "Java program" should be "Java applet"

Checkpoint 5.2

IBM (via Andi Snow-Weaver), 29 Oct 2002

Minimum success criteria

• Item 2 needs to be clarified. If I declare that scripts and style sheets are part of my baseline, are they above it or below it? Perhaps this can be clarified by expanding the example.
• the term "technology" needs to be defined along with adding and defining "platform"
• does the baseline include platform, language? i.e. what are the user agent requirements that need to be documented? could be useful in documenting the "configuration" that is accessible
• the success criteria really have nothing to do with designing for backward compatibility
  • Level 1 is "declaring" your configuration.
  • Level 2 is testing your baseline.
  • Level 3 is that it works in a text only browser.

SAP (via Audrey Weinland), 31 Oct 2002

• This point seems focused only on the general public user community. But what about the user community for certain products? Shouldn't a company like ours be allowed to decide ourselves if we want our products to be backwards compatible? If backwards compatibility becomes regulated, it would limit companies' ability to sell upgrades to existing customers.
• minimum level #1: How far backwards-compatible is far enough? Who determines that? How do you measure that? Should you force people not to use Flash at all, for example, even if they provide an accessible alternative?

Checkpoint 5.3

Ian Jacobs, 06 Oct 2002

The provisions of this checkpoint are not verifiable. Instead, these design goals are XAG design goals and should be manifest in that specification (though in more concrete terms). Perhaps this is the checkpoint that should read "Use formats that conform to XAG."

Sun (via Earl Johnson), 27 Oct 2002

How about, "Choose technologies that programmatically support, expose, and make possible building content that meets the WCAG." Although, it is hard to tell exactly what this checkpoint applies to. Perhaps it would be better to put the jist of this feedback (structure and content must be programmatically available to an AT) into Guideline 5's wording or into 5.1 or 5.4

IBM (via Andi Snow-Weaver), 29 Oct 2002

This is an important consideration but should not be a checkpoint. If you meet all the checkpoints, then you have obviously done this. If you haven't, then what difference does this make?

SAP (via Audrey Weinland), 31 Oct 2002

• The baseline AT needs to be defined. Otherwise it's too difficult to figure out which AT to support.
• minimum level #1 subpoint #3: Not sure what this means. What are publicly documented interfaces?
• minimum level #1 subpoint #5: Not sure what this means. Please clarify.

Checkpoint 5.4

Ian Jacobs, 06 Oct 2002

This checkpoint requires conformance to UAAG 1.0 Level A, but that is an incomplete profile. Please refer to sections 3.1 and 3.3 of UAAG 1.0 for information about how to include a UAAG 1.0 conformance profile in a specification.

Terry Thompson, 21 Oct 2002

All content has a user interface, which makes this checkpoint redundant. Should be "custom user interface".

IBM (via Andi Snow-Weaver), 29 Oct 2002

This checkpoint is about making the user interface operable and would be better organized as part of guideline 2.

SAP (via Audrey Weinland), 31 Oct 2002

• minimum level #1: This point needs to be clearer. We cannot tell if we would need to follow these other guidelines. If a Web app runs in a standard browser, does the interface still have to conform to the other guidelines? What is considered an accessible alternative? A text-only site? What would be an accessible alternative for a Web app page?
• level 2 #1: What does "or hidden within the page" mean? Variety of assistive technologies" needs to be defined. Otherwise it's too vague. Is it enough, for example, to target JAWS and MAGic?
• level 2 reviewer's note: Not sure how it would be possible to comply with the checkpoint without carrying out tests. The text specifically says "the interface has been tested." Please clarify.

Glossary and definitions of terms

• Please consider the UAAG 1.0 definitions of text content, non-text content, etc., which were written to clarify some definitions in WCAG 1.0 that the UAWG found inadequate. In particular, it's not clear what makes something text content or non-text content. I believe the UAAG 1.0 contributes to making this clearer. Ian Jacobs, 06 Oct 2002
• There are at least four uses of the root "present" in the document:
  • "Presentation" (rendering)
  • "A presentation" (a multimedia object)
  • "Present" (available, at hand; cf. checkpoint 3.2)

  I recommend choosing three different terms to avoid confusion. The definition after 1.3 uses "presentation" to mean "rendering". Ian Jacobs, 06 Oct 2002

• metadata is not defined in checkpoint 5.2. Terry Thompson, 21 Oct 2002

• The "Glossary of terms" should not be part of the recommendation, but kept in a separate doc such as the techniques. The "common WAI glossary" just needs to include the definitions that the WG proposes. The process is key here, that the terms be considered as part of the WCAG recommendation up to the "proposed recommendation" step, where the terms and definitions are "removed" from the recommendation and "ensured" are part of the common glossary for all WAI documents. IBM (via Andi Snow-Weaver), 29 Oct 2002

• The multimedia definition does not cover animation. Is it considered not part of multimedia? SAP (via Audrey Weinland), 31 Oct 2002

Editorial suggestions

• Please number provisions (sufficient criteria) uniquely. I would like to refer to provision 1.1.1 or 1.1.2 and have that be unambiguous. Ian Jacobs, 06 Oct 2002 (at the 10 Oct 2002 meeting, Ben reiterated that this is already on the to-do list)
• Please delete sections where there is no information (i.e., where it reads "(presently no additional criteria for this level"). Ian Jacobs, 06 Oct 2002 (at the 10 Oct 2002 meeting, decided to leave this until the end of the process)
• Use the active voice rather than the passive voice in making requirements. Ian Jacobs, 06 Oct 2002 (at the 10 Oct 2002 meeting, Avi took an action to put into active voice and Andi took an action to check with IBM editors)
• Overview of Design Principles - User Needs
  • First bullet point is slightly confusing. Better as" Someone who cannot hear will require auditory presented information transformed into a visual form"
  • Second point- Slightly misleading as relatively few blind people read Braille, better as "Someone who cannot see or hear may want to read through Braille....."
  • Also final point better as "Someone who does not read or see well may............." WWAAC (via David Poulson and Colette Nicolle), 4 Nov 2002
• Use a language style that is consistent between WCAG 1.0 and 2.0. In 1.0, checkpoints were stated as imperatives, which I think is more direct language, and easier to read. Users will commonly be consulting WCAG 2.0 as a "how to" document, so expressing particularly the success criteria using "how to" language will match users' expectations. Terry Thompson, 21 Oct 2002
• Check subject-verb agreement. I don't think this is a common problem, but Checkpoint 5.3, minimum success criteria #1 has as subject "the technology or combination of technologies", which is a singular subject, so items 1(a) through 1(e) should reflect this, i.e., use "supports device independence" rather than "support device independence". Terry Thompson, 21 Oct 2002

Presentation suggestions

• To make it easier for people to migrate from WCAG 1.0 to 2.0, the presentation of the two versions should match more closely, e.g., by drawing boxes around guidelines. Terry Thompson, 21 Oct 2002
• When reading the WCAG 2 what stands out is the checkpoint's informative box versus the chckpoint and what each level requires. The checkpoint wording should stand out more so that when a reader skims it their eye is drawn to the actual checkpoint first. Sun (via Earl Johnson), 27 Oct 2002

$Date: 2002/12/19 03:54:20 $ Wendy Chisholm