HPR Evaluation

AN HTML table with this evaluation is attached.

HPR evaluation against 8/9/99 User Agent Guidelines

This is an evaluation of Home Pager Reader versus the August 9, 1999, User Agent
Guidelines, http://www.w3.org/WAI/UA/WAI-USERAGENT/. The evaluation compares the
text and speech view of content, and ignores the fact that content may be
displayed in Netscape as well.
I think there is a class of browsers, which includes VIPInfoNet and PWWebSpeak
along with HPR, that could be called "targeted agents," or "audience specific
agents." This class should be restricted to targeted audiences of disabled
users.

As targeted agent, in our case targeted for the blind audience, we list as n/a
any checkpoint we believe is not relevant for that audience.

The evaluation includes comments about the checkpoints.
Checkpoints 8/9/99 Rating HPR 2.5 - Text/speech view

#       Checkpoint      Priority       HPR     Comment

        In General (Priority 1)
3.1     Ensure that all product documentation conforms to the Web Content
Accessibility Guidelines.
yes
3.2     Ensure that all user agent functionalities that promote accessibility
are documented.
yes
5.5     Allow the user to turn on and off rendering of captions.
n/a
HPR does not render closed captions. Clarification: Use "closed captions" since
"CAPTION" is an element.
7.1     Ensure that the user has access to document content, including
alternative representations of content.
yes
7.2     For dependent user agents. Ensure that the user has access to the
content of an element selected by the user.
yes
Seeking clarification - see below.
7.3     For dependent user agents. Render content according to natural language
identification. For unsupported natural languages, notify the user of language
changes when configured to do so.
no
I think that this checkpoint is satisfied by announcing the "current language"
in the whereami response. I don't understand why this one is "for dependent user
agents." Also it is not clear if this checkpoint is addressing element language
identification or page identification. The relationship to 9.9 is not clear. And
I still argue that this is not priority 1.

        User Interface (Priority 1)
5.6     Allow the user to turn on and off animated or blinking text.
n/a
HPR Does no render animated text.
5.7     Allow the user to turn on and off animations and blinking images.
n/a
similar
5.9     Allow the user to turn on and off support for user style sheets.
n/a
similar
5.10    Allow the user to turn on and off support for author style sheets.
n/a
similar
5.11    Allow the user to turn on and off support for spawned windows.
n/a
similar
6.1     Allow the user to control font family.
no
This is for the text view. Since HPR's designated audience is blind users,
6.1-6.6 should not apply.
6.2     Allow the user to control font size
no
ditto
6.3     Allow the user to control foreground color.
no
ditto
6.4     Allow the user to control background color.
no
ditto
6.5     Allow the user to control selection highlighting (e.g., foreground and
background color).
no
ditto
6.6     Allow the user to control focus highlighting (e.g., foreground and
background color).
no
I assume this is what we see in Windows standard list boxes.
6.14    Allow the user to control speech playback rate.
yes
I am taking speech playback to mean synthesized speech! But my interpretation
has to be wrong because these are not guidelines for us.
8.1     Allow the user to navigate views (notably those with frame viewports).
yes
Clarification sought. Even with the definitions, I believe views and viewports
are confused in the guidelines. Also the Guideline 8 talks about navigating the
content and 8.1 is navigating views. To "access content" and "navigate content;"
these phrases need clarification.
8.2     Keep track of the user's point of regard in each view and restore it
when the user returns to the view.
yes
As you move from one view of one page to another and back - the "point of
regard" should be the same.
9.1     Provide a mechanism for highlighting and identifying (through a standard
interface where available) the current view, selection, and focus.
yes
Clairification sought. Certainly "highlighting" is a bum steer. I hope this says
a user must be able to know what is the current view. Now if we could get view
and viewport straight it would help.

        Keyboard Support (priority 1)
2.1     By default and without additional customization, ensure that all
functionalities offered by the user agent are accessible using the keyboard.
yes
2.2     Provide documentation on default keyboard commands and include with user
agent documentation and/or user help system.
yes
2.3     Provide information to the user about the current keyboard
configuration.
yes     Clairification sought. If keyboard is not configurable, is this met? Is
this just an expansion of provide documentation?

        Device Independence (Priority 1)
1.1     Ensure that all functionalities offered through the user interface may
be operated through standard input device APIs supported by the operating
system.
no
There are features not available with the mouse. This should *not* be
non-compliance on an accessibility checklist. In fact they are not available
without speech output. (The settings menu.) But that was intended for the target
audience.
1.2     Ensure that the user can interact with all active elements of a document
in a device independent manner.
no
JavaScript elements.
1.3     Ensure that the user can install the user agent software in a device
independent manner.
yes
Default installation fits the description.
1.4     Ensure that the user can configure the user agent in a device
independent manner.
yes
1.5     Ensure that the user can access user agent documentation in a device
independent manner.
yes
1.6     Ensure that all messages to the user (e.g., warnings, errors, etc.) are
available through standard output device APIs supported by the operating system.
yes
Note, some error messages come as standard dialogs from Netscape, but HPR
messages meet 1.6.

        For Tables (Priority 1)
