UA Guidelines Review of IBM Home Page Reader

Abstract

In order verify the utility and applicability of the Guidelines,
the User Agent Accessibility Guidelines Working Group is testing the
Guidelines by reviewing a variety of user agents (both graphical
desktop and dependent user agnets) on a variety of platforms. This
review will help us correct weak points of the guidelines and fill in
gaps where required. The review is not meant as a definitive review of
products although we anticipate sending our findings and observations
to developers.

Status of this document

This is not a W3C Working Draft. The Guidelines document it refers
to is a W3C Working Draft, which means that it may change at any
time. This review is informative only and may not be used to rate or
compare product accessibility.

Please send comments about this document to the public mailing
list: w3c-wai-ua@w3.org

This document has been produced as part of the Web Accessibility
Initiative. The goal of the WAI User Agent Guidelines Working Group is
discussed in the Working Group charter.

A list of current W3C Recommendations and other technical documents
can be found at http://www.w3.org/TR.

Support for the following HTML accessibility
features: CAPTION and SUMMARY for tables,
ALT for images and areas, TITLE and LONGDESC
for images, HEADER attribute for table cells,
NOFRAMES, and NOSCRIPT.

Sequential navigation of all links, controls,
and content. Navigation keys separate from
activation keys. Direct navigation through
searching for text content, alt text, and
form control names. Direct navigation of
links and controls by typing the first letter
of link and control text from list of links
and controls. The exceptions include elements
involving JavaScript and applets.

Cell and spanned cell navigation keys for
both rows and columns. Caption and header
attributes read automatically. WhereAmI key
announces table summary, number of rows,
number of columns, and current cell location.
Orientation keys access header and footer
cells for rows and columns.

Checkpoint 2.2 For presentations that require user interaction within a specified time interval, allow the user to configure the time interval (e.g., by allowing the user to pause and restart the presentation, to slow it down, etc.).
(Techniques for 2.2)

Partial

Key available to cancel the loading of a
web page. Automatic forwarding is suppressed
by HPR to allow user to read the page and
then click on the link to go forward. HPR
does not provide control over timed audio
and video presentations. This guideline is
too vague to understand specifically what
is meant.

Checkpoint 2.6 Allow the user to specify that text transcripts, captions, and auditory descriptions be rendered at the same time as the associated auditory and visual tracks.
(Techniques for 2.6)

Checkpoint 2.5 If more than one equivalent alternative is available for content, allow the user to choose from among the alternatives. This includes the choice of viewing no alternatives.
(Techniques for 2.5)

Yes

Both ALT text and a link to LONGDESC rendered
for images. Setting available for rendering
or not rendering images with no or NULL ALT
text.

Can navigate a list of frame links for a
frameset . Key sequence to return to frameset
when in a frame. Can also tab between views
(links list, history list, text view) in
the HPR browser window.

Checkpoint 7.2 For user agents that offer a browsing history mechanism, when the user returns to a previous viewport, restore the point of regard in the viewport.
(Techniques for 7.2)

Yes

Checkpoint 8.5 Provide a mechanism for highlighting and identifying (through a standard interface where available) the current viewport, selection, and content focus.
(Techniques for 8.5)

Yes

This checkpoint seems to be the same as Checkpoint
5.3. However, the techniques for this checkpoint
indicate that the UA should allow the user
to CHOOSE the mechanism for highlighing through
OS conventions, CSS, etc. HPR provides a
mechanism but does not allow the user to
choose.

Checkpoint 1.1 Ensure that every functionality available through the user interface is also available through every input device API supported by the user agent. Excluded from this requirement are functionalities that are part of the input device API itself (e.g., text input for the keyboard API, pointer motion for the pointer API, etc.)
(Techniques for 1.1)

Partial

There is a non-visual settings menu that
is only available using the keyboard, not
the mouse. Most but not all settings in this
non-visual menu are also available in an
HPR dialog.

The HPR user interface uses standard Windows
components and APIs and inherits system settings
for these standard components. Other assistive
technology could access the HPR UI using
MSAA but not a DOM. Today's W3C DOM covers
content not UI, so should DOM be mentioned
in this UI checkpoint? Using DOM for content
is already covered in Checkpoint 5.1.

The HPR main window and dialogs consist of
standard controls which assistive technologies
can access through MSAA or Windows APIs.
However, HPR is not explicitly providing
any of these programming interfaces for changes
in its UI.

The HPR user can always press the help key
to get information about which default keys
to use. However, if the user changes the
default keyboard configuration, the help
information may be confusing since it does
not change.

Priority 2 checkpoints

In General (Priority 2)

Yes

No

N/A

Comments/Techniques

Checkpoint 2.3 When the author has not supplied a text equivalent for content as required by the markup language, make available other author-supplied information about the content (e.g., object type, file name, etc.).
(Techniques for 2.3)

Yes

HPR provides partial URLs and filenames for
images with no ALT text and partial classid
or data for objects with no textual content.

If Netscape opens a dialog, focus moves to
that dialog and a screen reader is required
to speak the dialog. If Netscape opens a
new Netscape window and the focus moves to
that new window, HPR loads the page in the
new Netscape window.

It is possible to reconfigure the HPR keys,
but it is not implemented in a user-friendly
way.

Checkpoint 10.5 Allow the user to configure the user agent so that the user's preferred one-step operations may be activated with a single input command (keystroke, voice command, etc.).
(Techniques for 10.5)

HPR doesn't use DOM access, but with the
communication between HPR and Netscape using
DDE, HPR usually loads the web page before
Netscape does!

Checkpoint 10.3 Provide information to the user about current author-specified input configurations (e.g., keyboard bindings specified in content such as by "accesskey" in HTML 4.0).
(Techniques for 10.3)

HPR presents a beep every 3 seconds and a
message every 30 seconds while loading a
document, but the message does not indicate
how much of the document is loaded. The user
knows loading is complete when HPR starts
reading the web page.

Checkpoint 9.5 Indicate the relative position of the viewport in content (e.g., the percentage of an audio or video clip that has been played, the percentage of a Web page that has been viewed, etc.).
(Techniques for 9.5)

Yes

The WhereAmI key announces a numerical position
of the user's current point of regard within
the current structure and relative to the
current page.

HPR's outline view is through keyboard navigation
and speech (not visually). The user can choose
to navigate by headers, tables, or structures
(which include lists, table rows, select
menus, and maps).