Re: [Fwd: ATAG review]

Here are draft WG responses to Cynthia Shelly's comments (updated with 
the results of the last couple of months). A few items have been missed 
and are marked with "@@@".

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

RESPONSE: Change made.


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

RESPONSE: It has been placed on A.3.1.1 and A.3.1.4, the two success 
criteria where the WG judged there might be confusion.


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

RESPONSE: Changed to "No 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.

RESPONSE: Unfortunately, the differences in keyboard shortcut 
availabilities across various platforms make more detail impossible. To 
help explain, the following text was added to the Intent section: "The 
wording is intentionally general because the features that require 
keyboard shortcuts and the number and nature of keyboard shortcuts that 
are available in various operating environments varies greatly (i.e., 
desktop systems generally have more keystrokes available to be assigned 
as shortcuts than mobile devices)."


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

RESPONSE: The new wording is "All functionality of the authoring tool is 
operable through a keyboard interface. (Level 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?

RESPONSE: A new success criterion was added "A.3.2.4 Content Edits Saved 
(Extended)The authoring tool can be set to save all content edits made 
by the author(s). (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"?

RESPONSE: Reworded as follows:
A.3.5.1 Text Search: The author(s) can perform text searches of web 
content as follows: (Level AA)
(a) Search All Editable: Any information that is text and that the 
authoring tool can modify is searchable, including: text content, text 
alternatives for non-text content, metadata, markup elements and 
attributes; and Note: If the current editing view is not able to display 
the results of a search, then the authoring tool may provide a mechanism 
to switch to a different editing view to display the results.
(b) Bi-Directional: The search can be made forwards or backwards; and
(c) Case Sensitive: The search can be in both case sensitive and case 
insensitive modes.


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

RESPONSE: This note was added "Note: If the current editing view is not 
able to display the results of a search, then the authoring tool may 
provide a mechanism to switch to a different editing view to display the 
results."


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

RESPONSE: A new success criterion was "A.3.6.2 Respect Platform 
Settings: The authoring tool respects platform display settings and 
control settings. (Level AA)"


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

RESPONSE: This was always the case. To emphasize this, the following has 
been added to the Intent section: "The most straightforward way to meet 
this success criterion is for authoring tools to simply implement 
preview features using user agents that are already in use by end users 
- see (a). This might be done in several ways, including by opening the 
web content in the author's default user agent or by making use of a 
user agent widget nested within the authoring tool's own user interface...."


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

RESPONSE: This was added to the Intent section: "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.

RESPONSE: This was reworded as:
"Applicability after the end of an authoring session: For 
author-generated content, the requirements of Part B apply only during 
authoring sessions. For example, if the author includes a third-party 
feed in their web content, the authoring tool is not required to provide 
checking for web content accessibility problems in that feed after the 
end of the authoring session. In contrast, for automatically-generated 
content, Part B continues to apply after the end of the authoring 
session. For example, if the site-wide templates of a content management 
system are updated, these would be required to meet the accessibility 
requirements for automatically-generated content. "


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

RESPONSE: A "Note on 'accessibility-supported ways of using 
technologies'" was added to the Conformance section.


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

RESPONSE: @@@


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

RESPONSE: Fixed.


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

RESPONSE: This note has been added to B.2.2.1, B.2.2.5, and B.2.2.10 
"Note: Automated and semi-automated checking is possible for many types 
of web content accessibility problems. However, manual checking is the 
minimum requirement to meet this success criterion. In manual checking, 
the authoring tool provides authors with instructions for detecting 
problems, which authors must carry out by themselves. 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.

RESPONSE: B.2.2.4 changed to Level A.


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

RESPONSE: @@@


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

RESPONSE: The note is reworded - maintaining no recommendation to fully 
automate: "Note: Automated and semi-automated repair is possible for 
many types of web content accessibility problems. However, manual repair 
is the minimum requirement to meet this success criterion. In manual 
repair, the authoring tool provides author(s) with instructions for 
repairing problems, which authors must carry out by themselves. 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.

RESPONSE: The WG agrees and believes this is covered 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.

RESPONSE: Authors should always have final control so (a) needs to be 
AND. The WG believes that because the file name is often unreliable, 
presenting it as a possibility is confusing.


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

RESPONSE: Automatically seleted templates already must be accessible 
(B.2.5.1(Level A), B.2.5.3(Level AA), and B.2.5.9(Level AAA).


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

RESPONSE: Prominence can be difficult to quantify exactly. The WG feels 
the current wording strikes the appropriate balance.@@@


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

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

RESPONSE: This wording was added to the Intent section: "The range of 
examples might include markup fragments, 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?

RESPONSE: That is supported by the conformance model. i.e a full 
conformance claim at Level A and a partial conformance claim Level AA 
for Part B.


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

RESPONSE: This has been done.


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

RESPONSE: This has been done.


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

RESPONSE: It is under "Related Resources for Success Criterion A.1.2.1".


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

RESPONSE: @@@


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


RESPONSE: The WG is 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?

RESPONSE: @@@


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

RESPONSE: This section has been reworded.

Received on Monday, 22 February 2010 20:37:53 UTC