RE: UAAG v2 Draft - Review

Note,

Most items here are relative straight forward text edits.  I've used a format of listing the section, the applicable text and either the phrase comment to indicate something that is a basic edit or discussion for something I think warrants some level of discussion.

This reflects review of the intro and guideline 1.

Section: Abstract
Text: Technologies not addressed directly by UAAG 2.0 (e.g., technologies for braille rendering) will be essential to ensuring Web access for some users with disabilities.
Discussion: Delete this.  There are loads of things important to web accessibility.  What's the point of this sentence?

Section: Guideline 1.1 - Alternative Content
Text: Summary: Let users see at a glance which pieces of content have alternatives like alt text or longdesc (1.1.1) and click on an item to see its available
alternatives (1.1.3); they can also choose at least one alternative like alt text to be always displayed (1.1.2), but it's recommended that they also be
able to specify a cascade (1.1.4), like alt text if it's there, otherwise longdesc, otherwise, filename, etc.
Comment: Rewrite as follows
Text: Summary: Allow users to easily determine which pieces of content have alternatives such as  alt text or longdesc (1.1.1) and interact with the text to see the available
alternatives (1.1.3); users can also choose at least one alternative such as alt text to be always displayed (1.1.2), but it's recommended that users also be
able to specify a cascade (1.1.4), such as alt text if it's there, otherwise longdesc, otherwise, filename, etc.

Section: 1.1.4
Text: The user can specify the fallback order in which to render alternative content.
Comment: Fall back should be cascade since that's what we use in the summary.

Section: 1.2
Text: Guideline 1.2 Repair missing content. [
Comment: The link immediately after this says Implementing 3.4).

Section: 1.2
Text: Summary: If the user chooses, provide useful alternative content when the author didn't, such as showing a filename in place of missing (3.4.1) or empty
(3.4.2) alt text.
Comment: Numbers need to be updated to refer to 1.x SC.  Suggest changing didn't to failed to do so in sentence talking about what the author did or did not do.

Section: 1.2.1
Text: The user can specify whether or not the user agent should generate and render repair text  (e.g. file name) when it recognizes that author has not provided alternative content.
Comment: Insert the word the before author.

Section: 1.2.3
Text: The user can specify whether or not the user agent should attempt to predict associations from author-specified presentation attributes (i.e. position and appearance). (Level AAA)
Discussion: I think this SC should be eliminated.  I don't know of any UA that does this and it seems hard to really do.  I know screen readers have tried to get this kind of thing working on the web and in apps and it is a hit/miss result.

Section: 1.2.4
Text: The user can be notified when user user agent cannot render alternative content (e.g. when captions are broken).
Comment: user user agent should be the user agent

Section: 1.3.1
Text: The user can specify that the following be highlighted so that each class is uniquely distinguished. It is not the intention that all recognized enabled elements be uniquely distinguished, just that they be distinguished from disabled elements. The user has the option to highlight the following classes of information so that each is uniquely distinguished.
Discussion: This doesn't flow. I don't have an immediate rewrite but this is hard to follow.  Sentence one and three repeat each other so perhaps deleting sentence one and making sentence three the first sentence is acceptable. Can we think of a better phrase than uniquely distinguished? It just sounds awkward.  Possible rewrite:
The user has the option to highlight the following classes of information so that each is uniquely distinguished. It is not the intention that all recognized enabled elements be uniquely distinguished, just that they be distinguished from disabled elements.

Section: 1.4
Text: Summary: Let users control text font, color, and size (1.4.1), including whether all text should be the shown the same size (1.4.2).
Comment: the shown the should have the first instance of the deleted or just say the same size and eliminate shown.

