Comment on the The December 7, 2006 Working Draft of ATAG 2.0

Comments on the December 7, 2006 Working Draft of the Authoring Tool 
Accessibility Guidelines 2.0 (ATAG 2.0)


I like the organization of the requirements into parts A and B to address 
the user interface and the generated content.

I have some concerns about the use of examples in parentheses within the 
Success Criterion (SC)  text.  While it is helpful to understand what the 
SC is about, I think it sometimes narrows the definition.  Just food for 
thought. 

It is nice to see the same definitions of terms shared with WCAG.

I'm not sure how A.0.1 fits into the organizational scheme?   From reading 
above about how the guidelines are organized it implies that checkpoints 
are associated with Guidelines?  But A.0.1 is not associated with a 
Guideline - is that the point of using a A.0 designation?  I originally 
just assumed that you were using a zero based numbering scheme but then I 
scrolled down and noticed that Part B begins with a Guideline and the 
numbering starts at B.1.  I think that the positioning of A.0.1 needs to 
be clarified.

For A.1.3 shouldn't there be a requirement that the authoring tool 
provides a mechanism to use the operating system display /audio selections 
(let the platform control the settings)?  The requirement is there that 
the user must be able to select the same settings in the tool but it would 
be nice to have an option for automatically using the platform settings 
This would avoid users having to modify the tool to match the operating 
system display settings.  I see that this is covered in the technique 
section.  Perhaps it is standard practice in most operating systems to 
rely on the platform settings as the default settings that the ATAG group 
doesn't feel this needs to be made a requirement?

A.1.5 - I'm not sure what a "semantic description" is.   There is an 
example in SC 3 but an example for SC 2 would also be helpful - what is a 
semantic description of coloring misspelled words?

A.2.1 - should there be something about supporting platform accessibility 
options for keyboard access (sticky keys and such?). 
SC 4 is setting a very high bar for web-based authoring tools.  For 
example, I'm not sure how I would implement going to the beginning / end 
of content within a rich text editor component on the web   Undo/redo is 
also particularly difficult on the Web.  I'm not disagreeing that this 
should be a requirement but it does make it highly unlikely that a web 
based authoring tool would ever achieve compliance with ATAG (at least in 
the near future on more than one user agent). 
SC 5 may be particularly difficult for Web based authoring tools.  I guess 
if they don't provide any additional, selectable keyboard functionality 
then there is no need to save the preferences. 

A.2.4  SC 1a - the author must be able to disable the flashing before it 
occurs. 
This technique does not seem sufficient:
Technique A.2.4-1.1 [Sufficient for (a)]: If flashing begins, providing a 
single input action that stops the flashing immediately and for at least 
the rest of the session. 

What if  the flashing generates a seizure before the user can perform the 
single input action? How would the user know what the single input action 
is?  I think a more appropriate technique would to warn the user of 
flashing content and provide a mechanism to disable it before it begins.

I don't understand this technique:  Technique A.2.5-1.3 [Advisory]: If 
loops are possible within the structured element set, providing a 
mechanism for alerting the author when they have completed a loop.  An 
example would be helpful.

A.3.3 SC1 - Why must a non-web based authoring tool provide web based 
documentation?   Just because the tool creates Web content, I don't see 
why it must provide documentation in a Web based form.  The SC does say 
that it doesn't have to be located on-line but if it must conform to WCAG 
then it would have to be Web content. This seems too restrictive.  A 
non-web based authoring tool should be able to provide accessible non-web 
based documentation.  I am guessing that this is mandated in order to have 
a guideline to judge the accessibility of the documentation against but I 
think conforming to Part A of ATAG would be sufficient. 

A.4.1 SC 2 is very confusing.   Even after looking at the techniques I 
have no idea what I am supposed to "publish"?  It sounds like, as an 
authoring tool author, I am supposed to document how I implemented the 
accessibility API.  Part A seems to require that I document what level of 
accessibility api I have implemented.   Part B seems to just be asking me 
to implement the accessibility API for each element which can receive 
focus.  And Part C is again asking the author to document the level of 
support for the accessibility API. The techniques for this didn't help 
clarify as it is just,  "  Implementing the relevant accessibility 
platform architecture(s), such as:", and is incomplete. A.4.1 SC2 really 
seems to fall under A.4.2 ? 

