- From: Ian Jacobs <ij@w3.org>
- Date: Tue, 23 Nov 1999 23:31:04 -0500
- To: keren beth moses <kmoses@students.uiuc.edu>
- CC: w3c-wai-ua@w3.org
keren beth moses wrote:
>
> I'm coming from a bit of an outsider's perspective. Most of these
> comments have to do with parts of the document (especially techniques)
> that I didn't understand.
>
> The introduction talks about contexts in which web access may be
> difficult. It includes many situations that may occur for individuals
> with and without disabilities. This sounds like the focus is on universal
> access. Immediately after, it states, "User agents must be designed to
> take into account the diverse functional requirements of users with
> disabilities." This puts the emphasis back on disability. The change in
> focus between universal access and disability access is confusing.
Yes, we've had a similar comment from Eric Hansen. I think we'll
have to clean this up.
> Checkpoint 1.3 and its techniques get very caught up in client-side image
> maps. It seems to me that there are other applications of this
> checkpoint. Mac and Unix users can't even access plain text links in
> Netscape Navigator without the mouse.
Yes, there could be more emphasis on text links, form controls, etc.
> Checkpoint 1.4 first and last techniques seem to say the same thing: allow
> the user to perform mouse events with the keyboard.
Yes.
> Checkpoint 1.5 techniques are phrased as "do not..." followed by a list of
> items. I think the do not only applies to the first two items in the
> list, since other items include their own "do not" or present techniques
> that should, in fact, be used. Perhaps it would be clearer to present as
> a "do" list and make every item a complete sentence.
This is fixed in the 21 November Draft [1] (which is not the draft
mentioned in the last call, but a newer WG draft)
[1] http://www.w3.org/WAI/UA/WD-WAI-USERAGENT-TECHS-19991121/
> Checkpoint 2.1 seems clear but the techniques section is very long
> awkwardly organized. I was more confused about the checkpoint after
> reading the techniques document than before.
That's not good!
> Perhaps this is because it
> gives a lot of information that is not specifically related to ways of
> implementing the checkpoint. This happens in other areas of the
> techniques document as well. The information given there can not always
> be described as a "technique"; maybe it's just the name that is confusing.
> Also, from checkpoint to checkpoint, the style and presentation of
> information is inconsistent (probably because it was written by a lot of
> different people).
See if the text in [1] is better.
Until recently, the Techniques Document has been a repository for
notes and information and is not consistent in style at all. We
are slowing molding it into a more consistent document (and your
continued comments are welcome).
We also recently changed the structure of the document from one
organized by theme (like the second half currently) to one
organized by checkpoint. This has made it easier for people
to contribute ideas for specific checkpoints (so we are
getting more content) but we will still need a serious editorial
pass to ensure that its readable, concise, accurate, not
too redundant, etc.
> I didn't understand Checkpoint 2.4. What is a "time-dependent active
> element"? The techniques document didn't help me much. I think an
> example is in order. How can you "provide time-dependent information in a
> time-independent manner, such as a static list of links that are
> time-dependent and occupy the same screen real estate"? How can a static
> list be time-dependent? Or did that mean "Provide time-dependent links in
> a static list that occupies the same screen real estate"?
yes.
In SMIL, a link at a particular place on the screen (I'll use the
graphical rendering for this comment) can point to different
resources over time. From section 4.5.2 of the SMIL spec [2]:
<BLOCKQUOTE>
2) Associating links with temporal subparts
In the following example, the duration of a video clip is split into
two
subintervals. A different link is associated with each of these
subintervals.
<video src="http://www.w3.org/CoolStuff">
<anchor href="http://www.w3.org/AudioVideo" begin="0s" end="5s"/>
<anchor href="http://www.w3.org/Style" begin="5s" end="10s"/>
</video>
</BLOCKQUOTE>
This example shows that what appears to be the same link designates
different resources between 0 and 5 seconds and 5 and 10 seconds.
If I am unable to activate the first link in time, I'll never have
access to it again.
[2] http://www.w3.org/TR/1998/REC-smil-19980615/#anchor
> Checkpoint 3.7 states "This is particularly important for scripts that
> cause the screen to flicker, since people with photosensitive epilepsy can
> have seizures triggered by flickering or flashing in the 4 to 59 flashes
> per second (Hertz) range. Users should be able, for security reasons, to
> prevent scripts from executing on their machines." Are these two things
> (epilepsy and security) related? If so, the relationship should be made
> clearer. If not, they should be separated somehow. Also, the "script
> techniques" document to which the reader is referred is a little sparse.
Eric Hansen also commented on this and we'll fix it.
> Checkpoint 5.8 states "If your custom interface cannot provide information
> or operation as defined above, then you may need to design your UA using
> any additional options provided by that platform." I don't understand
> what this means.
Nor do I. I propose deleting it.
> Checkpoint 10.1 is "Provide information about the current user-specified
> input configuration (e.g., keyboard or voice bindings specified through
> the user agent's user interface)." and has priority 1. How much
> information can the program give the user about configurations that the
> user has set?
If the user has configured the UA to perform UA-specific tasks, then
the UA can say a lot about them; they should all be in the documentation
and the bindings could link to that documentation. For example, if
Alt-N opens a new browser window, and the UA documents that
functionality,
then, for example, a brief description of what Alt-N does could link
to further documentation.
> The techniques document for this checkpoint is very
> confusing.
This is one of those sections that was a repository of notes
and will have to be made more intelligible.
> What does tabbing order have to do with user-specified
> configuration? Can the user ever set the tabbing order?
I don't know.
> There are also a
> lot of suggestions about allowing the user to search for things using the
> find command. This is fine, but I don't see how it relates to the
> checkpoint.
> Also, the issue of reserved keyboard shortcuts is addressed
> in Checkpoint 10.5; maybe it is best to refer the reader to that section
> instead of talking about conflicts here.
The sections are not quite the same: 10.5 says - don't provide
defaults that conflict with OS conventions. The info about reserved
sequences in 10.1 (should be in 10.2 first of all) discusses dynamic
changes to the input configuration where there is overlap between
the author's mappings, the user's preferred mappings, the default
mappings, and the os conventions.
> Checkpoint 10.2 is "Provide information about the current author-specified
> input configuration (e.g., keyboard bindings specified in content such as
> by "accesskey" in [HTML40])." and has priority 2. Why is this a different
> priority from Checkpoint 10.1? They seem very similar.
This is an issue that was highlighted in the last call announcement as
one the WG had not yet resolved [3].
[3] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0259.html
> Again, the
> techniques document is confusing, especially the statement, "The above
> classes my be distinguished by displayed properties in a combined
> presentation as well as by filtering to present only a restricted class."
This means:
- You can distinguish defaults from user-specified from
author-specified
with style (e.g., colors, though that's not sufficient)
- You can render one group of bindings at a time (e.g.,
author-specified
only for this particular page).
This section could be made clearer.
> Checkpoint 10.5 techniques should address the issues brought up in the
> Checkpoint 10.1 techniques about what should happen when there are
> conflicting keyboard shortcuts.
I think it should be in 10.2 for the aforementioned reason (how to
handle
the cascade).
> Isn't Checkpoint 11.4 ("In a dedicated section, document all features of
> the user agent that promote accessibility.") just a special instance of
> Checkpoint 11.2 ("Document all user agent features that promote
> accessibility.")? Does it need to be a separate point, or could it be
> included as a suggestion under Checkpoint 11.2?
It is a special case and I agree that this should be indicated.
However, the priority of a dedicated section is considered lower than
for documentation anywhere. Therefore, it was split into a separate
checkpoint.
Thank you so much Keren!
-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 Tuesday, 23 November 1999 23:30:39 UTC