I’ve written before about how failing to use semantic HTML, especially when implementing custom controls, often comes with a cost to accessibility. In response, some people have actually said to me, well, none of our users are blind, and most of our users aren’t super users with the keyboard. Why should we spend the additional development effort to make this feature work with assistive technologies?

This is making some pretty big assumptions about who our users are and what their needs are. Over a billion people in the world live with some disability. Disabilities can be permanent, temporary, or situational, and they may not always be visible to others.

At the same time, product teams are often really uncomfortable with implementing accessibility because they don’t know what is involved. I want to demystify what it means to “implement accessibility”, and demonstrate that accessibility is not really about building niche features for a niche audience, it’s about building an inclusive and usable web.

Accessibility is universal

Accessible design patterns are essential for some people, but are valuable for everyone. Consider a ramp or an elevator. Without these amenities, wheelchair users can’t navigate public spaces, but they aren’t the only beneficiaries: people with luggage or strollers, people on crutches, people carrying large or heavy items, or really, just any person. Proof of disability isn’t required!

The truth is that people are impaired when design fails to provide equitable access to resources; accessibility is about removing those barriers that exclude people. It’s dangerous to leave this as an afterthought in software development. The internet was built for everyone, not just for a select few. It’s not just a “best practice” for building a high-quality front-end application, it’s not just good for business — it’s a basic human right.

People are disabled by society, not just by their bodies. These barriers can be overcome, if governments, nongovernmental organizations, professionals and people with disabilities and their families work together. — World Health Organization

Principles for inclusive design

The Web Content Accessibility Guidelines (WCAG) include some pretty sound principles for how to build websites for everyone, aka POUR:

• Content should be perceivable to the senses (i.e. sight, hearing, touch)
• Controls and interactive elements should be navigable and operable by the user
• Content should be understandable and limit ambiguity or confusion
• Content should be robust enough to be accessed by a wide range of technologies

Those of us who are involved in interaction design are probably thinking of these principles already, but often from a limited perspective. Consider these various contexts, and think about how we might apply the POUR principles in each one:

• Visual impairments
  • Blurred vision
  • Using a device at night or in a dark room
  • Sensitivity to flashing, strobing, or flickering lights (e.g. photosensitive epilepsy)
  • Dizziness and nausea when viewing moving images
  • Loss in peripheral vision (e.g. glaucoma)
  • Color-blindness of various forms, including total color-blindness, in which one can only see in greyscale
• Hearing impairments
  • Deafness in various degrees — mild to profound, high vs low frequency, symmetrical vs asymmetrical
  • Sitting in a very noisy area, such as a metro station platform
  • Forgetting headphones in a quiet zone, such as a public library
• Motor impairments
  • Using a device with gloves on
  • Having to use one’s non-dominant hand after breaking an arm
  • Arthritis or joint pain
  • Loss or paralysis of limbs
  • Tremors or loss of fine motor control
  • Simply preferring to use the keyboard
• Cognitive impairments
  • Difficulty focusing
  • Difficulty problem-solving
  • Feelings of anxiety, stress, or frustration
  • Memory challenges (immediate, short-term, or long-term)
  • Trouble with reading, linguistic, and verbal comprehension (e.g. dyslexia)
  • Trouble processing visual information

Of course, this is not an exhaustive list of ways in which someone might be impaired, but hopefully it elucidates just how broad disability can be. While it can be difficult to find solutions that will work for everyone — in fact, solutions may often be in conflict — focusing on functional barriers over medical conditions gives product teams an actionable path towards building a more usable and inclusive web.

Implementing accessibility often sounds harder than it actually is

Once you’ve established bad habits and practices, it can definitely be challenging and costly to come back and retrofit already-written features. The problem is two-fold: if you aren’t designing interactions for accessibility, then you won’t be implementing accessibility.

But there’s no need to be afraid of “implementing accessibility”. I think people fear it because they don’t really understand what this means in practical terms. In many cases, there truly is no extra development effort required to do things the right way. Although there are a huge number of assistive technologies out there, the good news is, many of them work through the keyboard or emulate the functionality of the keyboard. So, as long as you are using structured, semantic markup, you are hugely on your way! Let’s use a few examples to illustrate common scenarios.

The importance of semantic HTML

In the CodePen example below, I’ve styled a div element and a button element to look identical to each other. If you click on either of them, you’ll notice that they both work as expected. However, if you attempt to use the keyboard to navigate to the fake button, you’ll find you simply can’t reach the element.

Now, we could add tabIndex='0' to the div element to tell the browser it can receive focus, however, our work would not be done. We would need to add some Javascript to handle pressing the Space and Enter keys while on the button. We would also need to add some aria attributes so that a screenreader could correctly announce this element as a button instead of some random text. But why bother doing this work, when we get all these behaviors and affordances for free, simply by using a button?

Choices like these are littered all throughout the web, and these choices actively break the ability to access content. The solution is dead simple: stop doing this now.

Custom components

If you require a custom visual design for a particular component, for which there may or may not already be a semantic equivalent, you need to be prepared to implement the behaviors you have stripped away by choosing to make a custom component. That means adding Javascript and the appropriate aria attributes to make sure the content is robust enough to be accessed by various technologies, because HTML and CSS alone cannot achieve this.

Sometimes, there are compromises you can make. For example, if you needed to customize a select box, it’s possible to do this and use the semantic select element, if you’re okay with the dropdown list retaining the native appearance when it’s open.

The effort required to style the “semi-custom” select box is trivial. But to fully customize it properly, there are a LOT of behaviors that come packed into select elements that we take for granted, that we would now have to write and test ourselves. The implementation may vary slightly from other browsers’ implementations, so it would be important to validate with users that they can still interact with it effectively. (We wouldn’t need to invest in user testing native controls.)

I used roughly 150 lines of Javascript to create a custom select element, and it isn’t even fully-featured. This also doesn’t include any unit tests I would write (sadly, you can’t really do this in CodePen).

We could choose a third-party library for our custom components, but we need to use the same standards to evaluate whether their custom components actually implement these behaviors. Many do not. For the few third-party libraries that do consider accessibility, we also need to consider how easy it is for us to apply custom themes, so that we can have a consistent look-and-feel to our application. This itself can also be quite painful.

So it’s a fine balance to walk when dealing with custom controls: what is the cost of implementing it yourself vs the cost of customizing a third-party component? Keep in mind, that you will be inheriting their technical and UX debt. Or, is there a compromise alternative available, like with the “semi-custom” select example?

Additional usability features

If we have perfectly semantic markup and are adding in the right behaviors and affordances wherever we are customizing things, our application should be working pretty well for most people. There are always things we can do to make the experience even better. For example, making use of skip navigation links so that a keyboard-user doesn’t have to tab a billion times simply to get to the main content of the page, where most of the interactivity lies. Identifying how we might improve the experience of the application is an important aspect of task-based user testing, and it’s usually the case that we forget to include users of assistive technologies in these sessions. We may be missing out on valuable and important feedback!

I’ll say it again: if you aren’t designing interactions for accessibility, then you won’t be implementing accessibility. That means taking a look at our existing practices and making sure we are including different voices every step of the way, because by definition, accessibility is for everyone.

Appendix: examples of assistive technologies

You might not have thought about some of these as assistive technologies, but they sure do help!

• screen magnifiers
• screen readers
• text-to-speech software
• speech recognition software
• alternate input technologies (e.g. head pointers, on-screen keyboards, single switches, and sip/puff devices)
• alternate pointing devices (e.g. eye-tracking)
• closed captioning
• high or low contrast aid
• blue light filter
• glasses
• hearing aids
• certain typefaces