8.3     For dependent user agents. Allow the user to navigate among table cells
of a table (notably left and right within a row and up and down within a
column).
yes
9.7     For dependent user agents. Provide access to header information.
yes

        For Images, Animations and Image Maps (Priority 1)
5.1     Allow the user to turn on/off rendering of images.
n/a
no images
5.2     Allow the user to turn on and off rendering of background images.
n/a
no images

        For Multimedia (priority 1)
5.3     Allow the user to turn on and off rendering of video.
n/a
no video rendered
5.4     Allow the user to turn on and off rendering of sound.
n/a
Sound not rendered by hpr.
6.8     Allow the user to control video frame rates.
n/a
6.9     Allow the user to control the position of captions.
n/a     (closed captions not CAPTION's)
6.11    Allow the user to control audio playback rate.
n/a
no "audio playback"
7.6     If a technology allows for more than one caption or description track
(e.g., caption, auditory description, video of sign language, etc.), allow the
user to choose from among the tracks.
n/a
no video, video description, captioning
7.7     Allow the user to specify that description tracks (e.g., caption,
auditory description, video of sign language, etc.) be rendered at the same time
as audio and video tracks.
n/a
7.8     If a technology allows for more than one audio track, allow the user to
choose from among tracks.
n/a

        For Events, Applets, and Scripts (Priority 1)
5.8     Allow the user to turn on and off support for scripts and applets.
no
We require JavaScript to start, but then do not support it!
10.1    Provide information about document and view changes (to the user and
through programming interfaces).
yes
None in Hpr, I think. Or maybe tab around windows. Current window announced.
This checkpoint must be clarified.

        For Standards and Conventions (Priority 1)
11.1    Implement the accessibility features defined for supported technologies.
yes
Standard Windows controls
12.1    Use and provide accessible interfaces to other technologies.
n/a
We are an assistive technology; we don't want to provide API's. We shouldn't.
12.2    Provide programmatic read and write access to user agent functionalities
and user interface controls (including selection and focus) by using operating
system and development language accessibility resources and conventions.
n/a
As an assistive technology (which includes targeted technologies), the
checkpoint is not applicable.
12.3    Notify dependent user agents of changes to the document and user
interface controls (including selection and focus) by using operating system and
development language accessibility resources and conventions.
n/a
Not relevant as an AT.
12.4    For graphical desktop browsers. Comply with W3C Document Object Model
specifications and export interfaces defined by those specifications.
n/a

        In General (Priority 2)
3.3     Describe product features known to promote accessibility in a section of
the product documentation.
yes
Perhaps should be n/a
7.4     When no alternative text representation has been specified, indicate
what type of object is present.
yes
Yes as option for images.
8.4     Allow the user to navigate among all active elements in the document.
yes
8.5     Allow the user to search for rendered text content, including
alternative text content.
yes
8.6     Allow the user to navigate the document structure.
yes
9.4     Make available information about an element's context within a document
(e.g., numerical or relative position).
yes
Both item x of y and link x of y.

        User Interface (Priority 2)
4.1     Allow the user to configure the user agent in named profiles that may be
shared (by other users or software).
no
6.15    Allow the user to control speech volume, pitch, gender and other
articulation characteristics.
yes
Issue Raised on list! It is ridiculous that gender and pitch are priority 2! The
phrasing makes conformance not clear. We change volume, and pitch under some
circumstances and claim conformance. WORDING!!
9.3     For dependent user agents. Allow the user to view a document outline
constructed from its structural elements (e.g., from header and list elements).
yes
The wording is not good. Don't we already have a 'navigate' by structural
elements. Is this a technique for 8.6?
10.2    Ensure that when the selection or focus changes, it is in the viewport
after the change.
yes

        Keyboard Support (Priority 2)
2.4     Allow the user to configure the keystrokes used to activate user agent
functionalities. Wherever possible, allow single key activation of functions.
no
With HPR 2.5 its is possible to configure keystrokes but not really useful, so
we say no here.
2.5     Allow the user to turn on and off author-specified keyboard
configurations.
no
Could this possibly be saying, after arguing for AccessKey, now allow it to be
turned off! AccessKey is a bad idea.
2.6     Use platform conventions to indicate which keys activate which user
agent functionalities.
no
This is accelerator key by underline in win32.
2.7     Avoid default keyboard configurations that interfere with system
conventions.
yes
Sure we avoid such.

        For Links (Priority 2)
9.5     Make available whether following a link will involve a fee.
no
Can this be determined?

        For Frames (Priority 2)
5.12    Allow the user to turn on and off rendering of frames.
yes
Yes because of frame expand, but I think this is an unrealistic checkpoint. What
does it mean to have rendering of frames truned off. Is this a request that
provide access to NOFRAMES content. If not, probably should be.
6.16    When new windows or user interface components are spawned, allow the
user to control window size and position.
n/a
9.2     For dependent user agents. Provide the user with information about the
number of viewports.
yes
But the closest I can imagine is for hpr there is one speech vieewport. On the
visual UI, there are 4. These numbers are fixed.

        For Forms (Priority 2)
9.9     Provide the user with access to any label explicitly associated with a
form control.
yes
6.7     Allow the user to control animation rate.
n/a
6.10    Allow the user to start, stop, pause, and rewind video.
n/a
6.12    Allow the user to control audio volume.
n/a
6.13    Allow the user to start, stop, pause, and rewind audio.
n/a
This is multimedia audio.

        For Standards and Conventions (Priority 2)
11.2    Support appropriate W3C Recommendations.
yes
But only the appropriate ones! Does this mean if we do not support ABBR and
ACRONYM (P1) we are not P2 compliant or not P1 compliant?
12.5    For graphical desktop browsers. Provide programmatic exchange of
information in a timely manner.
n/a
12.6    Follow operating system conventions and accessibility settings. In
particular, follow conventions for user interface design, default keyboard
configuration, product installation, and documentation.
yes

        In General (Priority 3)
7.5     When alternative text has been specified explicitly as empty (i.e., an
empty string), render nothing.
yes
8.7     Allow the user to configure structured navigation.
yes
Of course this is not clear. So I say YES since HPR has the most extensive
structure navigation.
10.4    When loading a document, make available what portion of the document has
loaded, whether loading has stalled, and when the user may begin to browse.
yes
Combined is more difficult to assess.
10.5    Make available what portion of the document the user has viewed.     yes
WhereAmI function.

        User Interface (Priority 3)
4.2     Allow the user to configure the visual arrangement of user interface
controls.
no
This is an unreasonable accessibility checkpoint.
5.13    Allow the user to turn on and off author-specified page forwards that
occur after a time delay and without user intervention.
no
It seems that page forwards are correct.
5.14    Allow the user to turn on and off automatic page refresh.
no
Is this something in control of browser?
9.10    Maintain consistent user agent behavior and default configurations
between software releases. Consistency is less important than accessibility and
adoption of system conventions.
yes
This is too far into user interface design. These are not accessibility issues,
they are usability issues. Which, I believe impact people with all disabilities.

        Keyboard Support (Priority 3)
2.8     Provide a default keyboard configuration for frequently performed
operations.
yes

        For Links (Priority 3)
7.9     Provide a mechanism (e.g., through style sheets) to distinguish visited
links from unvisited links.
no
7.10    Allow the user to specify (e.g., through style sheets) that images used
in links must have borders.
n/a
We don't have images.
9.6     Make available information about a link that will enable the user to
decide whether to follow the link.
no

        For Tables (Priority 3)
9.8     Make available the dimensions of a chosen table.
yes
        For Forms (Priority 3)
10.6    Allow the user to request to be prompted before a form is submitted.
no
Checkpoint should allow only onnon-submit button submission!

        For Events, Applets, and Scripts (Priority 3)
10.3    Allow the user to configure the user agent for notification of certain
types of document changes only.
no
I don't know what this means. Is is on my list of "guideline issues"


Detailed Issues list:
7.2 For dependent user agents. Ensure that the user has access to the content of
an element selected by the user.
The word "selected" gave me lots of problems. Since "selected" has a very
different and very common meaning, I wish a different word or phrase could be
found. I tried using "the current,"  rather than "selected by the user" and in
HPR I think that works.
9.16 Identify a link selected by the user.
9.19 Identify a table selected by the user.
9.23 Make available the coordinates in the current table of a selected table
cell
9.22 Identify the table containing a table cell selected by the user.

9.2 For dependent user agents. Provide the user with information about the
number of viewports.
Probably one example would clarify this for me.
9.10 Make available the number of links (to distinct targets) in a document.
9.11 Make available the number of visited links (to distinct targets) in a
document.
Why is this accessibility? Who cares about the number of visited links. And the
requirement of distinct targets vs links seems out of line as a guideline.
9.17 Make available whether a chosen link (target) is local to the document.
This does not seem to be an accessibility requirement. Does it have something to
do with "downlevel" browsing configurations.
10.3 Allow the user to configure the user agent for notification of certain
types of document changes only.
The wording of 10.3 is so nebulous as to make its compliance vacuous. "Certain
types" could be the empty set of types and thereby everybody complies.

(See attached file: hpr-uag.htm)

Jim Thatcher
IBM Special Needs Systems
www.ibm.com/sns
thatch@us.ibm.com
(512)838-0432