- From: Ian Jacobs <ij@w3.org>
- Date: Sat, 04 Dec 1999 19:15:31 -0500
- To: Wendy A Chisholm <wendy@w3.org>
- CC: w3c-wai-ua@w3.org
Hi Wendy,
Thank you for the comments!
- Ian
Wendy A Chisholm wrote:
>
> 1. Checkpoint 1.1
> I found it very confusing to have so many special cases for checkpoint
> 1.1.
Do you mean that it's confusing to have other checkpoints that are
special cases (e.g., 1.4) or that checkpoint 1.1 itself is
confusin (i.e., the part about low-level interfaces)?
> 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.
Please clarify your proposal.
> 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?
The key phrase in 1.3 is "active element". The key phrase in 1.4 is
"keyboard". They are different in that fundamental way. Both
checkpoints 1.3 and 1.4 indicate that they are important special cases
of
checkpoint 1.1.
> 3. Guideline 4
> It is not clear in either the Guidelines nor the Techniques that font size
> and changes should apply to captions.
In the rationale of Guideline 4, the following Note covers your
requirement:
Note. The checkpoints in this guideline apply to all
content, in including alternative representations
of content.
> 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.
The note after 5.2 is already long and I don't want to overload
it with an entirely separate topic (OS flags). Some options:
1) Leave it where it is
2) Move it to the Techniques.
3) Integrate some keyword into the checkpoint text.
I'll add as issue 165.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#165
> 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.
I'm not sure what to suggest here. Sequential access *can* provide
more context, but in the tabbing scenario, you don't get all context.
It's still true that in direct navigation, "some context may be 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.
1) I suspect that checkpoint 7.3 may go. Refer to issue 160
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#160
2) 7.5 is a special case of 7.4
3) 7.8 is a related to 7.7.
This means that the key navigation checkpoints are:
a) viewports
b) active elements (this includes direct and serial)
c) structure
d) searching
The WG decided (reference not handy since working offline due
to Bell Atlantic ISP problem) that specifics about navigation
would be better off in the techniques document.
> 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.
I have already proposed a note that clarifies that
7.5 is a special case of 7.4.
I guess one could consider 7.4 to be a special case of 7.7 (7.7
requires structured navigation, 7.8 requires configuration thereof).
I don't mind adding a note to 7.4 to this effect.
> 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)?
Yes, I'll add a note that it's an important special case as we've
done elsewhere.
> 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?
Yes, checkpoint 8.3:
8.3 Provide an outline of a resource view built from
its structural elements (e.g., frames,
headers, lists, forms, tables, etc.)
I propose some rewording of 8.3 to read "outline view of a resource".
> 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.
Please propose a rewording or that we should reconsider the checkpoint.
> 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."
I'd actually rather break out the parenthetical examples into a
second sentence. With your other change, that would give:
<BLOCKQUOTE>
Changes to content or browsing context may disorient users with
visual impairments or certain types of learning disabilities.
Unexpected changes may cause users to lose track of how many
viewports are open, which is the current
viewport, etc.
</BLOCKQUOTE>
> also, the use of "impariments" throughout the document ought to be
> reconsidered.
Refer to existing issue 137.
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#137
> 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.
9.1 Requires that the user agent notify the user
9.4 Allows the user to configure the user agent to filter out
information.
I'm not sure that the only changes that interest the user are those
that require user reponse. There are certainly changes that don't
interest
the user (e.g., the little icon is turning in circles). But there is
probably a class of changes (e.g., automatic refresh) where knowing is
important but no action is required.
> 13. Checkpoint 9.3
> yikes - are there really form submissions being triggered by mouseovers?
Yep.
> 14. Checkpoint 10.1 is confusing
> "Provide information about the current user-specified input configuration..."
> Who are we providing the information to?
To the user and through APIs. This should be clarified as is done
in 9.1: "directly to the user and through APIs."
> 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."
The only difference between 10.1 and 10.2 is where the configuration
comes from (10.1: user, 10.2: author). This is one of the issues
highlighted in the last call announcement and it appears
in the document status section.
Refer to issue 112
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#112
> 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?"
Ok.
> 16. Shouldn't Checkpoint 10.5 be a P1?
Added as issue 166
http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#166
> 17. Checkpoint 10.8
> Why does this only focus on "graphical arrangements?" Is the non-graphical
> covered by checkpoint 10.7?
This checkpoint was only meant for the
graphical user interface (e.g., buttons, menus, etc.)
_ 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 Saturday, 4 December 1999 19:15:54 UTC