Comments on UAAG 2.0 Working Draft of 2009-03-11

Hello all!

Here are some comments and suggestions on the latest draft of User Agent 
Accessibility Guidelines (UAAG) 2.0 Working Draft 11 March 2009.

A few are a bit clumsy as I has to stop to make your deadline for 
submissions, and for that I apologize, as well as for the amount of your 
time and effort they will require. They are currently sorted in document 
order, but most are suffixed with what I consider to be their priority, 
as well as a Type keyword: "Clarify" where I feel the draft needs 
clarification; "Expand" where I recommend increasing the requirements 
for compliance; "Formatting" where the change is strictly cosmetic or 
wording changes, such as normalizing terminology; "Narrow" where I 
recommend decreasing the requirements for compliance. Also I use ** to 
indicate comments which actually apply to more than one line item within 
the document, although the comment may only be explicitly associated 
with one.

I hope you find them useful, and as always I'm available to explain my 
thoughts or to help work out the best possible solutions.


#1. (Re 3.9) Override style sheet media types: 3.9.1 and 3.9.2 both 
require that the user be able to turn off or select between style 
sheets, but I think it's worth making explicit that this includes 
overriding the media types associated with the style sheets. If we do no 
make this explicit, a user agent might (with good intentions) not allow 
the user to select a style sheet identified with the "print" media type 
for rendering content to the display, or not allow them to use a 
"screen" style sheet for printing. I feel the user should be allowed to 
make these assignments. (Priority: 2 Medium) (Type: Expand)

#2. (Re 3.10.1) Highlight Viewport as an option: It is of course useful 
to highlighting the viewport that has the current focus, but I don't 
feel we need to require it to be active at all times; I think that if 
the user agent wants to allow the user to turn off this highlighting, 
providing such an option should not cost them Level A compliance. 
Therefore I recommend changing the wording to something to the effect of 
"The user can have the viewport with the current focus highlighted...", 
or adding "(This can be provided as a user option.)" (Priority: 2 
Medium) (Type: Clarify)

#3. (Re 3.10.11 **) Define or use another term for "chrome": Please 
either add a definition of "chrome" or replace the term with something 
more precise, more self-explanatory, and less imbued with other 
meanings. To me, "chrome" will always refer to purely decorative aspects 
of a user interface or content (by analogy to chrome-plating parts on 
the exterior of a car or motorcycle), but the document uses it in ways 
that don't seem to match this definition. I know that Mozilla 
programmers refer to "XUL applications running locally" as chrome, but 
that seems more narrow than what you're trying to say, and I also don't 
think you mean the name of Google's branded Web browser :-) If you 
define it in the glossary then you should use it without quotation marks 
around it every place it's used, which is currently 3.10.11, 3.11.4, 
4.4.1 and 4.4.2. (Priority: 1 High) (Type: Clarify)

#4. (Re 3.10.2 **) Move viewport to display the entire target range if 
it fits, otherwise at least the active end: Several success criteria in 
the document require the viewport be moved as necessary to ensure that 
some content (e.g. the new selection, or the search match, etc.) "is at 
least partially in the viewport". These should be modified to say that 
the viewport be moved "as necessary to ensure that the entire selection 
(or match, etc.) be in view, or if the entire selection does not fit, at 
least part of the selection be visible, including the active end of the 
selection if one exists." See my comment titled "Define active and fixed 
ends of a selection" for further details. (Priority: 2 Medium) (Type: 
Expand)

#5. (Re 3.10.3 **) Move viewport to display the entire content focus if 
it fits: See my comment on 3.10.2 titled "Move viewport to display the 
entire target range if it fits, otherwise at least the active end". 
(Priority: 2 Medium) (Type: Expand)

#6. (Re 3.10.4) Dissonance between "moving" and "resizing" viewports: 
The document refers to "moving" and "resizing" viewports, but the 
analogy between the two is inconsistent. Throughout the document, 
"moving a viewport" means changing which portion of the rendered content 
is visible, equivalent to panning. By analogy, "resizing" a viewport 
should also mean changing which portion of the rendered content is 
visible, but by zooming. Unfortunately, 3.10.4 uses the phrase moving 
viewport to mean moving the viewport relative to the visual display. It 
would be nice if we could either adopt a separate term for changing the 
latter concept, or adopt a term like "panning" a viewport for the 
former. (Priority: 3 Low) (Type: Clarify)

#7. (Re 3.10.4) Viewport sizes is often limited by being nested: 3.10.4 
says the user should have the option to make all graphical viewports 
resizable "within the limits of the display", but many viewport are 
limited not by the size of the display but by the size of the viewport 
in which they are nested. For example, it may not be appropriate to let 
the user resize a frame to be larger than the window in which it's 
displayed. Or, if you feel that should be allowed, then it makes equal 
sense to allow a viewport to be made larger than the physical display, 
as scroll bars or other navigation methods could be used to access the 
entire nested viewport. I recommend changing the text to read "within 
the limits of the display or the containing viewport". (Priority: 3 Low) 
(Type: Clarify)

#8. (Re 3.10.5) Allow alternatives to scrollbars: When rendered content 
extends beyond the viewport dimensions, 3.10.5 currently requires 
scrollbars to be provided--at all times. This is presumably in order to 
(a) provide feedback as to what portion of the content is visible and 
(b) to provide visible controls for panning the content within the 
viewport. However, I believe that in some cases UI other than scrollbars 
can accomplish the same goals, and in fact in some cases scrollbars are 
inappropriate or impractical (e.g. where the rendered content extends 
indefinitely or its extent is not known to the user agent). Example 
alternatives include providing scroll buttons to facilitate navigation 
and/or providing an "overview map" that highlights the region of the 
rendered content that is currently visible in the viewport. Using an 
alternative to scroll bars, or providing the user with an option to hide 
scroll bars in order to reclaim screen real estate, should not cost a 
user agent Level A compliance if equal functionality is provided through 
other means, and neither should providing the user with an option to 
hide scroll bars in order to save visual space. (Priority: 2 Medium) 
(Type: Clarify)

#9. (Re 3.10.6) Gracefully degrade if point of regard is no longer 
valid: Please explicitly recommend that the user agent gracefully handle 
the case where a saved state or its point of regard is no longer 
entirely valid. (E.g. if the page has been shortened, don't scroll down 
beyond the end of the document to where the point of regard used to be.) 
(Priority: 3 Low) (Type: Clarify)

#10. (Re 3.10.6 **) Define user agent extensions: I have no idea what 
the document means by "user agent extensions", which are referenced in 
3.10.6, 3.11.4, 4.1.2, 4.1.7. They're not nested user agents such as the 
Flash player... (Priority: 2 Medium) (Type: Clarify)

#11. (Re 3.10.8) Why limit stealing focus  top level viewports?: Why 
ensure that the user can stop top-level viewports from stealing focus, 
but not do the same about other events that steal focus (e.g. popup 
menus)? (Priority: 3 Low) (Type: Clarify)

#12. (Re 3.10.9) Exemption for technology unsupported by the platform: 
Things like the ability to force top-level viewports to remain on top 
may be limited by the platform, in which case I don't think the user 
agent should be penalized. (Priority: 3 Low) (Type: Clarify)

#13. (Re 3.10.New) Position top level viewports relative to the screen: 
I suggest adding a Level AA success criterion that the use be allowed to 
reposition top-level viewports relative to the screen. (Priority: 3 Low) 
(Type: Expand)

#14. (Re 3.12.1) Change title to "Source View": The title "Text view" is 
misleading, as for example HTML is often rendered as text. The 
requirement is that textual source to be displayed to the user, and to 
better reflect that change title to "Text Source View" or just "Source 
View". (Priority: 2 Medium) (Type: Clarify)

#15. (Re 3.12.2) Move Level from Note to Requirement: This requirement 
has "(Level AA)" after the "Note" paragraph, whereas elsewhere the level 
designations are attached to the actual requirement paragraph. 
(Priority: 3 Low) (Type: Formatting)

