Initial feedback: IBM review of ATAG

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

   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.
   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.
   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..."
   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.
   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.
   8. Guideline B.3.3; Documentation of authoring tool support for
      production of accessible content should be provided in an accessible
      format.

Sueann Nichols

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