[Fwd: ATAG review]

Hi all,

Here are the raw comments that Cynthia is bringing to PF for
discussion (as opposed to PFs official comments).

Cheers,
Jan


-------- Original Message --------
Subject: 	ATAG review
Date: 	Fri, 11 Dec 2009 00:27:27 +0000
From: 	Cynthia Shelly <cyns@microsoft.com>
To: 	W3C WAI Protocols & Formats <w3c-wai-pf@w3.org>
CC: 	Jan Richards <jan.richards@utoronto.ca>, "jeanne@w3.org"
<jeanne@w3.org>



Here's my review of ATAG 2.0, for discussion in PF.



I read the ATAG document itself thoroughly, and the parts of the
glossary I needed to read to understand the document.  I skimmed the
rest of the glossary and the implementation guide.



In general, I think it's quite good, and a significant improvement over
ATAG 1.0.



Part A

Applicability Notes

·         Mentions of " image label."  Shouldn't that be "text
alternative" instead?



A.1.2

I'm glad to see that there is now a single success criterion for
non-web, instead of trying to map non-w3c specs to WCAG levels.



A.3.1.2 Drawing Keyboard Access

*Note 2:* This success criterion should not be interpreted as
discouraging mouse input or other input methods in addition to keyboard
operation.

It seems like this note applies to all of A.3.1 Keyboard, not just drawing.



A.3.1.3 Avoiding Content Keyboard Traps

The word "Avoiding" is problematic.  Some people think it means "don’t
do," and others think it means "try not to do."  This was a frequent
source of confusion in WCAG 1.0, and WCAG 2.0 avoids (sorry, couldn't
resist) the word.  Instead use "No Content Keyboard Traps" or "Prevent
Content Keyboard Traps".



A.3.1.5 Keyboard Shortcuts

To what?  Key functionality?  Every possible function? How many are
enough?  This needs more detail to be testable.



A.3.1.6 Drawing Keyboard Access (Enhanced)

Should the AAA one require direct access, rather than also allowing
indirect access by editing properties?  I agree this makes sense for A
and AA, but should it go all the way for AAA?



A.3.2.1 Data Saved

Note: For web-based authoring tools, this applies to any web content
that has already been submitted to the server by the user agent.

I wonder if it would make sense to have a AAA SC that provides for
automatically submitting content in such a system?



A.3.5.1 Text Search: The author(s) can perform text searches of web
content in which all of the following are true: (Level AA)

(a) Search All Editable: The search can be within any information that
is text and that the authoring tool can modify (e.g., text content, text
alternatives for non-text content, metadata, markup elements and
attributes, etc.); and



Does "The search can be" mean "The search MUST be" or "The search MAY be"?



Note: If the current editing view is not able to display the results of
a search then the authoring tool may switch to a different editing view
to display the results (e.g., to a source content editing view to
display search results within markup tags).

I would hope that the authoring tool won't do this automatically, as
that could be quite unexpected and jarring.  Perhaps this should say
that the authoring tool could provide a mechanism for the author to switch?



Guideline A.3.6 [For the authoring tool user interface] Manage
preference settings

Should there be an SC for honoring operating system settings for
keyboard and display?

Alternatively, perhaps both honoring OS settings, and saving keyboard
and display settings, are general software issues, and not specific to
authoring tools?



A.3.7.2 Preview: If a preview is provided, then at least one of the
following is true: (Level A)

•(a) Existing User Agent: the preview makes use of an existing user
agent that is specified in the conformance claim (e.g., opening the
content in a third-party browser, browser component, video player, etc.); or

I think that sometimes previews are done with the default browser on the
system.  How would that be handled in the conformance claim?



A.4.1.3 Undo is Reversible: Authors can immediately reverse the most
recent "undo" action(s). (Level AA)

Add "This is sometimes called 're-do' ".



Part B

Responsibility After Authoring Sessions: Authoring tools are not
responsible for web content accessibility problems that result from
carrying out instructions made by authors during authoring sessions
(e.g., the content of a third-party feed specified by the author).
Authoring tools are responsible if the web content accessibility
problems are automatically generated (e.g., when the developer of a
content management system updates its site-wide templates).

This paragraph is a little hard to parse.  I don't have immediate
editorial suggestions, but I had to read this 3 times before I got it.



Guideline B.1.1 Support web content technologies that enable the
creation of content that is accessible

The SC here are about being able to produce WCAG compliant content.  It
doesn't talk about supporting Web technologies with Accessibility
Supported Uses.  If the guideline is about WCAG, it should say that.  If
it's about support of accessibility-enabling technologies, it should
have SC about that.  Perhaps both are needed?



B.1.2.2 End Product Cannot Preserve Accessibility Information

An example would be nice here.  (e.g. saving a structured graphic to a
raster image format)



B.2.1

Why is there a line between B.2.1.1 and B.2.1.2 when both are A?