#16. (Re 3.12.2) Add Synchronized Outline View: 3.12.2 (Level AA) 
requires providing an outline view. I suggest adding a Level AAA 
recommendation to synchronize an outline view with the normal 
(non-outline) view. Examples would include (a) highlighting the element 
in the outline view that contains/introduces the element with the 
content focus or selection, or (b) display the outline elements in 
parallel to (e.g. in the margin of) the normal view and scroll them with 
the normal view. (Priority: 3 Low) (Type: Expand)

#17. (Re 3.12.2) Define a Web resource's "size": I recommend you clarify 
whether the success criterion requires providing the size only of the 
linked Web resource or of the linked Web resource AND the additional 
resources it loads. The former option is easy to impliement but not very 
useful to the user. (Sure it's helpful to know a link is to a 750KiB PDF 
file, but it's misleading when it says it links to a 5KiB Web page that 
turns out to appear blank until the UA downloads another 750KiB of its 
included images.) The latter option would be generally useful but also 
more work for the user agent to implement (unless the W3C has already 
defined a standard way for a server to publish the complete size of a 
Web resource and its dependents...and if not it could, hint, hint). 
Still, I recommend the latter approach, especially since this is only a 
Level AAA. (Priority: 3 Low) (Type: Clarify)

#18. (Re 3.12.3) Define important elements by attributes: In addition to 
letting the user configure the set of "important elements" by element 
type (e.g. headers), I recommend suggesting that it also be by other 
attributes, such as DIV with class="section", or headers without the 
style display:none. I recommend this be part of success criterion 
3.12.3, but you could also add it as a separate success criterion. 
(Priority: 3 Low) (Type: Expand)

#19. (Re 3.13.1) Identify links to resources at a different site: 3.13.1 
requires links be identified as either Internal (to a location in the 
same resource) or External (to another resource), but I would add a 
further distinction, making three types: Internal (to a location in the 
same resource) or External (to another resource), and Global* (to a 
resource on a different host system). For example, a person browsing a 
particularly accessible Web site may want to be warned before taking a 
link that would take them to another Web site that is potentially 
inaccessible to them. (* the term "Global" is a placeholder; the working 
group may be able to come up with better terminology for the three types 
of links.) (Priority: 2 Medium) (Type: Expand)

#20. (Re 3.13.1) Clarify terms "link element content" and "link title": 
The SC requires providing "link element content" and "link title", but 
these terms are ambiguous and not defined in the glossary. My first 
interpretation was that "link element content" would be the text between 
the open and close A tags, meaning the text or graphics used to 
represent the link to the user, and that "link title" would mean the A 
element's title= attribute. However, on reflection I realized that a 
reader could interpret the phrases to mean the destination and the 
displayed text, respectively. I'm still not 100% sure I've interpreted 
them correctly.  (Priority: 3 Low) (Type: Clarify)

#21. (Re 3.13.1) Provide link destination: In addition to the pieces of 
information already listed, the user agent should provide the 
destination of each link (e.g. the href URI for an A element). 
(Priority: 2 Medium) (Type: Expand)

#22. (Re 3.13.2) Provide link's accessibility rating: In addition to the 
pieces of information already listed as level AAA, we could recommend 
the user agent should provide the WCAG compliance level associated with 
the destination of each link if it can be determined (e.g. that the 
destination resource identifies itself as complying with WCAG 2.0 at 
Level A, or that the destination does not describe it's accessibility in 
a standardized way). (Priority: 3 Low) (Type: Expand)

#23. (Re 3.4.1) : Contrast "user has the option" in 3.4.1 vs. "the user 
can globally set" in 3.6.1 vs... (Priority: ) (Type: )

#24. (Re 3.4.1) : Should it clearly state "when such repair text can be 
created"? (Priority: ) (Type: )

#25. (Re 3.4.2) : Why is this AA instead of A? (Priority: ) (Type: )

#26. (Re 3.4.3) : What are "recognized enabled elements"? "Enabled" is 
not defined, and it could be taken to mean any element that is not 
explicitly "disabled" or "grayed out". (Priority: ) (Type: )

#27. (Re 3.5.1) : "Content focus" is not defined. Is this referring to a 
cursor/caret representing the place in the content where the user's 
input will have effect, or is it an activation indicator showing which 
area of the document (e.g. window or panel) is currently taking input? 
(Priority: ) (Type: )

#28. (Re 3.5.1) : Why not require identification/highlighting of (all) 
links, and/or items that take input or can be manipulated by the user? 
(Priority: ) (Type: )

#29. (Re 3.5.1) : Worth noting that this is (as far as I can tell) the 
only place where UA is required to keep track of which links have 
recently been visited. While most "Web browsers" track this, most other 
hyperlink applications do not (e.g. Adobe Reader, document 
editors/viewers, mail clients, etc.). While this enhances usability for 
everyone, and is particularly useful for reducing cognitive load on 
short-term memory, I'm not sure it's *so* useful that it should be Level 
A. By contrast, we have no requirement at any level to provide similarly 
helpful UI such as highlighting areas of the document that have been 
viewed or edited. The only justification I can see for giving this 
requirement special treatment is that it's common among Web browsers, 
but as I pointed out, it's not common among other types of user agents. 
(Priority: ) (Type: )

#30. (Re 3.5.1) : I would add "active (moving) end of the selection". 
(Priority: ) (Type: )

#31. (Re 3.5.1) : Should we include adjustable appearance to highlight 
the caret? (Priority: ) (Type: )

#32. (Re 3.5.1) : GREG, what other things should go in this list? 
(Priority: ) (Type: )

#33. (Re 3.5.2) : Could reword to clarify that it's referring 
specifically to the highlighting option required by 3.5.1, rather than 
more general highlighting. (Priority: ) (Type: )

#34. (Re 3.5.2) : To be clear, if the platform does not normally allow, 
say, selection colors to be adjusted, then the UA does not need to 
provide it either. If that is intentional, would you consider adding a 
new AA requirement that can be earned by the UA providing a wider range 
of highlighting options than the "platform's conventional selection 
utilities"? (Priority: ) (Type: )

#35. (Re 3.6.1) Allow overriding author's use of font styles: I would 
add "font style" (e.g. italics, bold, all caps, small caps). Many such 
style choices can significantly decrease legibility for some users, and 
thus the user should be allowed to override the content author's use of 
such styles. I would recommend this be included in 3.6.1 which is a 
Level A requirements, but if that would be controversial it could be 
added as a separate Level AA requirement. (Priority: 2 Medium) (Type: )

#36. (Re 3.6.1 Global) : Is there a requirement for scaling of non-text 
content? (Text content is covered by 3.6.1.) (Priority: ) (Type: )

#37. (Re 3.6.1 Global) : Is there a requirement for scaling text 
portions of the UA's own UI? (3.6.1 only covers rendered text content.) 
(Priority: ) (Type: )

#38. (Re 3.6.2) Give user option whether to preserve font size 
restrictions: Give the user control over whether font size distinctions 
are reserved when rendered. Most users will benefit from the ability to 
scale up all text while maintaining size distinctions between different 
types of elements, but there are cases where it is equally important to 
some users that they be able to choose to hide such distinctions and 
instead use a single font size or a very restricted range of such sizes. 
An example would be a user with low visual acuity who chooses to have 
all text rendered at an extremely large size (e.g. the text nearly as 
large as the window); such a user would be hampered if the UA is forced 
to render titles in a size larger than the height of the window. Thus I 
recommend changing the wording from "When rendered text is rescaled..." 
to "The user has the option whether, when rendered text is rescaled...". 
(Priority: 1 High) (Type: )

#39. (Re 3.6.3) Normalize use of the terms "operating environment" and 
"platform": The document uses the terms "operating environment" (3.6.3) 
and "platform" (1.1.1 etc.) seemingly interchangably. To avoid confusion 
it should standardize on one term.  (Priority: 3 Low) (Type: Formatting)