I have concerns with reliance on the "content-type-specific WCAG benchmark 
document" in the checkpoint and success criteria text.  Since the 
definition indicates that the WCAG techniques document for a particular 
content -type meet this requirement.  But, the WCAG techniques are 
informative and there are not necessarily techniques for every WCAG 
success criteria for every content-type.  Where would the general WCAG 
techniques fit in?   There are many HTML techniques but many fewer for CSS 
and scripting.   What if someone creates a tool that uses ARIA (Accessible 
Rich Internet Applications from the WAI Protocols and formats group) 
techniques when creating content? There are currently very few WCAG 
scripting techniques to support ARIA.   Since there are some techniques is 
there a sufficient content-type-specific WCAG benchmark document"?   I 
think this needs further description / clarification.  Also, currently 
WCAG does not publish the techniques for different content-types in 
separate documents.

Checkpoints B.1.4 and B.1.5 seem almost impossible to achieve.  The note / 
exception about requiring accessibility information from the author helps. 
 I can live with these but they will be very difficult to meet in non-web 
based tools  and virtually impossible in web-based tools (although Web 
based tools will meet this by not implementing automatic generation). 

Example B.1.5.1.4 doesn't seem realistic. There may be cases where the alt 
text can not be determined until the image is used. 

Not exactly sure what this is trying to say - there are extra words or 
tense issues:   Technique B.1.5-1.4 [Advisory]: Ensuring that equivalent 
alternatives provided for pre-authored content are usable compatible with 
features to manage, editing, and reusing equivalent alternatives 

Nice section on providing prompting!  I was nervous when I first read the 
SC that said prompting was required (I really hate overly restrictive 
prompting) but the techniques document helps to clarify. 

B.2.1 SC 2 item B - I think you mean, "inform the author that  NOT 
following the instructions would lead to Web content accessibility 
problems."  I added the word "NOT" in front of the word "following". 

Regarding:  B.2.2 SC 1: An individual check must be associated with each 
requirement in the content type-specific WCAG benchmark document (i.e., 
not blanket statements such as "does the content meet all the 
requirements"). 
The content type specific WCAG benchmark has been defined as a WCAG 
techniques document - the techniques documents are not requirements so 
this SC doesn't make sense.  I think this revolves around my confusion of 
what exactly is a content-type-specific WCAG benchmark document?

Must an authoring tool provide its own accessibility checking? I think it 
should be allowed to work with a separate tool.  Also, when content is 
auto-generated from server side languages, it is often very difficult for 
the tool to test for accessibility problems.   If I can create a page 
using JSP, is the tool that allows me to enter the JSP tag required to 
interpret the tag code and know that it will be inserting an image and 
that there is no alt text?   This entire checkpoint seems overly 
restrictive as currently worded.  This is fine for simple HTML generation 
tools but becomes much more complicated for more advanced tools that use 
JSP, JSF, PHP, etc. 

This example of automated checking doesn't appear to meet the ATAG 
guidelines since information is conveyed using color.  You may want to 
include a statement that the accessibility problems can also be determined 
in some other manner in addition to just the blue font. 
Example of Automated Checking (3): This illustration shows an authoring 
interface of an automated check in a code-level authoring view. The text 
is: "<body><p>Image:</p><img href="pic123.gif"/><hr/><blink>Blinking 
text</blink></body></html>".In this view, the text of elements with 
accessibility problems (img and blink) is shown in a blue font, instead of 
the default black font. (Source: mockup by AUWG)

B.3.1 SC 1 is confusing:  "When the author has more than one authoring 
option for a given task (e.g., emphasizing text using semantic markup 
rather than inappropriately using header markup), then any options that 
conform to WCAG must have equal or higher prominence than any options that 
do not.  "
 Header markup is semantic markup so I think this needs clarification. 



Becky Gibson
Web Accessibility Architect
                                                       
IBM Emerging Internet Technologies
5 Technology Park Drive
Westford, MA 01886
Voice: 978 399-6101; t/l 333-6101
Email: gibsonb@us.ibm.com

Received on Wednesday, 3 January 2007 21:47:20 UTC