- From: earl.johnson <Earl.Johnson@eng.sun.com>
- Date: Tue, 30 Nov 1999 11:27:27 -0800 (PST)
- To: w3c-wai-ua@w3.org
- Cc: Earl.Johnson@eng.sun.com
Must have been to much turkey this weekend... I re-read General Comments C.
and D. and they didn't make sense so I've updated them below in hopes they'll
be clearer. Sorry for any confusion my written confusion caused. Please toss
out the 11/29 review and use this one.
Thanks, Earl
==========
UA Guidelines review, rev. 1
GENERAL COMMENTS
A. While content display capabilities are important it is also
important to ensure that the feature control portions of the UA UI
are also accessible. The later means things like adjusting
properties, getting to a menubar and it's entries, getting to and
navigating secondary windows, choosing a location, etc. The
guidelines explicitly address the content aspect but only implicitly
address the features control aspect. With all the focus on content
display there's a real risk that important aspecdts of the rest of
the UA will be overlooked. It'd be nice to see the features aspect
addressed or called out specifically in applicable guidelines. The
guidelines this comment applies to are #2, #5, #7, #10 and perhaps
#4. #4 provides a nice example for how this clearness can be
achieved.
B. Out of curiosity: Has someone sat down with the Web Content,
Authoring Tools, and UA guidelines to verify that the UA guidelines
cover all the UA dependencies covered in the Web Content and
Authoring Tools guidelines? It would be bad if the Web Content and
Authoring Tools guidelines called for things the UA guidelines
doesn't touch on.
Adding the forgotten words...
C. The guidelines and checkpoints in the document should stand alone so
the reader has a pretty good idea of what they mean without having
to rely on the Techniques document to explain what is meant.
Translating what was said originally into English...
D. Sometimes the same basic checkpoint is found in more than one guideline.
For example, checkpoints 1.3 and 10.3 seem like they could just as
easily be merged into a single checkpoint under guideline #1 or #10.
Taken as a whole, the checkpoints can be thought of as a long lists
of requirements which, from a development perspective, can be
overwhelming. While the checkpoints themselves say nothing about the
engineering effort required, I think reducing their number if
possible will make the accessibility effort seem like a less
daunting one to the developer. So the suggestion is look for
opportunities to remove checkpoints whose removal won't effect the
guideline's completeness. My review contains a couple candidates for
consideration.
SPECIFIC COMMENTS
Section 1.5
A. It's probably beyond the scope of this document and to early but it
would be nice if a statement could be made about 508 and what
minimum priority level is needed to enable compliance. Since access
novices will (hopefully) be using this guideline when they design or
redesign their UA, it might be good to add in another short section
that gives highlights of or makes general statements about 508, the
ADA, and the Telecom Act.
Section 2 - UA Guidelines
Guideline #1
Checkpoint 1.1 - The second sentence should be removed because it feels
like a design decision. It's a good point though so move it to the note
or Techniques document.
Guideline #2
A. In the description paragraphs, are there formats from other areas that
should be called out? SMIL is mentioned, is there anything from TV
or other areas? I'm just wondering because th UA enables all sorts
of technology convergence.
Checkpoint 2.3 - I think of speech recognition when I see the term
natural language. Is that what is meant here? If no, perhaps a better
description can be provided so the reader doesn't need to leave the
guidelines to verify what natural language means in the checkpoint.
Checkpoint 2.7 - What if the object isn't video or audio? Is this
checkpoint just for timed media or does it cover things like graphics
or interactive objects that say nothing about themselves?
Checkpoint 2.9 - Natural language again. The Techniques document
suggests this applies to the language that content gets displayed as or
was written in. Given the speech recognition conotations mentioned in
2.3 do you think something besides natural language might be a better
descriptor?
Guideline #3
A. A number of the checkpoints mention rendering. Should they be under
Guideline #10 since it's sub-guideline calls out rendering or should
rendering be moved from #10 to this guideline?
Guideline #4
A. Mentioning speech rate and pitch suggests to me the UA is the one
providing the audio service.
1. Does this aspect of the guideline still hold true if the platform
the UA is running on provides the service?
2. Isn't it the audio service that should provide the control?
3. Does this mean the UA will need to provide a controller UI for
all the audio services the user might have (e.g. different TTS
devices)?
Checkpoints for the UI - a major design access problem we run across is
windows that don't give an object input focus when they're made
activate. I'm not sure if it should be here or under guideline #7, #8,
or #9 but a checkpoint should say that a component needs to be assigned
input focus for the content -and- feature control portions of the UA
UI. This goes back to my general comment saying the feature control
aspect of the UA UI needs to be explicitly covered.
Guideline #5
A. From the Authoring Tools Guidelines: "Guideline 7. Ensure that the
authoring tool is accessible to authors with disabilities." The
first descriptive paragraph for it states: "The authoring tool is a
software program with standard user interface elements and as such
must be designed according to relevant user interface accessibility
guidelines."
1. While this excerpt doesn't yet specifically cover custom
components it does basically say use the platform's UI toolkit
when buuilding the authoring tool. I don't see the same clarity
in this document. It's important that this document say something
similar to: a) use the platform's standard UI components whenever
possible and ensure that custom components provide equivalent
accessibility information as standard UI components in the same
programmatic way or b) ensure UI components not based on a
platform's standard UI toolkit provide information and events
equivalent to that found in currently available accessibility
APIs (i.e. JAAPI and MSAA). My recommendation is this be a new
checkpoint(s).
2. Is this a guideline #4 point instead since it talks about the UI?
B. As noted in the Techniques document Java Accessibility API and MSAA
are public APIs. They enable the designer to easily make the feature
control aspects of the UA's UI accessible and can be extended to
cover many accessibility aspects of the content display. For
example, JAAPI directly supports not only buttons and comboboxes but
editable text also. But unlike DOM, SMIL, and other W3C specs they
aren't mentioned in the main guidelines. Since they are relevant,
why aren't the JAAPI and MSAA standards specifically mentioned as
examples in this document also?
Checkpoint 5.1 - What API(s) is it refering to?
Checkpoint 5.4 - Should this be moved to guideline #8 since it has to
do with orienting the user?
Checkpoint 5.5 - How about rewording it to something like "Provide
programmatic support that enables access to notification of changes..."
This checkpoint appears to be aimed at situations where an assistive
technology (AT) is utilized. For performance reasons I think the AT (or
other UA talking to, the prime UA for that matter) should ask for the
notification first before the UA starts providing it. The important
point is to provide programmatic facilities in the UA so an AT or other
technology has a clear place to go in the UA to let it know that they
want notification of various events.
1. Since it's change oriented shouldn't this one be in guideline #9
instead?
Checkpoint 5.6 - This feels like a guideline #6 checkpoint because it's
aimed at content.
Checkpoint 5.7 - What does this mean from a UA perspective when things
beyond it's control (e.g. the network) impact the performance? How does
a developer know what this means as it applies to the UA? How will they
know when they've successfully achieved this checkpoint? This
checkpoint should be reworded or a better example cited so what is
meant is clearer or the checkpoint should be removed.
1. General related document comment: the guidelines contain both
specific and general guidelines all mixed together. The
Techniques document provides clarity on some of the general ones
but not all.
a. How will the developer know when they have successfully met
those guidelines like the above?
b. What meaning does the Conformance seal of approval being
designed have in situations like this where the determination
of successful achievement depends so heavily on how well the
developer thinks they've done?
Guideline #6
A. Guidelines #5 & #6 without the checkpoints say the same thing to me.
But as I read the descriptions and checkpoints associated with each
guideline #5 seems to be oriented towards the feature control aspect
of the UA UI and #6 seems to be content display oriented.
1. The wording of the 2 guidelines should be worked on so it's clear
what they cover without the need of looking at the checkpoints to
ascertain what they're covering.
2. If my impressions of #5 & #6 are right then #6 should only contain
content oriented checkpoints and #5 should only contain feature
control oriented checkpoints.
Guideline #7
A. Comments on guideline wording and descriptive paragraphs
1. Regarding the sub-guideline: "Provide navigation mechanisms that
meet the needs of different users: serial navigation for context,
direct navigation for speed, search functions, structured
navigation, etc."
a. This starts off talking about the user but after the : symbol
it talks about techniques in a way that doesn't connect it
to the user. What does serial navigation for context and
direct navigation for speed mean?
b. I think everything after the : should be removed (especially
since they're better covered in the descriptive paragraphs)
or tied better to the user or reworded.
2. The descriptive paragraphs seem to only talk about content display
navigation. Navigating the feature control aspects of the UA's UI
should also be specifically covered (see general comment A at the
top). In case the guideline's Note was meant to do this - the
Note doesn't make this point clearly.
3. The Note covers search, navigation, and location of input focus.
The input focus shouldn't be mentioned here since it's covered in
guideline #8 or the connection between input focus and
search/navigation should be made clearer in the Note or
descriptive paragraphs.
Guideline #8
A. Regarding the sub-guideline: "Provide information about resource
structure, viewport structure, element summaries, etc. that will
assist the user understand their browsing context."
1. The wording as I read it says it's aimed at the content author not
UA. How about the following as a possible clarification
alternative: "Enable user to get at content meta data to assist
in understanding of browsing context (e.g. resource structure,
viewport structure, element summaries, etc.)"
2. I don't know what is meant by "element summaries." It would be nice
to see it touched on explicitly in the descriptive paragraphs or
pointed to as a glossary term.
3. There should be more information on resource structure, viewport
structure, and element summaries in the Techniques document as
well as what other related structure etc. need to be exposed so
that it's clearer to the developer what all they need to do.
B. Keeping with general comment A, it should be stated that both the
content display -and- feature control of (rest of) the UI need to
clearly show focus.
1. For developers using a platform's UI toolkit, it's for them easy
to think that the toolkit covers the focus issue however this
isn't necessarily so, especially when custom components are
utilized, and is something that the developer needs to explicitly
verify.
Guideline #9
Checkpoint 9.1 - The "to the user and through APIs" part isn't clear.
This isn't right either (because not all UAs will have a visual
display) but "visually and programmatically" seems closer to the point
it appears to me the checkpoint making.
1. I'm confused about the user part because the user gets the
information regardless of how the information is made available.
2. Specifically stating API sounds like the document is prescribing
what is necessary to successfully acheive this checkpoint. As
nice as it would be to do this, I don't think that's the
intention of the document. Stating programmatic allows the
developer to choose whether or not an API is the way tthey'll
achieve this checkpoint.
Checkpoint 9.2 - I don't understand what this one is telling the
developer to do. Adding a clarification example and/or working over the
wording would be helpful.
Guideline #10
A. How about making the descriptive, one sentence paragraph the the
sub-guideline? i.e. Replace "Allow users... the software." with "Web
users..."
1. The mention of rendering, mouse, keyboard, the user interface in
the guideline makes this guideline feel redundant to others
already covered under separate guidelines.
B. General guideline comment: What exactly does input configuration mean?
Perhaps this should be defined in the guideline's descriptive
paragraph so developers are better able to translate it's meaning
into the design of their UA.
Checkpoint 10.3 - I have a problem with this checkpoint because it
really covers 2 things - what the UA should provide and what it should
enable - but it doesn't present it that way. Single-key capabilities,
for example, are directly achievable by a UA however single voice
command is only possible if the UA provides it's own speech recognition
engine that the user can configure. Staying with the speech recognition
example, it may very well be a service provided by the platform which
the UA knows nothing about (and shouldn't have to). This needs to be
made clearer in the checkpoint as does what the developer needs to do
to meet it (they can do single-key but they can only be expected to
provide programmatic support that lets any input device control it).
1. What is the difference between this one and checkpoint 1.3?
2. If the plan is still to keep this checkpoint basically as it
stands then how about:
a. Move the second sentence should be moved into the
checkpoint's descriptive paragraph because the main point is
the change and control part.
b. Reword the checkpoint to something like "Allow the user to
change and control how they interact with the user agent."
Checkpoint 10.4 - What's this checkpoint saying? It's descriptive
paragraph doesn't add enough clariuty for me. The example is mnemonics
oriented but what should happen if, for example, speech input is used?
Confounding this, input configuration suggests to me the method the
user employs to do input but the example at least is more guideline #8
or #9 oriented.
Checkpoint 10.5 - How about rewording to something like "Avoid default
input configurations that conflict with operating system navigation,
control, and access conventions."
1. The access addition pertains to things like using 5 taps of the
shift key to do something other than invoke StickyKeys.
2. The Techniques document should include a mention of the StickyKey,
etc. keyboard invocation key sequences also since most desktop
platforms provide them these days.
Checkpoint 10.8 - Does this mean reconfigure where components in the
content display and feature control parts of the UA are?
1. This highlights the general difficulty I have with this
document - it's not clear when it's talking about the content
part and when it's talking about the rest of the UI part. The
Techniques document does happen to add partial clarity (it's the
feature control part) in this case but the guidelines be clear so
they shouldn't have to. Additionally, it's not clear if this
means the user should be able to control the actual component
layout of the UA.
Received on Tuesday, 30 November 1999 14:27:17 UTC