Section: 1.6
Text: Guideline 1.6 Provide synthesized speech configuration. [
Discussion: We have no summary for this section. Do we want summaries for all sections?

Section: 1.6.2
Text: The user can specify the following for synthesized speech: (Level AA) :
(a) pitch ("pitch" refers to the average frequency of the speaking voice), and
 (b) pitch range ("pitch range" specifies a variation in average frequency),
Discussion: Should these terms be defined in the glossary instead of the SC.  The doc doesn't flow as well with them defined here.


Section: 1.6.3
Text: The user can specify all of the speech characteristics offered by the speech synthesizer. (Level AAA)
Discussion: We have 1.6.4 that follows at AA that talks about specific items that must be configurable for the speech synthesizer.  SC 1.6.3 should likely move after the 1.6.4 that is AA.  Also, do we need to put any clarification that this is only for browsers that do some sort of self-voicing?

Section: 1.7
Text: Guideline 1.7 Provide style sheets configuration. [
Discussion: We have no summary for this section. Do we want summaries for all sections?

Section: 1.8
Text: Guideline 1.8 Help user to use viewports and orient within viewports. [
Discussion: We have no summary for this section. Do we want summaries for all sections?

Section: 1.8
Text: Guideline 1.8 Help user to use viewports and orient within viewports. [
Comment: Suggest this change to Guideline 1.8 Help the user to use and orient within viewports.

Section: 1.9
Discussion: I think this section is supposed to disappear.

Section: 1.10
Discussion: no summary

Section: 1.10.2
Text: 1.10.2Outline View:
Comment: Missing space character between 2 and Outline

Section: 1.10.2
Text: Note: The constitutes the important structural elements by the user (See 1.10.3)>
Discussion: The what?  Something is missing.

Section: 1.11
Discussion: No summary

From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org] On Behalf Of Greg Lowney
Sent: Thursday, June 23, 2011 1:28 AM
To: w3c-wai-ua@w3.org
Cc: UAWG list
Subject: Re: UAAG v2 Draft - Review

Hi! Here are some comments on keyboard items in the current draft, some of which address comments by other reviewers:

#1 Delete 1.9 Provide An Effective Focus Mechanism

Guideline 1.9 (Provide and Effective Focus Mechanism) is still around, but the reorganization that Kim and I proposed would have deleted it and scattered its success criteria into other, more targeted guidelines.  Some of that was done, but if all of our recommendations are implemented the few remaining there now will be gone:

1.9.3 (User Interface Focus: An active input focus is provided) was to be deleted as redundant to 2.1.2 (2.1.2 Keyboard Focus: Every viewport has an active or inactive keyboard focus at all times).

1.9.4 (Extensions Focusable) was to be deleted because the definition of user agent in the implementing document made clear that UI extensions and plug-ins are user agents and that all success criteria therefore apply to them.

1.9.6 (Retrieve Focus) has been moved to 4.2.2, so the original at 1.9.6 should be deleted.

1.9.7 (Return Focus) has been moved to 4.2.2, so the original at 1.9.6 should be deleted.

1.9.10 (Only on User Request) has been moved to 3.4.1, so the original at 1.9.10 should be deleted.

1.9.11 (On Focus) has been moved to 3.4.2, so the original at 1.9.11 should be deleted.

#2 Rename 2.1.3 Keyboard Navigability

2.1.3 (Keyboard Navigability) has been whittled down from our original proposal, which required the user be able to move the keyboard focus to any viewport and anything that takes input, to only discussing viewports. That may be acceptable because the ability to move between other controls may be handled adequately by 2.1.1 (Keyboard Operation). In fact, one could argue that 2.1.3 (Keyboard Navigability) is *entirely* redundant to 2.1.1 (Keyboard Operation). But if the group wants to keep 2.1.3 (Keyboard Navigability) as it currently reads, then we should at least change its title to reflect its reduced scope, perhaps to something like "Viewport Navigation".

#3 2.1.6 Separate Selection from Activation vs. 3.4.2 Avoid Side Effects of Navigation

This SC seems entirely redundant to 3.4.2 (Avoid Side Effects of Navigation). They currently read:

2.1.6 Separate Selection from Activation: The user can specify that selection is separate from activation (e.g., navigating through a set of radio buttons without changing which is the active/selected option).

3.4.2 Avoid Side Effects of Navigation: The user can move the keyboard focus to or from any enabled element without causing the user agent to take any further action.

I think the latter is clearer and has a better title is better, although the former's inline example is also helpful. Perhaps copy it into the latter?

#4 Revise 2.1.7 Follow Text Keyboard Conventions

The phrase "including, but not necessarily limited to," should probably be replaced by something like "such as", in order to avoid implying that the listed commands be implemented even on platforms where they are not part of the operating conventions. Or, more precisely but longer, it could end with something like "on platforms where those are standardized".

#5 Delete 2.2.3 Default Navigation Order

Kim and I had meant for what is now 2.2.3 (Default Navigation Order) to be moved to Guideline 3.4 (The user agent must behave in a predictable fashion) because, as its IER makes clear, its intent is to provide a consistent user experience across sessions and browsers, and that's what 3.4 is all about. While that was in our working notes, we failed to put it into the Wiki page so it didn't make it into the latest editor's draft. I suggest we complete the move.

#6 Elaborate on 2.3.2 Direct Activation and 2.3.3 Present Direct Commands

The first might be clearer if we include an inline example, such as "2.3.2 Direct activation: The user can move directly to and activate any operable elements in rendered content (e.g. by having the user agent create shortcuts for each). (Level AA)"

Similarly, we could elaborate on 2.3.3 by expanding its inline example to reference 2.3.2, such as "2.3.3 Present Direct Commands in Rendered Content: The user can have any recognized direct commands (e.g. accesskeys <ins>defined by the author or shortcuts added by the user agent</ins>) in rendered content be presented with their associated elements (Level A)"

#7 Rename Principle 4

In Kim's and my working notes we'd renamed Principle 4 and added moved some success criteria into a new Guideline 4.2, so the new organization was supposed to be:

    4. Facilitate programmatic access
        4.1 Assistive technology
        4.2 Nested user agents

Unfortunately we'd neglected to change the title of Principle 4 in the Wiki page, so it wasn't changed in the latest editor's draft where it's still titled "Assistive Technology" just like 4.1. I recommend it be renamed to "Facilitate programmatic access" or something similar.

#8 Clarify/fix 4.3.2 Return Focus

This currently reads "4.2.3 Return Focus [former 1.9.7, before that 3.11.7]: AAt any time, the user agent is able to retrieve input focus from a nested viewport (including nested viewports that are user agents). (Level A)"

The AAt should be "At".

But what is really the goal of this SC? Having the user agent be able to retrieve focus seems less important than allowing the user to be able to do so, and particularly doing so using the keyboard. (Are there any cases where one cannot get back even using a mouse?)

We could change "user agent" to "user", as in "the user is able to retrieve input", and/or add "using the keyboard" or "using any supported input device" (modality?).

If changed to be user-centric it would no longer belong in Principle 4, Programmatic Access.

#9 Change formatting of deleted links

It would be helpful if we could adjust the style sheet so that deleted links show up in a color that contrasts with the brown background used for deleted text.

    Thanks,
    Greg