Accessible websites are awesome websites

Orde Saunders' avatarUpdated: Published: by Orde Saunders

Today is Global Accessibility Awareness Day - a great day to be talking about accessibility.

What is a11y?

Accessibility - which is often represented by the numeronym a11y - is, as the name suggests, about how easy it is to access a website.

When you're developing websites you're in pretty much ideal conditions to access them: you have a top of the line machine, you're using the fastest and most reliable network in the form of localhost, you're sat on a chair that is adjustable in multiple dimensions, you're in a climate controlled office, you've got a large screen, there's anti-glare lighting, you've got your choice of keyboard and pointing device and you are intimately familiar with how the site works. Of course the site's accessible!

Now what about your users? They're using a three year old cheap Android device, they're stood on a crowded train with the sun shining in through the window onto their screen but they're about to go into a tunnel. How easy is it to access the site now? This is why everyone can't just use Chrome on a MacBook.

A11y is often thought of as being about disabled people and that can make it hard to understand and easy to dismiss as an edge case. But, as we saw with our user on a train, there's different types of disability. They're categorised into three types:

  • Permanent. For example, someone who only has one arm.
  • Temporary. For example, someone who has broken their arm.
  • Situational. For example, someone who is holding a child with one hand.

All three of these result in the same situation - that user is only able to use one hand.

This is why making a site more accessible has the potential to benefit everyone using it.

So what can you do to improve accessibility?

Well, the good news is that even the fact you're reading this means that you're aware of it and you're thinking about it so that's a really important step.

Also don't think that because you can't build the most perfectly accessible website ever that you're a failure: accessibility is cumulative, everything you do to improve accessibility adds up.

So let's look at two simple things you can do as part of your every day development to make what you build more accessible.

Use semantic HTML.

For devs this is the single most important thing you can do. HTML is incredibly powerful because the people who write the browsers put a lot of effort into making sure things work accessibly. For a simple example take the <a/> element. Now you could use a <span/> and then a hundred K of React to add an onclick handler and you can add a few dozen CSS declarations using fela to make it look like a link and you can add some aria properties to try and convince some assistive technologies to think it's a link and you can add a tabindex to make it keyboard navigable. Or you could use the <a/> element and the browser developers have done all of that work for you and your users have already installed it on your machine.

Now you don't have to obsess about this and spend hours agonising over picking the one perfect element but do think about which elements you're using and, especially if you're building things on top of a lot of <div/> and <span/> elements then consider if there is a better, more semantic, alternative.

Make things keyboard operable

Being able to use a web site with the keyboard is an a11y foundation. The obvious thing here is people who can't use a mouse so let's apply our three disability categories for this:

  • Permanent. Someone who has hand tremors - for example due to parkinsons disease - and lacks the fine motor control required for an on-screen pointer.
  • Temporary. Someone whose mouse has broken so they can't control the on-screen pointer.
  • Situational. Someone's whose mouse is out of battery so they can't use it until it's recharged.

If your site can be used with the keyboard then these people can still access it.

However, keyboard operability has more benefits.

If you can use a site with the keyboard then the majority of assistive technologies - such as screen readers - will be able to interact well with it. You don't need to know the specifics of the assistive technology, they will have their own integrations with the browser and they will often work in some variation of sending keystrokes. Léonie Watson points out that keyboard and screen reader navigation are different but the key here is that screen reader navigation builds on keyboard navigation: if your keyboard navigation doesn't work then neither will your screen reader navigation.

Even if you do have a mouse it's often quicker to use the keyboard for tasks (vim users, looking at you here). If you've ever been entering data into a form and tabbed between fields then you're using keyboard navigation. This also extends to on-screen keyboards on mobile devices, there's often a "next" key to move onto the next input and, again, that's using the browser's keyboard navigation.

In terms of what you can do when you're developing this one is simple - use the keyboard from time to time when you're checking if what you've written is working. Again, you don't have to obsess over it but if you are checking with the keyboard as you go you'll very quickly pick up when some thing's not working and that's the easiest time to get it right as you already have the full context of how it functions in your working memory, going back later to fix it will be much more difficult.

Recap

So what have we learned?

Accessibility is for everyone, it's not an edge case.

Accessibility is cumulative not binary, the more you do for accessibility the more accessible your site is.

Use semantic HTML, browsers have a lot of accessibility built in.

Make things keyboard operable by using the keyboard from time to time when you're developing.

Finally, you don't have to ask permission to make things accessible.

Resources

These provide more information about web accessibility.

The following are useful tools that help with finding and diagnosing accessibility issues.