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

Hi,

As today is the last day for comments on ATAG 2.0 and we will be meeting 
with WCAG at 4pm 
(http://lists.w3.org/Archives/Public/w3c-wai-au/2006OctDec/0033.html) I 
thought it would be a good time to respond to Becky's comments.

Due to the number and substantiveness of the comments I've decided to 
place the comments and my responses in our comment response table 
format. REMEMBER: this is my proposal for responses - the group will 
need to take a look at each to craft our official responses.

Cheers,
Jan



Becky Gibson wrote:
> 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
> 
> 
> 

-- 
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