- From: Ian Jacobs <ij@w3.org>
- Date: Wed, 01 Dec 1999 11:40:42 -0500
- 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 UTC