#40. (Re 3.6.3) Clarify or replace the term "conventional utility": What 
is meant by "the conventional utility available in the operating 
environment"? I assume "utility" in this context means "Utility software 
or a utility program, a software program that functions for a particular 
purpose" rather than the more general "usefulness". Because 
"conventional utility" is an unusual phrase, I recommend making it 
clearer by rewriting as something like "the range offered by global 
preference settings supported by the operating environment (i.e. 
configured through the system's Control Panel or System Preferences 
utility)". (Priority: 3 Low) (Type: Formatting)

#41. (Re 3.6.3) Require minimum option range beyond that of the 
platform: The minimum range for each text characteristic is "the range 
offered by the conventional utility available in the operating 
environment", and only if there is none does a wide range become 
required. Thus, as user who needs to adjust these settings in order to 
make the system accessible is in great shape if the platform has no 
conventions, but is "out of luck" if the platform offers a small range 
of options (e.g. a handheld device which normally uses just two font 
sizes, or does not provide any light-on-dark color schemes). It seems 
like the wider range should become required if the operating environment 
provides no default range OR if it offers a default range that is 
narrower than a certain threshold.  (Priority: 2 Medium) (Type: Expand)

#42. (Re 3.6.4) Clarify "Maintain contrast": This wording is unclear to 
me. Is the goal of this success criterion (a) to keep the user from 
accidentally choosing color preferences to something they can't use, or 
(b) to keep the administrator from intentionally choosing or enforcing 
setting that they don't realize will make the system inaccessible for 
some users, or (c) for the user agent to automatically and on-the-fly 
override content-specified colors in order to maintain significant 
contrast at all times? Please reword to clarify the intention and 
expectations. (Priority: 2 Medium) (Type: Clarify)

#43. (Re 3.7.1) Volume adjustments are almost always relative: The 
current wording is "The user can globally set the volume of all rendered 
audio tracks (including a 'mute' setting)  through available operating 
environment mechanisms. (Level A)".  However, when an operating 
environment provides a global volume control they typically do not allow 
the usr to "set the volume of all rendered audio" to a specific value 
but rather offer a RELATIVE setting that adjusts all audio up and down 
proportionately but maintains the relative distinctions between the 
volumes of different sounds. Thus the wording would be more accurate as 
"The user can globally set the relative volume...". (Priority: 3 Low) 
(Type: Clarify)

#44. (Re 3.7.1) Define or remove the term "mute": This success criteria 
requires the user have a "mute" options, it's not clear if that means 
the ability to turn the sound off altogether or would it be enough to 
offer the ability to lower the volume to a very low level? (Priority: 3 
Low) (Type: Clarify)

#45. (Re 3.7.1) Clarify the goal of "Global Volume": The current wording 
seems to require the operating environment to provide global volume 
settings, but that is clearly outside the scope of UAAG. I think the 
intended goal is to require user agents to respect any global volume 
preference settings made at the operating environment level. However, 
that's not what it says, so I suggest rewriting it to better reflect the 
original goal: "the user agent will respect any global volume preference 
settings made available by the operating environment". (Priority: 2 
Medium) (Type: Clarify)

#46. (Re 3.7.New) Lower non-speech volume when speech is playing: 
Consider adding a Level AAA success criteria recommending that the user 
have an option to request the user agent lower the volume of recognized 
non-speech audio tracks when recognized speech audio tracks are playing. 
(Priority: 3 Low) (Type: Expand)

#47. (Re 3.8.1 **) Clarify 3.8.1 "Speech Characteristics" vs. 3.8.2 
"(Speech) Option Range"   vs. 3.8.3 "Speech Characteristics": These 
three success criteria seem to overlap and share just two titles, so I 
assume it is just an editing error. They are identical except that 3.8.1 
is Level A and requires two basic settings, 3.8.3 is Level AA and 
requires three more advanced settings, and 3.8.2 is currently Level A 
but requires adjusting ALL settings. I assume the current 3.8.2 was , 
which has the widest range of requirements, is supposed to be Level AAA. 
If so, I recommend changing the titles to "Basis Speech 
Characteristics", "Advanced Speech Characteristics", and "All Speech 
Characteristics". Or another alternative would be "Speech Rate and 
Volume" (Level A), "Speech Pitch and Stress" (Level AA), and "Advanced 
Speech Characteristics" (Level AAA)". (Priority: 2 Medium) (Type: Clarify)

#48. (Re 3.8.2) Change title from "Option Range" to "Speech Option 
Range": If you do not accept my proposed changes to the titles of 3.8.1 
through 3.8.3, then change title from "Option Range" to "Speech Option 
Range" because the current title is not useful when taken out of 
context. That is, it makes sense if you know it's "Option Range" in the 
"Provide synthesized speech configuration" section, but is meaningless 
when standing alone.  (Priority: 3 Low) (Type: Formatting)

#49. (Re 3.8.4) Clarify "full numbers are spoken": Minor, but I'd 
recommend clarifying the meaning of the phrase "full numbers" by 
including an example, such as saying "one where numbers are spoken as 
individual digits and punctuation (e.g. 'one two zero three point five' 
for 1203.5 or 'one comma two zero three point five' for 1,203.5), and 
and one where full number are spoken (e.g. 'one thousand, two hundred 
and three point five')". (Technically the first option spells out 
punctuation as well as digits, but you can gloss over that if you'd 
prefer.) (Priority: 3 Low) (Type: Clarify)

#50. (Re 3.8.4) Are speech features used according to criteria or on 
request?: It currently reads "The following speech features are provided 
(Level AA): ... (c) at least two ways of speaking numerals: one where 
numerals are spoken as individual digits, and one where full numbers are 
spoken...". Is it the working group's intention that, for example, (a) 
user agents provide a user preference settings that all numerals, or all 
numerals meeting some criteria, should be spoken as digits, or (b) that 
the user agent provide a command by which the user asks the user agent 
to speak a particular number as digits (e.g. the most recently spoken, 
or the one that contains the focus or is selected, etc.), or (c) does it 
not matter which option the user agents uses? It seems that some of 
these features would be MUCH more useful to users on a case-by-case 
basis than as a global setting, especially if you had to use a global 
setting that caused, say, all text to be spelled out until you turned 
the option off again. It seems that ideally we'd request that the user 
agent provides both means of accessing those features. (Priority: 3 Low) 
(Type: Clarify)

