Comment on ATAG 2.0 Last Call

A quick review and comments on ATAG 2,0 draft  July 8, 2010

------------
ATAG 2.0 Review

Guidelines Part A  Applicability Notes #2
 "(e.g. if an image in the content lacks a label)" may be confused since
labels in HTML, refer to a component of a form. Perhaps use "e.g. image
in the content lacks a text alternative".

Part A

Guideline A.1.1 et al "[For authoring tool user interface]" the square
brackets could potentially create confusion, given ATAG is aimed
primarily at a developer audience. For developers the square brackets []
generally represent optional values. Parentheses would be less likely to
be confused.

Part B
Applicability Notes: #3
"...and repair tools" repair tools are in most cases only relevant to
static Web sites. These days the vast majority of sites are dynamically
generated. Perhaps drop the words "and repair." A "repair tool"
generally infers some form of automated fixing of HTML. Do such tools
exist in todays world of dynamically generated Web site? APrompt was
one, but it is no longer usable in the "repair tool" sense. 

B1.1.1 (2/3) wording may be too general. E.g. one could use a tool to
create WCAG  conforming content (if they don't use the table editing
features, or don't use the insert Flash feature, for instance). Perhaps
add language to include "all" editing functions produce conforming content.

B2.4.2 Automated Suggestions may be too complex to implement in an
authoring tool to be a Level A requirement. I see this more as an
advanced feature. In terms of Level A "must does" automated suggestion
is nice to have, but not a necessary requirement for creating accessible
content. If I were an authoring tool developer, I might see this
requirement as too strict. This might be a Level AA requirement. B2.4.2
and B2.4.4 would be implemented together. B2.4.4 would be implemented
first, to provide the reusable suggestions that would then provide data
for automated suggestions.

B2.5.6 Pre-Authored Content: Also see B2.5.8 below - Who decides on the
accessibility status of pre-authored content, which may be user
provided. In note (a) the words "Indicate" and "if known" provides a
loophole that would allow tools to ignore this guideline. If none of the
pre-authored content is reviewed for accessibility, developers can pass
this requirement by omitting the accessibility status.

B2.5.8 Pre-Authored content in a repository is generally user provided,
as opposed to developer provided.  Should there be a distinction here
between what the system provides, and what is provided by others?
Perhaps distinguished in a way similar to the incompleteness of
templates in the note for B.2.5.9. A definition of
"pre-authored-content", might also be provided here, distinguishing it
from templates.

Conformance claims: Is there going to be a Conformance Claim program to
validate claims made by developers, and by others representing authoring
tools? ATAG differs from WCAG in claims made in that WCAG is easily
checked with a variety of tools to confirm conformance claims. Such a
tool does not exist to confirm ATAG conformance claims. Experience with
the claims process for another standards organization I'm involved with,
raises questions about the "honesty" of claimants, or perhaps the
"scope" of a particular claim that omits points of failure. Self-claims
are easy to make, but they don't hold much clout, and they can easily
deceive or mislead potential users. As a purchaser of an ATAG conformant
authoring tool, I'd want something more than a self-claim.  A dishonest
developer could potentially have a competitive advantage over an honest
one.  Perhaps there should be a distinction between self-reported
compliance, and W3C (or another granting body) endorsed compliance. Or,
perhaps setup something that legally binds a claimant, such as
submitting a claim through a central, perhaps W3C, claims site, where
they must agree to a legal statement before making a claim. This would
discourage invalid claims, and potentially provide recourse in the event
that a fraudulent (or less than complete) claim is made to the detriment
of other developers or users of an authoring tool.




-- 
Greg Gay
Project Manager
Inclusive Design Research Centre
OCAD University
416 977-6000 #3956

Received on Tuesday, 31 August 2010 07:38:45 UTC