Leonard R. Kasday, Ph.D., Diane Nelson Bryen, Ph.D., Paul Ryan Bohman, M.S.
Institute on Disabilities
at Temple University,
WebAIM (Web Accessibility in Mind), Center
for Persons with Disabilities, Utah State
University
Copyright (c) 2001-3 Institute on Disabilities, WebAIM
Funded by the RERC on Communication Enhancement
through a grant from the National
Institute on Disability and Rehabilitation Research
People with motor disabilities often face obstacles navigating Web pages. Web navigation is usually easiest with a mouse, but even users who can operate a mouse or similar device (e.g. a joystick or trackball) may encounter pages that require fine motor control. People who cannot use a mouse may encounter pages that require mouse operation, forcing them to emulate the mouse via keyboard commands, which is slow and often impractical. Even when a page is theoretically usable via the keyboard, the number of keystrokes required may be impractically large. This whitepaper describes the problems, and how they can be addressed by four different approaches: 1. User Strategies, 2. Web Page Design Strategies, 3. Browser Enhancements, and 4. Accessibility Enhancement Tools. It also presents initial work on an online accessibility enhancement tool, named Accent, that transforms Web pages into formats more accessible to people with significant motor disabilities.
Traditional ways of storing information present substantial obstacles for people with significant motor disabilities. It can be difficult for a person with motor disabilities to manipulate books and papers, and even when assistive technology is available to help (e.g. low-tech devices like mouthsticks or more advanced technology like motorized page turners), it can be difficult to retrieve books and papers from shelves and file cabinets. The World Wide Web has the potential to overcome these physical obstacles: Web pages can be retrieved and scanned by switches or interfaces to the person's existing assistive technology, such as an Augmentative and Alternative Communication device, or AAC.
Unfortunately, existing Web pages, and the devices available to browse those pages, often present obstacles of their own, which can make it excessively time consuming, or even impossible, for a person with motor disabilities to use the Web. This paper addresses these obstacles and how they can be addressed by:
The paper addresses the needs of two groups of users with motor disabilities:
This paper extends remarks made in the Institute on Disabilities/UAP Comments on 36 CFR Part 1194[3]. It also presents initial work on an online accessibility enhancement tool, called Accent, that transforms pages into a format more accessible to people who use AAC or have significant motor disabilities.
Even when an individual with motor disabilities can operate the mouse, there can be difficulties using the mouse.
Borders between frames need very fine mouse control to grab and move, as shown in this example of resizable frames.
In this first screenshot, the mouse pointer is nearly touching the division between the top and bottom frame. However, this proximity is not sufficient to grab the dividing line.
This second screenshot shows what happens when the pointer is moved just a few pixels:
The cursor has changed to a double pointed arrow, showing that, if the user manages to press the mouse key without moving the mouse, the dividing line can be moved up and down. Unfortunately, it takes extremely fine motor control to grab and move the dividing line. This is a particular problem when the user has increased font size to an extent that a frame needs to be enlarged.
Make it easier to grab the frame borders, by providing at least an option to:
Create a control that allows the user to resize the frames. The control could create a popup window and prompt the user to choose the specific size of each of the frames in the frameset, giving the user full control. This type of control can be written either in JavaScript or in a server-side scripting language.
Image links may be too small to be easily selected with a mouse.
Here is an example of a very small image used as a link: 
Use the <label> tag to associate the text with the form element. This allows the user to click on the text to select the radio button or checkbox. Note: older browsers do not support this functionality.
Insert a text identifier for each form element (e.g. {a}, {b}, {c}, etc). Create a function allowing users to jump to the desired form elements, based on the text identifiers.
Microsoft Windows has a feature that reduces the need for mouse movement called "SnapTo", which automatically moves the mouse pointer to the default button or the center of a dialog box. This feature is found in the "Mouse" control panel (not the Accessibility Control Panel), as shown in the following screenshot:
This feature does not work on links or other objects on Web Pages, which is certainly a problem for people who find SnapTo useful.
Be aware that if you use these features, they will not apply on Web pages.
Have option to use these features.
Not applicable.
Not applicable.
Some users cannot use the mouse. Most of the time, it is possible to navigate Web pages using the keyboard. However, some Web pages have elements that can only be operated with a mouse. This requires the user to use mouse emulation: e.g. moving the mouse one small step at a time with the keyboard, which is slow at best, and impractical at worst. The offending elements are as follows:
An "image map", is an image with selectable regions. For example, the following image map has regions labeled "Catalog", "Service", and "Contact".
The most common form of image maps ("client side image maps") allow the user to use the tab key to step through the links. However there is another form, called "server-side image maps" which do not have this capability. The user must select a region with a mouse, which is a problem for people who typically use the keyboard or keyboard emulation.
Use mouse emulation.
Not applicable.
Not applicable.
Frame resizing was discussed above, where it was noted that fine motor control is needed to grab the border between the forms. This is another case where mouse operation is essential, and the user must resort to mouse emulation.
Some pages use programmed objects, for example text that continuously scrolls up:
These may be implemented by Flash, Java , and Javascript Applets. These often require the use of a mouse. Also, they may require speed of response, e.g. to click on a headline as it scrolls by:
Not applicable.
Some Web pages use the "mouseover" feature. This is a feature that causes information to appear, or some other action to take place, when the user simply moves the mouse over an item. Consider for example, the following graphic:
When the user moves the mouse over this graphic, a submenu appears, supplying the user with new information and new options.
This additional information is not available by tabbing or any other keyboard method. It is only available when the mouse (or mouse emulation) is used.
Provide a keyboard-accessible alternative to the mouse-dependent script, either instead of or in addition to the original script.
The online repair tool described below will add an icon
which the user can reach in the usual way—e.g. through the tab key or
the shortcut that the tools provides—and which allows the user to activate
the same functionality as the mouseover using the keyboard.
Even when the user can navigate the Web page via the keyboard, operation can be slow or confusing.
If there are many objects it takes a long time to tab through the links. e.g. Yahoo, a popular Internet portal, has about 270 links on its home page. Therefore as many as 270 tabs may be needed to access a particular link. If it takes a person 2 seconds to activate a key—not uncommon for people with significant motor disabilities—it would take more than six minutes to reach a link at the bottom of the page.
Here is a screenshot of a part of the Yahoo! home page[8]:
Tabbing through each of these links to reach one in the middle or near the end of the page is a tedious and time-consuming activity.
Notes:
Despite the potential usefulness of access key shortcuts, they fall short of their promised benefits. First of all, there is no recommended standard set of access keys for common Web site functions. For example, the link to the home page in one Web site might be the H key, whereas other sites it may be the M key, Q key or U key. Users will have to learn the shortcut keys for every Web page they visit. Secondly, access keys conflict with the shortcut keys of browsers and assistive technologies, especially when international hardware and software configurations are taken into account. There is no reliable access key character that will not conflict with at least one computer configuration.
Not applicable.
Change the way that access key shortcuts are activated.
It can be hard to see where you are when tabbing though objects. Consider the following screenshot, taken with Microsoft Internet Explorer.
The "Resources" link is highlighted, but very hard to see.
1. Use a browser that highlights the selection region more distinctly. The
Opera Browser and Internet Explorer for
Macintosh are good examples of this strategy. Here is a screenshot from the
Opera browser:
it is easier to see that the "Resources" link is highlighted.
2. Use style sheet that highlights selected links. A stylesheet is a set of
rules that tells the browser how to display objects on the Web page. To use
your own stylesheet, for example, in Microsoft Internet Explorer, select Tools,
then Options, Accessibility. Then check "Format documents using my style
sheet" and browse to the stylesheet. This will cause text links to highlight.
(Unfortunately, with current browser technology, it does not cause images
or form items such as checkboxes or radio buttons to highlight--this is discussed
more in the next section)
The following demonstration uses the stylesheet shown in Appendix I.
Here is a screenshot of what it looks like when a link is selected using the default highlighting in Internet Explorer:
Here is a screenshot of the selected link with the stylesheet in Appendix I.
Use stylesheet that incorporates the rule in Appendix I, or other similar rules.
Make selection highlight easier to see, not just a faint dotted line, or at least provide the option to do so.
Increase the visibility of highlighted links and form elements, e.g. by using a stylesheet that incorporates the rule in Appendix I, or other similar rules.
One of the ways to improve highlighting of selected objects in the previous section makes use of stylesheets. However, style sheet highlighting does not work directly on input objects (checkboxes, radio buttons, etc.)
Not applicable.
Not applicable.
Support style sheet highlighting on input objects.
Create a <span> or <div> element around each form element that is highlighted when tabbed to, as in the screenshot below:
This approach is used in the prototype tool described in this paper
There are apparent inconsistencies tabbing through objects with Microsoft Internet Explorer (i.e. the need to use arrows on radio buttons).
An example is shown as a form below this paragraph. If you are reading this on a computer (rather than on paper) you can try it out. Start with the cursor in box "X" and press the tab key. If you are using Microsoft Internet Explorer, tabbing will step you one-by-one through lines 1 to 5, but the next tab skips to line 8 instead of taking you to line 6. In other words, you cannot use the tab keys to step you through the radio buttons. It turns out that you need to use the arrow keys instead. This is an inconsistency, or at least an apparent inconsistency.
Let the tab key always step through each separate visible element (e.g. radio buttons).
Possibilities include:
The enter key submits forms in most modern browsers from within text input elements as well as submit buttons. A person using the keyboard to navigate a long form may accidentally submit it by pressing Enter.
The Institute on Disabilities at Temple University and WebAIM at Utah State University have collaborated to create a prototype tool to increase the accessibility of Web pages for people with motor disabilities and for people who use AAC technologies. Len Kasday initiated the development process at the Institute on Disabilities, with support from the RERC on Communication Enhancement.
Accent is an online tool (www.accent.webaim.org) that processes Web content to make it more accessible to individuals with motor disabilities. Users of this tool can submit the URI (Uniform Resource Indicator, i.e. Web Address) of a Web site, and then continue using that Web site with the enhancements of the Accent tool throughout that site. There is no need to submit every page in a Web site individually, since each subsequent page is processed through Accent before being displayed for the user. Users can also upload individual files one at a time to view them through Accent, though this approach does not lend itself to browsing Web sites.
Here is a screen shot of the Accent home page:
The user can choose which accessibility features to utilize in Accent by clicking on the "change preferences" button. Accent will save these settings for the user as long as the user's browser has cookies enabled.
The tool addresses some of the main problems for keyboard operation, namely the problems associated with small image links, too much tabbing, scripts that require a mouse, and selection highlights that are difficult to see. Accent allows the user to:
The default minimum image link size is 10 pixels. Users can increase this size in order to more easily click on small images. In the following screenshots, the minimum size was increased to 40 pixels.
Original image (with keyboard shortcut): 
Image after setting minimum size to 40 pixels:
The key to providing quick access to links is to provide a keyboard shortcut to each link, using a method that does not interfere with hardware or software configurations. Accent inserts a text identifier before every link, and then provides a JavaScript function that opens a dialogue box, requesting that the user type the letter(s) of the text identifier.
Here is a portion of the Yahoo! home page with the added text identifiers that
Accent provides:
In order to access these text identifiers, Accent inserts a button at the top of the page which activates the JavaScript shortcut feature. The user simply types the letter(s) of the shortcut, presses OK, and then the script not only takes the user to the link within the Web page, but follows that link to its destination. This cuts down the number of keystrokes to only 3 or 4 (depending on whether the text identifier consists of 1 or 2 letters).
The same text identifiers also work with form elements. The user types in the letter(s) of the text identifier, and the script jumps to the specified form element, and highlights it with a yellow and red outline.
The tool makes mouseover events accessible to the keyboard. Accent inserts
an icon
next to the links that activate mouseover events.
When the user tabs to the new icon, the mouseover event is activated as if
the user had used a mouse.
Below is an example of a university Web site with a side menu that displays a submenu when the mouse is moved over the links. (In this example, the mouse is over the word "students".)
The following screenshot shows Accent in use on the same Web page with the same mouseover submenu activated:
Notice that Accent has inserted a text identifier for each of the links, plus a mouseover icon for each of the words which activate submenus.
Accent applies a Cascading Style Sheet (CSS) style to the Web page which highlights the active link with a yellow background and dark red border.
The style appears when the user tabs to a link. This allows the user to more easily keep track of the keyboard focus on the page.
The same CSS style is applied to form elements when tabbed to, making it easier to keep track of the cursor location when filling out forms.
Note: the style is not applied to the form element directly, but to a <span> or <div> tag surrounding the form element.
The Web has the potential to provide unparalleled freedom to people with motor disabilities, as long as: 1. the user employs effective access strategies, 2. Web developers include accessibility features in their Web content, 3. browsers provide accessibility options, and 4. accessibility enhancement tools further increase the usability of Web content for users with motor disabilities. The goals are to increase the usability of mouse functions for people with motor disabilities and to provide keyboard access to all content, with a minimum number of keystrokes. Both of these goals are mentioned in the World Wide Web Consortium's (W3C) Web Accessibility Guidelines[10] and User agent Guidelines [11], but these guidelines are quite general in their treatment of the topic, leaving out the details of exactly how to accomplish the goals. Their vagueness has led to the creation of the more specific topics covered in this paper. The greatest success will be achieved when users, Web developers, browser developers, and accessibility tool developers work together to solve the challenges faced by people with motor disabilities.
Please send comments to Paul Bohman, co-author of this paper, at paulb@cpd2.usu.edu. We are especially interested in comments from individuals with motor disabilities people who use AAC technologies. If you, as a user of AAC devices, encounter additional obstacles to using the Web, please contact us and we will try to provide a strategy.
The research was funded by the RERC on Communication Enhancement through a grant from the National Institute on Disability and Rehabilitation Research.
This stylesheet will cause text links to highlight when you tab to them. Unfortunately, with current browser technology, it does not highlight image links or form items such as checkboxes and radio buttons.
Put this in a file called "highlight.css"
a:active, a:focus, a:hover
{
background: #FFFF66;
color: #000000;border: solid #990000;
font-weight: bold;
padding: 3px;
}
[11] The W3C User Agent Guidelines may be found at http://www.w3.org/wai/ua