#51. (Re 3.8.4) Provide ability to call out formatting changes using 
speech: The list of four speech features includes the ability to spell 
out text one character at a time and to speak numbers one digit at a 
time. I would suggest adding another, similar feature, which is "speak 
formatting changes: where changes in text formatting are indicated by 
spoken cues (e.g. 'how begin italics kind end italics of you to let me 
come'), ideally using speech characteristics to differentiate text being 
spoken literally from added spoken cues". (Priority: 3 Low) (Type: Expand)

#52. (Re 3.9.New) Non-Author, non-User Style Sheets : 3.9.1 requires the 
user be allowed to override author-provided style sheets, and 3.9.2 does 
the same for user-supplied style sheets, but what about style sheets 
that don't fit into either category? For example, what if basic, 
standardized style sheets are provided by the user agent or even the 
operating environment? Because 3.9.1 and 3.9.2 are identical except for 
the sources of the style sheets, I recommend combining them into a 
single success criterion which covers all style sheets regardless of 
whether they were provided by the author, the user, or other sources. 
(One could argue that "user provided" really means any that aren't 
provided by the author, but I don't think all users would assume that.) 
(Priority: 3 Low) (Type: Expand)

#53. (Re 3.9.New) Allow users supplied style sheets: 3.9 requires the 
user be allowed to diasble or switch between user-supplied style sheets, 
but nowhere does this draft document require or recommend that the user 
be allowed to supply any. I think this is pretty basic and should be a 
Level A success criterion (or, at worse, Level AA). (Priority: 2 Medium) 
(Type: Expand)

#54. (Re 4.1.1) Add Synchronized Outline View: It says that all 
functionality is operable with keyboard commands that don't require 
specific timings for individual keystrokes. You might want to clarify 
somewhere that key combinations are not considerd to require specific 
timings despite the fact that (strictly speaking) timing comes into play 
to ensure the keystrokes overlap. (That is, CTRL+A requires the CTRL key 
be held down long enough that it is still down when the A key is 
depressed.) I believe ISO 9241-171 specifically addresses key 
combinations separately from timing-dependent key presses. (Priority: 3 
Low) (Type: Clarify)

#55. (Re 4.1.10 **) Clarify difference between 4.1.10 vs. 4.1.11: 4.1.10 
and 4.1.11 seem to overlap and the difference between them is unclear. 
Were the two supposed to be combined? First, 4.1.9 applies to UI only, 
whereas 4.1.10 applies to both UI and rendered content (e.g. 
accesskey=). Second, 4.1.9 requires the user be able to assign new 
shortcut keys, whereas 4.1.10 does not. (At least not explicitly; see my 
other comment on the need to define "override" in these contexts.) 
(Priority: 1 High) (Type: Clarify)

#56. (Re 4.1.11) Use "recognized" instead of "that the user agent can 
recognize": We don't need to write out "(information) that the user 
agent can 'recognize'" when we already have the term "recognized 
(information)" defined and used throughout the document. Change 
"keybinding (i.e. access key) that the user agent can *recognize*" to 
"recognized keybinding (i.e. access key)" with the word "recognized" 
being a link to the glossary entry. (Priority: 3 Low) (Type: Formatting)

#57. (Re 4.1.2) Is keystroke precedence realistic?: Is there evidence 
that most UA available today actually implement this precedence, either 
by default or as a user option?  (Priority: ) (Type: )

#58. (Re 4.1.3) Say "Next in navigation order" rather than "Subsequent": 
It reads "always move the keyboard focus to a subsequent focusable 
element", but I think you mean it should move the keyboard focus to "the 
next focusable element according to the navigation order". It is 
important to specify that it is the next element in the navigation 
order, instead of "an" (meaning any?) subsequent element. Online 
definitions of "subsequent" stress the following but not immediately 
following. (Priority: 2 Medium) (Type: Clarify)

#59. (Re 4.1.3) "Focusable" vs. "Enabled" elements: The term "focusable 
element" and "focusable item" only occur in 4.1, whereas elsewhere the 
term "enabled element" seems to be used to mean the same thing? 
(Priority: 3 Low) (Type: Clarify)

#60. (Re 4.1.4) Provide a better example of navigation without 
activation: The current example ("navigating through the items in a 
dropdown menu without activating any of them") is weak because dropdown 
menus normally function that way on most platforms. A better example 
would be "navigating through a set of radio buttons without changing 
which is the active/selected option", as that is something that has 
historically been overlooked in a number of implementations. (Priority: 
3 Low) (Type: Clarify)

#61. (Re 4.1.4) Say "Moving keyboard focus" rather than "Selection": I 
think this should use the phrase "have keyboard navigation separate from 
activation" rather than "have selection separate from activation". 
Normally the term "selection" is used refers to either (a) selecting one 
or more items from a list, thereby making toggling their status (which 
is also called activating the item), or (b) selecting one or more items 
or a range within a field (as in a text string within a text field, or a 
region of a graphic), thereby identifying the range to be effected by 
subsequent operations. (Compare with ISO 9241-171 wording.) (Priority: 3 
Low) (Type: Clarify)

#62. (Re 4.1.5) Say "Display" rather than "Discoverable": I recommend 
changing the title of this SC to "Display keyboard commands" rather than 
"Discovery of keyboard commands", because the former more accurately 
reflects the actual success criterion. Making keyboard commands 
discoverable is a very good general goal, but it could be met by many 
methods such as including the commands in a help screen (assuming it is 
itself accessible). In contrast, the wording of this SC actually 
requires one specific method of accomplishing that goal: "displaying" 
all direct keyboard commands "with" their associated controls. 
(Priority: 2 Medium) (Type: Clarify)

#63. (Re 4.1.5) Clarify "Display of Keyboard Commands" or reduce to 
Level AA: While I'm all in favor of encouraging the display of keyboard 
commands with the associated items, I don't think it is reasonable to 
make it a Level A requirement at this time as (a) I don't know of any 
user agent that complies, and (b) the wording it too vague. Keep in mind 
that the current wording would apply to both rendered content and to the 
user agent's user interface. For example, does any browser provide an 
option that would display "CTRL+L" or "CTRL+D" printed next to its 
address bar? Is CTRL+B or CMD+B ever displayed next to selected text? 
The vagueness stems to the ambiguity of the term "direct keyboard 
commands", which are not defined (see my comment below that addresses 
this more specifically). (Priority: 1 High) (Type: Clarify)

#64. (Re 4.1.5 **) Define "direct keyboard command": The term "direct 
keyboard command" is used in 4.1.1, 4.1.3, and 4.1.5, but is never 
defined. Is it supposed to refer only to (a) "direct keyboard navigation 
commands" that merely move the focus to an associated item (e.g. CTRL+L 
or CTRL+D to move the focus to the address bar and select its contents), 
and/or to (b) keyboard commands that immediately activate or perform an 
action upon a user interface element (e.g. ALT+F to activate the File 
menu), and/or (c) keyboard commands that immediately carry out a 
specific action, usually but not always upon the element that has the 
selection or focus (e.g. CTRL+A to select the entire contents of the 
field that currently has or contains the keyboard focus)? If you mean 
choice (a) then you might want to use the term "direct keyboard 
navigation commands" rather than "direct keyboard commands". (Compare to 
ISO 9241-171 terminology--shortcut keys?) (Priority: 1 High) (Type: Clarify)

#65. (Re 4.1.6) Require all platform text area keyboard conventions, not 
just navigation: I don't think 4.1.6 should be limited to only requiring 
UA comply with the platform's standard keyboard commands for 
"navigation" within text fields, but should instead require support or 
all platform conventions for keyboard commands in text fields, 
including, but not limited to, commands for cut, copy, paste, delete, 
select all, and undo. Therefore I recommend changing the title to 
"Standard text area keyboard conventions" and the text to include "cut, 
copy, paste, delete, select all, and undo". Note that the title limits 
the scope to "navigation" but the wording of the actual success 
criterion does not: it does not explicitly say "navigation", but on the 
other hand the list of "including, but not limited to" examples does not 
include any that commands that lack a navigation component, even if some 
of them have effects beyond merely navigation (e.g. delete, 
shift-to-select). (Priority: 2 Medium) (Type: Expand)

#66. (Re 4.1.6 **) Insert comma before "including, but not limited to": 
Most examples of "including, but not limited to," that I find on the Web 
(often legal documents) use a comma before, as well as after, the word 
"including".  The document is currently inconsistent, sometimes using 
all two commas (e.g. 4.1.6), and sometimes none (e.g. 4.1.7), but never 
all three. (Priority: 3 Low) (Type: Formatting)

