Join Derek Featherstone for an in-depth discussion in this video Views of accessibility, part of UX Foundations: Accessibility.
- Accessibility is often thought of as a legal or technical requirement. This makes sense. In many countries, there are laws in place that are supposed to ensure accessibility. Laws are black and white, right? You are either in compliance with the law, or you're not. The World Wide Web Consortium has an entire set of guidelines, the Web Content Accessibility Guidelines, that are usually cited as the standard for accessibility in those laws. But there's a problem. Earlier, we talked about accessibility being all about ease of use for people with disabilities.
Just because a website meets those standards from the W3C doesn't mean that it'll be easy for someone to use if they have a disability. Here's why. Here's a typical map that you might find somewhere on the internet. There are a few things that are required to make this map compliant. One of the biggest is ensuring that it can be used with a keyboard. In order to do that, we need to make sure all on-screen tools used to pan around the map can be used by a keyboard. There are three ways to make that happen. We can use a link, we can use a button, or we can use a div and allow that div to be clickable with the keyboard.
So we do that. But which choice is the right choice? Look at all of these buttons. The fact that we call them buttons should give you a clue what the right element choice is. The buttons all perform an action. Panning up, panning down, panning left, or panning right. They aren't like links. Links go to another page or go to somewhere else on the same page. From a functional perspective, they may all perform the same way.
But from an assistive technology perspective, we are better off using buttons than all other options. They are more readily recognized by all types of assistive technologies and are more intuitive and have exactly the right functionality built into them. They are activated by the keyboard's enter or space bar, and the focus stays on the button after is has been activated. Creating a custom control is a lot of work for very little payoff. And using a native button creates exactly the right expectation for the user. While the other options can be compliant, the best, easiest to understand, and most broadly compatible choice is the button.
We do a lot of accessibility assessments for our clients and in some cases, we actually disagree with an assessment that has been done by someone else. Shocking, I know, but it happens. Here's an example where someone asked us about using color to convey information. In general, you shouldn't use color alone to convey information because it relies on having good color vision, and of course, vision in general. Here you see a navigation bar and one of the top level navigation items includes a color change to say that it is the currently active section of the site.
Effectively, it's a you-are-here indicator. The client said, what do we need to do here? We keep getting a fail from the reviewer because we're using color alone to indicate where we are in the site. It's true. That one link, on its own, uses color alone to convey where we are in the site. But take a look at the bigger picture. That link is part of a page, which is part of a site. In addition to color, there's a page title that says where we are.
There's also a breadcrumb trail or topic path that orients the user. Finally, there's a big old heading as the first piece of content in the main part of the page. There's at least three other ways where the user is given clues about where they are. They're not in the navigation bar, so yes, that part isn't compliant. But in the big picture, it's very likely that the user will be just fine knowing where they are. A visible treatment that places an arrow or other symbol in that link would accomplish the same thing.
Yes, this is easy to fix, but no, it wouldn't be at the top of my list of priorities for addressing accessibility. Here's one last example. We often say, for accessibility reasons, that we don't want to auto-play video or audio on a web page. It can startle people. It interferes with screen-reading technology. So, we have a rule that says never auto-play content on a website. The problem with that is that auto-play can actually be a desirable thing.
For someone that has fine motor control or dexterity issues, manually starting a video on every page with the keyboard can be very difficult. What's good for one group of users might actually be the exact opposite of what another group of users needs. The rule should be, never auto-play content on a website, except for those people that benefit from auto-playing content. See the difference? Does this meet compliance simply isn't enough detail to know whether or not a person with a disability can actually use the solution we've designed and built.
Context truly matters. Accessibility can't simply be about compliance. It has to be part of user experience. And that's where your job comes in.
- What is accessibility?
- Managing flow
- Ensuring proximity in your design
- Understanding how screen readers and voice recognition programs work
- Designing for hearing, vision, mobility, and cognitive issues
- Considering accessibility in layout
- Integrating accessibility into your content strategy