Efficient keyboard support in web-pages

Efficient keyboard support in web-pages Martin SCHREPP, Rakesh JANI SAP AG, Neurottstrasse 16, D-69190 Walldorf, Germany Abstract. An efficient keyboard access to web sites is vital for many disabled users. We conducted a study which compares the efficiency of web site navigation by keyboard and mouse. This study shows clearly that the current amount of keyboard support in most common web sites is far from being sufficient. The effort necessary to conduct a certain task by keyboard is much higher than the necessary effort to conduct the same task by mouse. We relate this result to the current design paradigm used to organize web sites. In addition we discuss typical problems concerning keyboard support in web sites, possible solutions and their constraints. Keywords. Accessibility, Keyboard support, Web page design, Efficiency, Usability

Introduction Since many disabled users are not able to use the mouse or other pointing devices, it is necessary to provide unlimited keyboard access for web pages. This is vital for blind users, since the keyboard is for them the most important input medium. There are also users who are not able to work efficiently with the mouse, because their tactile skills are restricted. Several guidelines are available which describe what is necessary to make web pages accessible. Well-known examples are the Web Content Accessibility Guidelines [1] from the W3C’s Web Accessibility Initiative, the Section 508 guidelines [2], or the technical specification ISO TS 16071 [3] from the International Organization of Standardization (ISO). These guidelines consist of a number of checkpoints which describe properties that an accessible web site must have. The checkpoints are oriented towards the special needs of people with sensory (like colour blindness or even total blindness), mobility (e.g. arthritis or total paralysis) or even cognitive impairments. The main content of these guidelines concerning keyboard support is that every interactive part of the interface (e.g. buttons, fields, links, etc.) must be reachable by keyboard actions. In addition all possible actions must be supported over the keyboard, for example it must be possible to follow links with the SPACE or ENTER key. Keyboard access to interactive elements of web sites, like links or fields, is in general provided by including all interactive elements of the page into a virtual linear sequence. The user is able to navigate from an element in this sequence to the next respectively previous element by pressing the TAB-key (therefore this virtual sequence is called the TAB-chain) respectively the key combination SHIFT + TAB. This method to make sites accessible over keyboard is problematic if a web site contains a huge number of interactive elements, since the user has to press the TAB-key very often to reach the required element.

1. A study on keyboard support in web sites We conducted a study which compares the necessary effort for users which navigate in a web site using the mouse respectively the keyboard. For this study we measured on several popular German web sites the number of interactions (key presses or mouse clicks) necessary to navigate to a predefined page within the web site. The investigated web sites can be grouped into online journals, web shops and official web sites from governmental organizations. In each category we examined 6 common web sites and formulated 3 different tasks on each site. Each task was solved in parallel by mouse and by keyboard navigation. Table 1 shows the result of the study. Table 1: Results of a comparison of necessary interaction steps between keyboard and mouse navigation. Category Online Journals Web Shops Government Sites

Average number of clicks in mouse navigation 1,89 3 2,88

Average number of key presses in keyboard navigation 114,33 102,44 61,99

The results clearly show that the necessary effort to access the information by keyboard is much higher than the necessary effort to access the same information by mouse. This results from the fact that the design of most web sites is heavily optimized for mouse navigation. Another general observation is that the effort to finish a task by keyboard navigation clearly increases with the number of pages within the web site, while this has only limited influence on the necessary effort by mouse navigation. For a user who navigates a page with a mouse the effort to execute a link on a page is independent from the number of links on the page (except when the user has to scroll down to reach the link). Thus, it is for such users a very efficient design to organize the content of a web site over a few navigational pages which contain many links. This is also in line with research results concerning the organization of hierarchical data, which showed that users find resources faster in broader shallow sites than in narrow deep sites [4, 5, 6, 7]. Also quite popular statements like The required information is just 3 clicks away are based on this type of design. But for a user navigating solely with the keyboard this type of design is problematic. Assume, for example, that a page contains n links and that users of this page select all those links with the same probability 1/n. These links are included in the tab chain in a sequential order. Thus, a user navigating by keyboard will have to press in average (n+1)/2 times the TAB-key to select the desired link. This number clearly depends on n and reaches an unacceptable value in typical web sites. For example, the start page of www.cnn.com contains 144 links, the start page of www.zeit.de (a German newspaper) contains 241 links, and the start page of www.zdf.de (web site of a German television channel) contains 168 links (all numbers measured in October 2004). It is important to notice that the described organization of web sites is not in contradiction with the accessibility guidelines mentioned in the introduction. The efficiency of the keyboard support is only covered by Section 508 checkpoint o) A method shall be provided that permits users to skip repetitive navigation links and WAI 1.0 checkpoint 9.5 Provide keyboard shortcuts to important links.

