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

The following review of IBM Home Page Reader 2.5 for Windows 95, 98, and NT 4.0 was submitted 4 February 2000. It is based on the 26 January 2000 Candidate Recommendation.

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.


Priority 1 checkpoints

In General (Priority 1) YesNoN/A Comments/Techniques
Checkpoint 2.1 Ensure that the user has access to all content, including equivalent alternatives for content. (Techniques for 2.1)  Yes   
Checkpoint 6.1 Implement the accessibility features of supported specifications (markup languages, style sheet languages, metadata languages, graphics formats, etc.). (Techniques for 6.1)  Partial    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.
Checkpoint 7.3 Allow the user to navigate all active elements. (Techniques for 7.3)  Partial    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.
Checkpoint 8.1 Make available to the user the author-specified purpose of each table and the relationships among the table cells and headers. (Techniques for 8.1) Yes    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 11.1 Provide a version of the product documentation that conforms to the Web Content Accessibility Guidelines. (Techniques for 11.1)  Yes    Accessed with a single key, online help is a single, simple web page with headings and links.
Checkpoint 11.2 Document all user agent features that promote accessibility. (Techniques for 11.2)  Yes   
Checkpoint 11.3 Document the default input configuration (e.g., default keyboard bindings). (Techniques for 11.3) Yes     Keys reference section in the online help.
Control of style (Priority 1) YesNoN/A
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)      N/A The user agent for this is usually a plug-in.
Checkpoint 3.1 Allow the user to turn on and off rendering of background images. (Techniques for 3.1)    N/A
Checkpoint 3.2 Allow the user to turn on and off rendering of background audio. (Techniques for 3.2)     N/A
Checkpoint 3.3 Allow the user to turn on and off rendering of video. (Techniques for 3.3)     N/A
Checkpoint 3.4 Allow the user to turn on and off rendering of audio. (Techniques for 3.4)     N/A
Checkpoint 3.5 Allow the user to turn on and off animated or blinking text. (Techniques for 3.5)     N/A
Checkpoint 3.6 Allow the user to turn on and off animations and blinking images. (Techniques for 3.6)    N/A .
Checkpoint 3.7 Allow the user to turn on and off support for scripts and applets. (Techniques for 3.7)  No  We require JavaScript to start HPR, but then we do not support it. However, the user could turn off JavaScript through Netscape once HPR is started.
Checkpoint 4.1 Allow the user to configure the size of text. (Techniques for 4.1)  No  The target HPR audience is blind users.
Checkpoint 4.2 Allow the user to configure font family. (Techniques for 4.2) No  
Checkpoint 4.3 Allow the user to configure foreground color. (Techniques for 4.3)  No 
Checkpoint 4.4 Allow the user to configure background color. (Techniques for 4.4)   No 
Checkpoint 4.5 Allow the user to slow the presentation rate of audio, video, and animations. (Techniques for 4.5)     N/A 
Checkpoint 4.6 Allow the user to start, stop, pause, advance, and rewind audio, video, and animations. (Techniques for 4.6)      N/A
Checkpoint 4.8 Allow the user to configure the position of captions on graphical displays. (Techniques for 4.8)      N/A
Checkpoint 4.9 Allow the user to configure synthesized speech playback rate. (Techniques for 4.9) Yes    
Checkpoint 4.10 Allow the user to configure synthesized speech volume. (Techniques for 4.10)  Yes   
Checkpoint 4.12 Allow the user to select from available author and user style sheets or to ignore them. (Techniques for 4.12)   N/AStyle sheets not supported in this release.
User Interface (Priority 1) YesNoN/A
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.
Checkpoint 4.13 Allow the user to configure how the selection is highlighted (e.g., foreground and background color). (Techniques for 4.13)   No 
Checkpoint 4.14 Allow the user to configure how the content focus is highlighted (e.g., foreground and background color). (Techniques for 4.14)   No 
Checkpoint 5.3 Implement selection, content focus, and user interface focus mechanisms. (Techniques for 5.3)  Yes   
Checkpoint 7.1 Allow the user to navigate viewports (including frames). (Techniques for 7.1)  Yes    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.
For Keyboard and other Input Devices (Priority 1) YesNoN/A
Checkpoint 1.4 Ensure that every functionality available through the user interface is also available through the standard keyboard API. (Techniques for 1.4)  Yes   
Checkpoint 10.2 Avoid default input configurations that interfere with operating system accessibility conventions. (Techniques for 10.2)  Yes   
For Communication (Priority 1) YesNoN/A
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.
Checkpoint 1.2 Use the standard input and output device APIs of the operating system. (Techniques for 1.2) Yes   
Checkpoint 1.3 Ensure that the user can interact with all active elements in a device-independent manner. (Techniques for 1.3)  Partial    HPR 2.5 does allow the user to interact with most active elements using the keyboard and/or a mouse. The exceptions include elements involving JavaScript and applets.
Checkpoint 1.5 Ensure that the user interface provides information through redundant output modes. (Techniques for 1.5) Partial     All output is auditory, and most but not all output is also displayed textually. Question: How would a telephone voice browser meet this requirement?
Checkpoint 5.1 Provide programmatic read and write access to content by conforming to W3C Document Object Model (DOM) specifications and exporting interfaces defined by those specifications. (Techniques for 5.1)     N/ADon't see a need for any other assistive technology to access our DOM.
Checkpoint 5.2 Provide programmatic read and write access to user agent user interface controls using standard APIs (e.g., platform-independent APIs such as the W3C DOM, standard APIs for the operating system, and conventions for programming languages, plug-ins, virtual machine environments, etc.) (Techniques for 5.2) Yes    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.
Checkpoint 5.4 Provide programmatic notification of changes to content and user interface controls (including selection, content focus, and user interface focus). (Techniques for 5.4)  Partial  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.
Checkpoint 10.1 Provide information to the user about current user preferences for input configurations (e.g., keyboard or voice bindings). (Techniques for 10.1) Partial     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) YesNoN/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.
Checkpoint 5.6 Follow operating system conventions and accessibility settings. In particular, follow conventions for user interface design, default keyboard configuration, product installation, and documentation. (Techniques for 5.6) Yes    
Checkpoint 6.2 Conform to W3C specifications when they are appropriate for a task. (Techniques for 6.2)  Partial     HPR supports HTML 4.0 including common deprecated elements, but not SMIL, CSS, MATHML, or DOM.
Checkpoint 7.4 Allow the user to choose to navigate only active elements. (Techniques for 7.4)  Yes    HPR provides key sequences and a special view for navigating only links and controls.
Checkpoint 7.5 Allow the user to search for rendered text content, including rendered text equivalents. (Techniques for 7.5)  Yes    HPR allows searching for text content, alternative text, and form control labels and states (meta text).
Checkpoint 7.6 Allow the user to navigate according to structure. (Techniques for 7.6)  Yes    HPR allows navigation by characters, words, items/paragraphs, table cells/rows/columns, headings, lines, and other structures (lists, forms, maps, and select menus).
Checkpoint 8.2 Indicate to the user whether a link has been visited. (Techniques for 8.2)    No 
Checkpoint 8.3 Indicate to the user whether a link has been marked up to indicate that following it will involve a fee. (Techniques for 8.3)   No  
Checkpoint 8.7 Provide a mechanism for highlighting and identifying active elements (through a standard interface where available). (Techniques for 8.7)  Yes    HPR has a separate view and unique key sequences for identifying active elements.
Checkpoint 10.7 Allow the user to configure the user agent through a profile. (Techniques for 10.7)    No  HPR allows configuration settings for only one user.
Checkpoint 11.4 In a dedicated section of the documentation, describe all features of the user agent that promote accessibility. (Techniques for 11.4)      N/A HPR is an assistive technology, so all features promote accessibility.
Checkpoint 11.5 Document changes between software releases. (Techniques for 11.5)  Yes   
Control of style (Priority 2) YesNoN/A
Checkpoint 3.8 For automatic content changes specified by the author (e.g., content refresh and page forwards), allow the user to slow the rate of change. (Techniques for 3.8)  Yes    Automatic forwarding suppressed by HPR to allow user to read the page and then click on the link to go forward.
Checkpoint 4.7 Allow the user to configure the audio volume. (Techniques for 4.7)      N/A
Checkpoint 4.11 Allow the user to configure synthesized speech pitch, gender, and other articulation characteristics. (Techniques for 4.11) Partial    Users can configure speech rate, pitch, volume, and language and whether to use voice changes for link announcements, but they cannot select the voice/gender.
User Interface (Priority 2) YesNoN/A
Checkpoint 4.15 Allow the user to configure how the focus changes. (Techniques for 4.15)    No  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.
Checkpoint 4.16 Allow the user to configure user agent initiated spawned viewports, prompts, and other windows. (Techniques for 4.16)    No  HPR does not spawn new viewports and windows but Netscape does.
Checkpoint 8.6 Make available to the user an "outline" view of content, built from structural elements (e.g., frames, headers, lists, forms, tables, etc.) (Techniques for 8.6)  Yes    In speech but not visually in one view, HPR provides outline views of content using the header, table, and structure navigation keys.
Checkpoint 9.1 Ensure that when the selection or content focus changes, it is in a viewport after the change. (Techniques for 9.1)  Yes   
Checkpoint 9.2 Prompt the user to confirm any form submission triggered indirectly, that is by any means other than the user activating an explicit form submit control. (Techniques for 9.2)     N/A  I don't think a form submission can be triggered indirectly in HPR.
For Keyboard and other Input Devices (Priority 2) YesNoN/A
Checkpoint 10.4 Allow the user to change the input configuration. (Techniques for 10.4)  Partial   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)    No 
Checkpoint 10.6 Follow operating system conventions to indicate the input configuration. (Techniques for 10.6)    No 
For Communication (Priority 2) YesNoN/A
Checkpoint 5.5 Ensure that programmatic exchanges proceed in a timely manner. (Techniques for 5.5)  Yes   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)    No  HPR doesn't support ACCESSKEY.

