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

Comments and questions about 5 November UA Guidelines

From: Wendy A Chisholm <wendy@w3.org>
Date: Thu, 02 Dec 1999 11:53:32 -0500
Message-Id: <4.2.0.58.19991202101010.00abec80@localhost>
To: w3c-wai-ua@w3.org
Hi all,

This has changed quite a bit since I last saw it!  Excellent.  But, that 
means I have lots of questions. <grin>

I apologize for not finishing this before the last call deadline.  I am 
also not up to date on the list, and apologize if any of my comments have 
already been addressed by the group or echo someone else's comments.

1.  Checkpoint 1.1
I found it very confusing to have so many special cases for checkpoint 
1.1.  Parts of the checkpoint are too generalized.  I think it would be 
hard to determine when it was satisfied.  Therefore, I suggest breaking it 
out into X number of separate, stronger checkpoints.

2. Checkpoint 1.4
How is 1.4 different from 1.3?  1.3 is about "device independence" 1.4 is 
about keyboard input.  Therefore if 1.3 is satisfied, isn't 1.4 covered?

3. Guideline 4
It is not clear in either the Guidelines nor the Techniques that font size 
and changes should apply to captions.

4. Guideline 5
The 2nd paragraph of the rationale ("Some operating systems have operating 
system-level flags....") isn't obviously covered by checkpoint 
5.2.  Although I guess this is what "conventions" refers to.  I don't have 
a suggestion for how to reword it, but perhaps this could be emphasized in 
some way.  I worry that some people will never read the Techniques or 
rationale and thus the checkpoints need to stand on their own in a 
checklist.  Perhaps shorten the paragraph from the rationale and move it to 
a Note of checkpoint 5.2.  The current note only talks about assistive 
technologies, not recognizing access flags.

5. Guideline 7 - typo
The 1st bullet in the rationale is missing the word, "content."
<blockquote>
Sequential access (e.g., line scrolling, page scrolling, tabbing access 
through active elements, etc.) means advancing through rendered _content_ 
in well-defined steps (line by line, screen by screen, link by link, etc.) 
forward and backward.
</blockquote>

6. Guideline 7 rationale
The first bullet discusses sequential access and gives the example of 
tabbing through links.  The second discusses direct access and says that 
"context may be lost."  However, one of the complaints of tabbing through 
links is that link context is lost.

7. Guideline 7 Checkpoints
7.1 says to navigate between/within viewports,
7.3 talks about navigating among the cells of a table,
7.4 says to navigate *to* active elements,
7.5 says to navigate only among active elements,
7.7 says to navigate by structure
7.8 configure structured navigation

It seems to me that we need a checkpoint that generally says, "navigate 
between and within child elements of a parent."  This would cover tables 
(navigate among cells), forms, and perhaps frames as well as other types of 
"container" or "grouping" elements that may evolve.  It is also recursive 
(thus nested tables, or tables in frames, etc. would be covered).

However, this sounds a lot like "navigate by structure" with a slightly 
different emphasis.  Structure seems to refer to headers, paragraphs, etc. 
rather than among the cells of a table.

7.5 seems to be a special case of 7.8 and/or 7.4.  While 7.4 seems to be a 
special case of 7.8.

Therefore, in general these seem to overlap quite a lot and are perhaps not 
general enough.  I do not see a clear proposal for how to make them less 
overlapping or more clear.

8.  Checkpoints 8.4 and 8.5
Isn't 8.4 another attribute of a link that a user will consider when 
deciding to follow a link or not (i.e., isn't 8.4 covered by 8.5)?

9.  Checkpoint 8.6
This is assuming that a user agent provides an "outline view."  I realize 
that if one doesn't they don't have to conform to this checkpoint (plus 
it's a p3), but does this imply that a user agent *should* have an outline 
view?

10. Checkpoint 8.9
yikes!  Can we really suggest that user agents maintain consistent behavior 
between releases?  What affect will this have on innovation?  I think the 
issue is that behaviors may change but that the way in which Assistive 
Technologies get at the information behind the behavior should be 
consistent (unless there is a major innovation, e.g. the future DOM.  ATs 
will have to incorporate changes, but then access should be improved 
).  Granted, it's a p3, but it might send a weird message.

11. Rationale for Guideline 9
I think it would be clearer if the first sentence read, "Changes to content 
or browsing context (new viewports opening, changes in focus between 
viewports) may disorient users with visual impairments or certain types of 
learning disabilities." In the next sentence I would substitute "dynamic 
content" for "script."

also, the use of "impariments" throughout the document ought to be 
reconsidered.

12 Checkpoint 9.1
Checkpoint 9.1 - rather than providing information about events (such as 
informing a user when a pop-up appears), isn't there some way to help the 
user reorient themselves and change focus as well?  For example, in the 
visual browser, a pop-up appears.  it doesn't say, "a pop-up is going to 
appear, prepare yourself."  A pop-up usually appears to alert the user of 
something. This checkpoint seems to be forcing the visual paradigm onto a 
non-visual user.  Instead we ought to be looking at the function of the 
visual pop-up and figuring out how that event can be translated to a 
non-visual paradigm.  The way it reads now, it sounds like a 
"meta-event."  It seems that the goal is to ensure that the user knows (in 
the case of the pop-up) that they are being asked to do something - press 
an OK button, input some information, ignore a banner ad <grin>.  I think 
this is covered by Checkpoint 9.4 - let the user decide what happens when 
changes occur.

13. Checkpoint 9.3
yikes - are there really form submissions being triggered by mouseovers?

14.  Checkpoint 10.1 is confusing
"Provide information about the current user-specified input configuration..."
Who are we providing the information to?
Reading the checkpoints there seems to be a mixture of "let the user know 
about author settings" (which is 10.2), "let the user override author 
settings," and "use the user's system setting."  Therefore, I don't see 
where we are "providing information about the current user-specified 
configuration."

15.  Checkpoint 10.3
In the note, shouldn't it say, "For voice-activated browsers, allow the 
user to modify what voice commands activate functionalities." rather than 
"self-voicing?"

16.  Shouldn't Checkpoint 10.5 be a P1?

17. Checkpoint 10.8
Why does this only focus on "graphical arrangements?"  Is the non-graphical 
covered by checkpoint 10.7?

18. I found several typos, but I'm assuming others picked them up. I'll 
check the next release to see if they've been fixed.

--wendy
<>
wendy a chisholm (wac)
world wide web consortium (w3c)
web accessibility initiative (wai)
madison, wisconsin (madcity, wi)
united states of america (usa)
tel: +1 608 663 6346
</>
Received on Thursday, 2 December 1999 11:46:45 GMT

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