But it is hard to find web sites which comply with these two checkpoints, since they are themselves somewhat problematic in the context of the web. Keyboard shortcuts are a very efficient tool to perform actions on a page, but the user has to learn them. Thus, they are adequate to support expert users who interact daily with an application and are thus willing to spend the time to learn the shortcuts. But visitors of web sites (disabled or not) are not this type of users. Even a disabled user will not accept that he or she has to learn shortcuts to get information out of a news page, especially since there will be different shortcuts used on different pages as long as there are no standards available (and it will be nearly impossible to formulate such standards, since different web sites offer quite different interaction patterns). Thus, a handicapped user will naturally accept to learn the shortcuts used by his or her browser, but will refuse to learn navigational shortcuts for each single web site. 2. What can be done to improve the keyboard access to web sites? As we have shown one of the main problems in keyboard access to web sites is the fact that the keyboard support is provided solely over the TAB-chain. In principle there are two possibilities to solve that problem. The first method is to shorten the length of the TABchain by reorganizing the content of the web site. The second method is to add accelerators (user interface elements that allow the user to perform a task quickly even though the same task can also be performed in a more general and possibly slower way) for keyboard access to the page. Before we go into a more detailed discussion of these methods we will describe some constraints that every solution must consider. As we have argued already in the last section, keyboard shortcuts will not solve the problem. It is impossible to force different web-designers to use the same set of shortcuts for identical functions. Thus, even if a page supports shortcuts, users will not know these shortcuts and will not accept that they have to learn shortcuts for each page they visit. Thus, the only chance to improve keyboard support in web sites is to add visually indicated accelerators (for blind users this indication must be of course enhanced with a textual representation) to give users some idea about their existence and functionality. The accelerators must be intuitive to use and should not require learning. But on the other hand they should not disturb non-handicapped users who navigate with the mouse. Assume, for example, that we add accordingly to Section 508 checkpoint o) skipping options for repetitive navigational links. How should the existence of these skipping options be indicated to disabled users? Often keyboard support can be dramatically improved by avoiding basic mistakes. We will give now some examples for typical design problems we observed in our study. One of the problems we often observed in web sites is that the pages contain multiple links which point to the same target. For example, a summary of an article is shown on a news page. It consists of a picture on the left, a title link and a link More… at the end of the summary, which all navigate to the same page. All three links are included in the tab chain. If such multiple links would be avoided the length of the TAB-chain would decrease significantly and the keyboard access would be much faster. It is a well-known fact that the

