Front-end development for screen readers

Writing screen reader accessible code is not as difficult as it seems. With a few basic techniques, you can get started right away and significantly improve the accessibility of your application.

Practice listening

The first step you can take is to learn how to operate a screenreader. You are already used to visually viewing your code when you are developing. To get your application screenreader accessible, you also need to listen to your application. This way you can hear what you are doing, test your code and improve it.

A good screenreader is installed by default on both macOS and Windows. There are also tutorials available that will teach you the necessary skills. You don't have to become an expert, as long as you know the basics you have enough to test your own code.

macOS VoiceOver

• Open System Preferences > Accessibility
• Click on VoiceOver
• Click on Open VoiceOver Training

Windows Narrator

• Open Settings > Ease of Access
• Click on Narrator
• Click View the complete guide to Narrator online

Good semantics

When you work with a screen reader you notice what it needs from your app, good html semantics. Take the example of a button:

<button>Play video</button>

When you drop on this element via your tab or screen reader key, the screen reader says, "Play video, button" or "Play video, button. But what if instead of a button you had used a div?

<div class=“primary-button”>Play video</div>

De screenreader weet niet dat dit element een button zou moeten zijn. Daarbij navigeert de tabtoets alleen tussen elementen die standaard klikbaar zijn, zoals buttons en links. Dus deze div is ook nog eens lastiger te bereiken.

HTML has a lot of elements available and when you use the right ones screen readers can automatically handle them well. When you are about to use a div look first to see if you can't use an existing element. That way you will have a much more accessible app with little effort.

WAI-ARIA

In some situations the standard HTML elements are not enough. For example, when you have a special UI that cannot be created with standard elements. Or the button from the previous example has such special functionality or styling that you can't use a button element. In those situations, you can use WAI-ARIA attributes.

To find out which WAI-ARIA attributes are best to use, check out W3C's website. They write the WAI-ARIA specifications and have a lot of information and examples available on their Web site. They have a list of design patterns you can use: https://www.w3.org/TR/wai-aria-practices-1.1/examples/.

To improve our div, you can start by telling the screen reader to interpret it as a button with a role="button". You can also make sure the tab key can reach the div by adding a tab index of 0. With these simple adjustments, your div has become much more accessible and your screenreader will read it correctly.

<div class=“primary-button” role=“button” tabindex=“0”>Play video</div>

Conclusion

When you apply good semantics, supplement with WAI-ARIA where necessary, and test with screen readers, you can build applications that both look and sound good.