EOWG comments on ATAG 2.0 Working Draft of 7 December 2006

Dear ATAG Working Group,

Following are comments compiled from EOWG discussions of the 7 December 
2006 ATAG 2.0 Working Draft
http://www.w3.org/TR/2006/WD-ATAG20-20061207/
at EOWG teleconferences on 5,12, and 19 January 2007.

My apologies for not completing the write-up of these comments and getting 
them to you sooner. Please let us know if you have any questions on these 
comments.

Thank you,

- Judy Brewer on behalf of EOWG


1. Consider moving the conformance section after the guidelines themselves, 
though still keeping it a part of the main document (as opposed to putting 
it in an appendix); e.g., see http://www.w3.org/TR/UAAG/cover.html#toc

2. The dependency between ATAG 2.0, and WCAG 1.0 and WCAG 2.0, needs to be 
clarified in the Introduction.

3. Briefly mention in the Abstract that ATAG 2.0 applies to both WCAG 1.0 
and WCAG 2.0.

4. Consider whether "Content Type-Specific WCAG Benchmark" belongs within 
the ATAG 2.0 spec. It seems better to put it in a separate document and 
point to it from the ATAG 2.0 spec.

5. Provide one or more example conformance statements. Put these in a 
separate document and point to them from the ATAG 2.0 specification. Also 
note that the fourth point asks for a description of how the normative 
success criteria were met for each of the checkpoints that were required; 
that seems a lot to ask for. Perhaps the example would help clarify that 
this is a requirement for brief comments, and not detailed descriptions.

6. Introduce concepts and terms before they are used. For example, several 
things in the "Relative Priority Checkpoints" section are required to 
understand the point, but have not yet been introduced or explained; for 
instance: "Part A" & "Part B", "conformance profile", "content 
type-specific WCAG benchmark".

7. The content in 1.2 does not entirely match the heading ("Role of 
authoring tools in Web accessibility"). Re-examine the content for 
suitability in this document, possibly moving some material out and 
pointing to it in another document(s); or break up the content into 
different sections; or broaden the heading.

8. [editorial] In several places, the links cause some reading difficulties 
(since they are emphasized by both color and underline), especially when 
only part of compound nouns are linked. For example, in the introduction, 
in the second sentence, "...assisting authoring tool developers to...", the 
word "developers" gets lost and instead it should be the focus. In other 
places, links may be unnecessary, e.g. the links in '(e.g., an HTML editor 
with both code-level and WYSIWYG editing views)' go to the bullets right 
underneath; instead of links, put 'described below'.

9. Consider providing a resource like the WCAG 2.0 Quick Reference (note 
though that this may be renamed) where users can get a version of the ATAG 
2.0 guidelines and techniques that apply specifically to their project by 
filtering based on options such as WCAG version, WCAG priorities, and type 
of tool. For example, users would choose the relative priority up front, 
and then the options for filtering would take care of sorting out the 
relevant priorities (since "relative priority" is a complicated concept to 
understand).

10. Add a link at the top of the document to the [Contents] (as is done in 
many W3C specifications).

11. ATAG should apply to modular components (such as widgets) of the 
authoring tools as well as to the authoring tools themselves.

12. Consider mentioning the following as one among several overarching 
principles (or a quick tip?) for the document: "If the authoring tool is 
Web-based, then the user interface should be WCAG-compliant, and the 
content that is produced should be WCAG-compliant."

13. Since relative priority is such a key concept for ATAG conformance, 
introduce it in the Introduction.

14. The concept of content-type specific WCAG benchmarks is not 
sufficiently clear from the description, nor how to implement it; and the 
developer is pointed to too many resources for details on how to implement 
this. For example, EOWG readers had the following questions: Is 
"content-type specific WCAG benchmark" different from a Techniques 
document? Does "content-type specific WCAG benchmark" need to be normative? 
Should the authoring tool developer write the "content-type specific WCAG 
benchmark," or the vendor?

