Re: Initial feedback: IBM review of ATAG

Hi Sueann,

Thanks so much for sending in these comments. I think it makes sense to 
get a good start on them before the PF comments arrive. My comments are 
marked with JR below.

Sueann Nichols wrote:
> Below is the feedback to date. Several people I have asked to review the 
> document have not completed their review and have asked for an extension.
> 
> *General / global comments*
> 
>       1. *Applicability to Mobile devices* ATAG 2.0 is written to be
>       technology agnostic. Is there value is reminding the reader in the
>       document that it applies to mobile devices as far as web
>       applications are accessed through mobile browsers? For example,
>       this might be appropriately added in the _definition of web
>       content_
>       <http://www.w3.org/TR/2009/WD-ATAG20-20091029/#def-Web-Content-Technology>

JR: Mentionning mobile devices is good idea. The definition of web 
content, however, was worked out in conjunction with WCAG-GL and UAWG so 
I'd prefer not to change it if possible. How about adding a new example 
under "Examples of authoring tools:" in the glossary definition of 
"Authoring Tool": "software for creating mobile web applications"

>       2. *Repair assist* It appears to me from reading that ATAG
>       requires checking and repair options for all WCAG checkpoints. I
>       wonder if this is intended to be fully encompassing. There are
>       checkpoints that are very difficult to automate detection and even
>       harder to automate repair. For example, the recognition that color
>       is being used without alternate form, is very difficult to
>       automate. I'm just checking that the intent is that all
>       checkpoints are checked. 

JR: The relevant success criterion (B.2.3.1) includes this note, to make 
clear that the assistance can be manual rather than automated (e.g. 
documentation): While automated repair assistance or more advanced 
implementations of semi-automated repair assistance may improve the 
authoring experience, manual repair assistance is the minimum 
requirement to meet this success criterion (as well as success criteria 
B.2.3.2 and B.2.3.3).

> *Section specific comments*
> 
>       1. *Abstract; Introduction.* Suggest adding hyperlink to
>       "Implementing ATAG 2.0" at first reference in each section. As it
>       stands, several references are made in these sections, but the
>       first hyperlink is not provided until the Guidelines section, and
>       then only in the Guideline A.1.1 box – not obvious to identify or
>       find.

JR: Agreed - editorial correction.

>       2. *PART A, Guideline A.1.2* The link provided "Implementing
>       A.1.2" is incorrect. It links to
>       "http://www.w3.org/TR/2009/WD-IMPLEMENTING-ATAG20-20091029/#gl-Web-based-accessible",
>       which is the same link as "Implementing A.1.1" I believe it is
>       intended to link to:
>       "http://www.w3.org/TR/2009/WD-IMPLEMENTING-ATAG20-20091029/#gl-non-Web-based-accessible"

JR: Agreed - editorial correction.

>       3. *Guideline A.3.1* This guideline is worded "Enhance keyboard
>       access to authoring features." The word enhance infers to me that
>       this is an extended enhancement beyond minimal. I believe the
>       intent is to require keyboard access for all function. I suggest
>       wording such as, "Ensure keyboard access..." or "Provide keyboard
>       access..." be considered.

JR: The reason is that keyboard access is often a core component of 
"accessibility standards and/or platform conventions that support 
accessibility" that must already be followed as per success criterion 
A.1.2.1.

>       4. *Guideline A.4.2 ... Document the user interface* The
>       documentation should be provided in at least one accessible
>       format. Perhaps this is obvious to the reader, but I don't see
>       this stated in the /TR Draft/ or the /Implementing/ document. I
>       would hate to see someone weasel out of it.

JR: We have this text already "See Also: The accessibility of the 
documentation is covered by Guideline A.1.1 and Guideline A.1.2." In 
addition, I suggest:

(1) rewording the "Applies to Features for Part B:" applicability note 
to read:
Features for meeting Part A must be accessible: The Part A success 
criteria apply to the entire authoring tool user interface, including 
any features added to meet the success criteria in Part A (e.g., 
documentation, search functions, etc.).

(2) Reword A.4.2 Rationale: Some authors may not be able to understand 
or operate the authoring tool user interface without proper ACCESSIBLE 
documentation.

(3) Adding text to the example: "The documentation includes..."->"The 
documentation conforms to WCAG and includes"


>       5. *PART B; Existing Technologies* Please check the wording of
>       this section. Something appears to be extra/missing/erroneous:
>       "The Part B success criteria /in only apply/ to support for
>       production of web content..."

JR: Editorial. "The Part B success criteria in only..."->"The Part B 
success criteria only..."

>       6. *Guideline B.1.2; Rationale* Please double check that the
>       wording selected covers retaining accessible information that
>       comes from a non-web source. For example, the headings and
>       alternate text in a non-web word editing document that is output
>       to HTML. Please see related comments about the /Implementing/
>       document, that the intent wording seems to limit the intent only
>       from /web/ transformed to /web/.

JR: I suggest: "Rationale: Accessibility information is critical to 
maintaining comparable levels of web content accessibility..."->
"Rationale: Accessibility information is critical to maintaining 
comparable levels of accessibility..."

>       7. *Guideline B.2.2; B.2.2.4 Help Authors Locate* This may seem
>       obvious, but it might be useful to state that it should be located
>       or indicated in an accessible manner. Tools often highlight
>       problems. This is sometimes accessible only to the sighted.

JR: I'd prefer not to have to add "in an accessible manner" to each 
success criterion. Maybe instead we could add a new normative 
applicability note for Part B to read:
Features for Part B must be accessible: The Part A success criteria 
apply to the entire authoring tool user interface, including any 
features added to meet the success criteria in Part B (e.g., checking 
tools, repair tools, tutorials, documentation, etc.).

>       8. *Guideline B.3.3;* Documentation of authoring tool support for
>       production of accessible content should be provided in an
>       accessible format.

JR: See above.

Cheers,
Jan


> 
> Sueann Nichols
> 
> 877-202-9272 (t/l) 930-0636
> ssnichol@us.ibm.com
> IBM Human Ability & Accessibility Center
> http://www.ibm.com/able

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

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

Received on Friday, 4 December 2009 20:50:49 UTC