#67. (Re 4.1.7) Clarify whether group-to-group navigation is ordered: 
The current wording is ambiguous as to whether keyboard navigation "from 
group to group of focusable items" requires sequential navigation (e.g. 
CTRL+TAB to move between pane or panels) or whether it is sufficient to 
provide direct navigation to groups (e.g. CTRL+D or CTRL+L to move to 
the address bar). If the former, the wording should be changed and I'd 
also recommend that the "forwards and backwards" language be applied to 
sequential navigation between groups. Note that today most browsers 
support sequential navigation between viewports and other groups of 
elements within content items, but do not always support sequential 
navigation between groups of user interface items; the current wording 
includes both (per the examples in the glossary definition of "serial 
access"). (Priority: 2 Medium) (Type: Clarify)

#68. (Re 4.1.7 **) Normalize "toolbar" and "tool bar": The term 
"toolbar" occurs once in the document (4.1.7) but "tool bar" occurs four 
times (all in 4.8); neither is defined. A Google search for "Tool bar" 
yields 2.5 million hits, while "Toolbar" yields 40 million, so I suggest 
we standardize on "toolbar" unless we're conforming to some other WAI 
phasebook. (Priority: 3 Low) (Type: Formatting)

#69. (Re 4.1.8) Require single keystroke OR key combination, etc.: 
Change the text from "are available in a single keystroke" to "are 
available using a single keystroke, key combination, or sequence of 
unmodified keystrokes". The dictionaries I found online all define 
keystroke as a single depression of a single key, and there are clearly 
not enough available single keystrokes to assign to all of the important 
commands. (The reason I also include "or sequence of unmodified keys" is 
because of the StickyKeys feature which allows the user to emulate a key 
combination using sequential unmodified keystrokes.) Since this is only 
Level AA it's not high priority, but without a change such as this it 
would not be accomplishing its goal AND it would make Level AA 
compliance extremely difficult. (THAT CAN BE MEMORIZED AND ENTERED 
WITHOUT CHECKING INTERMEDIATE RESULTS, e.g. F10,F,O is OK for 
File->Open, but F10,Down,Down,Enter is not?) (Priority: 2 Medium) (Type: 
Expand)

#70. (Re 4.1.9) Is 4.1.9 actually Level A?: I ask because elsewhere the 
success criteria for a guideline are sorted according to Level, but here 
4.1.9 (Level A) follows 4.1.8 (Level AA). Is this a temporary artifact 
that will be fixed when items are renumbered? Or is 4.1.9 miscategorized 
as A when it should be AA? (Priority: 3 Low) (Type: Clarify)

#71. (Re 4.1.9) Is overriding all UI keyboard commands too broad?: I'm 
concerned because I'm not sure that any browsers allow the user to 
override *all* of the platform's UI keyboard commands" (e.g. ALT to 
activate the menu bar, CTRL+O for open, CTRL+A for select all, Tab for 
sequential navigation, etc.). Is it possible that the current wording is 
unintentionally broad? (Priority: 1 High) (Type: Clarify)

#72. (Re 4.1.9 **) "Platform" vs. "Operating Environment": In some 
places the document uses "platform" (e.g. 4.1.6) but in others users 
"operating environment" (e.g. 4.1.9) for what appears to be the same 
thing. Please consider normalizing the terminology. (Priority: 3 Low) 
(Type: Formatting)

#73. (Re 4.1.9 **) Define "override" keyboard shortcut bindings: 4.1.9, 
4.1.10 and 4.1.11 require the user be able to "override" keyboard 
shortcuts, but don't define the term. 4.1.9 and 4.1.11 refer to 
"rebinding" and so requires the user to be able to assign new shortcuts 
that replace the default ones, whereas 4.1.10 does not mention this and 
so implies that the user only needs to be able to remove default 
shortcuts, but the ability to reassign or assign new shortcut keys is 
presumably left optional. For the goal of improved accessibility there 
are really three potential features: (a) the ability to delete existing 
shortcuts is useful when they conflict with shortcuts used by assistive 
technology; (b) the ability to reassign shortcuts for functions that 
already have them accomplishes that goal PLUS retains the ability of 
shortcuts to reduce the number of keystrokes and/or steps required to 
execute an operation; (c) the ability to assign new shortcuts to 
functions that don't have them by default accomplishes both of those 
goals PLUS allows the user to further reduce the number of keystrokes or 
steps they have to enter. One way of handling these diverse choices 
would be to make the first option be Level A, the second Level AA, and 
the third Level AAA. (Priority: 2 Medium) (Type: Clarify)

#74. (Re 4.1.9 **) Normalize "keyboard shortcuts" vs. "keyboard shortcut 
bindings": 4.1.9 uses the term "keyboard shortcut binding" while 4.1.10 
uses "keyboard shortcut". I assume they are meant to refer to the same 
thing, so the document should standardize on one phrasing. (Priority: 3 
Low) (Type: Clarify)

#75. (Re 4.2.1) Change title "All Available" to make sense out of 
context: 4.2.1 is an example of a success criteria whose title ("All 
Available") is not useful when taken out of context. That is, it makes 
sense if you refer to "4.2.1 All Available in 'Provide access to event 
handlers'", but is meaningless when you refer to it just as "4.2.1 All 
Available". I recommend changing all such titles so that they make sense 
when quoted out of context, such as changing "4.2.1 All Available" to 
"4.2.1 Access to all input device event handlers". (Priority: 3 Low) 
(Type: Clarify)

#76. (Re 4.2.2) Change title "Show all" to make sense out of context: 
The title "4.2.2 Show All" 4.2.1 is an example of a success criteria 
whose title ("All Available") is not useful when taken out of context. 
That is, it makes sense if you refer to "4.2.1 All Available in 'Provide 
access to event handlers'", but is meaningless when you refer to it just 
as "4.2.1 All Available". I recommend changing all such titles so that 
they make sense when quoted out of context, such as changing "4.2.2 Show 
All" to "4.2.2 Show all input device event handlers". (Priority: 3 Low) 
(Type: Clarify)

#77. (Re 4.2.3) Change title "Activate All" to make sense out of 
context: 4.2.3 is an example of a success criteria whose title 
("Activate All") is not useful when taken out of context. That is, it 
makes sense if you refer to "4.2.1 Activate All in 'Provide access to 
event handlers'", but is meaningless when you refer to it just as "4.2.3 
Activate All". I recommend changing all such titles so that they make 
sense when quoted out of context, such as changing "4.2.3 All Available" 
to "4.2.3 Activate all input device event handlers". (Priority: 3 Low) 
(Type: Clarify)

"#78. (Re 4.2.3 **) ""Activate all input device event handlers"" is 
unclear: I'm afraid that I can't understand this success criterion based 
on its title (""Activate All"") or its text ( ""The user can activate, 
as a group, all event handlers of the same input device event type, for 
the same control""), nor is it clear how it is different than 4.2.1. 
Both require the user be able to activate event handlers, but they 
differ in:

(a) although 4.2.1 applies to ""(content) elements"" that take content 
focus while 4.2.3 applies to ""(user interface) controls"" (per glossary 
definitons);

(b) 4.2.1 requires that the user can activate them with the keyboard 
while 4.2.3 doesn't specify the means, presumably making it OK if the 
user has to click a mouse to activate a mouse-click event handler (which 
seems to remove the point);

(c) 4.2.3 says ""as a group"" while presumably 4.2.1 finds it enough if 
they can be activated separately;

(d) 4.2.1 only applies to the event handlers that are ""explicitly 
associated"" with the element that has content focus, while presumably 
4.2.3 requires it for all UI controls that handle events even if they 
""bubble up"" to the control rather than being ""explicitly associated"" 
with it;

(e) 4.2.1 requires the user be able to navigate to and then trigger 
event handlers for an element, while 4.2.3 would presumably be met by 
providing an entirely separate facility that merely allowed the user to 
pick UI controls and their event handlers from a master list;

(f) etc., etc.

As you can see, I find 4.2.3 (and probably 4.2.1) need significant 
changes to be made both clear and useful. I recommend that the two SC be 
combined into a single SC that (a) applies to both content elements that 
have the content focus AND to UI controls that have the UI focus, (b) 
lets the user activate, in a single operation, ""all"" of the event 
handlers for the user's choice of input device event handlers 
""explicitly associated"" with that element or control. (Priority: 1 
High) (Type: Clarify)"

#79. (Re 4.3.1) Clarify a minimum extension for time limits : 4.3.1 
requires the user be able to extend time limits, but provides no 
guidance or minimum amount. Thus, UA would comply even if it only 
allowed the user to add 0.1 second to the default timeout period. I 
recommend it require the user to be able to disable the timeout 
altogether, or if that's not acceptable at least extend it to some 
minimum multiple of (e.g. five times) the default value. (COMPARE WITH 
ISO 9241-171) (Priority: 2 Medium) (Type: Expand)

#80. (Re 4.4.1) Define "general flash and red flash thresholds" : This 
success criteria should provide a link or explicit cross-reference to a 
definition of or guidance on "the general flash and red flash 
thresholds". (Priority: 2 Medium) (Type: Formatting)

#81. (Re 4.5.1) Add ability to restore default settings: Please add a 
requirement that the user be able to restore user agent preference 
settings to their default values. Without that, if a user makes a change 
that is detrimental, 4.5.1 ensures that it will be difficult to get rid 
of. I would like to see this be Level A, although if too few user agents 
currently provide this then it could be Level AA for the time beng. 
(Priority: 2 Medium) (Type: Expand)

#82. (Re 4.5.1) Add ability to restore preference settings without using 
the UI: If the user changes a user agent preference setting that makes 
the user agent inaccessible to them (e.g. a blind user turning of a 
setting required for screen reader compatibility), they would ideally 
have a way to restore their choice of either the defaults values or a 
previously save group of values, in a way which allows them to bypass 
the user agent's current (inaccessible) settings. For example, (a) a 
user agent could ship with a separate utility for resetting or loading 
user preference settings, or (b) holding down a modifier keys or 
specifying a command-line switch when starting the user agent could 
force it to use the default settings, or previously used and known-good 
settings, or a specified set of settings. This could be Level AA. 
(Priority: 3 Low) (Type: Expand)

#83. (Re 4.5.2) Clarify the term "User Profiles": Very minor, but it 
seems strange that the term "user profiles" occurs in two SC titles but 
neither in their actual text nor elsewhere in the document. You might 
consider either (a) explaining the term inline, e.g. "the user can save 
and retrieve multiple user profiles (sets of user agent preference 
settings), or (b) adding the term "user profile" in the glossary, or (c) 
changing the titles to avoid the term, e.g. "Save and load user 
preference settings".  (Priority: 3 Low) (Type: Formatting)

#84. (Re 4.5.3) Reword to allow "exporting" user preference settings: I 
recommend rewording this slighty to clarify. It currently requires that 
"sets of preferences ARE STORED as separate files (allowing them to be 
transmitted electronically)", but I think "are stored" implies that this 
happens all the time. The high-level goal is that the user is able to 
save their user preference settings so that they can be archived, 
transmitted, and loaded on another device. This can be achieved by 
always storing them as separate files or by providing import and export 
commands.  (Priority: 3 Low) (Type: Clarify)

