Details expander

All right, today, let’s talk about details expanders. These might also be called accordions in your design system, but generally, we’re going to look at what you need to know about them right now.

This information is adapted from AtomicA11y.com, Atomic A eleven Y and from TheBookOnAccessibility.com. Now, you’ll notice this lesson isn’t titled accessible Details Expander, because if you created something that’s not accessible, you didn’t create an expander, you just created really crappy decoration. That’s not what we’re to do today. You can’t possibly learn every single nuance about accessibility in a single lesson. But you will become alert to the fact that there are requirements about the way expanders are supposed to work and function for people using assistive technology and different disabilities. You can always refer to atomica11y.com for more information, more working examples, and code.

To be sure that we’re talking about the same thing, an expander allows detailed information to be hidden by default. It can be closed or collapsed and hide the information, or it be open and expanded and reveal that information.

When we’re talking about people with disabilities using expanders, we’re generally talking about these disabilities. So beginning with low vision, we’re talking about people who use their smartphone or their laptop device. They may be changing the font size on their devices. They might be using magnification tools that zoom way, way in on their screen. Or on a smartphone, they might be pinching and zooming in to see detail better.

Not everyone perceives color the same way. One in twelve men and one in 200 women have differences in the way they perceive color.

When we’re talking about people with motor disabilities, we’re talking about people who are unable to use a mouse or tap on their screen or do those things precisely. So they may be using a keyboard to navigate their device. They might be using a switch controller, which is something akin to a game controller, or they might be using voice commands to speak to their device.

And when we’re talking about blindness, we’re talking about people who are using their smartphone, they’re using their desktop machine, but they’re using applications is called screen readers to read what’s happening on the screen to them in combination with a keyboard or by swiping and tapping on their smartphone in a very specific sequence.

To accommodate people with low vision, the first barrier we want to remove is being able to adjust the default font size on the device. Now, this is different from hitting Command or Control plus and zooming in in that way in your browser. We’re talking about literally resizing the default typeface size by 200%. This helps people who would say they don’t have a disability, but they just bumped up the text size on their phone so they can see it a little bit easier.

For people with low vision, we also want to make sure that our text has a minimum contrast ratio of 4.5 to 1, and the expanded or collapsed indicator has a contrast ratio of at least three to one. For people with differences in color perception, we cannot use color as the only means of conveying meaning. For some people, red and green, for example, look exactly the same.

For people with motor disabilities that prevent them from being able to tap or click precisely, we want to make sure that we’re providing them with a generous target area. The click or tap target area must include the label and be no smaller than 24 by 24 pixels to meet AA requirements. To meet AAA requirements, the target area includes the label and is no smaller than 44 by 44 pixels.

For people using assistive technology, there is a very specific set of keyboard and screen reader interactions that they expect to be able to use. For people using a keyboard or for people using a screen reader in combination with the keyboard. When they press the tab key, focus will move to the expander, and when they press the space bar or the enter key, the expander will toggle between being open and closed.

For people using a mobile screen reader on their smartphone or handheld device, when they swipe, left or right, it will move focus to the expander, and they will hear it express its state as expanded or collapsed. And when they double tap, it will toggle the expander.

The screen reader output must include the name role and state of the expander. Its name must be clear. It must identify its role of being either a button or a summary, and it will express its state of being expanded or collapsed.

To meet AA requirements, keyboard focus must be visible in some way. To meet AA requirements, the focus indication must have a 3:1 minimum contrast ratio against the default and adjacent elements. Oftentimes, it is much easier to assign a blanket 3:1 contrast ratio across all components such as this thick outline rather than trying to design a custom focus style for every single component.

Let’s listen to a screen reader interaction with a summary component.

About the NATO Alphabet. Collapsed. Summary. About the NATO Alphabet. Expanded. Summary.

You heard its name, its role, in this case of summary, and its state. It expressed whether it was expanded or collapsed.

About the NATO Alphabet. Collapsed. Button. About the NATO Alphabet. Expanded. Button.

Here, because of the way the component was coded, it described its role of button, but everything else was the same.

The difference between those two components is simply how they’re coded. It’s possible to create an expander out of a details and summary component, and this requires no additional scripting.

It is also perfectly acceptable to construct an expander out of a button and custom components. This does require additional JavaScript for the actions of expanding and collapsing and for describing its state. This works just fine and gives you a little bit more control over the expansion and collapse animation.

Let’s talk about use cases for expanders. We definitely should use expanders where people might need additional details, and it’s not going to be problematic if we hide trivial information by default. But where people definitely need the details, don’t hide information.

Let’s not do weird stuff with expanders. So don’t separate the text label from the indicator, and don’t place the indicator on the right for wide content. This is to help people with low vision. People with low vision may be using a magnification tool that allows them to zoom way, way in. When they come across an expander, it may look like this if the indicator is way off on the right, and they will have no idea of knowing whether this is a button, a heading, or what this component will do if they click on it unless they scroll far to the left and far to the right in order to understand it.

Only the button is clickable and focusable. Do not focus the entire summary expander.

And let’s try to avoid mashups. When we bring expanders into combination with other components, we’re often creating very complex interactions. It’s important to understand that you might have a great team of developers working for you who might be able to work through how to make this accessible. But we want to make sure that we’re committing to keeping that accessible for as long as we use that component. So just because we shipped something and deployed it and it was accessible doesn’t mean that future developers will keep it accessible. You must have a plan for maintenance and continually keeping those specialized components accessible.

A common use case for expanders is FAQs. And let’s be honest, most FAQs are full of questions you wish people would ask rather than anything helpful in completing tasks. Instead, place that information where people are actually looking for it and need it.

And if you have a series of expanders, don’t automatically collapse them as you open a new one. This eliminates people’s ability to read and simultaneously compare information across expanders.

Are there times when it’s okay to break the rules? Maybe you saw Apple or Google do something. Well, look, just because Apple or Google do something, even though they’re great big, successful companies, doesn’t mean they necessarily had people with disabilities in mind when they made that. Maybe your manager thinks that an inaccessible pattern looks way cooler. Look, it is your job as a designer, as a developer, to advocate for the people using your products. Do the right thing. Maybe you’re on a tight deadline and everybody’s saying, We don’t have time for accessibility. That’s nonsense. It doesn’t take any longer to design and build for accessibility than it does to create something full of barriers for people with disabilities. Maybe the devs are telling you that it’s just not possible to build an accessible expander, but I can assure you they are wrong. There are plenty of examples on AtomicA11y.com that can help them code and build a accessible expander with very little effort. And lastly, maybe you know it’s not good to hide helpful content from the customer, but someone is telling you that you want to do it because it gets all of this content above the fold. Well, okay, the concept of getting content above the fold is from the early 2000s before people knew how to scroll. You can trust that your customers and users know how to scroll on the internet in this day and age.

So that’s the end. Go forth and come back when you need help. You can always find more information, examples and code at AtomicA11y.com. And if you’re building a enterprise-level TheBookOnAccessibility.com is written just for you. Thank you.