- From: Ian Jacobs <ij@w3.org>
- Date: Thu, 02 Dec 1999 22:48:15 -0500
- To: gv@trace.wisc.edu
- CC: w3c-wai-ua@w3.org
Gregg Vanderheiden wrote:
>
> 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.
Thanks Gregg! My comments below. I have cut out the editorial issues.
> 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?
Yes, I agree. Added as issue 141.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#141
> 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.)
Ok.
> 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). ??
I guess what's need here is "or through an API". I believe we've
been working under the assumption that, for example, text messages
on the screen suffice since they can be picked up by assistive
technologies. But that solution wouldn't satisfy this checkpoint
as written. Added as issue 142.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#142
> 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" ??
I propose deleting 2.6 and mentioning audio tracks in 2.2
Added as issue 143
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#143
> 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"
The term "control" is defined in the glossary as follows:
<BLOCKQUOTE>
User control of the user agent - interface, behavior,
styles, etc. - means that the user can choose preferred
behavior from a set of options. For instance, control of colors
means that the user can choose from available colors, within
the limits offered by the operating system or user agent.
</BLOCKQUOTE>
I'll make sure that instances of the word "control" link to that
definition.
>
> 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.
I'm not sure you're referring to 2.7, which reads
"When no text equivalent has been specified, indicate what
type of object is present."
Checkpoint 2.8 reads "When alternative text has been
specified explicitly as empty (i.e., an empty string),
render nothing."
But 2.8 uses "i.e." not "e.g.", so I don't think it suggests
more than one possibility.
> 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.
I will raise this as an issue but assume it's editorial so I
can propose changes directly in the next draft. Added as issue 144
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#144
> 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?
That is apparently what 3.4 means.
> Techniques document should explain what "natively rendering audio" means.
Yes.
>
> 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.
Yes, this has been pointed out and will be moved.
> 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?
Added as issue 145
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#145
> 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.
Added as issue 146
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#146
> 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
Review of some priorities added as Issue 147
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#147
> 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.
Refer to existing issue 132
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#132
> 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).
In Unix, documentation conventions include "man" and "info"
In Windows, documentation conventions involve the windows help system.
> 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.
Added as issue 147
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#147
> 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
7.4 reads "Allow the user to navigate all active elements."
7.5 reads "Allow the user to navigate just among all active elements."
I guess the best solution is to say in 7.5 what is different from 7.4
in a note.
> GV#24 -----------------------------
> 8.9 Maintain consistent user agent behavior and default configurations
> between software releases.
>
> I think this one is perhaps too 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"
I don't think additional "relaxation" is necessary. The checkpoint
doesn't go so far as to say "don't change anything", it conveys
the notion of consistency. Furthermore, the second sentence indicates
explicitly where flexibility may be applied: Consistency is less
important than accessibility and adoption of operating
system conventions.
> 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.
The note below indicates another way: a script that submits the form
when a menu item changes. Does RETURN count as explicit submit?
How does one push a button without a mouse in today's browsers?
Added as issue 148
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#148
> 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.
Checkpoint 10.3 reads "Allow the user to change and control the input
configuration." This means reconfigure keyboard, voice, and other
input bindings. Not redesign the whole GUI interface.
Note that 10.8 refers to moving around GUI parts (Priority 3).
> 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.
yes.
> 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.
The "and software" part is more of a wish than a requirement.
> I also wonder if this is really a priority 2
Added as issue 149.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#149
> -----------------------------
>
> 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.
Yes, I think we will try to do that at the ftf in Austin.
> 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.
Thank you Gregg, and thanks for taking the time to review the
document so thoroughly.
- Ian
--
Ian Jacobs (jacobs@w3.org) http://www.w3.org/People/Jacobs
Tel/Fax: +1 212 684-1814
Cell: +1 917 450-8783
Received on Friday, 3 December 1999 19:34:42 UTC