AUWG Response to Comments on ATAG2.0 from Cynthia Shelly

Hi Cynthia,

Thank you very much for submitting comments on the W3C Working Draft of 
the Authoring Tool Accessibility Guidelines (ATAG) 2.0 dated 29 October 
2009.

Your comments are here:
- 
http://lists.w3.org/Archives/Public/public-atag2-comments/2009Dec/0000.html

The draft responses were posted to the AUWG mailing list (at the link 
below) and a full text listing appears below:
http://lists.w3.org/Archives/Public/w3c-wai-au/2010AprJun/0028.html

Here is the notice that these are the official AUWG responses: 
http://lists.w3.org/Archives/Public/w3c-wai-au/2010AprJun/0030.html

If you have any concerns with the response, please contact myself 
(jan.richards@utoronto.ca), Jeanne Spellman (Jeanne Spellman 
<jeanne@w3.org>) or send an email to public-atag2-comments@w3.org.

================================
Full text:
================================

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

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: Authors 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)
Note: As per Success Criterion A.2.3.1, authors' display settings must
still be independent of the web content being edited."


   > 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
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. On
the other hand, if a preview is being developed that is already a
departure from existing user agents, then the W3C User Agent
Accessibility Guidelines (UAAG) must be followed - see (b). At the time
of publication, UAAG version 1.0 is a W3C Recommendation and version 2.0
is under development. Note: Developers may develop a preview from
scratch that does not meet (b) as long as authors retain the option to
preview using their own user agent, since this meets (a)."


   > 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 only apply 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: Example added: "If the web content technology of the output of
a web content transformation cannot preserve recognized accessibility
information (WCAG 2.0 Level A) (e.g., saving a structured graphic to a
raster image format), then at least one of the following are true:..."


   > 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 (and
encouraged) 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: This has been reworded, plus additional intent added:
"B.2.2.7 Metadata Production: Authors have the option of associating
accessibility checking results with the web content as metadata. (Level
AA) Note: The metadata format that is implemented will dictate the
nature of the associated results (e.g., specific check results, summary
conformance claims, etc.)"
"Intent of Success Criterion B.2.2.7:

The intent of this success criterion is to facilitate the creation of
accessibility metadata, which can have multiple uses, benefiting both
authors (e.g., by enabling interoperability between various checking and
repair tools) and end users (e.g., by enabling accessible resource
discovery).

The intent of the note is to be clear that no particular format is
required. Various metadata options exist and they differ in the nature
of the information they encode. The metadata choice will depend on the
intended use of the metadata. While this success criterion does not
require the use of a particular accessibility metadata format,
accessible resource discovery is facilitated by formats that include
specific checking results as opposed to formats that only include
summary conformance information. The reason for this is that individual
end users who are seeking accessible content, may have preferences for
certain types of accessibility information (e.g., captions), but not for
others (e.g., audio descriptions). This level of detail can be extracted
from specific checking results, but not from summary conformance claims."


   > 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 (and
encouraged) 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 authors 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 selected 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: While this is a good point, there are lots of curb-cuts in our
requirements and if we called out this one we would need to call out the
others and it isn't our primary goal.


   > 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: This example added: "Make backup of accessibility info: An
authoring tool automatically archives a backup copy of the original web
content, if accessibility information will be lost (e.g., when a
structured SVG graphic is saved as an unstructured JPG graphic), and
notifies authors of both the location of the backup copy and the fact
that the new content will not be available to any end users who need the
accessibility information."


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


================================

Cheers,
Jan



-- 
(Mr) Jan Richards, M.Sc.
jan.richards@utoronto.ca | 416-946-7060

Adaptive Technology Resource Centre (ATRC)
Faculty of Information | University of Toronto

Received on Tuesday, 20 April 2010 16:22:08 UTC