User Agent Working Group Review of ATAG Last Call

Authoring Tool Working Group Members:

Members of the User Agent Accessibility Guidelines Working Group would like to congratulate you on reaching last call with your document and a job well done.  We have the following comments for consideration related to your document.

1.
A.2.1.1 Recognized Alternative Content: If recognized alternative content is available for editing view content renderings, then the alternative content is provided to authors.
UAReview: (and other SC) this and other success criteria were at time very hard to understand (for us it depended on the line breaks). suggest changing 'editing view' to 'editing-view'. it may help the reader understand the content rendering and alternative content are in the editing-view.  We believe the clearest wording for the SC would be "is available when rendering content in editing views", if you can adopt the phrase "rendering content" as equivalent to "content rendering".


2.
A.3.7.2 Preview: If a preview is provided, then at least one of the following is true: (Level A) [Implementing A.3.7.2]
(a) Third-Party User Agent: The preview makes use of an existing third-party user agent; or
the goal of A.3.7 is to ensure the preview is accessible.
if A.3.7.2.a is true, there is no guarantee that the 3rd party user agent is accessible. A.3.7.2.a only says there is a preview, A.3.7.2.b the preview must be accessible according to UAAG. the way A.3.7.2 is written having a preview and the preview being accessible could be mutually exclusive.
UAReview: Suggest changing
(a) Third-Party User Agent: The preview makes use of an existing third-party user agent; or to be
(a) Third-Party User Agent: The preview makes use of an existing third-party accessible user agent;
We think a clearer, less subjective wording for may also be "The preview makes use of an existing third-party user agent that conforms to the User Agent Accessibility Guidelines Level A; or". However, we should also acknowledge that the authoring tool may allow the user to configure which third-party user agent should be used, and should be able to pick an accessible one but should not be prohibited from choosing an inaccessible one. I haven't had time to draft wording that entirely works.

3.
1.            Scope of authoring tool user interface: The Part A success criteria apply to all aspects of the authoring tool user interface that are under the control of the authoring tool developer. This includes views of the web content being edited and features that are independent of the content being edited, such as menus, button bars, status bars, user preferences, documentation, etc.
UAReview:What about authoring systems that offer end-to-end publishing and web server publication/configuration.  It should be clear where any line for AU responsibility ends.
If you do expand this, you might want to give examples to more clearly define what you mean by "authoring systems that offer end-to-end publishing and web server publication/configuration". Would that include Web-based authoring tools such as when Drupal provides forms where the user can author or edit content that it hosts, using either text markup or WYSIWIG mode, and their choice of Web browsers?


4.
A.3.6.2 Respect Platform Settings: The authoring tool respects platform display settings and control settings.
UAReview:Broaden this to any settings that impact accessibility?  If these definitions of "display settings" and "control settings" seem broad enough to possibly include all input or output preference settings;, it would be nice if one didn't have to take the links to the glossary to figure that out, and it's still somewhat ambiguous: would it include the option to hide or show alternative text? Also, an example of preference settings beyond display and control settings that still affect accessibility would be the option to turn on and off AT compatibility modes such as support for platform accessibility API.

5.
B.2.5.2 Provide Accessible Templates: If the authoring tool provides templates, then there are accessible template options for a range of template uses.
UAReview: How does this differ from just making any templates accessible?  One would assume all templates offered should have equal accessibility.  What happens if the end user selects a template with less accessibility?
It sounds like you're proposing a requirement that if the user selects an inaccessible template, the authoring tool at least provides an accessible mechanism to exit the mode where they're using that template. Also minor, but it might clarify that we're talking about templates that are accessible to the author while creating or editing content, not templates that are designed to produce content accessible to the end-user. Is the latter also addressed somewhere?


6.
B.2.5.4 Template Selection Mechanism: If authors are provided with a template selection mechanism, then both of the following are true: (Level AA) [Implementing B.2.5.4] (a) Indicate: The selection mechanism indicates the accessibility status of templates (if known); and (b) Prominence: Any accessible template options are at least as prominent as other template options.
UAReview: The definition for prominence says in part:
For purposes of conformance to ATAG 2.0, item A is considered to be at least as prominent as item B if:
both items occur in the same item container (e.g., a menu for menu items, a list for list items, a dialog box for text boxes); if item B is emphasized, then so is item A;

so if the accessible option is at the bottom of a menu separated from the less accessible option by 10 entires, this is acceptable?  If the list has 25 items and the user must scroll to see the accessible option, is this then acceptable?

Off the topic somewhat, but the question of whether accessible options should be displayed as prominently as, and/or in proximity to, their inaccessible counterparts applies to more things than just templates (for example, a list of schemes).


Respectfuly,

UAAG Members