14 accessibility hacks to make your users’ day better

Who cares about accessibility?

We’ve all been there. The design and UX guys cooked up some beautiful artboards, the devs applied their dev-fu to convert them into a blazing fast and responsive app, the QAs banged their hammers on it until they stopped making dents, bugs were squashed, rough edges were polished and the deployment went smoothly without anything blowing up. Then you check the benchmarks — and it turns out your accessibility score is garbage. So the designers go back to the drawing board, the developers start wading in their code wondering what they did wrong, new bugs are introduced, workload is added and everyone is lamenting. Does your app really need accessibility? Will anyone actually appreciate the effort, or is it just a thankless chore? How many users of your app will have disabilities anyway?

Turns out, a lot of them

According to WHO, one billion people experience some kind of disability. That’s 15% of the world’s population, or one in seven people. In other words, a LOT of your users will have some type of disability. It might be a minor one, making the use of certain parts of your app mildly annoying, or a severe one, making the use of the app impossible.

And they’re everywhere

It’s more of a ‘minor inconvenience’ than ‘disability’, but I suffer from protanopia, which is a form of color blindness resulting from defective red color perception. This translates from clever-speak into “I really don’t see whether your text is underlined red or green, I have no idea which of your beautiful buttons is light blue and which is lilac, I also can’t see whether the notification I got is good or bad - the green and red diode colors look absolutely the same to me.” These are just annoyances, and most of the time I forget about them anyway, but other seemingly innocent little quirks can be insurmountable mountains for people with more serious conditions. Their user experience will be - to put it mildly - pretty lousy.

So how about some empathy?

Putting yourself in someone else’s shoes can really change your perspective. Go on - get the Nocoffee vision simulator and see how your app can look for people with poor vision. Use only your non-dominant arm for navigation for a couple of minutes. While you’re at it, shake your hand when swiping on the touchscreen. Try a screen reader and see how easy it is to navigate through the app. Increase system font size and see whether text is easily readable. And let me remind you - one in seven people in the world has to do one (or more) of these things all the time. Suddenly, accessibility features stop feeling like a boring ritual to please the benchmark gods and start getting serious.

But it’s so overwhelming, what can we do?

Glad you asked. Fortunately, even if you don’t have the budget, time or inclination to implement all WCAG guidelines, there are some simple things you can do. Things that take next to no time, but that can make a world of difference for people experiencing disabilities. Things that, when taken into consideration from the get-go, will not increase your workload whatsoever. What is this sorcery, I hear you asking? Well, mostly it boils down to not being lazy or sloppy. And before you take offense at me calling you lazy - let he, who has never been sloppy or lazy in the face of a looming deadline, cast the first stone. Do I see any stones? No? Then let’s move on.

Some design tips

I’m no designer, but that has never stopped me from obnoxiously pretending to be an expert, so here we go, some tips to make your design more accessible:

mind your colors. Use simple, contrasting colors and when you color code things, mark them in different ways too (for example, with shapes). There are many tools you can use to check contrast, for example, Figma has a contrast checker plugin.  This one is, as you might imagine, pretty close to my heart.

make sure the text is legible. Low contrast or small font size can make the text difficult to read. You can use the material design color tool to test your color and size combinations.

make buttons large enough and make sure there is spacing between clickables. This will make life easier for users with motor disabilities. The material design docs recommend minimum button sizes of 48x48 pixels. It is worth remembering that it’s not the visual representation of the button that has to be this large — it’s enough if the click target extends to the immediate vicinity of the button. This way, if the user taps somewhere in the general location of the button, they will still hit it.

links in text are buttons too. They need to be large enough to tap or click them as well. It is also worth noting that while most of us are not fond of the default link styling with underlines, sometimes text decoration is the only thing that allows a user with vision impairment to distinguish the link from the rest of text *cough* redlinksongreentext *cough*.

avoid very long and dense blocks of texts. For example: people suffering from dyslexia can get very real headaches trying to get through long passages of text. It also helps if text is NOT justified, but simply left-aligned. Justified text can be very hard to follow for people with certain disabilities (such as dyslexia).

use simple, linear layouts. Don’t spread content all over the screen. Users of screen readers, as well as users on the autistic spectrum,  will thank you.

limit your use of elaborate animations. They can cause nausea or make it difficult to navigate your app to persons with certain conditions.

use native platform components wherever possible and practical. For example, use system native dialogs instead of custom ones. Users with cognitive disabilities will have an easier time navigating through your app, without having to learn new ways of doing things. Also, native components often have great accessibility support out of the box.

In other words: don’t go crazy with weird colors, complex layouts and custom components and don’t force users to decipher or tap very small targets and you should generally be fine.

Some developer tips

I am a developer, so I feel entitled to obnoxiously pretend to be an expert. Therefore, here are some tips for developing more accessible web apps:

structure content using html. Don’t rely on text size and placement. For example, headers should be placed in <hX> tags, and they should follow sequential progression. So no <h5>s after an <h2>.

use semantic html. The core of this is simple: if something is a button, it should be a <button>. If something is an input, it should be an <input>. We too often make fancy buttons with divs and spans, whereas they could be just plain buttons. Also, all web pages should have one header, one main container, and (optionally) one footer. This can be achieved simply by using a <header> tag, a <footer> tag and a <main> tag. If you insist on making various components with customized divs or spans, you can add a “role” attribute to specify what they do. This is very important for screen reader users, as they rely on this information to identify which part of your page contains what, and on the ability to use the keyboard to focus on its various components, such as buttons or links.

add meaningful alts to images. Again, this is important for screen reader users, because this way they have access to the information conveyed by the image. Alts should be descriptive, but they need not repeat the information already conveyed by their captions. Material design docs contain very good guidelines regarding image alts.

distinguish between informative and decorative images. Screen reader users don’t need any information on images which are purely decorative — these should be presented as background images or, if using an <img> tag, they should have empty alts (“”). This way screen readers will skip them. On the other hand, informative images should be described with appropriate alts, so that they serve their purpose for all users.

add labels to all buttons. If there is an “X” icon button to close a popup, screen readers will recognize it as a button (provided that it is a <button> element or has the role=“button” attribute) but that’s it: the user won’t know what the button is for, as it contains no text. You can easily add a label and render it invisible with css — the screen reader will still recognize it and read it to the user. You can also use the aria-label attribute. By the way, you can learn more about ARIA, or Accessible Rich Internet Applications on MDN.

fight the designers to the last man and woman in order NOT to remove the focus outline. Just kidding. But there are ways to disable the focus outline for mouse users and enable it again for keyboard users. It’s also pretty simple. You can learn more here.

In short: use logical and meaningful html structure and label everything that looks like it could use a label, and you’re good to go.

Curb-cut effect

The topic of accessibility is of course very vast, and I’ve only scratched the surface. But this scratched surface requires minimum effort and it will allow you to very easily make your app more accessible, and when you implement it from the get-go, you won’t even notice any increase in workload. Then, there is also the curb-cut effect. Ever notice how curb cuts make life easier not only for wheelchair users, but also for moms with children in strollers, or people hauling very heavy wheeled suitcases? The same applies to your apps: when you ensure that all text is sufficiently big and presented in small, digestible chunks, everyone — not just people with cognitive disabilities —  will have an easier time processing it. If you make your buttons big and easy to tap, they will be easy to tap for all users, not only those with motor problems. So if you make your app more accessible, everyone wins. You get your benchmark scores, and I’ll finally be able to tell which button is good and which is bad. How cool is that?