#85. (Re 4.5.3) Degrade gracefully when loading foreign user profiles: 
In addition, ideally the loading of stored user preference settings 
would degrade gracefully when the settings were saved by different 
versions of the user agent or on a different platform. If this is not 
specifically required, it is likely that some implementations would 
simply refuse to load saved settings from an older (or newer) version of 
the user agent, or a 32-bit version of the user agent might refuse to 
load preference settings saved by a 64-bit version, or that the saved 
preference files might contain system-specific information that would 
break if loaded onto another computer. I recommend adding, "User agent 
should allow loading preference setting saved by earlier versions of the 
user agent, or on different devices or platforms, using those preference 
settings that are applicable on the current system and gracefully 
handling those that are not applicable." (Priority: 3 Low) (Type: Expand)

#86. (Re 4.5.3) Clarify the term "wizard": The term "wizard" only occurs 
in this SC's title and text, and in the latter it's written in quotation 
marks. I recommend adding a definition of "wizard" to the glossary and 
using it without quotation marks. (Priority: 3 Low) (Type: Formatting)

#87. (Re 4.6.1) Change "Search Rendered" to "Search Rendered Content": 
Change the title from "Search Rendered" to "Search Rendered Content" to 
make it slightly clearer when taking out of context. ("Search Rendered" 
sounds too close to "Search Offered".) (Priority: 3 Low) (Type: Formatting)

#88. (Re 4.6.1) Why is Searching Level AA?: I assume there is a good 
reason that Search Rendered Content is Level AA instead of Level A, but 
it seems at first consideration that it would merit Level A, both 
because it's easy and because it's almost universally implemented (at 
least in Web browsers, email clients, and similar user agents). If the 
reason is that it's more difficult or less common to search text 
alternatives as well as rendered text, consider splitting it into two 
separate success criteria, one at Level A for searching rendered 
content, and the other at Level AA for searching rendered content AND 
text alternatives. (Priority: 3 Low) (Type: Expand)

#89. (Re 4.6.2) Change title from "Bi-Directional" to "Search forwards 
of backwards": Change the title from "Bi-Directional" to "Search 
forwards of backwards". This would (a) make the title more meaningful 
and less ambiguous when taken out of context, as bi-directional doesn't 
make it clear it's about searching, and (b) because "bi-directional" has 
a totally different common meaning with regard to text, namely applying 
to languages that may be written right to left. (Priority: 3 Low) (Type: 
Formatting)

#90. (Re 4.6.3) Indicate matched text: When a Search operation finds a 
match, I recommend that in addition to the criteria already listed, the 
matching content should be indicated to the user. For example: visually 
highlighting, calling out with a separate indicator, and/or selecting 
matching text or content whose text alternative contained a match; 
beginning to play media content from the time marker corresponding to 
the time code of the matching text in the closed captioning stream, or 
voice and/or highlight the phrase in the closed captioning stream 
corresponding to the match. Add bullet item "(c) indicate match: 
highlight, select, and/or resume playing at the point corresponding to 
the matched text content." (Priority: 2 Medium) (Type: Expand)

#91. (Re 4.6.3 **) Move viewport to display the entire matched text 
content if it fits: See my comment on 3.10.2 titled "Move viewport to 
display the entire target range if it fits, otherwise at least the 
active end". (Priority: 2 Medium) (Type: Expand)

#92. (Re 4.6.4) Clarify minimum for alerting user after last match: The 
text requires that "the user is alerted when there is no match or after 
the last match in content". I recommend rewriting slightly to: (a) 
require user confirmation of the alert, to avoid the common problem of 
the alert being so subtle that users continue to cycle through the 
document long after they've found every match (e.g. in Mozilla Firefox), 
and (b) change "or after the last match" to "AND after the last match", 
in order to make it clear that the user agent must provide alerts in 
both cases, not just one, and (c) recommend distinct alerts for the two 
conditions, to avoid the user mistakenly thinking that they've searched 
the entire document when they have not. (Priority: 3 Low) (Type: Clarify)

#93. (Re 4.6.4) Change title from "No Match" to "Alert on No Match": 
Changing the title from "No Match" to "Alert on No Match" would make it 
better describe the actual requirement. (Priority: 3 Low) (Type: Formatting)

#94. (Re 4.6.5) Provide both case-sensitive  and case-insensitive 
search: This success criterion would be stronger if there it required 
both case-sensitive and case-insisensitive search options. At the moment 
it only requires that the user have access to case-insensitive search, 
and I would argue that case sensitive searching is as helpful and 
helpful to as many people as case insensitive searching; both make use 
easier for some people in some situations, but also worse for some 
people in some sitations. (For example, it may require extra work for a 
person using speech output to determine the capitalization of the string 
they want to search for, and so want case insensitive search, while 
another person for wishes to reduce the amount of reading or the number 
of keystrokes they type may want case-sensitive search so they don't 
have to wade through hundreds of partial (wrong-case) matches. Change to 
read "Case Sensitive Search Option: The user has the option of 
performing case-sensitive or case-insensitve text searches." (Priority: 
3 Low) (Type: Expand)

#95. (Re 4.6.5) Provide Advanced Search options?: I guess I'm just not 
sure why case insensitivity is considered the only search option 
warranting explicit mention. If providing case-insenstive search 
improves accessibility by reducing the work load for the user (reading 
or input), then the same argument could be made for additional Advanced 
Search options. For example, the ability to control whether searching 
wraps at the beginning or end of the document, the ability to search 
only within rendered text or only within text alternatives, the option 
whether or not to use stemming (i.e. matching all variations of a word 
rather than only exact matches), the ability to search for a specific 
content type (e.g. graphic, table, or heading level 1--although that is 
partially addressed by 4.7), etc. I could imagine adding a general 
recommendation along these lines at Level AAA, but it's definitely low 
priority. (Priority: 3 Low) (Type: Expand)

