In modern web design, drop down menus appear very frequently. The early versions of these menus often used Adobe Flash, with the unfortunate side affect of being virtually unusable to individuals who rely on screen readers for web access. With the advent of advanced CSS, it became possible to create similar effects using standard web technologies, and drop-down menus became more accessible to people who are blind.

For those who think of accessibility on the web as applying only to visual deficits, this seemed like the answer to accessibility issues. (Those who chose not to worry about accessibility often use CSS menus because they are easier to create than Flash versions, and scale better for cell-phones.) Unfortunately, there are disabilities beyond blindness that hinder web access.

A significant number of people who have difficulty with hand control can use a keyboard or other text device, but lack the control to use the mouse effectively. (Many kinds of assistive technologies can mimic keyboards efficiently, but do not provide the freedom of movement provided by a mouse.) CSS Menus, while accessible to mouse and screen reader users, present difficulties for visitors attempting to use the keyboard to navigate a site.

Behind the Scenes

In order to understand the difficulty of drop down menus, we must understand a bit about how they are made.

Flash menus, essentially, are graphical segments that are brought forward or pushed back depending on the position of the mouse. Since they are graphics, they are not visible at all to text readers, except as a generic graphic.

CSS menus are created using formatting and positioning of standard HTML. The underling structure is simply a nested list. The visible portion of the menu is the outermost list, and the drop-down portions are sublists. Each item in the list is a link to content. The associated formatting of the sheet changes the display of the submenus depending on whether or not the mouse is over the outer list item. Depending on the method used, the submenu may be set to display off the screen, or not be displayed at all unless the mouse is over the "menu title." When the mouse moves over the title, the inner list is displayed overlapping the out, so that the menu "drops down."

This arrangement, in theory, presents no difficulties for screen-readers, since all of the links are available in the code of the web page. Similarly, text-only browsers can see all of the links, and present them just as any other list. And, in theory, keyboard navigation remains possible, since the links can be traversed using the tab key.

In fact, however, keyboard navigation is virtually impossible with this kind of menu because, while the tab key moves the "focus" to the submenu items, the user has no way of knowing what item is currently selected, or even what items are available. The only items that can be reliably accessed are those of the outer list.

A Simple Solution

Fortunately, there is a simple solution for this problem. While the Menu 1 page in the example list may contain content about the subject, it must contan, within its body, an explicit list of all of the pages or locations that can be reached via the submenu.

This approach will not inconvenience a mouse user, who can use the submenu to directly reach the locations. It will, however, make it possible for the keyboard-only user (or the mouse-user how has difficulty with nested menus) to access all of the locations offered through the sub-menu.