- From: Scott Luebking <phoenixl@netcom.com>
- Date: Tue, 30 Nov 1999 12:02:09 -0800 (PST)
- To: w3c-wai-ua@w3.org
Hi,
Just a few comments.
Check points:
4.10 Allow the user to start, stop, pause, and rewind video.
4.13 Allow the user to start, stop, pause, and rewind audio.
These two checkpoints should have incremental forward and back up.
Media players of different types often have a slide bar which
can be hard for blind users or mobility impaired people to use.
Buttons for incremental back up and forward are easier to use.
The incremental back up is especially useful for those situations
where the sound is momentarily not understandable, e.g. truck
passing by, announcement over a speaker phone.
4.14 Allow the user to control synthesized speech playback rate.
Incremental back up might be useful here also.
Techniques:
2.1
.
.
.
User interface issues
Another user interface issue is making intelligent decisions
concerning rendering and layout based not only on structure
of content, but also on the subject matter / information in the
content.
2.4
+ Allow the user to control the timing of changes.
One useful technique is the ability to stop and start
flow of changes. Another is to have an option where the user
is asked if the user agent should continue just before a change is
made.
3.9 Allow the user to turn on and off author-specified forwards that
occur after a time delay and without user intervention.
Similarly, the browser could have an option where the browser asks
the user if it should continue with the forwards.
3.2 Link techniques
* When presenting the user with a list of the hyperlinks contained
in a document, allow the user to choose between "Display links
using hyperlink text" or "Display links by title (if present)",
with an option to toggle between the two views.
If the user has selected to show links by title and a particular
link has no title, then the hyperlink text should be shown for that
particular link.
3.3 Table techniques
A rich set of navigation functions could include:
jump to specific cell
up/down 1 or more rows
left/right 1 or more columns
bottom row in same column
right column in same row
jump to row headers for cell
jump to column headers for cell
jump back to cell
There should be a discussion about navigating through nonuniform
tables, e.g. tables where the data area contains span cells,
the number of columns can vary between rows, the number of rows can vary
between columns. For example, if you navigate up into a cell
which spans three columns, which cell above the span cell
should you go into if you go up another cell? Or what happens if
you are in the last cell of a row and the previous row has fewer columns?
If the user agent is taking a guess at header information, the
user agent might find two or more possibilities. Providing the user
with a mechanism to review the possible choices and make a selection
could be very useful.
It would probably be helpful if the user could get table summary
information which includes:
how many span cells in data area
range of number of columns in data area
range of number of rows in columns in data area
maximum depth of nested tables in data area
number of nested tables in data area
The user should be able to get table summary information
from inside a cell. It might be helpful to provide two
types of table summary information, i.e. a brief summary and a
more detailed summary.
A comment about problems when a cell has two or more
nested tables could be beneficial.
3.4 Frame techniques
* Provide (possibly nested) lists of links to each frame in the
frameset. The link text can be the frame title (given by "title"
or "name" if "title" is not present). Or, if no title or name are
available, render the title (e.g., the TITLE element in HTML) of
the document that is loaded into the frame.
If the document has no TITLE element, having the link text be a
string containing the number of images, the number of words and
the URL for the frame document can be helpful. Providing the number
of words and the number of images can be helpful in guessing the
purpose of the frame, e.g. few images and few words is probably
a title, more words is probably an index, many words is probably
text area.
3.5 Form techniques
When navigating through OPTION's, have some key like the ESC key exit
the list of OPTION's without making a selection.
When navigating through form controls, how does a user know about
reaching the end of a form? Similarly, how does a user know where one
form ends and another begins?
Can a user agent assume that the access technology will tell
the user which radio button in a group of radio buttons is selected?
GENERAL COMMENTS
I think there should be a strong statement at the beginning of document
about the need to have disabled people in the process of designing
and testing the software. It probably should say that the guidelines can
help avoid pitfalls, but it is quite possible to follow the guidelines
and still end up with an inaccessible user agent.
A number of blind people have commented to me about disliking
confirmation boxes and warning boxes. Perhaps, there needs to be
a comment about gratuitous use of these boxes. For lesser important
warnings, the option of getting a sound instead of a box might be preferable
for some blind users.
Any computer-stored documentation for the agent should have a search feature.
(This probably applies more for user agents in the UNIX environment.)
A summary of the current state of a user agent, including various
setting, which can be displayed on request and then cut and pasted
into an email can be useful for tech support for the user agent
and for the access technology.
Scott
Received on Tuesday, 30 November 1999 15:25:39 UTC