W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 1999

Gregg Vanderheiden review [Fwd: FW: UA Review - Laundry List]

From: Ian Jacobs <ij@w3.org>
Date: Wed, 01 Dec 1999 11:40:42 -0500
Message-ID: <38454F8A.2409EE9F@w3.org>
To: w3c-wai-ua@w3.org
(Forwarded from the w3c-wai-au list).

Gregg Vanderheiden wrote:
> 
> 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

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel/Fax:                     +1 212 684-1814
Cell:                        +1 917 450-8783
Received on Wednesday, 1 December 1999 11:41:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:49:34 GMT