Accessing Nav Drop-Downs

Recently I came across a site that has a less than accessible horizontal main navigation bar with drop-down menus containing links to the different pages in each section. This got me thinking once again about the use of drop-downs from an accessibility perspective.

In particular, I thought it might be useful to consider the different ways drop-down menus are used with the aim of hopefully identifying the best way of providing keyboard and screen reader access to the main navigation and drop-down items.

I sent out a request asking people to suggest drop down menus that I should look at. Many thanks Denis Boudreau, Rick Ellis, Thierry Koblentz, Chris Hoffman and Priti Rohra for their suggestions and advice. I would also like to thank Russ Weakley, Andrew Downie and Grant Focas for suggestions, menu testing and help in preparing this article.

My aim with this article is not to look at the technical side of how drop-downs are prepared; rather I am concerned with the user-experience for people who rely on the keyboard to access the web, with and without a screen reader.

It seems that there are three basic types of navigation systems which use drop-down menus:

  1. Full tab, where the user tabs through the main navigation menu and all the drop-down options for each item.
  2. Tab and arrow, where a combination of tab and arrow keys can be used to move between items in the main navigation menu and the drop-downs
  3. Tab and enter, where the main navigation item is not a link and you can tab from main item to main item. When enter is selected on a main item the drop-down is presented and the tab key or arrow key is used to move between the choices.

Examples

The following four examples of different navigation menus with drop-downs can all be accessed with the keyboard and to varying degrees are likely to be accessible to screen reader users. The testing of these sites was done using browsers with JavaScript enabled. (NB: when I refer to using the tab key, this includes shift+tab for moving backwards.)

These examples were tested with the following system configurations: Windows XP and 7 using I.E. 8 and Firefox 3.6; Apple OSX with Safari 5.0 and Firefox 3.6. They were also tested using recent versions of the following screen readers JAWS, Window Eyes and NVDA. With some quirks and subtle differences, the screen readers all appear to behave reasonably consistently. 

1. Full tab

The Museum of East Anglia Life website has a main navigation menu with drop downs that can only be accessed by tabbing.

Screenshot of The Museum of East Anglia Life showing dropdown menu in action

Keyboard only with Windows and Mac: With Win/IE8, Win/Firefox 3.6, Mac/ Safari 5 and Mac/Firefox 3.6, when you tab from one main item to the next, the drop-down menu for the item is presented and it is necessary to tab through all the links it contains in order to move to the next main item. The keyboard arrow keys do not work with either the main navigation or the drop-downs.

Keyboard with Screen reader: With the tab key you move through all the links, similar to above. However if you use the arrow keys, you can just go from main item to main items. It appears that when you use the arrow key to go to a main navigation item and then press the tab key the drop-down menu choices are presented and you can move through the options with either tab or arrow. The presence of sub-items and how to access them is not conveyed to the screen reader user.

2. Tab and arrow example 1

The Mozilla website has main navigation items that can be accessed with the tab key or the arrow keys.

Screenshot of Mozilla website showing dropdown menu in action

Keyboard only with Windows and Mac: With Win/IE8, Win/Firefox 3.6, Mac/ Safari 5 and Mac/Firefox 3.6, you can move between the main navigation items using either the tab key or the left/right arrow keys. When on a main navigation item, pressing the down arrow key opens the drop-down and you can use the up/down arrow keys or the tab key to move through the drop-down choices.

Keyboard with screen reader: With the screen readers it was not possible to use the arrow keys to open and use the drop-down menu. However, pressing enter on each main navigation item took the user to the relevant section landing page. If the screen reader user decides to abandon normal behaviour and try the menu with the Virtual Cursor turned off (insert+z with JAWS), the arrow key will cause the content of the drop down menu to be presented. But with JAWS the items are read out as a continuous list so it is virtually impossible to make a specific choice from a menu.

3. Tab and arrow example 2

