My Advice to a Developer New to Accessibility

Reading time: about 7 minutes

Published

disability a11y webdev

Learning about accessibility for the first time can feel overwhelming. You start reading, and at some point, it hits you: There is so much to learn! And if you're like me and feel that it's your responsibility to make the things you create accessible, that might even make you feel anxious.

And yes, there is a lot to learn regarding accessibility. But you don't need to know everything at once. As Meryl Evans reminds us in her tweet (and a blog post the tweet links to), it's about progress over perfection:

So, here are some things I wish I had known when I first started learning accessibility. Heck, I wish I had known these things when I started learning web development! I'll share semantic HTML, keyboard navigation, and listening to people with disabilities.

Learn Semantic HTML and Use It

So, first thing: Learn semantic HTML. But what does it mean? Semantic HTML, or semantic markup, describes its meaning to the browser and developer in a human- and machine-readable way. So, with semantic elements, a human will know what the HTML element is about, and the browser knows what it should render and how it should behave when a user interacts with it.

Here's an example: 

<button onClick={...}>I'm an honest button</button>

That button uses a semantic button-element. When it does so, the browser knows what it should do when the user either clicks or activates it with a keyboard or other input device. Here's an example of a non-semantic "button":

<div className="button" onClick={...}>
    I look like a button
</div>

So, this "button" made out of div looks like a button and even has the onClick-handler. So, wouldn't a human recognize it as a button? Well, yes and no. It depends on the human.

You see, this "button" works only for mouse users. As div is not an interactive element by nature, it doesn't handle interaction the same way as, for example, a button-element. When using a semantic button-element, that onClick-event propagates such that it handles keyboard interaction as well. However, divs don't do such a thing.

Another reason a non-mouse user will recognize that it's not a button is that you can't focus on it. That means the button is not in the focus/tab order. And that, in turn, means that a non-mouse user can't interact with it.

There are lots of semantic elements in the HTML. For some reason, we tend to use a div for many things. Did you know, for example, that you can annotate addresses with an address-element? Or wrap dates or times with the time-element? Or display progress with a progress-element? MDN lists HTML elements, so be sure to check that list.

If you want to read about other benefits of using semantic HTML, I wrote a blog post "Ode to Semantic HTML" a while back.

Learn About Keyboard Navigation

Another piece of advice I want to give is something we touched on in the previous section: Learn about keyboard navigation.

What And Why of Keyboard Navigation

Now you might wonder, "Why would anyone use keyboard to navigate?". Well, first of all: not everyone can use a mouse, or they just don't want to. Sometimes doing tasks on a computer is way faster with, for example, a keyboard.

There are lots of different ways of using digital devices. Some people use a tool called a screen reader, which reads the screen's contents out loud. Some use a keyboard for navigation because they can't use a mouse. And some people utilize assistive tools like mouth sticks, custom keyboards, switch devices, and other tools to use digital devices. And let's not forget voice interfaces or eye-tracking technologies, which some people use.

So the point is that there are multiple other ways to interact with a digital device than just a mouse. And we, as developers, need to create interfaces that work for all of our users and not exclude anyone.

Now you might feel overwhelmed. "How can I create websites for all those needs?" Well, I have good news: You don't need to think about each different input method. Many of the input methods mentioned above emulate what a plain ol' keyboard does.

My suggestion is: first, learn how keyboard navigation should work on a website. After you've learned that, it's time to learn about the specifics of other input methods.

Let's talk a bit more about keyboard interaction. There are two things I urge you to learn and exercise: Keyboard navigation patterns and how to test them (and regularly do so).

Keyboard Navigation Patterns

So, how does keyboard navigation work? When users want to go forward, they press the Tab-key, and this takes (or should take, depending on how well the website has been coded) them to the next interactive element. That means a link, button, input field, or similar - and not, for example, a heading.

When keyboard users want to read something or to navigate forward on a site without interactive elements, they scroll with arrow keys. I want to emphasize that because I see a lot of websites where a developer has added tabIndex-attribute to non-interactive elements so keyboard users could navigate forward.

It's a great thing that a developer thinks about keyboard users. This pattern, however, increases the amount of the tab stops to reach the actual interactive elements. For some, it's frustrating, but for some, it can even be painful if, for example, each keypress causes pain.

Okay, back to patterns. When a keyboard user wants to navigate to the previous interactive element, they use Shift + Tab.

There are different patterns for activating interactive elements. I'll list a few of them:

As you can see, buttons and links are activated with different keys. Specifically, the spacebar key doesn't activate a link. This distinction between the elements is good to remember - when users see something like a button, they think it works as a button. If the underlying component is a link, it doesn't activate with Space but rather scrolls down on the page. That's super frustrating.

You can find the expected keyboard navigation patterns for more complex user interface element patterns from WAI-ARIA Authoring practices.

Testing with Keyboard

When you build user interfaces, be sure to test with a keyboard. The basic method is to navigate through the whole site using the keyboard. When you encounter an interactive element, try to trigger it. Check that it works as expected - meaning that you can do everything with a keyboard that you can with a mouse.

Oh, and one note if you're using Mac and Safari. You need to enable keyboard navigation for them - I don't know why, but it doesn't work out of the box. Here are instructions for enabling keyboard navigation for Mac and Safari.

Listen to People with Disabilities

The final advice I will give in this blog post is to listen to disabled people. This advice consists of two things: Listening and learning about their (our) life in general and listening to the feedback we/they give.

I'll share some resources I've found helpful and informative. There's plenty more out there on the internet, and if you think something should be included, I definitely want to know about them!

One of the good places to go for these stories is Twitter. There are a couple of hashtags I recommend following: - #ActuallyAutistic - #EverydayAbleism - #DisabilityPrideMonth

I'd love to add some more here, so if you know some other good hashtags, let me know.

Also, a good resource for experiences and expectations of disabled people is Nicolas Steenhouts' A11y Rules Soundbite-podcast series. These short discussions with disabled people give a lot of good points of view for designing and building the web.

I also want to mention a brilliant book from Emily Ladau: Demystifying Disability. I actually wrote some thoughts from it once I had read it, so check that blog post too: "Thoughts From Reading Demystifying Disability by Emily Ladau"

Another great resource is Disability Visibility-project. It's defined on the About-page with the following words:

The Disability Visibility Project is an online community dedicated to creating, sharing, and amplifying disability media and culture.

Do you have some other resources? Or other advice an accessibility-novice developer should know about?

Links in the Blog Post