Re: [Fwd: ATAG review]

Here are some possibilities for handling Cynthia Shelly's comments (JR:):

Jan Richards wrote:
> 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.

JR: Nice to hear. :)


> Part A
> 
> Applicability Notes
> 
> ·         Mentions of " image label."  Shouldn't that be "text
> alternative" instead?

JR: Agreed.


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

JR: Agreed. But things get repetitive...so what if we moved it up into a 
section under Rationale for the whole Guideline called "Remember:" or 
something similar:

"Remember: This guideline and its success criteria should not be 
interpreted as discouraging mouse input or other input methods in 
addition to keyboard operation."

PLUS we could convert the "See Also" sections that appear elsewhere into 
"Remember".

AND maybe we could bring the reminders about manual checking and repair 
up to that level too since it is so important that readers notice those.


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

JR: I suggest: "No Keyboard Traps" - this is in synch. with the current 
draft of UAAG 2.0.
(http://www.w3.org/WAI/UA/2009/ED-UAAG20-20091105/#principle-operable)


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

JR: UAAG 2.0 uses this wording:
4.1.8 Important Command Functions: Important command functions (e.g. 
related to navigation, display, content, information management, etc.) 
are available using a single or sequence of keystrokes or key 
combinations. (Level AA)

JR: Plus they have this requirement which is quite useful:
4.1.12 Present Direct Commands in User Interface: The user has the 
option to have any direct commands (e.g. keyboard shortcuts) in the user 
agent user interface be presented with their associated user interface 
controls (e.g. "Ctrl+S" displayed on the "Save" menu item and toolbar 
button). (Level AA)


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

JR: Agreed and perhaps both. I think property pages might be more usable 
for some users with disabilities (e.g., people using screen readers), 
whereas more direct manipulation would probably be more usable by others 
because the user only needs to focus on one place on the screen.


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

JR: I'm ok with a Data Saved (Extended) Level AAA.


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

JR: Suggest "The search can be within any information that is text and 
that the authoring tool can modify"=>"Any information that is text and 
that the authoring tool can modify is searchable."


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

JR: Maybe in the Intent we could make this point....e.g. The intent of 
the Note attached to "(a) Search All Editable" is to clearly allow the 
authoring tool to present search results to authors in such a way that 
the searched-for information is immediately editable. Of course, 
unexpected changes of context can present accessibility issues, so 
accessible implementations will include some mechanism for informing 
authors that the editing view has changed."


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

JR: I think A.3.6 was formulated to make it easier for tools to simply 
respect the platform settings. I suggest we make this clear with this 
line in both Intent sections (A.3.6.1, A.3.6.2):
"The intent of limiting the success criteria to "the authoring tool 
controls (i.e., that are not controlled by the platform)" is exempt 
authoring tools that simply respect the Keyboard preference settings and 
Display settings of the platform.


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

JR: I agree that and suggest rewording=>
(a) Third-Party User Agent: the preview makes use of an existing 
third-party user agent; or

AND make this change to one of the examples:
A web-based authoring tool performs previews by opening the web content 
in a new tab or window of the author's default user agent.


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

JR: In the intent, reword=>"The intent of this success criterion is to 
ensure that an inadvertent "undo" can be reversed, which 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.

JR Suggest rewording=>Responsibility After Authoring Sessions: For 
*author-generated content*, authoring tools are only responsible for web 
content accessibility problems that are detectable during authoring 
sessions (e.g., the authoring tool is not responsible for the content of 
a third-party feed added by the author). The authoring tool is always 
responsible for content that it *automatically-generates* (e.g., when 
the developer of a content management system updates its site-wide 
templates).


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

JR: Doesn't the conform to WCAG wording cover that? Maybe it is 
something to clarify in the Intent?


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

JR: Agreed. Rewording=> "...conform to WCAG 2.0 Level A (e.g., saving a 
structured graphic to a raster image format), then..."


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

JR: Editorial. Will fix.


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

JR: If we follow the "Remember" idea above. PLUS add a clarification we 
might get:

Remember: While automated checking or more advanced implementations of 
semi-automated checking may improve the authoring experience, manual 
checking is the minimum requirement to meet success criteria B.2.2.1, 
B.2.2.4 and B.2.2.10. In Manual Checking the tool provides the author 
with instructions for detecting a problem, but does not automate the 
task of detecting the problem in any meaningful way. For more 
information on checking, see Implementing ATAG 2.0 - Appendix B: Levels 
of Checking Automation.


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

JR: OK


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

JR: Needs discussion.


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

JR: Working that in to a "Remember" section as above:

Remember: While certain types of 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 success criteria B.2.3.1, B.2.3.2 and B.2.3.3). In 
manual repairing, the tool provides the author with instructions for 
making the necessary correction, but does not automate the task in any 
substantial way. For more information on repair , see Implementing ATAG 
2.0 - Appendix C: Levels of Repair Automation.


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

JR: I think this gets covered pretty well in B.2.4.2 (a)


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

JR: I think that's what and implies. OR would mean mean the relevant 
source could be used but the author would not have control.


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

JR: I think this needs group discussion.


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

JR: I think this needs group discussion - due to the wording complexity 
this could introduce.


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

JR: B.3.2 is more about features of the tool, B.3.1 can be features of 
the web technology being edited.


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

JR: Agreed. Rewording => "...(e.g., markup, screen shots of WYSIWYG 
editing views, sample code and sample applications)..."


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

JR: That's OK.


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

JR: Agreed.

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

JR: Agreed.

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

JR: It's under "General Guides"...we could make it more visible.


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


JR: Agreed.


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


JR: Not sure what is meant here. The GL is "Support web content 
technologies that enable the creation of content that is accessible".


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

JR: Agreed.

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

JR: Agreed.

Cheers,
Jan

PS: Thanks again to Cynthia Shelly for putting all this together.

Received on Monday, 14 December 2009 17:09:56 UTC