W3C home > Mailing lists > Public > public-atag2-comments@w3.org > March 2009

ATAG 2.0 comments

From: <Anna.Zhuang@nokia.com>
Date: Tue, 17 Mar 2009 08:57:45 +0100
To: <public-atag2-comments@w3.org>
Message-ID: <D1E1C1C072023846AC4A55088BAA4B03309A48CFB1@NOK-EUMSG-04.mgdnok.nokia.com>
Dear ATAG WG,

I have a few comments to the ATAG working draft.


In the Introduction section, second paragraph after the first two bullets: "As ATAG 2.0 guides authors in complying to WCAG 2.0, similar to the constraints of WCAG 2.0, even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability ..." --- "will not be accessible" is a very strong statement provided that  "individuals with all types, degrees, or combinations of disability" is something hard to be precisely measured. I suggest you say "may not be fully accessible" or something along these lines.
Introduction, definition of authoring tool, Notes on Definition, point 2: "if the tool archives as Web content". --- What does that mean? The tool itself is archives as web content? Can you make it more clear in the text.
Organization of the ATAG 2.0 document, Part A, point 4:  "Authors with a wide range of abilities must be able to understand the user interface functions and components that they can perceive and operate. " --- wide range of abilities normally means a smart and capable person. The document however addresses humaan disabilities and limitations. So it is better to say at least "a varying range of abilities" or something along these lines.
 Organization of the ATAG 2.0 document, Part B, point 2: "Actions may be taken at the author's initiative that may result in accessibility problems<l>."  --- There are two sides of the story. Author might conciously select a "technique" that is inherently not accessible and on the other hand author may do so because he lacks accessibility knowledge. The document should address both cases.
Organization of the ATAG 2.0 document, Part B, point 3:  "Authoring tools should encourage the author's awareness and discovery of tools, features, ..." --- Tool should encourage discuvery of tools??? Please elaborate on this or simply remove the second instance of tools from the sentence.
Organization of the ATAG 2.0 document, Success Criteria --- the first paragraph does not explain how ATAG 1.0 c hecpoints corespond to ATAG 2.0 success criteria. Should they relate at all? Or should ATAG 2.0 reader forget ATAG 1.0 doc alltogether? Think of tool developers who already have experience in implementing ATAG 1.0 and want to update the tool to ATAG 2.0. I also don't feel the bridge between ATAG 2.0 and WCAG 2.0 is very well built.
Levels of conformance --- you end up having lots of redundant text and also partial conformance is not well explained. How about you restructure this section and first explain that there are different types of conformance: full and partial. Then explain what is full conformance, meaning both part A and part B requirements must be satified, then have 3 points for level A, AA, AAA of full conformance explained. Next explain what is partial conformance for Part A and have 3 points there, next explain wehat is partial conformance for Part B and have 3 points there. Also, WCAG 1.0 had rather handy text explaining what A, AA, AAA conformance mean to the end user: impossible to use, hard to user, somewhat difficult to use. For some reasons WCAG 2.0 lacks this text. You may wish to explain all 6 points of partial conformance in terms of the end user experience. This is important because this gives tool developers a good level of human perception of what he wants to achieve in the end. Dry requirements don't give such simple picture.
It might be good to mention part A and part B purpose in the bullet list just before ATAG guidelines section.
ATAG 2.0 guidelines, Part A, scope, end of the first sentence: Are you talking about tool developer or web content developer who is tool user. Be careful with the word "developer" in this document as it means two different things. If it is a tool develoiper better to state it clearly in the spec.
All guidelines in Part A have unnecessary text in []. Consider removing [For the authoring tool UI]. You don't have such explanation in Part B guidelines. This is self evident from the scope of Part A and if it is not, you need to make it evident on the high level and not repeat it with each guideline.
Guideline A1.1: Please elaborate more on web based functionality.
Guideline A1.2 Please give better explanation of non web based functionality
Both guidelines A1.1 and A1.2 refer to WCAG but not in any specific way. Should it be stated more clearly that e.g. all WCAG requrements applicable to a given tool UI needs to be met.
You have a big chuynk of copy pasted text in A1.2.1-A1.2.3. can you avoid redundancy?
Principle A2 and A3, you have bullet list that is also organised alphabetically. Why so? Perhaps you better remove the bullets and leave alphabetic ordering only.
Best regards,
Anna Zhuang
Received on Tuesday, 17 March 2009 07:59:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 17 March 2009 07:59:31 GMT