time necessary to click on a target depends on the distance of the cursor to the target and on the size of the target (this is called Fitts-Law, see [8]). Thus, it makes sense to offer for optimal mouse navigation in addition to a text link the possibility to click on a bigger picture. But in such cases the additional links should be taken out of the TAB-chain (this can be achieved easily by setting the value of the attribute TABINDEX for the corresponding page element to -1). Irrelevant elements in the TAB-chain are another typical problem. For example, in a layout table the focus is set first to the cell and then to the link contained in the cell. Here the cell is an irrelevant element in the Tab-chain. A powerful way to improve keyboard access is to provide a search function for content of the web site. This allows a user to directly access the relevant information without browsing. But to be effective this search function must be presented at the beginning of the TAB-chain. Often the user has to tab through a huge part of the page to reach the search function, which clearly reduces the efficiency of this tool. Another typical problem we often observed is that the focus is not set to the proper place after page navigation. For example, a user performs a search over a search function. The hit list for the search is displayed in another page. But the focus is not, as the user would expect, on the first element of the hit list, but on the first link in the page. Thus, the user has to tab through the header area of the page again to reach the result of his or her search request. A simple way to improve keyboard navigation is to add a number of redundant links for page internal navigation to the beginning of the page. Assume, for example, that there is a page which contains 100 links and that it is possible to group these links into 10 groups each containing 10 links. We can thus add 10 redundant page internal links to these groups to the top of this page. If the user clicks on one of these redundant links, then the cursor focus is set to the first link in the corresponding group. Such a simple mechanism can improve the keyboard navigation significantly. If we assume that a visitor of the site selects each link with the same probability, then in average users navigating per keyboard have to press 10.5 times the TAB-key to reach the desired link. This is a dramatic improvement compared to the average 50.5 presses of the tab key which are required without this mechanism. The redundant links serve here as accelerators which allow a faster keyboard navigation. Another more sophisticated solution is to use Java-Script to detect if the actual visitor of the page navigates over keyboard or mouse. This can be done, for example, by adding a Java-Script function to the page which catches the onkeydown event in the document and simply counts how often the user pressed the TAB-key. In addition, a second function can be added which catches the onmousemove event in the document and simply collects the information if the user has used the mouse at all. If the page detects that a user navigates solely by pressing the TAB-key (for example, if the TAB-key is pressed 5 times and the mouse was not used in between) then it can dynamically present special additional hints to that user, for example in a popup. These additional hints can contain a list of useful shortcuts or other hints for quick keyboard navigation. Such a solution can be implemented in a quite generic way and creates thus only a small effort for web site designers. In

contrast the keyboard support in the page is enhanced significantly and such a solution also does not get into the way of users who navigate by mouse. 3. Conclusions As we have shown providing keyboard access solely over the TAB-chain is problematic if a web site contains many interactive elements. We have also argued that it does not make sense to reorganize the content of such web sites into a bigger collection of small pages, since there is some evidence that users find resources faster in broader shallow sites than in narrow deep sites. The usability of web sites for users relying on keyboard navigation can often be improved dramatically by small enhancements. This can be done, for example, by page internal navigation links and by avoiding typical problems like multiple links to the same target. Thus, even small and straightforward changes to the page design can improve the user experience for disabled users a lot. But to enable users to navigate with the keyboard as efficient as with the mouse it is necessary to add accelerators to support keyboard access over dynamic techniques. In addition, we think that our arguments show that even if a web site is conform to the WAI guidelines or the Section 508 guidelines it may be in practice unusable for disabled users relying solely on keyboard navigation. The current guidelines should be enhanced by checkpoints which force designers to consider also the efficiency of the keyboard access to a web site. References: [1] [2] [3] [4] [5] [6] [7] [8]

Chrisholm, W.; Vanderheiden, G. & Jacobs, I. (1999): Web Content Accessibility Guidelines 1.0. Available online under http://www.w3c.org/TR/WCAG10/ . US Department of Justice. Section 508 of the Federal Rehabilitation Act. Available online under http://www.section508.gov/ . ISO/TS 16071 (2003). Ergonomics of human-system interaction -- Guidance on accessibility for humancomputer interfaces. Genf: International Organization for Standardization. Kiger, J.I. (1984). The depth/breadth tradeoff in the design of menu-driven interfaces. International Journal of Man-Machine Studies, 20, 201-213. Jacko, J.A. & Slavendy, G. (1996). Hierarchical Menu Design: breadth, depth and task complexity. Perceptual and Motor Skills, 82, 1187-1201. Zaphiris, P. & Mtei, I. (1997). Depth v. Breadth in the arrangement of Web links. Available online under http://otal.umd.edu/SHORE/bs04/index.html. Larson, K. & Czerwinski, M. (1998). Web page design: Implications of memory, structure and scent from information retrieval. Proceedings of the Association of Computing Machinery’s Computer Human Interaction Conference, 18-23. Raskin, J. (2002). The humane interface. Addison-Wesley.