This document:Public document·View comments·Disposition of Comments·
Nearby:Authoring Tool Accessibility Guidelines Working Group Other specs in this tool
Status: allopen proposal pending resolved_yes resolved_no resolved_partial other Type: allsubstantive editorial typo question general comment undefined
Quick access to LC-2330 LC-2331 LC-2332 LC-2333 LC-2334 LC-2335 LC-2336 LC-2337 LC-2338 LC-2339 LC-2340 LC-2341 LC-2342 LC-2343 LC-2344 LC-2345 LC-2346 LC-2347 LC-2348 LC-2349 LC-2350 LC-2351 LC-2352 LC-2353 LC-2354 LC-2355 LC-2356 LC-2357
There are 28 comments (sorted by their types, and the section they are about).
1-20 21-28
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.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.
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.
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?
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 There should be a navigate by relationships: labels, controls, describedby, etc. should those features be supported.
A.3.4.2 This should include role types such as ARIA roles.
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 saved?
Add a comment.