Priority 3 checkpoints

In General (Priority 3) YesNoN/A Comments/Techniques
Checkpoint 2.4 When a text equivalent for content is explicitly empty (i.e., an empty string), render nothing. (Techniques for 2.4)  Yes   
Checkpoint 2.7 For author-identified but unsupported natural languages, allow the user to request notification of language changes in content. (Techniques for 2.7)    No  HPR renders in speech supported language changes using its own algorithm, but it does not notify the user of element language attributes for unsupported languages.
Checkpoint 7.7 Allow the user to configure structured navigation. (Techniques for 7.7)  Yes    HPR allows navigation by characters, words, items/paragraphs, table cells/rows/columns, headings, lines, and other structures (lists, forms, maps, and select menus). The difference between 7.6 and 7.7 is very subtle.
Checkpoint 8.4 Make available to the user information that will help the user decide whether to follow a link. (Techniques for 8.4)    No 
Checkpoint 9.4 When loading content (e.g., document, video clip, audio clip, etc.) indicate what portion of the content has loaded and whether loading has stalled. (Techniques for 9.4) Partial     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.
Control of style (Priority 3) YesNoN/A
Checkpoint 3.9 Allow the user to turn on and off rendering of images. (Techniques for 3.9)      N/AHPR only renders text and speech.
User Interface (Priority 3) YesNoN/A
Checkpoint 8.8 Allow the user to configure the outline view. (Techniques for 8.8)  Partial    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).
Checkpoint 8.9 Allow the user to configure what information about links to present. (Techniques for 8.9)    No 
Checkpoint 9.3 Allow the user to configure notification preferences for common types of content and viewport changes. (Techniques for 9.3)    No 
Checkpoint 10.9 Allow the user to configure the arrangement of graphical user agent user interface controls. (Techniques for 10.9)    No  The target HPR audience is blind users.
For Keyboard and other Input Devices (Priority 3) YesNoN/A
Checkpoint 10.8 Provide default input configurations for frequently performed tasks. (Techniques for 10.8)  Yes