#96. (Re 4.7.1) Structured Navigation should follow rules applying to 
Text Search: Providing structured navigation is a very useful, but it 
would be more useful if more of the specific behaviors required for text 
searches were also required for structured navigation. Examples include 
moving the viewport to display the match (4.6.3), highlighting the match 
(proposed), and providing alerts for no match and before wrapping 
(4.6.4). I recommend replicating those success criteria from 4.6 here in 
4.7. (As a side note, it can be useful to consider both structural 
navigation and text search as special cases of the same thing, a 
distinction that gets blurry when advanced search options allow limiting 
search by element type.) (Priority: 3 Low) (Type: Expand)

#97. (Re 4.7.2) Recommend separate structured navigation commands for 
different sets of important elements: Recommend separate structured 
navigation commands for different sets of important elements at Level AA 
or Level AAA... (Priority: ) (Type: )

#98. (Re 4.7.Note) Define or replace the term "navigation bars": The 
note for 4.7 uses the term "navigation bars", which is neither defined 
nor used anywhere else in the document. I have no idea what the authors 
meant by the term, so I recommend either defining it in the glossary, 
defining it in parentheses where it's used, or replacing it with a more 
widely understood term or a more descriptive phrase. (Priority: 3 Low) 
(Type: Formatting)

#99. (Re 4.8 New) Add hiding and repositioning toolbars: The only 
success criteria involving toolbar discuss configuring the individual 
controls, but I consider it as important that the user can configure 
which toolbars are displayed as well as their size and location. These 
abilities let the user simplify the UI in order to reduce distraction, 
reduce their pointing device motion, increase the amount of space 
available for viewport content and/or assistive technology, avoiding 
conflict between floating toolbars and "always-on-top" assitive 
technology windows, etc. I recommend adding a new success criterion, 
"4.8.3 Configure Toolbar Locations: The user can configure the position 
and size of any toolbars, whether they are displayed or hidden, and 
whether they are floating or docked to a specific portion of the top 
level viewport (subject to the limits of the underlying presentation 
technologies)." (See my separate comment "Defining the term 'toolbar'" 
for more information about floating vs. docked toolbars.) (Priority: 2 
Medium) (Type: Expand)

#100. (Re 4.8.1) Change title from "Configure Position" to "Configure 
Position of Toolbar Controls": Change this title from "Configure 
Position" to "Reposition Toolbar Controls". This will: (a) make the 
title meaningful when taken out of context (that is, when referenced 
without the fact that it's in the section on toolbars); (b) make it 
clear that it addresses the positions of controls within a toolbar, 
rather than the positions of the toolbars themselves (a mistake I made 
on first reading). "Reposition Toolbar Controls" is equivalent to 
"Configure Position of Toolbar Controls", but more succinct, so I 
recommend it unless you want to use "configure the position of" 
throughout the document instead of the shorter "reposition" because you 
feel the former more strongly implies that changes are persistent across 
sessions. (Priority: 3 Low) (Type: Formatting)

#101. (Re 4.8.1) Simplify wording once toolbars are defined: Once we add 
to the glossary a definition for toolbar and link to it from here, we'll 
be able to greatly simplify the wording of this success criterion. 
Change from "For graphical user agent user interfaces with tool bars, 
the user can add, remove..." to "The user has the option to add, remove, 
and configure the position of user agent user interface controls on any 
toolbars from a pre-defined set of controls." (Priority: 3 Low) (Type: 
Formatting)

#102. (Re 4.8.2) Clarify scope of "toolbar configuration": If you accept 
my proposed new success criterion about letting the user configure the 
presence, position, and size of toolbars, then 4.8.2 needs to be 
reworded to make clear that restoring "the default toolbar 
configuration" includes both the presence, position, and size of each 
toolbar, AND the presence and position of the user interface controls 
displayed on those toolbars. Reword to read, "The user can restore the 
default toolbar configuration, including the presence, position and size 
of all toolbars as well as the presence and position of the user agent 
user interface controls on those toolbars." (Priority: 2 Medium) (Type: 
Clarify)

#103. (Re 4.8.2) Change title from "Restore Defaults" to "Restore 
Default Toolbar Configuration": Change the title from "Restore Defaults" 
to "Restore Default Toolbar Configuration" or even "Restore Default 
Toolbars". This will make the title meaningful when taken out of context 
(that is, when referenced without the fact that it's in the section on 
toolbars). (Priority: 3 Low) (Type: Formatting)

#104. (Re 4.9.4) Switch order of Execution Toggle and Execution 
Placeholder: This is extremely minor, but I think 4.9.4 (Execution 
Toggle) makes much more sense if it's read AFTER reading 4.9.5 
(Execution Placeholder). At least it confused me. Switching the order of 
the two would make it clear for first-time readers why Execution Toggle 
only applies to executable content that would not normally be contained 
wihtin a particular area. (Priority: 3 Low) (Type: Formatting)

#105. (Re 4.9.6) Reword for clarity: The current wording of the third 
bullet item is "when audio and video tracks are synchronized: above 75% 
of the original speed, maintain synchronization; below 75% the user 
agent is not required to render the audio track." I think it would be 
somewhat easier to read as "when audio and video tracks are expected to 
be synchronized, synchronization is maintained as long as they are 
played at 75% of their original speed or higher." (Priority: 3 Low) 
(Type: Formatting)

#106. (Re 4.9.6) What about non-audio, non-visual tracks?: This success 
criteria addresses the cases where there is at least a visual track, or 
only an audio track, but should we address cases that include a textual 
track such as is used to render captions on a tactile display? While I 
know many users can read tactile displays extremely quickly, I'm not 
sure what appropriate speed options should be required for the benefit 
of the wide range of tactile display users. (Priority: 3 Low) (Type: 
Clarify)

#107. (Re 4.9.6) Why different speed options when video is present?: 
Currently audio only should be slowed to at least one setting between 
75-80%, while for audio with video it's 40-60%. It's not clear to me why 
a user concerned with the audio track should be penalized--not given a 
choice of higher than 60%--just because there's also a video track that 
they might not care about. (Priority: 3 Low) (Type: Clarify)

#108. (Re 4.9.7) Split multimedia stop/start from pause/resume: I'm 
concerned that none of the major Web browsers comply with the Level A 
success criteria that they allow the user to stop, pause, and resume 
multimedia. Neither Firefox, Internet Explorer, nor Safari allow the 
user to pause and resume animated gifs regardless of their duration. 
Consider splitting this SC into two: the ability to stop and start 
multimedia as Level A, and the ability to pause and resume multimedia as 
Level AA. (Priority: 1 High) (Type: Narrow)

#109. (Re 4.9.7 **) Remove restrictions based on multimedia duration: 
4.9.7 and 4.9.8 both restrict their applicability to multimedia that 
lasts three seconds or longer at default playback rate.  Because a user 
agent would often not know the duration of multimedia content, it would 
have to provide these controls for all multimedia, so I would remove the 
3-second restriction from both success criteria (and my proposed split 
off 4.9.7). (Someone could argue that the Note for this guideline, which 
says it only applies to multimedia "that the user agent can recognize" 
means that 4.9.7 and 4.9.8 would only apply to multimedia for which the 
user agent can recognize the length. If that is the working group's 
intention then the Note should be significantly reworded to make this 
clear, and the working group needs to accept that these criteria would 
have extremely limited applicability.) (Priority: 1 High) (Type: Expand)

#110. (Re 4.9.8 **) Remove restrictions based on multimedia duration: 
Please see my comment with this title for 4.9.7 (Stop/Pause/Resume 
Multimedia). (Priority: 1 High) (Type: Expand)

#111. (Re 4.9.Note) Clarify that this Note does not restrict all success 
criteria: The Note for Guideline 4.9 reads "The guideline only applies 
to images, animations, video, audio, etc. that the user agent can 
recognize." Since all of the examples given are audio or visual, it 
gives the impression that the Note means "multimedia". However, the 
guideline includes success criterion (e.g. 4.9.D Text Scaling, and 4.9.4 
Execution Toggle) that clearly do NOT apply to multimedia, images, 
animations, video, or audio. I recommend you either (a) change the list 
in the Note to include "text" and "executable content" or (b) remove the 
Note and include "recognized" (and perhaps "rendered") in the wording of 
the individual success criteria (as is done for other Guidelines). 
(Priority: 3 Low) (Type: Clarify)