B.2.2.1 Check Accessibility (WCAG Level A): At least one individual
check is associated with each WCAG 2.0 Level A Success Criterion that
the authoring tool has the functionality to modify web content to meet
(e.g., an HTML authoring tool that inserts images should check for alt
text; a video authoring tool with the ability to edit text tracks should
check for captions). (Level A)

Note: While automated checking or more advanced implementations of
semi-automated checking may improve the authoring experience, manual
checking is the minimum requirement to meet this success criterion (as
well as B.2.2.4 and B.2.2.10).



How does a tool create a manual check?  I know what it means for an
author to do this, but I can't figure out what it would mean for a tool
to do it.



B.2.2.4 Help Authors Locate: For any checks that require author judgment
to determine whether a potential web content accessibility problem is
correctly identified (i.e., manual checking and semi-automated
checking), the relevant web content is identified (e.g., displaying the
web content, displaying line numbers, etc.) (Level AA)



Maybe this should be A?  It's not very useful to know that there's an
error somewhere, if you don't know where.  I'd make automatically taking
the author to the line in question AA.



B.2.2.8 Metadata for Discovery: If the authoring tool records the
accessibility status of web content, then authors have the option to
associate this status with the web content as metadata to facilitate
resource discovery by end users. (Level AA)

Do any authoring tools do this now?  This seems far less important, and
far less proven, than B.2.2.4, yet they're the same level.  I'd make
this AAA.



B.2.3.1 Repair Accessibility (WCAG Level A): For each WCAG 2.0 Level A
web content accessibility problem that is identifiable during checking
(required in Guideline B.2.2), repair assistance is provided. (Level A)

Note: 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).

I'm not sure I agree that automated repair improves the user
experience.  Authors generally HATE it when tools change their content
automatically.



See also: This guideline applies when non-text content is specified by
the author(s) (e.g., an author inserts an image). When non-text content
is automatically added by the authoring tool, see Guideline B.1.3.



B.2.4.1 Editable: Authors are able to modify alternative content for
non-text content. This includes types of alternative content that may
not typically be displayed on screen by user agents. (Level A)

I think this applies when text alternatives are automatically generated
too.  One good approach to text alternatives is to generate them, and
then expose them to author to edit or tweak.



B.2.4.2 Automated suggestions: During the authoring session, the
authoring tool can automatically suggest alternative content for
non-text content only under the following conditions: (Level A)



•(a) Author control: authors have the opportunity to accept, modify, or
reject the suggested alternative content prior to insertion; and

•(b) Relevant sources: the suggested alternative content is only derived
from sources designed to fulfill the same purpose (e.g., suggesting the
value of an image's "description" metadata field as a long description).



These should be OR, not AND.  Providing a suggestion based on something
like the file name is often a good starting point to get authors to put
in something better.  If the author has the opportunity to change it,
then the tool developer should be able to decide as part of his design
work what sources are appropriate in a particular authoring scenario.



Guideline B.2.5 Assist authors with accessible templates and other
pre-authored content

This needs SC about other pre-authored content, particularly controls.

Add a AAA about making the default template accessible?



Guideline B.3.1 Ensure that accessible authoring actions are given
prominence

Add a AA or AAA about accessible options being MORE prominent than
inaccessible ones?



Why does B.3.1 emphasize prominence, while B.3.2 emphasizes
availability?  B.3.2's rationale talks about prominence in addition to
availability.



Guideline B.3.4 Ensure that any authoring practices demonstrated in
documentation are accessible

Should specifically mention sample code and sample apps, as these are
frequently not accessible, and authors cut and paste from them.



Conformance

What about mixed level conformance?  For example, if a tool is AA on
part B, but only A on part A?



Implementation Guide

General:  more whitespace around the boxes for the intent and examples
would make it easier to read.  Maybe shade these sections too?  It was a
little hard to figure out what parts were different than the main ATAG
document.



Similarly, it would be nice if it was easier to find the beginning of
each SC.  Perhaps making the Implementing Success Criterion x.x.x
heading larger, and putting more vertical whitespace before it?  I also
noticed that these aren't real headings (<h1>-<h6>).  They should be.



A.1.2

A link to the ISO software standards for accessibility would be good, or
at least to a non-fee summary of it if there is one.



Implementing Guideline A.3.4 [For the authoring tool user interface]
Enhance navigation and editing via content structure

It might be good to add a note that these sorts of keyboard
optimizations are often very much appreciated by power users, whom one
would expect in large numbers among certain types of web authors.



B.1.1 doesn't answer my question about what meeting WCAG has to do with
Support web content technologies.   It certainly does have to do with
the creation of accessible content.



B.1.2.2 need an example of when accessibility info can't be preserved.
Maybe saving to .jpg?



Appendix A

(15) onclick IS device independent in all implementations I'm aware of.
The word doesn't sound like it, but it does work.










-- 
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 Monday, 14 December 2009 15:04:31 UTC