Accessibility is like privacy: it often isn't the core business of a company. Even menu's become the victim. As a result, some might never be able to reach or interact with your main navigation.
Read about Web Content Accessibility Guidelines 2.1 if you are new to web accessibility.
In this article, you'll learn why and how to build accessible menu's or dropdowns.
Use a focusable element to trigger the action
Be sure to make the hamburger menu focusable. This basically means, use buttons. And if you want to use HTML anchors, be sure to use an anchor with an href attribute that makes sense. So, no div or span elements are allowed to create the hamburger icon.
When not using an href attribute at all, the HTML anchor won't be able to receive focus at all and the button or contents it will expose, might not be accessible all together.
Don't hide the hamburger button
Obviously, hiding your hamburger menu using the CSS declarations display: none; or visibility: hidden; will benefit no one. Using an aria-hidden=true attribute won't make things better for screenreader users. Be sure to make your hamburger element focusable, regardless of the device or technology that is being used.
Describe your menu button
Be sure to describe your menu button. Even if you don't like the descriptive text "Menu" next to the hamburger menu, don't get rid of this.
Put the descriptive text into an element that will visually hide it, but make screenreaders read aloud the meaning of the button. When using bootstrap, this could be achieved using the sr-only class. Another option is introducing an aria-label attribute where it's value will describe the purpose of the anchor or button.
Displaying text via before/after pseudo elements
When using pseudo elements to display a text, take into account different devices and technologies. For example, not all screenreaders might see text that was introduced using the CSS :before or :after pseudo elements. Be sure to add a text via the more traditional ways, such as text (wrapped in a screenreader only-element) or aria-label attribute.
Outline the focus
This often still is the first thing that is being reset or omitted using boilerplate stylesheets, but will make website quite inaccessible for for example bad sighted visitors, or visitors with a motor impairment.
Chrome even changed it's default outline so that it will always be clear which item received focus, regardless of the background. Want to remove outline? Don't do it!
Is the menu (still) closed?
When the menu is closed, make sure that the inner elements (child elements) can't receive focus. This could be done by setting the CSS visibility property to "hidden", or the CSS display property to "none". More on techniques for hiding content.
Is the menu opened?
I might be able to tell if the menu is opened, as something visually will happen on the screen. But what if you are using a screenreader? Using aria-expanded to indicate the state of a collapsible element.
Can we find our way?
Visitors using a mouse will often see changes within their screen, such as opened dialogs. As a result they know they have to proceed within the opened dialog, such as subscribing for your newsletter, viewing the enlarged image within the fancybox, choosing an option from the dropdown list.
Move the keyboard focus
However, what if you're bad sighted, blind, or just can't skip to other parts that easily because of a motor disability? When buttons have to be clicked to trigger certain actions, be sure to move the focus to the dialog, dropdown menu or other widgets.
This could be achieved using JavaScript. Too much work? Be sure to get the order of your elements right and don't let other focusable elements get in between of the button and the dialog so the focus order is preserved.
Incorrect tab-order
Another pitfall is to technically position your collapsible menu before the menu-button. When you do this, keyboard or screenreader users have to traverse the elements in the opposite direction. This could be achieved by pressing Shift+tab keys at the same time. However, users can't tell the order in which your developers programmed the menu-items and thus won't be able to tell they should do so in order to reach the menu.
Let this be another reason to get the order right, or just move the keyboard focus to the collapsed menu.
Closing the collapsed menu
No one wants to get trapped. But what if you open a door and:
- don't know the amount of steps needed to get back;
- don't know how to get back at all;
- need to take 73 steps before you can leave the room;
- but don't know in advance how many steps should be taken to do so.
This is how visitors not using a mouse might feel like once they open an expandable menu or any other dialog. Be sure to give them an escape, like literally. When the escape key is being fired, try to let the menu or dialog close and bring the focus back to the element which was responsible for opening the menu in the first place. Or in other words, place them back in front of the door.
Nu.nl, a Dutch online newspaper, had a large dropdown with 73 items. Nu.nl already fixed an issue where users always had to go through this list of invisible items, even when the menu wasn't expanded.
Another (unsolved) issue is stepping out of the menu. Once the menu is opened, you are likely to have a bad time. As Nu.nl is into web accessibility, I created a solution for them to make the expanded menu go away and get back to where you came from when the escape key is being pressed.
