12

Here's the situation. A large corporate site has a mega-menu in the primary navigation. The secondary-level page areas are available from within this dropdown (in this example the secondary levels are 'Menu one' and 'Menu two'). There are also selected tertiary levels from these sections shown in the dropdown ('one-a', 'one-b' etc.) This way you can navigate directly to selected tertiary pages from anywhere in the site, all well and good. Full navigation (Primary and secondary levels) is also available on the site footer

mockup

download bmml source – Wireframes created with Balsamiq Mockups

HOWEVER, the issue here is with the accessibility. Keyboard navigation of this type of navigation means that they cannot open the nav dropdowns menus to select lower sections (they open on mouse hover) so the only selectable elements via keyboard are the Primary navigation options (Nav 1, Nav 2, Nav 3 etc). Selecting this can open up a landing page of sorts for that item, but the landing pages don't contain all the links available; just some headline promotion items. The only way to use full navigation via keyboard is through the navigation in the footer. However the footer is (obviously) right at the bottom of the page. There will be a lot of content within the main body content so the tab order means that keyboard users cannot easily access the navigation of the site.

So, what are my options here.

  1. Say, screw it; who uses keyboards to navigate in this day-and-age (not an ideal answer)
  2. Change the tab order so that the footer links are the first thing selected when using tab (this is unexpected behaviour so isn't really desirable)
  3. Force the whole website strategy to change to include links on these category landing pages for all the lower categories just for the benefit of keyboard-only users (No idea on the usage figures of people who browse via keyboard only, I would assume this is a very small number but I don't want to rely on this assumption)
  4. Other - Surely there is something better than the above options

Note: I'm not worried about screen-readers; the navigation will be configured correctly so that it is available for these type of users. This issue is primarily aimed at accessibility of keyboard users.

Improve this question
5
  • 1
    Apparently I'm missing something, but I don't see why you can't navigate to tertiary levels using the keyboard. Have tabulation switch between top-level items, and move the focus through the second and third levels using the arrow keys, like you do with any standard menu.
    – Vitaly Mijiritsky
    Mar 15, 2012 at 17:29
  • Because the menu is triggered on cursor hover, not click. If you tab to it and click it will select the main menu option, not expand it.
    – JonW ♦
    Mar 15, 2012 at 18:37
  • 1
    However if it is possible to get some different keyboard navigation in place that'd be ideal. I'm not a JS person so it might just be that it's perfectly possible and I'm just not aware it is.
    – JonW ♦
    Mar 15, 2012 at 18:47
  • Keyboard navigation through drop-down menus is possible, although it's usually something that web developers will overlook because it's a feature that practically no one implements, so the devs themselves never use the feature. I'd eventually like to create a set of simple, reusable plugins that perform all the correct WAI-ARIA handling for accessibility, but it takes time and research to get it right.
    – zzzzBov
    Mar 17, 2012 at 5:02
  • Cant you modify it so on keyboard focus of the primarly element open the tertiary levels? EDIT - Just seen your reply! Add OnFocus events if possible and consider implementing WAI-ARIA attributes.
    – Sheff
    Mar 17, 2012 at 16:00

6 Answers 6

Reset to default
4

I think your best option is to implement keyboard navigation. You can do it fairly easily, though there are some gotchas you have to work around. I've done it where one can use the arrow keys and tab key on the keyboard to navigate through all the menus. (Alas the example I'd show you is all but destroyed by bad overseas outsourcing...sigh...)

You mainly need to deal with focus events to accommodate the keyboard.

Note another annoyance with hover-based menus will be touch devices. Many can accommodate it in different ways (iOS, for instance, sometimes require a double-tap), but I'd also make sure they open on a click/tap as well as hover.

As for option #4, this is a good idea from a UX perspective even more so than accessibility.

The problem with links being in pulldown/mega menus is that they are not readily visible. A user can easily forget what other options there were (out of sight, out of mind). It's probably a good idea to list the sub-categories on those internal pages to allow users to easily scan their options and get 'orientated' within the site easier.

Finally, lots of folks prefer keyboard navigation (by no means a majority, but plenty of power typers/programmer like folks avoid the mouse whenever they can). There's also a lot of folks that depend on assistive pointing devices...typically people with large and small motor issues, so you'll be doing them a big favor accommodating them if you can.

Improve this answer
6
  • Can you define 'keyboard navigation' in this instance. Keyboard navigation is available via standard tab-orders, but I believe you mean something more bespoke here.
    – JonW ♦
    Mar 15, 2012 at 17:13
  • Is your JS set up to expose the mega menus when a person tabs into them? That'd be what I'm getting at: the menu behaves as a menu when navigated via the keyboard. (I also like to add arrow key navigation in addition to the tab, but that's just a bonus).
    – DA01
    Mar 15, 2012 at 17:15
  • It's not my JS, but I believe that it's set not to expand on tab in. Is that actually the best thing to do though? If tabbing onto the primary nav opens up the navigation then if the user is trying to tab to main page content they'd have to tab through each of the dropdowns and their tertieary items. That could be dosens of tab-presses before they get to the content. Also if tabbing automatically opens the menu it covers up the main page content. I'm also not sure that's wise either.
    – JonW ♦
    Mar 15, 2012 at 17:24
  • 1
    From an accessibility standpoint, you usually want a 'skip to content' link near the top of the page (I like to hide it then expose it on focus) so you don't have to navigate through the menu every time. As for it opening the menu, my argument is that regardless of the input device a user is using, they should experience the same intended behavior. It's hard to navigate through a menu if you can't see it.
    – DA01
    Mar 15, 2012 at 17:35
  • You get the accepted answer for being in first and describing the answer well, although the best demo of the functionality you refer to was shown in David Farough's answer (i.e.ircan-rican.gc.ca/projects/wet-boew-menubar)
    – JonW ♦
    Mar 19, 2012 at 12:22
2

Check out the megamenu which is implemented in the Web Experience toolkit developed by the Government of Canada. This is equally accessible by keyboard and mouse. the menu uses RIA and jQuery. when the menu gains focus, the arrows can be used to move through menu structures. Right and left arrows will move through top level menus. Escape can be used to close a menu. Pressing tab from a top level menu will move your focus out of the menu structure. the URL for this project is: http://ircan-rican.gc.ca/projects/wet-boew-menubar

Improve this answer
1
  • That's not a bad example, the functionality is good for keyboard users, but my only reservation is with the discoverability of the left-right cursorkey functionality. Instinct tells me that it's tab that should move between primary navigation options, not left-right keys. (However just because it's my personal instinct to do this doesn't mean that's how all users would act)
    – JonW ♦
    Mar 16, 2012 at 16:12
1

Well I have an idea that might work:

For visually impaired people :

Keep the primary menu as unordered list and drop down menu as you will normally code in HTML , which will be accessible via keyboard tabs. Now make all this navigation hidden. So the normal people who will be using the site will be using it with mouse hover as usual.

The keyboard navigation will work perfectly for the visually impaired people now..

Drawbacks: Keyboard navigation has to go through all the inner items which is secondary and tertiary and finishing it will only make it move to primary navigation.

Improve this answer
1

The design could be modified to trigger menu display on the onfocus() event.

See this Accessible jQuery UI demo I came across a few months ago, which is completely keyboard-friendly, even the image carousel, sliders, menu tabs, etc.

I use arrow keys to traverse menu siblings, and tab to descend or ascend the menu hierarchy.

Granted, it's not a mega menu, but it may be adaptable for your design.

Improve this answer
1

The Web Accessibility Initiative (WAI) suggests "Using an expandable and collapsible menu to bypass block of content", through clicks and not mouse-over to access or skip blocks of content. The page include code examples and related reading on similar topics.

Description

This technique allows users to skip repeated material by placing that material in a menu that can be expanded or collapsed under user control. The user can skip the repeated material by collapsing the menu. The user invokes a user interface control to hide or remove the elements of the menu. The resources section lists several techniques for menus, toolbars and trees, any of which can be used to provide a mechanism for skipping navigation. Note: Similar approaches can be implemented using server-side scripting and reloading a modified version of the Web page. [1]

Most probably you would have to rewrite the entire menu-structure, however we would like to include as many as possible to our web site, and get high ratings on Accessibility measurements.

[1] http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-TECHS/SCR28

Improve this answer
0

You could implement the microsoft way of doing it: have a little underlined character in each menu item indicating the accesskey. This will involve a lot of JS'ing the accesskey back and forth since accesskeys can only be used once, even if the ither uses are hidden.

Open Word(not 2007/2010) and try navigating via keyboard. If you're used to it, it's pretty easy to just use the alts.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.