RE: Comment on ATAG 2.0 Last Call

Hi all,

More initial comments (marked JR). Disclosure: Greg has the office next to me and dropped by for clarification a couple of times during his review.

BTW: I don't mean my comments to be the only ones. I encourage all WG members to send their thoughts on these as they come in. 


> -----Original Message-----
> From: Greg Gay [mailto:greggay@rogers.com]
> Sent: August 30, 2010 2:03 PM
> To: public-atag2-comments@w3.org
> Subject: 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".

JR: Agreed.

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

JR: Maybe "()" instead?


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

JR: I think there are still possibilities for gathering info from users in an automated way. An idea I discussed with Greg would be to change the handle on the SCs to "Assist Accessibility Repair" so that readers are less likely to immediately think of "Repair tools". 


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

JR: Wording is meant to be general...the more specific details are dealt with later.


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

JR: ATAG2 is not requiring it. In fact, it's meant to address the opposite problem - over-enthusiastic 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.

JR: Maybe we can tweak this to be more clear that we need the mechanism (e.g. metadata of some kind) in place, whether or not the user has used it for any particular piece of pre-authored content.


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

JR: It definitely makes sense to clarify the distinction between what the developer provides and what is submitted by other users.


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

JR: I agree it's an issue, but out of scope.

Cheers,
Jan

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




-- 
(Mr) Jan Richards, M.Sc.
jrichards@ocad.ca | 416-977-6000 ext. 3957 | fax: 416-977-9844
Inclusive Design Research Centre (IDRC) | http://inclusivedesign.ca/
Faculty of Design | OCAD University

Received on Monday, 30 August 2010 19:49:12 UTC