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.
| # | Checkpoint | P | HPR | Comment |
|---|---|---|---|---|
| In General (Priority 1) | ||||
| 3.1 | Ensure that all product documentation conforms to the Web Content Accessibility Guidelines. | 1 | yes | |
| 3.2 | Ensure
that all user agent functionalities that promote
accessibility are documented. |
1 | yes | |
| 5.5 | Allow the user to turn on and off rendering of captions. | 1 | 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. | 1 | yes | |
| 7.2 | For dependent user agents. Ensure that the user has access to the content of an element selected by the user. | 1 | 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. | 1 | 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. | 1 | n/a | HPR Does no render animated text. |
| 5.7 | Allow the user to turn on and off animations and blinking images. | 1 | n/a | similar |
| 5.9 | Allow the user to turn on and off support for user style sheets. | 1 | n/a | similar |
| 5.10 | Allow the user to turn on and off support for author style sheets. | 1 | n/a | similar |
| 5.11 | Allow the user to turn on and off support for spawned windows. | 1 | n/a | similar |
| 6.1 | Allow the user to control font family. | 1 | 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 | 1 | no | ditto |
| 6.3 | Allow the user to control foreground color. | 1 | no | ditto |
| 6.4 | Allow the user to control background color. | 1 | no | ditto |
| 6.5 | Allow the user to control selection highlighting (e.g., foreground and background color). | 1 | no | ditto |
| 6.6 | Allow the user to control focus highlighting (e.g., foreground and background color). | 1 | no | I assume this is what we see in Windows standard list boxes. |
| 6.14 | Allow the user to control speech playback rate. | 1 | 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). | 1 | 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. | 1 | 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. | 1 | 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. | 1 | yes | |
| 2.2 | Provide documentation on default keyboard commands and include with user agent documentation and/or user help system. | 1 | yes | |
| 2.3 | Provide information to the user about the current keyboard configuration. | 1 | 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. | 1 | 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. | 1 | no | JavaScript elements. |
| 1.3 | Ensure that the user can install the user agent software in a device independent manner. | 1 | yes | Default installation fits the description. |
| 1.4 | Ensure that the user can configure the user agent in a device independent manner. | 1 | yes | |
| 1.5 | Ensure that the user can access user agent documentation in a device independent manner. | 1 | 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. | 1 | 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). | 1 | yes | |
| 9.7 | For dependent user agents. Provide access to header information for a selected table cell. | 1 | yes | |
| For Images, Animations and Image Maps (Priority 1) | ||||
| 5.1 | Allow the user to turn on/off rendering of images. | 1 | n/a | no images |
| 5.2 | Allow the user to turn on and off rendering of background images. | 1 | n/a | no images |
| For Multimedia (priority 1) | ||||
| 5.3 | Allow the user to turn on and off rendering of video. | 1 | n/a | no video rendered |
| 5.4 | Allow the user to turn on and off rendering of sound. | 1 | n/a | Sound not rendered by hpr. |
| 6.8 | Allow the user to control video frame rates. | 1 | n/a | |
| 6.9 | Allow the user to control the position of captions. | 1 | n/a | (closed captions not CAPTION's) |
| 6.11 | Allow the user to control audio playback rate. | 1 | 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. | 1 | 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. |
1 | n/a | |
| 7.8 | If a technology allows for more than one audio track, allow the user to choose from among tracks. | 1 | n/a | |
| For Events, Applets, and Scripts (Priority 1) | ||||
| 5.8 | Allow the user to turn on and off support for scripts and applets. | 1 | 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). | 1 | 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. | 1 | yes | Standard Windows controls |
| 12.1 | Use and provide accessible interfaces to other technologies. | 1 | 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. | 1 | 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. | 1 | 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. | 1 | n/a | |
| In General (Priority 2) | ||||
| 3.3 | Describe product features known to promote accessibility in a section of the product documentation. | 2 | yes | Perhaps should be n/a |
| 7.4 | When no alternative text representation has been specified, indicate what type of object is present. | 2 | yes | Yes as option for images. |
| 8.4 | Allow the user to navigate among all active elements in the document. | 2 | yes | |
| 8.5 | Allow the user to search for rendered text content, including alternative text content. | 2 | yes | |
| 8.6 | Allow the user to navigate the document structure. | 2 | yes | |
| 9.4 | Make available information about an element's context within a document (e.g., numerical or relative position). | 2 | 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). | 2 | no | |
| 6.15 | Allow the user to control speech volume, pitch, gender and other articulation characteristics. | 2 | 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). | 2 | 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. | 2 | 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. | 2 | 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. | 2 | 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. | 2 | no | This is accelerator key by underline in win32. |
| 2.7 | Avoid default keyboard configurations that interfere with system conventions. | 2 | yes | Sure we avoid such. |
| For Links (Priority 2) | ||||
| 9.5 | Make available whether following a link will involve a fee. | 2 | no | Can this be determined? |
| For Frames (Priority 2) | ||||
| 5.12 | Allow the user to turn on and off rendering of frames. | 2 | 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. | 2 | n/a | |
| 9.2 | For dependent user agents. Provide the user with information about the number of viewports. | 2 | 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. | 2 | yes | |
| 6.7 | Allow the user to control animation rate. | 2 | n/a | |
| 6.10 | Allow the user to start, stop, pause, and rewind video. | 2 | n/a | |
| 6.12 | Allow the user to control audio volume. | 2 | n/a | |
| 6.13 | Allow the user to start, stop, pause, and rewind audio. | 2 | n/a | This is multimedia audio. |
| For Standards and Conventions (Priority 2) | ||||
| 11.2 | Support appropriate W3C Recommendations. | 2 | 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. | 2 | 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. | 2 | yes | |
| In General (Priority 3) | ||||
| 7.5 | When alternative text has been specified explicitly as empty (i.e., an empty string), render nothing. | 3 | yes | |
| 8.7 | Allow the user to configure structured navigation. | 3 | 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. | 3 | yes | Combined is more difficult to assess. |
| 10.5 | Make available what portion of the document the user has viewed. | 3 | yes | WhereAmI function. |
| User Interface (Priority 3) | ||||
| 4.2 | Allow the user to configure the visual arrangement of user interface controls. | 3 | no | This is a totally 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. | 3 | no | It seems that page forwards are correct. |
| 5.14 | Allow the user to turn on and off automatic page refresh. | 3 | 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. | 3 | 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. | 3 | yes | |
| For Links (Priority 3) | ||||
| 7.9 | Provide a mechanism (e.g., through style sheets) to distinguish visited links from unvisited links. | 3 | no | |
| 7.10 | Allow the user to specify (e.g., through style sheets) that images used in links must have borders. | 3 | 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. | 3 | no | |
| For Tables (Priority 3) | ||||
| 9.8 | Make available the dimensions of a chosen table. | 3 | yes | |
| For Forms (Priority 3) | ||||
| 10.6 | Allow the user to request to be prompted before a form is submitted. | 3 | no | Only on non-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. | 3 | 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 "current," which in HPR I think is correct replacement.
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.