- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Wed, 1 Dec 1999 01:15:33 -0600
- To: <w3c-wai-au@w3.org>
Sorry to be so late with my comments, but this has been a terrible month
full of deadlines.
First, let me start by saying what a great document this is, overall. I may
be bias since I bring a fair amount of knowledge to the table with me, but I
found the introduction to be very easy to read and understandable. It was
crisp and comprehensible and this followed through the guidelines, overall.
I think the introductions to each set of guidelines were especially well
written and helpful in providing an explanation of the guideline and a
context for the checkpoints that followed.
Below are my comments. For convenience, I've separated each comment with a
dotted line that begins with GV# to facilitate screen readers and to
provide a reference number for commenting or asking questions.
The comments range from significant issues to minor grammatical. Since
there is a continuum between the two, I just have them all in order
together.
GV#1 -----------------------------
1.0 Introduction
Great - No comments other than that
GV#2 -----------------------------
GL1 - Paragraph 3
Suggest adding word FULL to sentence as in
"Access to FULL user agent functionality through...."
At the end of the paragraph you MIGHT also add a sentence that says
"Full access via the keyboard also facilitates voice access to web pages by
everyone"
GV#3 -----------------------------
1.1 & 1.4
In 1.1 you say that agents are NOT required to implement low level
functionalities
yet in 1.4 you say that EVERY functionality must be available through the
keyboard.
Shouldn't you qualify this one some way as well since it is a special case
of 1.1?
Or you need to say "except ..." in 1.1?
(by the way, marking the special cases as you did here is VERY nice. There
are other places where this should be done as well.)
GV#4 -----------------------------
1.5 Says that all messages to the user must be available via all output
device APIs. [Priority 1]
That sounds like the UA must talk (to send messages out of the audio
channel) if it beeps (uses the audio channel for beeps). ??
GV#5 -----------------------------
GL2 - Paragraph 1
Suggest you add (E.G. CANNOT SEE IMAGES) and (PHONE BROWSER CANNOT DISPLAY
GRAPHICS) to the first sentence as below
"Users may not be able to perceive primary content due to a disability
(E.G. CANNOT SEE IMAGES) or a technological limitation (E.G. PHONE
BROWSER CANNOT DISPLAY GRAPHICS) or configuration (e.g., browser configured
not to display images).
GV#6 -----------------------------
GL2 - Paragraph 3
Suggest the following edit by adding WHETHER and SHOULD BE DISPLAYED
"User agents should allow users to specify whether primary content should be
rendered, or WHETHER alternative equivalents supplied by the author SHOULD
BE DISPLAYED, or both."
Otherwise the referents are unclear and I misread the sentence to be that
the OR was that the user agent should specify that the author should supply
alternative equivalents
GV#7 -----------------------------
GL2 Last Paragraph
The only place where I noticed a sentence that didn't seem to belong was
this last paragraph in this guidelines. (That means - nice writing!)
Here though the topic sentence is
"Mechanisms for specifying alternative content vary according to markup
language."
But the last sentence is on another topic and seems to be just tacked on as
a stream of consciousness.
"The ability to access frame alternatives is important for users of some
screen readers and users with some cognitive impairments."
Perhaps you should put "NOTE: " in front of it or make it a stand alone
sentence paragraph or both
GV#8 -----------------------------
2.2 and 2.6
2.6 seems to be an echo of 2.2
is it an "Important special case of 2.2" ??
GV#9 -----------------------------
2.3 is not real clear. You might add a phrase to explain what that means
without requiring them to go to the techniques document.
GV#10 -----------------------------
2.4 and several others
You mention that something should be controllable but you do not say
anything about the range. Many times these are but only over a range that
is too small to be effective. Suggest you add the phrase "OVER A WIDE
RANGE" to the end of this and other "adjustment" guidelines. The techniques
document can then discuss things like the range (which is usually 5 times
the average response rate or setting - but can be 10 times for some types of
motion).
A couple of other places I notice this are 4.7 and 4.8. You might search
for the word "control"
GV#11 -----------------------------
2.7
You should specify exactly what they should be looking for as "empty". If I
am a programmer I would have no idea EXACTLY which strings I should be
trapping for. No Characters? Something with just a "space"?
Saying e.g. kind of implies that there are a lot of examples (or at least
multiple) and the programmer should know what they are.
GV#12 -----------------------------
Guideline 3 and 6 (and also a bit on 5, 9 and 10)
Up to here (and for most guidelines that follow) you have a very nice
consistent style for presenting the guidelines.
First - you have a short phrase like title for the guideline (in a box)
Second - you have a bold sentence - which I take to be the real guideline.
Third - you have non bold text providing background
In guideline 3 (and 6 ) however you change this format
The title (in the box) of Guideline 3 looks like a Guideline. It is too
long
In Guideline 6 the Title REALLY looks like the guideline. And the Bold
sentence looks like a note -- not a guideline at all.
Guideline titles 5,9 and 10 are a bit too long and look like guidelines
too. However these can probably be fixed by just dropping the word
"standard" from 5 and the word "the" from 9 and 10. 5 may be ok as
it is.
For convenience here are the guidelines in question.
-----
Guideline 3. Allow the user to turn off rendering or behavior that may
reduce accessibility
Ensure that the user may turn off rendering or behavior specified by the
author that may obscure content or disorient the user.
-----
Guideline 6. Implement open specifications and their accessibility features
In particular, implement W3C specifications when they are appropriate for a
task and follow accessibility guidelines for those specifications.
-----
Guideline 5. Observe operating system conventions and standard interfaces
Communicate with other software (assistive technologies, the operating
system, plug-ins) through applicable interfaces and observe conventions for
the user interface, documentation, installation, etc.
-----
Guideline 9. Notify the user of content and viewport changes
Alert users, in an output device-independent fashion, of changes to content
or the viewport.
-----
Guideline 10. Allow the user to configure the user agent
Allow users to configure rendering, mouse, keyboard, the user interface,
etc. to facilitate daily use of the software.
Compare these to the rest where the titles really are short enough or
telegraphic enough that they look like titles instead of guidelines.
GV#13 -----------------------------
3.4
What does natively rendering audio mean? A browser can't make a sound
except by doing it through the speaker. Does this refer to directly
driving the speaker -- not through the operating system? Is that
possible anymore? Does anyone do that?
Techniques document should explain what "natively rendering audio" means.
GV#14 -----------------------------
3.7
suggest adding the word PARTICULARLY into the phrase
...." by flickering or flashing PARTICULARLY in the 4 to 59 flasher per
second range."
Since this is the most sensitive area but not the only area. In the
techniques document you should mention that 20 hz is the peak sensitivity
frequency.
GV#15 -----------------------------
3.7 again
The last sentence of the note on 3.7 talks about security issues. This is
not an access issues so I suggest it be put into parenthesis.
GV#16 -----------------------------
3.10
Why is blinking and animation a priority 1 but auto refreshing (which can
have the same effects) only a priority 3?
GV#17 -----------------------------
4.11 control of audio playback rate
controlling the synthetic speech rate makes sense to me... but I don't
understand what controlling the audio rate would do.
Does this mean that all browsers would have to have audio compression
(chopping) software built in?
This one has me stumped. And techniques doc is silent on what it means.
I would suggest dropping this one. [Unless of course there
(by the way for cognitive disabilities the research points to presenting
information faster... not slower. It turns out that short term memory
loses the front of the audio before the back gets there if it is slow.
Faster (but not too fast of course) presentation was better. (but long
sentences are bad at any speed). I should really go back and try to
find those references. Been too long.
GV#18 -----------------------------
4.16
there are a number of guideline that seem to have higher ratings than your
stated rating criterion. That is, things would be very helpful are rated
as Priority 2 when they don't necessary make the pages very hard to use if
you don't implement them. They just make them harder or hard.
Also some priority 1s don't seem to be absolute barriers, but rather just
hard to use.
I haven't been in on the discussions so I may not realize the full impact or
need for some of these but some that seemed to be high on first reading..
(you may just want to look at them) are....
4.16
5.2
8.3
8.5
10.3
10.6
GV#19 -----------------------------
4.17
I thing you should add "or no style sheet" to the end of the guideline.
You have it in a note that follows... but the note is a "should" note (which
is not a P1) and the guideline is a P1.
GV#20 -----------------------------
5.8
the First sentence of this checkpoint and the second sentence don't sound
like they are talking about the same thing.
The first sentence refers to OS conventions and settings. But there are no
settings in the second sentence and "documentation" doesn't seem to be
either an OS convention or setting (or to have OS conventions). Maybe
my eyes are just tired. You may want to explain the "documents"
connection. You may also want to say something about SUPPORTING
Accessibility settings such as ShowSounds or High Contrast.
GV#21 -----------------------------
Guideline 6 Paragraph 1 sentence 2
Talks about "the current guidelines..."
Not clear what guidelines it is referring to. Does that mean "THESE"
guidelines? All of the current W3C guidelines? All the access
guidelines? It could mean "THESE" or "Web Content" guidelines.
You might want to add or change a word to make it clear.
GV#22 -----------------------------
7.4 and 7.5
in 7.4 it says......
".......to searching on active elements only (e.g........."
this sounds like 7.5 which deals with navigating ONLY through active
elements and makes it confusing as to what is really being said in 7.4.
this is important since 7.4 is a P1 (and NEEDS to be a P1)
but tabbing ONLY through active links (which is 7.5) is not critical and
is not a P1.
You might want to remove that bit about "active elements only" from 7.4
GV#23 -----------------------------
Guideline 8, Paragraph 3, bullet point 2
This is one of only 2 or three sentences in the whole document that didn't
make sense when read. I read it a few times and (because I already know
the concept) I recognized it. But I don't think a first time reader (who
doesn't already understand ) would get it. You might want to look at this
one or add some text or and example or.....
The bullet I am referring to is the one that starts "link context".
Perhaps an example of what should be done would be best way to address this.
GV#24 -----------------------------
8.9 Maintain consistent user agent behavior and default configurations
between software releases.
I think this one is perhaps to stringent. I would hate to be trying to hit
the priority 3 items and then come across this one that says I can't change
my user interface at all or change any default configurations (even if the
old ones were dumb) between software releases.
Perhaps it could be made a little less absolute by adding "as much as
possible " in front of "between software releases"
GV#25 -----------------------------
9.2
little grammatical thing
Change ' the viewport" to "a viewport" perhaps?
"the viewport" implies a particular viewport... so in this case it would
imply that you couldn't change viewports ever. (you couldn't change the
selection from one viewport to another.
GV#26 -----------------------------
9.3 Is use of the RETURN key included in what we mean here? If so then
we should so state. If not then we should so state.
GV#27 -----------------------------
9.6
In the note that follows- it is not clear if the browser is supposed to
allow the user to choose between these (e.g. the browser would have to
provide them all) or whether the browser programmer could chose which one -
based upon what made sense for that instance.
GV#28 -----------------------------
10.3 last sentence of the NOTE
Is it a priority 2 that the user be able to redesign the GUI interface on
the browser???
This seems to be a very high bar. Some browsers allow some modification but
not all and I don't know of any that allows more than modification of the
toolbars.
GV#29 -----------------------------
10.4
This appears to be the same as another checkpoint that says "use OS
conventions". Is this a "special important case" of the other
checkpoint? If so you might want to note it as were the others.
GV#30 -----------------------------
10.6
If is read this right, it says that it is a Priority 2 that browers all
use the same configuration setting files (or have a translator) so that
settings from one browser could be used to configure another. (or other
software that isn't even a browser?)
Hmmmm
I would suggest that the phrase "and software" be removed.
I also wonder if this is really a priority 2
-----------------------------
And that is it.
My final comment is to say that you might want to go over each one a final
time and make sure that the priorities are correct and that they are not put
high because people would really like them.... But because they are really
need at that level as per you definition.
There will be companies out there who will try to meet these at P1 or P2 or
P3 level. But if they hit things that are barriers to meeting all of P2 or
P3 they can fall back to the previous level. (there really aren't any P1.75
levels). And regulatory agencies might specify that P2 must be met (rather
than just P1) if there aren't too many things in P2 that aren't really
needed.
Sorry if any of these comments seem to miss the point.......
Wish I could have been in on all the discussions.
But you did a great job on these --- the effort really shows.
I haven't had time to try to compare this to see how current browsers would
stack up - or to follow discussion as to whether browser developers feel
they could meet these (or if there are any killer items in here). With the
content guidelines that was a good test of the practicality of the
guidelines and we learned a lot by trying that. It was easier for us to
create pages than it is for you to create a browser though. Before you go
to proposed recommendation though you should do whatever you can in this
department. You won't regret it in the long run.
These have come a long long way from where you started on this.
This was a really tough area.... I am impressed with how well this turned
out.
Congratulations.
Gregg
Received on Wednesday, 1 December 1999 02:14:26 UTC