Some comments on UAAG 1.0 Last Call, Nov 2000

(Per request, resending to the public alias)

Hi Ian,

Here are my comments on the current version of the W3C WAI User Agent
Accessibility Guidelines (http://www.w3.org/TR/2000/WD-UAAG10-20001023/).
These do not necesssarily reflect the opinions of everyone at the company.

On the whole I think it is quite good. However, there are a very small
number of things that I feel strongly need to be fixed, and there are some
things I think are still confusing or not yet quite right. My suggestions
and questions for clarification are below. 

I want to thank the entire working group and contributors for all for the
incredible amount of thought and work you have put in; it really shows.
These will be very useful in helping guide developers and helping improve
future guidelines for accessible software design. I certainly hope my
suggestions are useful to you as you continue to refine the document.

    Best wishes,
    Greg Lowney
    November 13, 2000

Note on formatting: The list of comments is divided into sections by
priority, and within each section the comments are sorted according to their
checkpoints. Each comment consists of four fields: the checkpoint number
(followed by a letter if there is more than one comment for that
checkpoint); a paraphrased title for the checkpoint (to orient the reader
without requiring reference back to the guidelines document); my comment;
and the priority I assign to the comment (high, medium, or low, depending on
how strongly I feel it should be addressed in order to improve the
document). Comments are separated by blank lines, and fields within each
comment are separated by the TAB character.
High Priority Comments

General		Overall, I do not feel that the guidelines are yet specific
enough to be testable in an objective fashion. That makes them fine as
guidelines to help guide developers, but difficult to implement fairly as a
standard to measure against. I recognize that it's difficult to be concrete
when trying to maintain platform, device, and technology independence, but I
would still encourage you to review the guidelines and techniques documents
and ask yourself whether disparate parties, reviewing the same software,
would reliably come to the same conclusion as to level of compliance. I have
tried to call out some of the places where checkpoints were especially
notable for giving far too much leeway or too little guidance in this
regard. As has been suggested before, I think a good steps would include:
clearly label techniques as minimal requirements vs. recommendations vs.
examples; clearly indicate when user agents need to implement all of the
requirements, any one of the requirements, or select between groups of
requirements that need to be implemented together; clearly prioritize
optional steps; and give examples of how a person would evaluate a product
for compliance.	Priority 1 - High

1.1A	Make all functionality available through every supported input
device and input API:	I still find this overly broad, and causing
complications in other checkpoints. In particular, I disagree with the
implication that a user agent must take an "all or nothing" approach to each
input modality: according to the current wording it's OK to support no
functionality by mouse or voice, but if you use them for anything you have
to use them for everything. I consider keyboard to be the only required
input method on the Windows platform, and feel it's acceptable to support
other input methods only for selected shortcuts. I firmly believe that
browsers will begin supporting voice input natively but only for a limited
set of tasks. If you do not change this checkpoint, they will end up
ignoring it.	Priority 1 - High

1.1B	Make all functionality available through every supported input
device and input API:	The sentence "Developers are not required to
reimplement input methods of APIs, e.g., text input through a mouse API or
pointer motion through a keyboard API" further obscures exactly what is and
is not required of the user agent. I think you need to provide some better
guidance on this distinction.	Priority 1 - High

1.4	Let the user interact with all active elements with any supported
input device:	I feel this is too broad, and that you should clarify what
is the responsibility of the user agent, the operating system, and
third-party accessibility aids. For example, clarify whether each agent is
be required to provide an on-screen keyboard if they run on a platform that
does not have one generally available. Is it sufficient if one is available
commercially?	Priority: 1 - High

Medium Priority Comments

1.2	Use standard input and output APIs:	I still believe this should
be priority 2 if the information is exposed through other programmatic means
that are standardized for the operating system. To do otherwise is to limit
progress by requiring the application to use API that may be considered
limiting and nearing obsolescence. Earlier discussions of this got bogged
down on pros and cons of specific API, but that misses the point: if a
platform defines more than one API for exposing screen content, do you have
to use the one that also draws text to the screen? I believe the answer is
no, because on some platforms that API may not be the one that AT devices
can monitor, and it may not provide as much information as another API. The
key, in my opinion, is that applications should do what is best for
accessibility, which is not always what is the standard convention, but will
instead vary from one platform to another, and over time as different API
become commonly used and supported by AT.	Priority: 2 - Medium

2.1	Content through UI:	I feel the description of 2.1 is too vague
on exactly what portions of the content are satisfied by providing a
document source view. You say it's good enough for some things, but not
everything, and give a few examples but no clear guidance on how to
extrapolate to other cases.	Priority: 2 - Medium

2.3	Access to equivalents:	The techniques document should refer users
to the section that has a list of equivalencies supported in HTML. In
particular, I would like to see it call out NOFRAMES as an equivalency that
is often overlooked, but to which the user should have access.	Priority: 2
- Mmedium

3.8	Make images optional:	I recommend expanding the wording of the
checkpoint to make explicit that they should provide be configurable to
replace the graphic with a textual equivalent or repair text, rather than
merely omitting it. This is in techniques but I think it is key enough that
it should be in the checkpoint wording.	Priority: 2 - Medium

4.1	Allow configuring font sizes:	My experience is that allowing the
user to override font sizes is extremely useful, but also can also cause
some pages to become unusable if they specify the size or location of
elements in absolute values (for example, width="100px"). I believe that in
order to make adjustable font sizes truly usable, the user should also be
able to instruct the user agent to override all absolute sizes.	Priority: 2
- Medium

4.3	Allow configuring text colors:	You need to define "system colors",
as this has a very specific meaning in the Windows operating system (the
list of colors that the user has assigned to system UI elements) that is not
the same as what you mean (the range of colors supported by the system).
This affects several UAAG checkpoints.	Priority: 2 - Medium

4.5A	Allow configuring presentation speed:	Some checkpoints such as
this one have Techniques that include benefits as well as implementation
techniques. There was talk about clearly separating or categorizing the
bullet items in Techniques but that does not appear to have happened yet, or
not consistently.	Priority: 2 - Medium

4.5B	Allow configuring presentation speed:	Define "not recognized as
style" in the sentence "Allow the user to slow the presentation rate of
audio, video and animations that are not recognized as style." I cannot
figure out what this means, nor why you would want to not allow the user to
override attributes of things that fit that category. Or, if you mean
"Allow...and animations that are not recognized. Use styles to make this
configurable" then you should restructure the sentence to make that clearer.
This is also an issue with 4.6, and affects 4.8 and 4.9.	Priority: 2
- Medium

4.7	Allow positioning of transcripts and captions:	I still feel this
seems very difficult to implement. Have UA vendors signed up to meet this
requirement? (I also feel it is more appropriate as Pri 2; I will defer to
the group since you discussed it at length and decided to stay with Pri 1,
but I remain unconvinced.)	Priority: 2 - Medium

4.11	Allow independent confguring volumes of audio sources: 	Why is this
limited to sources that are synchronized to play simultaneously? Shouldn't
it apply to all sources? If the restriction is removed, 4.13 (allow speech
volume to be controlled independently) would be reduced to a special case of
4.11.	Priority: 2 - Medium

4.12A	Allow configuring speech playback speed:	This checkpoint is
ambiguous and confusing because it mixes two different issues. I recommend
it be broken up into one checkpoint that keeps the first sentence ("Allow
the user to configure and control synthesized speech playback rate according
to the full range offered by the speech synthesizer"), but that the
remaining sentences (which specify the desired minimum ranges) be broken out
into a second checkpoint targeting providers of hardware- or software-based
speech synthesizers, because user agents usually have no control over the
range of speeds provided by the speech synthesizers available on a given
system. Breaking it out in this way would limit its applicability to those
UA manufacturers who provide their own speech system and thus do have
control over the supported ranges.	Priority: 2 - Medium

4.12B	Allow configuring speech playback speed:	The statement "The
user must be able to increase or decrease the playback rate in increments of
5% of the current playback rate" leads to problems. If the engine allows the
user to select a speed of one wpm, then this wording requires them to
support increments of .05 wpm, which is clearly not useful to the user.
Priority: 2 - Medium

4.12C	Allow configuring speech playback speed:	You do not
specifically require overriding author-specified speeds, as you do in other
checkpoints. Perhaps that is implied, but if so why do you explicitly
mention it in other cases?	Priority: 2 - Medium

4.16	Allow configuring selection highlighting:	Requiring the option
to use a specific font face for selected text is unrealistic as it may often
require the entire document to reflow and repaginate, taking up far too much
time as well as being very confusing. This is also true of changing font
size and some other text formatting, such as bold, expanded, and condensed.
Therefore I would make it optional, rather than required, that the user be
allowed to select those attributes for highlighting. This also applies to
4.17 (allow configuring focus highlighting) and 8.2 (allow configuring
highlighting of recently visited links).	Priority: 2 - Medium

4.17	Allow configuring focus highlighting:	The default highlight for
focus should not only differ from that used for selection, but they must
both be discernable when applied to the same text. For example, you cannot
have selection indicated by blue and focus by red, or by small and large,
because text could not be displayed with both attributes at the same time.
Priority: 2 - Medium

4.18	Make optional whether focus moves automatically to new viewports:
I see this a beneficial but only important enough to warrant priority 3
instead of 2. If, for example, an aid tells the user a new viewport has the
focus, and if the OS allows returning to the previous window with a single
keystroke, this seems like an annoyance rather than a serious obstacle.
Priority: 2 - Medium

4.20A	Allow the user to control opening and closing of viewports:	If
the user agent should let the user control opening of viewports, should they
not also control automatic closing of viewports? The current wording only
requires that the user be able to manually close a viewport, not that they
should be able to prevent automatic or script-directed closing of the
viewport. I would add the latter.	Priority: 2 - Medium

4.20B	Allow the user to control opening and closing of viewports:
Should also allow merely prompting for confirmation, rather than forcing the
user to open the viewport manually (as is indicated by the current wording).
Priority: 2 - Medium

4.20C	Allow the user to control opening and closing of viewports:	I
fear that many pages will fail to work well if the user does not allow
frames to open. In that case, should the user agent render the noframes
equivalent, or simply hope the user will eventually open the new frame?
Priority: 2 - Medium

4.21A	Allow keeping the focus viewport on top:	4.21 seems redundant
to 4.20; if you notify the user and don't open the viewport automatically,
that is nearly equivalent to opening it but not giving it focus.
Priority: 2 - Medium

4.21B	Allow keeping the focus viewport on top:	4.21 is not relevant
only to graphical user interfaces, but to any agent that supports
overlapping viewports. This can be supported in character-based environments
such as MS-DOS.	Priority: 2 - Medium

5.8	Follow operating system conventions that benefit accessibility:	The
first sentence is great, but the second ("In particular, follow conventions
for user interface design, keyboard configuration, product installation, and
documentation") makes too many assumptions when listing specific OS
conventions and saying they benefit accessibility on all platforms and
situations. Operating system standards do not always support accessibility.
For example, one could imagine that on some platforms it is standard to not
provide keyboard UI for some operations, or where the standard documentation
format or installer are not the most easy to use for people with
disabilities. I recommend softening the wording to say that those examples
"often" or "usually" benefit accessibility and in those cases should be
followed.	Priority: 2 - Medium

6.2	Use W3C standards where appropriate:	I recommend you clarify in
the checkpoint wording that it only applies to content. For example, HTML
could be used for presenting user agent UI, but we would not want to imply
that such is required. Right now the scope (that it applies specifically to
content) is only conveyed by headings between the guidelines, but is not
evident from the wording of the guideline itself, and thus is lost if the
guideline is quoted out of context.	Priority: 2 - Medium

7.3A	Allow navigation to all active elements:	I feel that the
minimum requirements to comply with this checkpoint are too low. It says "If
the author has not specified a navigation order, allow at least forward
sequential navigation of elements, in document order." If a user agent were
to provide only this method of keyboard navigation, I would not want it to
be considered accessible. That would definitely be a case where it would be
so cumbersome as to be considered unusable.	Priority: 2 - Medium

7.4A	Allow navigating only to active elements:	The definition of
active elements is a bit vague. By the current definition, the only things
that are not active elements are static text, static graphics, blank space,
and disabled controls. Everything else takes input: read-only text could be
considered to have a default action of becoming selected, and selected text
might be considered to have a default action of copying the text to the
clipboard. I do not believe that is what you intended when discussing
navigating only to active elements. It would work, of course; one could
imagine navigating through a document and putting focus on each range of
text that separates other elements that take input, but you would not want
navigation through "active elements" to include every character in such text
because then you're not really skipping much, and so not significantly
speeding up navigation. 	Priority: 2 - Medium

7.4B	Allow navigating only to active elements:	I consider it more
likely that user agents will omit the ability to select text with the
keyboard than that they will omit the ability to move quickly between active
elements. (For example, Internet Explorer lacks the former but has the
latter ability.) And yet, the latter is a checkpoint and the former is not.
That does not seem appropriate to me. 	Priority: 2 - Medium

7.5A	Allow searching rendered text:	Should add that the user agent
should not automatically start searching from the beginning of the document
after reaching the end, unless you inform the user before doing so. Such
"wrapping" around the end of the document is very disorienting, and most
users don't even realize they have started over.	Priority: 2 - Medium

7.5B	Allow searching rendered text:	The wording is using the terms
"viewport" and "point of regard" inconsistently with other uses in the
document. I believe the sentence that describes searching "all text within
the viewport, both inside and outside the point of regard" should read "all
text within the document associated with the viewport, whether or not the
text falls within the visible area of the viewport." This is more consistent
with the use of terms in 4.19, for example, which reads "Ensure that when a
viewport's selection or content focus changes, it is in the viewport after
the change."	Priority: 2 - Medium

7.5C	Allow searching rendered text:	When searching a document, the user
agent should also search equivalent text (such as ALT text of images).
Priority: 2 - Medium

7.5D	Allow searching rendered text:	When searching a document, the user
agent should not search text whose properties prevent it from being visible
(such as text that has visibility="hidden"), or equivalent text for elements
with such properties (such as alt text for an image that has
visibility="hidden").	Priority: 2 - Medium

7.5E	Allow searching rendered text:	When searching a document and there
is a match, the user agent should highlight the found text, preferably by
making that text the selection and giving it the focus in the document
viewport. This change should be exposed programmatically through the DOM,
and by following any platform-specific conventions. This will allow
assistive technology to begin reading from the found text.	Priority: 2
- Medium

8.3A	Allow configuring highlighting of links that invoke a fee:	I
recommend removing the reference to "fonts" from the passage "For graphical
viewports, offer at least three rendering options, including colors and
fonts. Allow the user to select from among the range of system colors and
fonts." Requiring the option to use a specific font face for temporary
highlighting is unrealistic as it may often require the entire document to
reflow and repaginate, taking up far too much time as well as being very
confusing. This is also true of changing font size and some other text
formatting, such as bold, expanded, and condensed.	Priority: 2 - Medium

8.3B	Allow configuring highlighting of links that invoke a fee:	You
may want to add a recommendation that the user agent provide an option to
prompt for confirmation when the user activates a link that invokes a fee.
That fits into the general usability principle of "forgiveness," meaning
allowing easy recovery from incorrect actions.	Priority: 2 - Medium

8.6	Support system standards for selection and focus:	The
checkpoint reads "Implement selection, content focus, and user interface
focus mechanisms. Implement them according to system conventions... This
checkpoints refers to the logical selection and focus...," but I'm afraid
that this one is very vague to me, so I recommend adding further
clarification. What exactly are you trying to require?	Priority: 2 - Medium

8.8	Highlight and identify active elements:	This seems to be confusing
the concepts of 'active elements' and 'focus'. The checkpoint wording seems
to state that the user agent should provide a way for users to easily
identify all the visible active elements (for example, providing an option
to draw a consistent, recognizable border around all links, command buttons,
and so forth). However, the Techniques imply that it is sufficient to allow
the user to configure how the element with focus is displayed. That is not
only different from the checkpoint, but it is less useful (since the user
would have to navigate through all elements to identify those that are
active) and already covered in 4.17.	Priority: 2 - Medium

9.3A	List author-specified input shortcuts:	The techniques should make
clear whether it is sufficient to provide a separate list of keyboard
shortcuts, or whether they need to be displayed in the user interface and/or
document itself.	Priority: 2 - Medium

9.3B	List author-specified input shortcuts:	Does this also require the
user agent to display information about elements that take mouse input (e.g.
via scripts)?	Priority: 2 - Medium

9.5A	Allow remapping keyboard shortcuts:	9.5 ("Allow the user to
assign a single-key binding to at least a majority of the functionalities
available in the default keyboard configuration") seems entirely redundant
to, albeit a subset of, 9.4 ("For any binding in the default keyboard
configuration, allow the user to override it with a binding of a single key
alone or with modifier keys"). If there is something additional here perhaps
you could more clearly call it out.	Priority: 2 - Medium

9.8	Provide keyboard shortcuts for basic actions:	Please clarify that
providing brief key sequences rather than single keystrokes or key
combinations satisfies this checkpoint. For example, in Internet Explorer
the sequence of ALT+A followed by A will "add to favorites". That sequence
actually displays and menu and activates the command on that menu, and no
additional keyboard shortcut seems necessary. The checkpoint does not
explicitly say that single-key or key combinations are required to comply.
Priority: 2 - Medium

10.1	Provide documentation in accessible HTML:	I believe that it is
important for documentation to be available in accessible formats, but HTML
is not the only accessible format. Also, if documentation is not extensive,
then being in accessible but more cumbersome formats would be tolerable. In
addition, it can be very difficult to produce an HTML version of
documentation that was originally designed to be contextual help composed of
many small topics and designed to be accessed directly or indexed rather
than read sequentially. I would recommend documentation be provided as a
separate HTML document, but I feel the requirement should just be to be in a
format generally recognized as accessible.	Priority: 2 - Medium

10.5	Document product changes that affect accessibility:	I would
explicitly require product changes affecting accessibility to be referenced
in the dedicated section of the documentation devoted to product
accessibility (checkpoint 10.4).	Priority: 2 - Medium

New-A	Expose user agent or global preference settings	A user agent should
provide a documented mechanism for scripts and plug-ins to query preference
settings that affect accessibility. For example, if the user agent has an
option to replace each animated image with a static images, a script or
add-in that is designed for that user agent should be able to query that
setting and use the value to adjust its own behavior.	Priority: 2 - Medium
Low Priority Comments

3.2A	Make audio, video, and animation optional:	Animation is a
broader category than animated images. This checkpoint should apply to all
animations, not just those that are commonly thought of when referring to
"animated images".	Priority: 3 - Low

3.2B	Make audio, video, and animation optional:	Please excuse me if
I'm behind on the state of the art, but we had a discussion a while back as
to whether there was any means to coordinate between the user agent and a
plug-in or external rendering agent, so that the latter can adjust its
presentation to the preferences set in the user agent (such as the
preference setting to display animation as a still image). We would like to
see user agents support such mechanisms.	Priority: 3 - Low

3.4	Make image blinking and animation optional:	3.4 ("Allow the user
to configure the user agent to render blinking images as motionless images")
overlaps with 3.2 (make audio, video, and animation optional).	Priority: 3
- Low

3.6	Let the user control client-side redirection:	I think allowing the
user to control client-side redirection is valuable when a page is displayed
for a time before the redirection takes place, but is less useful or
important when the redirection is instantaneous. In that case it may be more
annoying than helpful; after all, the redirection is supposed to be
invisible to the user.	Priority: 3 - Low

4.13	Allow configuring speech volume:	Clarify that the user agent
should allow overriding author-specified volume settings.	Priority: 3
- Low

4.14	Allow configuring speech playback attributes:	You might want to
clarify that this checkpoint requires user control over both speech UI of
the user agent and speech that is part of author-supplied content.
Priority: 3 - Low

5.3	Provide programmatic access to content using standard API:	I'd
feel more comfortable with this if examples were provided. 	Priority: 3
- Low

5.7	Support the W3C Document Object Model (DOM) for style sheets:	I
would rate this as priority 2, rather than priority 3, because it provides
the only reasonable programmatic means of adjusting the global presentation
of a document. Low vision tools, in particular, may want to do this, as may
tools for people with cognitive or reading impairments.	Priority: 3 - Low

7.1	Allow navigation between viewports:	You may want to explicitly
note that this must be available through all supported input devices, as per
1.1.	Priority: 3 - Low

7.3B	Allow navigation to all active elements:	Clarify whether it
is sufficient to allow direct navigation with some input devices, such as
the mouse (which is implied by 7.3 and 1.1). I feel direct navigation is
sufficient for the mouse, and that sequential navigation with the mouse
(e.g. a button to move to the next active element) may be desireable but is
not important enough to be required. Anyone who relies on mouse only would
have an on-screen keyboard that allows them to simulate keystrokes for
navigation.	Priority: 3 - Low

7.3C	Allow navigation to all active elements:	The techniques give
examples sequential and direct navigation techniques, and elsewhere you
discuss structural navigation and search. When discussing keyboard
navigation techniques, I also list directional navigation as another class,
and strongly recommend it be implemented in any case where the screen
contains a two-dimensional arrangement of active elements.	Priority: 3
- Low

7.5E	Allow searching rendered text:	I think this checkpoint has a level
of detail that could be left to Techniques; it is certainly more detail than
most have.	Priority: 3 - Low

8.5	Provide information about links:	It would be nice to also
make it easy to tell whether a link was to a resource inside or outside the
current Web site, without the user having to compare URLs.	Priority: 3
- Low

9.4A	Allow configuring shortcuts:	Nice, but not easy to implement and
probably difficult to get user agents to comply. Note the existence of
third-party tools to do this for any application.	Priority: 3 - Low

9.4B	Allow configuring shortcuts:	May want to scope this so it does
not imply that the user agent has to allow the user to change the default
mouse shortcuts (e.g. change the default action on click from "open" to
"display information").	Priority: 3 - Low

9.5B	Allow remapping keyboard shortcuts:	I do not understand the
point trying to be made by the reference to MouseKeys, so I suggest you
clarify that.	Priority: 3 - Low

9.6A	Follow conventions for indicating shortcuts:	Techniques identify
underlined characters as a convention used in Microsoft Foundation Classes
for Windows, but they are really conventions used by Windows and almost all
class libraries for that platform.	Priority: 3 - Low

9.6B	Follow conventions for indicating shortcuts:	Techniques for this
checkpoint lists several things that are not directly related to and much
broader than this checkpoint (e.g. notifying the user when input contexts
change).	Priority: 3 - Low

	Thanks again,
	Greg

Received on Tuesday, 14 November 2000 17:45:08 UTC