#112. (Re 5.1.1) Provide define ARIA: Please include a link to a 
glossary entry for WIA-ARIA. (Priority: 3 Low) (Type: Formatting)

#113. (Re 5.1.1) Does ARIA only address textual messages?: I'm not 
familiar enough with WIA-ARIA, but this success criteria recommends its 
use or equivalent for text messages but ignores non-textual messages 
such a graphical pop-ups. Is that intentional or accidental? (Priority: 
3 Low) (Type: Clarify)

#114. (Re 5.1.2) Forms, or forms and equivalent?: I find this a success 
criteria a bit confusing. First, it explicity applies to form 
submissions, but it's not clear to me what all would count as form 
equivalents. For example, I presume an email composition window would 
count, and the "Send" button or menu item would be the submitting 
control, as would a "Save" button or menu item. But what about the mail 
client's window showing headers for messages in your mailbox? If you 
press Enter to open a window showing the contents of the seleted 
message, is that a submission, and is the list item representing the 
message header the submitting control? Second, if a form package is 
implemented such as, say, pressing Enter moves the focus to the Send 
button and then activates it, that would seem to exempt them from this 
success criterion, because the focus would be on the submitting control 
when the control performs the submission--even though the distinction 
may be completely invisible to the user. For that last case, the 
distinction you really mean is for the focus to be on the submitting 
control before the user issues the command that activates it. I admit 
it's a pretty esoteric distinction, but it's just an example of what I 
perceive as this SC's ambiguity. (Priority: 3 Low) (Type: Clarify)

#115. (Re 5.2.New) Additional methods of helping users avoid and correct 
mistakes: It seems that there are numerous other techniques that are 
equally or more effective at helping users avoid and correct mistakes, 
compared with the (only) one that is included for this guideline. A 
prime example would be an Undo function. Compare with the ISO 9241-171. 
(Priority: 2 Medium) (Type: Expand)

#116. (Re 5.3.1) "Web Content" vs. "Online": Bullet A says the user 
agent accessibility document must be "Web content and conforms to WCAG 
2.0 Level 'A' (although it is not necessary for the documentation to be 
delivered on-line)". To me, these terms seem backwards, as I interpret 
"web content" to mean "delivered via the World Wide Web" whereas I 
interpret "delivered on-line" to mean electronic regardless of whether 
it's provided on a CD-ROM, installed locally with the product, residing 
on a remote server and viewed via the Web. By my definitions the phrase 
should read "Electronic content that conforms to WCAG 2.0 Level 'A'. (Or 
perhaps "in a Web-compatible format and conforms to WCAG 2.0 Level 'A'", 
but what do the terms "Web content" or "Web-compatible format" mean, and 
what is "not Web content" when almost anything can be delivered over the 
Web and rendered by user agents and their plug-ins? (Priority: 3 Low) 
(Type: Clarify)

#117. (Re configure, control, user option) : "A global configuration is 
one that applies across elements of the same Web resource, as well as 
across Web resources." makes it sound like applying "across elements of 
the same Web resource" is more "global" than "across Web resources". I 
would suggest rewriting to read "A global configuration is one that 
applies across Web resources as well as across elements of the same Web 
resource." (Priority: 3 Low) (Type: )

#118. (Re configure, control, user option) : I think of "global" options 
as ones that applies across pieces of software running on the same 
platform. Examples include changing default foreground and background, 
and selection colors in the Windows Control Panel or Macintosh 
Preferences. Any option which only applies to a single user agent I 
would not consider a global option. (Priority: ) (Type: )

#119. (Re General) Add persistent per-site and per-resource settings: 
There are many success criteria allowing the user to make global 
settings changes and to make temporary settings changes for a specific 
Web age or session. Consider adding one or more Level AAA success 
criteria to the effect that the user agent should (ideally) allow the 
user to set persistent settings for specific sites and resources. 
Examples might include turning off all scripts loaded by a particular 
Web page, or overriding author-specified colors when viewing any page on 
a specific Web site. These would make life much easier for users who 
otherwise are forces to constantly change global, coarse-grained 
settings to adapt to each Web resource they're viewing, or making 
temporary settings adjustments every time they visit a particular 
resource. (Priority: 3 Low) (Type: Expand)

#120. (Re General) Normalize capitalization of SC titles: The titles of 
most success criteria have each word capitalized (e.g. 4.1.9), but some 
only capitalize the first word (e.g. 4.1.10). These should be 
normalized. (Also note that, unlike most success criteria, only the 
first words of Principles and Guidelines are capitalized.) (Priority: 3 
Low) (Type: Formatting)

#121. (Re General) : Should we discuss key combinations? (Priority: ) 
(Type: )

#122. (Re General) Define or replace the term "Multimedia": The document 
usually uses the term "multimedia" to include single media that includes 
anything other than just text. (Priority: 3 Low) (Type: Clarify)

#123. (Re Glossary) Cross-reference all terms defined by the same entry: 
I hope that the final glossary, when a single glossary entry is used to 
define more than one term, will include cross-references from all terms 
to their shared definition. For example, the glossary should have 
entries for "values" and "defaults" that say "See 'properties, values, 
and defaults'". This is not an absolute necessity when the user is 
reading the document online and can follow links to or search the 
document for the definition of a term, but it's vital when the reader is 
working from a paper copy and would have to scan the entire glossary to 
find that the definition of "defaults" is buried in the entry sorted 
under "properties".  (Priority: 2 Medium) (Type: Formatting)

#124. (Re Glossary) Define the term "toolbar": I recommend adding a 
glossary definition for "toolbar". By noting there that toolbars only 
occur in "graphical user agent user interfaces", we can remove that 
wording from 4.8.1 and avoid the issue of why the explicit restriction 
is not also used for other success criteria relating to toolbars. The 
glossary entry can also address the fact that "Depending on the 
capabilities of the underlying display technologies, toolbars may be 
allowed to 'float' in a user-specified position relative to the screen, 
or they may be 'docked' to a user-specified position relative to the top 
level viewport. Similarly, 'docked' toolbars may overlap other viewport 
content or they may reduce the size of the viewport to ensure they do 
not overlap." Again, that would allow us to avoid addressing that in 
4.8.1. (Priority: 2 Medium) (Type: Clarify)

#125. (Re Glossary.Active End of Selection) Define active and fixed ends 
of a selection: A glossary entry should be added for the fixed and 
active ends of a selection. Most operating environments have the concept 
that a selection extends between a fixed or stationary end (typically 
where the selection process was started) and an "active" end that 
continues to move as the user adjusts the selection. For example, the 
user typically selects a region by moving the mouse while holding down a 
mouse button; the selection extends from the location where the button 
was first depressed (the fixed end) to the current mouse location or 
where it was when the button was released (the active end). During that 
process the viewport should move to keep the latter end in view. 
Similarly, users typically use the keyboard to select a range of text by 
pressing navigation (e.g. arrow) keys while holding down a modifier 
(e.g. shift) key; if they start with no selection, just a cursor in 
between to characters, and hold down the Shift key while pressing the 
right arrow key, the cursor will move one character to the right, and 
the selection will extend from the cursor's original location (the 
"fixed end") to its new location (the "active end"), thus including the 
single character in between. While continuing to hold down the Shift 
key, subsequent right arrow keys will extend the selection by moving the 
cursor (the active end) to the right, while presses of the left arrow 
key will shrink the selection by moving the cursor to the left.  
(Priority: 2 Medium) (Type: Clarify)

#126. (Re General) Compare with ISO 9241-171: I didn't have time to do a 
complete comparison between this draft and ISO 9241-171, but I'm puzzled 
by some of the obvious discrepancies... (Priority: 1 High) (Type:)


    Thank you and I remain at your service,
    Greg Lowney
    Lowney Access Research, LLC
    http://www.access-research.org