This document:Public document·Annotated document·View comments·Search comments·Add a new comment·Send replies to comments·Disposition of Comments·
Nearby:Authoring Tool Accessibility Guidelines Working Group
Other specs in this tool
Quick access to LC-2330
There are 28 comments (sorted by their types, and the section they are about).
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
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.
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)
Why is there a line between B.2.1.1 and B.2.1.2 when both are A?
A.3.7.2 See comment on A.1.2.1 regarding requiring conformance claims
(item a). Item b may not be possible if the author has not met the
requirements of WCAG (included text alternatives, provided structural
markup, etc.) Is item c referring to UAAG version 2.0? If ATAG 2.0 is
on track to finish first, it may be problematic to reference a standard that is not yet complete and I don't think we want to be referencing UAAG 1.0 which may be outdated.
Guideline A.1.2 This is a general comment about the non web accessibility compliance points: There are no restrictions on what an
accessibility standard is. It is user defined now. Consequently, the
evaluator could define their own compliance claims.
A.1.2.1 In WCAG, it is not a requirement to make a conformance claim.
This provision seems to require that authoring tools make a claim.
Suggest removing "and cite in the conformance claim)" and adding an
additional sentence: "If an ATAG 2.0 conformance claim is made, the
claim should cite the accessibility standards and/or platform
conventions that were followed.
A.2.1.1 Define "accessible" as used in the context of this provision.
A.2.2.2 If you are accessing text, you need access to the caret
position, and the selected text. Does use of a text view preclude
embedded objects? If not then they need to be accessible as well.
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.1.1 The provision is repeated. Why is this provision needed? It is
already required by provision A.1.1.1.
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.2.3 This provision is an example of a WCAG requirement that is made for stringent in ATAG. There's no issue with doing that when there is a good reason which in this case, I think there is. But the problem is that the authoring tool developer may have already implemented one of the other strategies that are allowed by WCAG. Somewhere ATAG should call out where there are provisions that override WCAG provisions. Maybe in A.1.1.1?
A.3.2.3 This checkpoint only says to stop. Per WCAG 2 you want to be
able to Pause and Hide content.
A.3.4.2 This should include role types such as ARIA roles.
A.3.4.2 There should be a navigate by relationships: labels, controls,
describedby, etc. should those features be supported.
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?
A.3.6.1 and A.3.6.2 What about auditory settings? Most authoring tools
don't have them but if they do, shouldn't the preference setting be
Add a comment.