This example for Yahoo Developers also allows the user to use the tab or arrow keys to move between main navigation items, however the selection of drop-down menu choices appears to be different.

Screenshot of Yahoo developers website dropdown menu in action

Keyboard only with Windows and Mac: With Win/IE8, Win/Firefox 3.6, Mac/ Safari 5 and Mac/Firefox 3.6, you can tab from main navigation item to main item and when you press the down arrow the drop-down is presented. If you move from main item to main item with the left/right arrow keys each main navigation item is presented with the drop-down open. You use either the tab key or the up/down arrow keys to move through the drop-down options.

Keyboard with screen reader: The screen reader provides no indication to the user that there is a drop-down or how to access it and without any indication many screen reader users a likely to keep pressing the enter key in the hope of something happening. If the “virtual cursor” is turned off, when you press the down arrow key, the menu is reported but as you move down the drop-down items, with JAWS at least, the screen reader also reads content from the page directly after each item. However, if you use the down arrow to open the menu and then tab through the items just the drop-down items are reported. Yahoo “Communication” drop-down menu contains an item, PIM, which can be expanded to present third level items by pressing the right arrow, but again there is no indication that this item can be expanded or how to do it.

4. Tab and enter

With some sites, the main navigation item is not a link and the drop down menu for each item is accessed by pressing the enter key. It should be noted, that in this example from TJK Design, it appears that “Articles: E-K” page is the active page.

Screenshot of tjkdesign keyboard friendly dropdown menu in action

Keyboard only with Windows and Mac: With Win/IE8, Win/Firefox 3.6, Mac/ Safari 5 and Mac/Firefox 3.6, you tab from main navigation item to main item, but the main navigation items are not links to the landing page for each section. When focus is on a main item, pressing the enter key opens the drop-down menu, which can then only be accessed with the tab key. However, when tabbing through the main navigation items, the drop-down menu of the current page is presented when you tab to the main navigation item for that page. You can then use the tab key to move through the drop-down options related to this section.

Keyboard with screen reader: Keyboard access appears to function in the same way as described above, with the screen reader reporting each item as you tab to it and when you tab to the main navigation item for the active page the drop-down opens and you can move through the options, but in this case with either tab key or the arrow keys. For main navigation items relating to pages that are not the active page, pressing enter will open the menu and then you can move through the menu with either the tab or arrow, but tab seems a little easier to use.

Conclusion

After reviewing these menus, I have a far better understanding of why most of the people I know who rely on the keyboard to use the web have a pretty negative impression of drop-downs. Without a mouse, they are difficult to use and it appears that you can not expect them to perform in a consistent fashion.

It is hard to make a definitive statement about which drop-downs are likely to be the most accessible, in part because I think it will depend on the particular circumstances of each site. For example, a site with very few main navigation items and only a few drop-down options is not likely to present a big problem for someone who has to tab through all of them. On the other hand, if the main navigation and drop-downs contains hundreds of links, tabbing through all them could be a serious problem for some people.

From this limited testing, it seems to me that the usability and accessibility of drop-downs for screen reader users and for other people who rely on the keyboard to access the web would be significantly improved if there was a generally agreed (standard) behaviour for drop-downs and information about how to use them without a mouse was available to all users. I think these are the two key issues associated with the use of drop-downs and I would be very interested to know what other people think.

Which is better and why?

  1. Is it better to rely on just the tab key rather than a combination of tab and arrow?
  2. If we do rely just on the tab key, is it better to force keyboard users to tab though all the drop-down options? Or should you allow keyboard users to only tab from main item to main item, for example, and then they make the next level of choices on the section landing pages?
  3. If a combination of tab and arrow keys is the way to go, what is the best approach? And, how many keyboard users would even think of using the arrow keys? Not many I suspect, so what is the best way of informing them?

