-
Notifications
You must be signed in to change notification settings - Fork 18
Inaccessible hamburger control #40
Description
I am limiting accessibility feedback to the hamburger navigation, though the site is full of accessibility issues and barriers (you can test with just your Tab key to start). The hamburger, however, is a critical failure that blocks the greatest set of users from accessing any of the content on the site while also demonstrating a broad swath of WCAG failures coupled with a technically straightforward fix.
The control that shows and hides the navigation when zoomed or in a mobile browser is inaccessible.
- It has no accessible name,
- Ref: WCAG 2.1 SC 4.1.2 Name, Role, Value (Level A);
- It has no focus styles and the browser default is removed,
- Ref: WCAG 2.1 SC 2.4.7 Focus Visible (Level AA);
- The hover style for the hamburger (the close button has no hover style) cannot be used as the focus style since it has a 2.2:1 contrast ratio with the adjacent border,
- Ref: WCAG 2.1 SC 1.4.11 Non-text Contrast (Level AA);
- It does not programmatically indicate its expanded/collapsed state,
- Ref: WCAG 2.1 SC 4.1.2 Name, Role, Value (Level A);
- The primary navigation is not hidden, forcing 23
Tabpresses or mobile swipes to get to the hamburger,- Ref: WCAG 2.1 SC 2.4.3 Focus Order (Level A),
- Ref: WCAG 2.1 SC 2.4.7 Focus Visible (Level AA);
- The button to close the navigation, and all the navigation, precedes the hamburger control in the DOM, forcing a user to know to tab backward,
- Ref: WCAG 2.1 SC 2.4.3 Focus Order (Level A);
- The button to close the navigation has an accessible name of "[en-US] general.close_nav" (from the nested
<span>),- Ref: WCAG 2.1 SC 3.3.2 Labels or Instructions (Level A);
- The SVG in both buttons lacks an image alternative, or should be hidden completely from screen readers if no alternative is appropriate (the latter applies in this case),
- Ref: WCAG 2.1 SC 1.1.1 Non-text Content (Level A),
- Ref: WCAG 2.1 SC 4.1.2 Name, Role, Value (Level A);
The relevant code today:
<button class="Pagination__SidebarToggle-fmwu6l-2 dKQIoy SidebarToggle">
<svg […] class="Hamburger__Container-j038hg-0 fIONJq">
[…]
</svg>
</button>.dKQIoy:focus {
outline: 0px;
}The easiest way to address this:
- Use a disclosure widget;
- Remove the close button (and restyle the hamburger)
- Move the navigation to after the hamburger in the DOM;
- Hide the navigation container with
display: none;until expanded; - Increase the contrast on the hover styles;
- Replicate the hover styles as focus styles;
- Provide accessible names using a method that you can easily localize;
Your HTML and CSS then might look like this:
<button class="Pagination__SidebarToggle-fmwu6l-2 dKQIoy SidebarToggle" aria-expanded="true|false" aria-label="Navigation">
<svg […] class="Hamburger__Container-j038hg-0 fIONJq" aria-hidden="true">
[…]
</svg>
</button>
<div class="Nav__NavContainer-uo6ep0-1 iskZBJ">
[…]
</div>.dKQIoy:focus svg {
stroke: rgb(34, 36, 41);
}
.dKQIoy:focus {
background: rgb(65, 199, 199);
}For more details on disclosure widgets, including how they work, how to code them, how they are exposed in screen readers, and so on, I have a tutorial: Disclosure Widgets.
I recommend you use this pattern for the language selectors as well, since right now they are completely inaccessible because they use <div>s with click handlers instead of native <button> elements.