Case Study: Bringing Accessibility to Tabs and Accordions
Smarten up your interface for WCAG and JAWS
Tabs and Accordions are useful ways to organize content on your website, but they present special challenges for people with disabilities. Why, and how can you fix that?
Lipman Hearne recently created a new WordPress theme for Northern Arizona University as part of a university-wide branding and enrollment marketing engagement, which additionally included comprehensive brand development and an identity refresh, a new marketing strategy, print and digital communications, and media planning, implementation, and measurement. As we developed page templates, we took the opportunity to examine how we were coding layout elements, and to see if there were ways we could improve the accessibility of the frameworks we’d been using. Tabs and accordions presented a particular challenge. This case study, originally prepared for the WPCampus 2017 conference, provides an overview of the solutions we developed.
The Tab and Accordion Elements
Tabs and accordions organize your content into panels that are revealed when your visitors want to see them. In the tab, above, we are presenting a sequence of related panels of information that make the most sense read left to right; in this case, we expect our reader to click each tab, and read each panel. In the accordion, we present four chunks of information, only one of which may be relevant to your visitor; in this case, your visitor can toggle open the panel she wants to read.
They create meaningful groupings of content, and make the page look less information-dense by hiding secondary information, but they also make a few assumptions about your visitor:
- She is using a mouse or touchscreen device and can click or tap on the tabs or accordion toggles
- The organization of the information makes sense, because she has seen and used a file drawer or an accordion file
- She can even see what’s on the screen and knows that there’s information that will be revealed when she interacts with these features
None of these assumptions can be counted on. Your digital audience comprises a great number of people with a wide range of physical, visual, cognitive, and neurological capability.
How do we make our content most accessible?
First, by listening. Safia Abdalla (@captainsafia) Tweeted out this question:
“If you have a disability, what’s the hardest thing about browsing the web?”
The replies were illuminating, and it’s worth reading the whole discussion thread. But a few common complaints jump out with regards to tabs and accordions:
I don’t have one but my mother has Parkinson diseas and mouse Interactions are really hard for her
— A dev has no name (@KodierKroete) June 4, 2017
Lack of focus outlines. Especially on links (they look ugly to most designers so they remove them) and custom components (eg dropdowns).
— nuton.dev (@NutonDev) June 3, 2017
My brother-in-law has cerebral palsy, buttons and links are too small for him to use. He can only use touch because he can’t hold a mouse.
— Gary Rozanc (@garyrozanc) June 3, 2017
What do we do?
There’s a specification for that! We start by making sure that a site meets Web Content Accessibility Guidelines (WCAG), which describe a set of standards for (among other things) font size, type color and contrast, the proper captioning of images and media, and non-mouse usage. This ensures that everyone, from the law-school hopeful with cerebral palsy to the future MBA who happens to be color blind, can easily find information on your site.
Further, we need to make sure our content is accessible to screen readers, including VoiceOver for the Mac, and JAWS for Windows.
How do we do it?
You have two options.
Option 1: Destroy!
This is the easiest and fastest fix to implement. Give your users a choice of how they’d like to interact with your site—in this case, would they like to have tabs and accordions on the page, or would they prefer an Enhanced Usability Mode, which turns your components from tabs and accordions to regular HTML content, like this:
Everybody wins. All your visitors get to interact with your content the way they want to, and you save dozens of hours of development time.
There are, however, cases where exposing all hidden content does not make for a better user experience. For instance, if you have a page with 56 course listings in accordion panels, the best user experience may be one where your visitor can skip over those that are outside of her area of interest rather than having to wade through every expanded listing.
Option 2: Accessible Tabs and Accordions
We found three main benchmarks that ensure a site’s tabs and accordions pass WCAG and screen-reader testing:
- Keyboard navigation
- Obvious focus indication
- Spoken instruction
Load the web page and set your mouse aside. Start tapping the Tab key on your keyboard. This is how many folks will use your website, either because using a mouse is not feasible for them, or because they simply can’t see the screen. Can you open the navigation menus? Can you expose every panel of hidden content?
Obvious focus indication
As you tab around the page, do you know where you are? In the above example, we can toggle open each tab and accordion panel, and it’s always clear which panel is about to be toggled.
Visitors using screen readers, such as JAWS, absolutely rely on spoken instruction. In the example above, the blue outline indicates which element of the page has focus—that is, which element is currently under your cursor, and what the screen reader is going to read out loud. As the cursor moves from element to element, your site should provide spoken instructions for navigation. For example, when you first focus on the tab group, the screen reader will tell you, “You have reached a tab control,” and then provide instructions for switching tabs, and for getting from the tab button to the related tab panel.
Want to know more? We’ve shown our work!