13 Comments

  1. I will suggest allow users accessing the web via keyboard with or without screen readers to Tab through the main navigation options and open/close the drop-down menu with the Enter key if they wish and access the sub-options. Access to the sub-options should be available with Tab as well as Arrow keys. Most importantly provide instructions to users on how to use the same using the site Help or as an instruction link that can be accessed if required.

    If we can make drop-down menus wherein users can navigate through the main options using the Tab as well as Left/Right Arrow keys would be an icing on the cake!

    Cheers,
    Priti Rohra

  2. Hey roger

    I am a Jaws user and I prefer the method where tabbing will take one to the main items and then hitting enter on the item opens the drop down and one can navigate by either tab or arrow. Using some form of message saying something along the lines of “press enter to expand” or something along those lines when the main item gets focus would also help.

  3. Hi Roger,

    Very interesting article thanks!

    I built the Museum site a few years back now using the Suckerfish jQuery plugin for the main navigation. I like the Mozilla approach of enabling the arrow keys though because tabbing down through big lists would get tiresome pretty quick. I’m surprised the Yahoo! menu had shortcomings, they’re usually on the ball when it comes to accessibility but as you say, we still don’t have a consistent method and any technique would have to be covered on a site help page. I think we’re there with regards to using nested lists (I hope) – *just* the behaviour to sort now!

    Thanks again, Karl
    @singlecelldsgn

  4. Thanks for the good review, Roger! I would be interested in hearing from more JAWS users about their preference for using or the arrow keys to initiate a dropdown menu. Since is commonly used to instigate a function, and arrows are commonly used for moving through lists, it seems like we have a hybrid situation. As a sighted person, I would think that it would be more convenient and more intuitive to move through a list of subpages using arrow keys, eliminating the need for pressing . But perhaps that would be confusing for screen reader users?

    At any rate, a nice writeup on an important topic!

  5. Sorry–I placed enter in brackets which caused it to be deleted from my note. Roger, please feel free to delete my earlier note and this sentence.

    Thanks for the good review, Roger! I would be interested in hearing from more JAWS users about their preference for using enter or the arrow keys to initiate a dropdown menu. Since enter is commonly used to instigate a function, and arrows are commonly used for moving through lists, it seems like we have a hybrid situation. As a sighted person, I would think that it would be more convenient and more intuitive to move through a list of subpages using arrow keys, eliminating the need for pressing enter. But perhaps that would be confusing for screen reader users?

    At any rate, a nice writeup on an important topic!

  6. Great article, Roger, and an important topic! A couple of thoughts:

    First, the Yahoo! menu you’re reviewing uses YUI2. The accessibility of the YUI3 menu (called MenuNav Node Plugin) is much improved. There are several examples linked from this page:

    http://developer.yahoo.com/yui/3/examples/node-menunav/index.html

    Also, the DHTML Style Guide Working Group is a group of people representing a couple of dozen organizations, working together to define a standard interface for various DHTML widgets. Here’s what they have to say about the “menu” widget:

    http://dev.aol.com/dhtml_style_guide#menu

  7. Nymphaea Notschaele

    I find in remarkable that you find inconsistencies between navigating drop-down menus with and without screen reader. This is important to know when evaluating a website for accessibility.

    On your question Which is better and why?
    Once we have a standard this will no longer be such an important question but in the mean while …
    I (as a sighted occasional keyboard user) like nr. 2 Tab and arrow. This because I am used to use arrow keys for navigating in window menus and it saves me from tabbing trough all items in the menu.

    By the way have you considered testing with speech recognition?

  8. I think a standard would be good but getting everyone to even be aware of it yet alone follow it will be the real difficulty. Personally if there are hundreds of sub items to tab or arrow through I would say that has usability issues not just keyboard issues. I have seen very deep long structures of sub nav items which are just as hard to know what to click on for mouse, sighted users let alone those with keyboard or using a screen reader. Add to that the often duplicated or awkward terms used leaves users unsure what to click on.

    Long dropdown navs are misused often as a result of little thought. I prefer having sub items nav on the sub page where it can be given context. That might be “one more click” but it’s better than the two or three that might occur as a user tries to understand a complex nav structure.

    If the dropdowns have just a few items then I guess it might be useful to all but I try to avoid them on every main nav still and have a sub nav on the sub page.

    The trouble with selecting any option, a standard or not, is that user may not like them, the change might confuse them as they have developed managing behaviours.

    I’d be interested in hearing any use of heading tags in main navs, would screen reader users prefer the familiar heading navigation?

    There is the mobile user issue too, where the oft used :hover is used to show dropdowns. That clearly doesn’t function and if the main nav is only accessible by a keyboard stroke. Compacting that is where the main nav acts as a link as well, tapping or clicking on it will cause a navigation so the dropdown isn’t even seen.

    I think this is a much more complex situation that it might appear.

  9. I tried some of the Yahoo 3 examples which Terrill Thompson pointed us to using the Jaws 11.0.1467 (current version). some of these worked quite well while others were less successful. I thought that the guidelines around the presentation of menus and the propper behaviour of menus made sence. It’s too bad that these are not more widely adopted. I think that consistancy is important. I think that it does not make sense to require the use of enter to open a main menu item if the item indicates that it is a submenu then the right arrow key should open the menu. When I moved to one of the main menu items, Jaws told me that it was a sub menu. I pressed enter to open the menu and then arrowed through the items. I could open a item which was a sub menu by pressing the right arrow key. In one of the examples I tried, I would hear Jaws speak the previously selected menu item and the newly selected menu item as I arrowed through the menu items. I also noticed when activating a menu that sometimes I would hear the click sound which is associated with the activation of the Jaws Forms mode. This was a little disconcerting.but I have to say these samples are a vast improvement from the yahoo 2 samples.

  10. The nav-menus on the Mozilla site are accessible via keyboard with and without a screen reader in use. Alt+left/right arrow keys open and move focus to menu on left or right. Escape closes menu and one can tab through main menu items or sub menu items (when sub menu is open). Use of lists is good. Screen reader users can use list item navigation too. The role of every main menu link should be conveyed to AT e.g. “Product Menu” or “Add-on menu” and so on. Off-screen text on the anchor and a title attribute will accomplish this. The museum site: a screen reader user can use list item navigation to move from one main menu link to the next without stepping through sub menu list of links. But a sighted keyboard-only user cannot do this. And the “menu” role for links is not announced. Again use of list markup is good. This has scope for improvement.

  11. My spouse and I absolutely love your blog and find most of your post’s to be precisely what I’m looking for. Do you offer guest writers to write content in your case? I wouldn’t mind writing a post or elaborating on a lot of the subjects you write related to here. Again, awesome site!

  12. Hi Roger,

    I appreciate the length you went on this Drop-Down Menu Use Case.
    I work with some JAWs screen reader users, and they get so frustrated with these type of drop down menus. Especially, as you indicate, with lengthy drop downs of many menu options. IE: My co-worker, Joy, an experienced Jaws user, would still take a few minutes to access the 4th or 5th column menu drop down and the 10 or 12 menu options below it.

    We tried to see if Jaws would at least give her an idea of what menu items are available, but as you know, that is not possible with hidden items. I think that is the biggest culprit here.
    If the element are hidden until they are invoked, then usability is not addressed. And as you clearly found, there is no uniformity from site to site on these drop downs. The W3C should make standards. HTML5 has surely brought improvements, but without uniformity, and without visibility, 25% of web users are not getting proper or full accessibility.

    I see you conducted this study around 2010. Have you, or the W3C come to a standard or a resolution now into 2014? I hope so, and look forward to any up-dates. Thank you, Pete

  13. I always used to study post in news papers but now as I am a user of web
    therefore from now I am using net for articles or reviews, thanks
    to web.

Leave a Reply