Re: EOWG comments on ATAG 2.0 Working Draft of 7 December 2006

Judy,

Please thank the EOWG for their constructive comments.

I have added them to our comment list at:
http://www.w3.org/WAI/AU/2007/atag20_pubWD_7dec2006_comment_responses.html

And to members of AUWG, see you at the F2F tomorrow.

Cheers,
Jan




Judy Brewer wrote:
> 
> 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
> 
> 
> 

-- 
Jan Richards, M.Sc.
User Interface Design Specialist
Adaptive Technology Resource Centre (ATRC)
Faculty of Information Studies
University of Toronto

   Email: jan.richards@utoronto.ca
   Web:   http://jan.atrc.utoronto.ca
   Phone: 416-946-7060
   Fax:   416-971-2896

Received on Wednesday, 25 April 2007 01:27:19 UTC