W3C logoWeb Accessibility Initiative (WAI) logo

WAI: Strategies, guidelines, and resources to make the Web accessible to people with disabilities

Comments on ATAG

7/14/08

Introduction:

Organization

Definition of Authoring tool is normative, but it doesn't say where the normative section ends. If the organization part is normative, them we need to make sure the “must” and “should” in the Organization section conforms to the RFC of Keywords.

Success Criteria

  1. Use of “[Sufficient]” and “[Advisory]”: Why both “” AND [] ? If there is something significant about it, it isn't clear what it means.

  2. Success Criteria Level General: I don't like defining the level of support for Accessibility by talking about the restrictions on the tool. I don't think it is correct (Universal Design) and could easily become a detriment to marketing a product rather than an asset. (Most accessible=most limited.) I recommend that we stick with the WCAG Level guidelines and define it in terms of the barriers to use.

  3. A Part A. “Thus people with the widest 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 tools in different ways” It would seem to me that the “widest range” would apply to AAA, not A.

  4. Success Criteria Level AA – Part A. Isn't clear. I couldn't figure out what made something AA instead of A or AAA.

Relationship to WCAG

Last sentence in first paragraph is missing words, or doesn't make sense. “...to mean for the particular Web content technologies that an authoring tool produces and is implemented using (if applicable).“

Part A

Guideline A.1 – Facilitate access by AT

  1. I think it would be more clear if A.1 were moved to the end of Part A, as the last Guideline instead of the first. Then all the other things would already be covered, and this is sweeping up the last of the functionality by saying that all functionality is implemented in the Accessibility API. It duplicates much of A.2.3 which adds to the confusion.

  2. “User Interface “Chrome””. Same problem as UAAG. We need to pick terms and be consistent with them. If we use chrome, don't put it in quotes. Define it and make it a term. User Interface Chrome is redundant.

  3. If we are going to put “(user interface "chrome", content display)“ with each SC, then let's clarify it, e.g. “Applies to user interface” or “Applies to content display” or “Applies to both user interface and to content display.”

  4. Guideline A.1.2 should be the parallel of A.1.1: Ensure that non-web based functionality is implemented using the accessibility architecture appropriate to the platform.

  5. All titles in A.1.2 need editorial work.

  6. All the SC for A.1.2 need to be focused on the Accessibility Architecture. The word “platform” should be reserved for the “OS”.

  7. A.1.2.1 Don't understand: “or leverage existing implementations of the architecture.” Recommend we reserve “architecture” for “accessibility architecture”. Or find a better word for Accessibility APIs (which I know is Windows-centric).

  8. I think A.1.2.2 is level AA and A.1.2.3 is level A, but it would help if they were explained more clearly.

  9. A.1.3: Why should they cite conventions? How does that improve accessibility?

  10. A.1.3.2: What is Keyboard Configuration? Is that Keyboards shortcuts, or is that a standard keyboard, vs. Enhanced vs. Dvorak?

Guideline A.2 – Perceivable

  1. Switch order of SC A.2.1.1 and A.2.1.2.

  2. SC A.2.1.1 (existing #) should focus on the view mode rather than on the content. For example “An Editing view that renders non-text objects also has a view or option where the text-equivalent of the object is displayed and is available to accessibility architecture. (or whatever word we standardize on)”

  3. SC A.2.1.2 (a) should reference A.2.3.1 or we should merge the two.

  4. SC A.2.1.2 (b) Can we help Time-Based Media with an in-line explanation as well as a link to the definition? It's the first time the term is used, and it isn't explained. I suggest “ Time-Based Media (Audio-Video)”. I like the referral to A.2.2.

  5. A.2.2 Success Criteria needs numbering.

  6. A.2.2.5(?) Time-based content renderings doesn't seem to belong here.

  7. We need to clarify when an audio description is needed and when captioning is needed. This whole section seems unclear.

  8. SC A.2.3.1 seems to be more applicable to A.1.

  9. Need consistent use of “platform”. Recommend that “platform” be used when we are discussing the OS/Hardware and a different term when referring to the A11y APIs.

  10. SC A.2.3.3 needs a better title. Suggest: Alternate Presentation of Modified Content.

  11. SC A.2.3.4 needs a better title. Access to Text Styling Properties

  12. SC A.2.3.5 needs clarification: Suggest: Meaningful Sequence: When the sequence in which user interface components are presented affect their meaning, the semantic equivalent of that sequence is available via the accessibility architecture.

  13. SC A.2.3.7 has a typo “edtiable”

  14. SC A.2.3.7 belongs in Part B or in A.1 – I don't see why it is here.

Guideline A.3 – Operable

  1. SC A.3.1.1 Keyboard. Add the line from UAAG, “this does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.”

  2. SC A.3.1.6 should be Level A.

  3. G A.3.1 Remove Note #2 as it is now part of A.3.1.1. Are Notes normative?

  4. SC A.3.2.1 Suggest: Data Saved. If the authoring tool ends an authoring session due to a time limit, then the user is given an interrupting warning and given an option to save the data. If the user doesn't act on the warning within several minutes, then the data can be expired.

  5. SC A.3.6.1 overlaps with A.2. Needs some work to separate and discriminate between them.

  6. Recommend adding a new AC for Level AAA. “Customized sets of keyboard shortcuts [or whatever word we decide to use] can be imported and exported.”

Guideline A.4 – Understandable

  1. Merge A.4.1 and A.4.4. Take the SC for Guideline A.4.4 and make them the Level A SC for Guideline A.4.1. Broaden the rationale to include Documentation.

  2. A.4.2.1 also belongs in Operable Keyboard (A.3.1)

  3. A.4.3.3 Error is passed in text and available to accessibility architecture.

  4. Guideline A.4.3 broaden beyond text. Suggest: Note 2. It is acceptable to group like actions (e.g typed words, a series of backspaces, a series of right-arrow for positioning) ....