15. A.1.4 is difficult to understand. It currently states "For the 
authoring tool user interface, ensure changes to the display settings of 
editing views do not affect the content being edited." How about instead: 
"For the authoring tool user interface, ensure that changes to the display 
settings of editing views do not affect the content." Then also remove 
"being edited" from the success criteria. Note that the lead-in phrase on 
success criterion 3 is ambiguous: "Editing views that have their display 
characteristics set by rendering the content being edited (e.g., WYSWYG 
editing views) must override these characteristics..."

16. Checkpoint and success criterion B.2.6 seem to be saying that an 
authoring tool must have evaluation functionality on board. If this is what 
is meant, then it should be stated more clearly, even if you also include 
the precise statement here of the evaluation tool functions that are 
expected. (There was some but not conclusive EOWG discussion as to whether 
plug-in capability of evaluation functions should be a sufficient success 
criteria, instead of requiring authoring tools to have evaluation 
functionality on board, but in our discussions we focused primarily on the 
understandability of the document.)

17. Consider whether these terms (perceivable, understandable, operable, 
etc.) ought to be in your glossary.

18. For success criteria 2 and 3 under A.1.5, the phrase "the semantic 
description of the presentation must be available programmatically" was not 
understandable to EOWG readers despite considerable discussion. One 
interpretation included that this should be referring to the "semantic 
function" not "semantic description" but this was not clear; and in 
addition, the relationship to the authoring tool interface was not clear

19. For the entire part A of the guidelines, the use of "For the authoring 
tool user interface" at the front of each checkpoint makes the checkpoints 
more difficult to understand. Consider bracketing this phrase and 
capitalizing the following phrase, for instance: "A.1.1 [For the authoring 
tool user interface] Provide text alternatives for all non-text objects. 
[Priority 1]" so as to keep the context you need, but allow your readers to 
focus on the primary information in each checkpoint.

20. The use of some terms from WCAG, such as "perceivable," is not clear in 
the context of ATAG. To the extent that these terms are being used in the 
same way as they are in WCAG -- which it mainly appears that they are, 
except the fourth one where the term has apparently changed to 
system-friendly -- they should be re-explained for this document. Consider 
adding a new section (up front, or in higher level document) that explains 
the use of these terms for this document.

21. Editorial suggestion:
* /TR/ATAG20 is a formal Technical Specification/W3C 
Recommendation/Standard that is stable and referenceable. Keep it simple 
and succinct. Generally, include in /TR/ATAG20 only what is important for 
the actual technical specification. Move the supporting information to 
other documents, and in /TR/ATAG20 briefly mention the topics, and then 
point to the external documents.
- Examples:
"These guidelines have been written to address the requirements of many 
different audiences, including, but not limited to: policy makers, 
technical administrators, and those who develop or manage content. An 
attempt has been made to make this document as readable and usable as 
possible for that diverse audience, while still retaining the accuracy and 
clarity needed in a technical specification."
"As an introduction to accessible authoring tool design, consider that the 
authors and end users of Web content may be using the tool and its output 
in contexts that are very different from that which may be regarded as 
typical. For example, authors and end users may:... have a text-only 
display, or a small screen.",
"In addition, following the guidelines provides benefits for authors and 
end users beyond those listed in these various disability-related contexts. 
For example, a person may have average hearing, but still require captions 
for audio information due to a noisy workplace. Similarly, a person working 
in an eyes-busy environment may require an audio alternative to information 
they cannot view."
- Rationale:
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 the need for repetition across documents, and 
the potential for that information to get out of synch.
- Note:
Shawn submitted a similar comment on WCAG 2.0:
- http://lists.w3.org/Archives/Public/public-comments-wcag20/2006Jun/0224



-- 
Judy Brewer    +1.617.258.9741    http://www.w3.org/WAI
Director, Web Accessibility Initiative (WAI), World Wide Web Consortium (W3C)
MIT/CSAIL Building 32-G526
32 Vassar Street
Cambridge, MA,  02139,  USA

Received on Tuesday, 24 April 2007 22:28:53 UTC