Ever made an app that is impossible to use? There’s a chance you have. Technology users are a diverse bunch, which means that some of your users are using your app much differently than you would expect. That’s where accessibility comes in: Designing for everyone regardless of disability. Here are some tips and resources to get you started.
Don’t rely on a single sense
Whenever I ask people what comes to their mind when thinking about accessibility, the answer is almost invariably: “Putting alt texts on pictures!” That is indeed an essential part of making your product accessible.
If a user wouldn't know what to do if an image is missing, it needs a label. For example, if you were to write something like this:
A screen reader would announce it as just a "button". Not very helpful.
But what to write for the label? Certainly not a description of the image. I, being a screen reader user, wouldn’t know what to expect if your button said “pencil”. Instead, think of what you would write if you couldn’t use any images at all. That’s your label.
However, labeling images is just a small part of the big picture (no pun intended). What if your product uses different color backgrounds extensively to convey some state but your user is colorblind? What if your product has a set of complex instructions and one of your users is dyslexic? What if your product requires the user to drag something around with a mouse but they can’t use one? All those examples are about relying on only one of your user’s abilities to use your product, and that is a fatal design flaw.
Semantics are the key
I’m betting my entire year’s salary that at least one of you has written something like this:
Now, what do you think a screen reader might announce when encountering that piece of code? Most likely it's going to be one of the following:
- “Clickable”
- “Blank” (denoting a blank line)
- Nothing at all
Not such a good user experience, right?
Assistive technologies need to be told what each UI element does. In other words: What is its “role”. Sounds complicated? That’s because in most cases you don’t need to worry about this. All standard UI elements in HTML as well as on the desktop and mobile have all the necessary accessibility information built into them. A , on the other hand, is "a generic inline container for phrasing content, which does not inherently represent anything." No amount of pixel-bending makes that generic container a button in the eyes of a browser or a screen reader. Likewise, a pile of nested's does not turn automagically into a fully keyboard navigable drop down list; It needs semantics. Using a wrong element for the task is just as bad: If your control acts semantically like a checkbox then it must be a checkbox element, not a link or a button. (Yes, I’ve seen both being used.) Again, it all comes down to meeting the user’s expectations. A link acts very differently than a checkbox, and using a stateless control for representing state makes no sense anyway. The right thing to do in this case, simple as it sounds, would be to use a native, semantically correct UI element whenever one is available. If the action of clicking your downwards-pointing arrow is something you think a button would do, then it is a . However, there are some rare cases where this isn’t possible. For example, mobile operating systems might have restrictions on how far you can customize a ui widget without creating a new one, and on the web you can’t do something like a tree view without making your own UI widget from scratch. IN these cases you have to start fresh and implement all the accessibility functions of that widget yourself. Unless reinventing the wheel — and doing it really, really well — is something you fancy doing, I’d advise you sticking to native elements and widgets. And this brings me to…
No ARIA is better than bad ARIA
If you’re a web developer, you might have come across an acronym called ARIA, which stands for Accessible Rich Internet Applications. It’s a set of HTML attributes that can be used to make web applications more accessible. Or less accessible as is often the case.
Roles are probably one of the most-cited examples of ARIA misuse. Roles are a mechanism of giving any html element a different semantic meaning.
Hello
would look like a button to a screen reader.
Now, I once saw a bit of code that looked like this:
- ...
Using
- is all well and good. It's a plain old unordered list. But then there's that role="listbox". That piece of code suddenly turned that unordered list into an element which is very, very different than an unordered list. Needless to say that this control didn't work at all for screen reader users, since that element was never meant to be used like a list box. It would have worked perfectly with no ARIA at all. ARIA should be the last tool you need. Like that compatibility CSS you hope you would never have to write. In 9 cases out of 10 native html elements have solved all the accessibility problems you ever need to think about. And for those times where ARIA is actually necessary and useful there are plenty of resources to help you out. Which, again, brings me to…
A special note to UI component authors
UI frameworks and components are a great thing for us developers. They let us focus on what makes the product special rather than making components that have been made thousands of times already. A popular, well-designed UI component is a huge usability booster, since usability — like accessibility, I might add — tends to get thrown out of the window when budgets hit their limits. However, pre-made UI components have their downsides as well: A beautiful but badly designed UI component spreads inaccessibility around like a rampant virus.
One of the ui components with notoriously lacking accessibility are date pickers. Browser support for the date element has only now started to appear, so it’s hardly surprising that there are dozens upon dozens of variously functioning datepickers running around the interwebs. Most of the ones I have seen are so neglected in their accessibility that it’s not even funny. However, one of the best I’ve come across is AirBNB’s React-dates. It’s an absolute joy to use.
I cannot stress this enough: If you’re not going to take accessibility feedback seriously, at least when your new component has started to gain any kind of traction, you might as well not bother writing the component at all. Skimping on accessibility testing means that someone, somewhere is bound to get a user experience from hell.
What can I do?
The above examples certainly weren’t an exhaustive list of accessibility problems and their solutions. They were just some “low hanging fruits” that you, the developer, can go and fix right away with tremendous impact to your (screen reader) users. Here are some tips and resources that will give you a much broader understanding of what accessibility is and how to design for everyone.
- There are standard guidelines which are used for measuring the accessibility of apps and web services. By far the most common one is the WCAG, which stands for Web Content Accessibility Guidelines. Both iOs and Android have also their own accessibility instructions and guidelines. Unlike the WCAG, these resources are more practical and give you concrete examples on how to use the accessibility apis on each platform. Start here if you’re a mobile developer.
- Read. There are a ton of freely available accessibility resources. These include MDN’s accessibility documentation, Heydon Pickering’s inclusive components blog and the free resources provided by accessibility consulting companies such as WebAIM, The Paciello Group and Deque Systems.
- One of the easiest things you could do would be to use an automatic accessibility evaluator like Deque Systems’ AXe or WebAIM’s WAVE. There is also eslint-plugin-jsx-a11y to keep React developers in check. These tools are absolutely better than nothing, but keep in mind that these are just that, mechanical tools. Using these exclusively would be like ditching your UX designer for automatic CI builds, i.e. something that makes zero sense.
- Dive right in: All of the major operating systems on the desktop and mobile have built-in accessibility features, such as a screen reader and a magnifier. On Windows you still would be better off installing a 3rd party screen reader. This is what some of my colleagues have ended up doing and they’ve found it to be an interesting challenge.
- Testing the accessibility of your product with real users is by far the best thing you can do. After all, they are the people who have the real insight of knowing when something is or is not accessible. As I mentioned, there are dedicated companies who perform this kind of auditing for you, and they’re able to give you precise instructions on what to fix. Seeking testers in social media or even through some local disability organizations would also be a good bet.
