FW: User Agent Working Group Review of ATAG Last Call

Hi all,

Thanks to UAAG for the review! Here are my initial thoughts, (marked JR).

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

JR: Ah yes...it's a view for editing, not someone editing the view. I'm ok with "editing-view". I'm also ok with the suggested re-wording. (not substantive change)


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

JR: Actually the logic is a bit different...it's that previews are meant to show how content will appear to end users in the "real world" - i.e. in an existing user agent where the user agent accessibility is the user agent developer's concern. (a) is the straightforward way to provide this. But if the authoring tool developer wants to depart from existing user agents, then the accessibility of that new user agent becomes THEIR concern and so UAAG would apply. 


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

JR: ATAG 2.0 certainly applies to Drupal and other CMS systems. I think this is clear from: " software for generating/managing entire web sites (e.g., content management systems, courseware tools, content aggregators)"


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

JR: I suppose we could roll together the display and control settings into "setting that affect accessibility". But I'm wary of such broad language since almost anything can affect accessibility in some way. Also we use "Display Settings" by itself for " A.2.3.1 Independence of Display:".
I think we sufficiently cover the API support in: A.1.2.1 Non-Web-Based Accessible: Non-web-based authoring tool user interfaces follow accessibility standards and/or platform conventions that support accessibility. (Level A) [Implementing A.1.2.1]  


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

JR: We're not saying that every template needs to be accessible. But rather, that at least some of the templates need to be accessible (a common sense definition of range is probably >1). Re: Accessible to whom...since this is Part B, B.2.5.2 relates to the production of accessible content for end-users BUT at the top of Part B is this normative note: "Features for meeting Part B must be accessible:..." so it is covered.
I think we do need to clarify that we are talking about developer-provided templates, not user-submitted ones over which developers don't have control.


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

JR: It's not perfect, but in my opinion trying to dictate the order within a container is a non-starter because the order is dependent on so many factors. E.g., if I'm not mistaken, "accessible" is something like "zugänglich" in German, so in an alphabetical list templates labelled as accessible would be sorted to the bottom. 

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

JR: The general principal of prominence for accessible options is covered by:
B.3.1.1 Accessible Options Prominent (WCAG Level A):


Cheers,
Jan

Received on Friday, 3 September 2010 14:04:12 UTC