Make your code screen reader friendly

In a previous blog post we talked about the importance of accessibility in your application. In this post we will zoom in on screen readers. A screen reader is a program that helps people with a visual impairment to interact with your website or application by reading aloud what is displayed on the screen.

To enable this, the front-end code must provide structure and recognizable elements. Actually, the web is accessible by default and screen readers can manage perfectly, it is just our job to not screw it up. So here are some tips and tricks to make sure you don’t.

Use HTML attributes to improve accessibility 

Adding the correct HTML attributes takes very little effort and can tremendously improve accessibility. There are dozens of ARIA (Accessible Rich Internet Applications) attributes to help you out, but the one we use the most is aria-label. This attribute is used to add a description to an element that contains only visual content, like icon buttons. The aria-hidden attribute can be used to hide elements for screen readers if they only contain visual information (like the icon itself).

Instead of: 

Do: 

If the image contains some information that is needed and should not be hidden, provide an alt attribute to describe it. Beware that title adds extra information for a tooltip, but is not read by a screen reader.

Instead of:

Do: 

Add keyboard events

Like stated before, the web is accessible by default and when you use standard elements like button and a, accessibility comes for free. However, from time to time we need to add a click handler on a non-interactive element like a div.

In order to make these elements focusable and interactive, use the tabindex attribute and provide keyboard handlers like keyup or keydown as an alternative to mouse events. In addition, add the role attribute to indicate to screen readers that the element behaves like a button or a link. 

Instead of:

Do: 

A tip to make sure that these simple improvements are implemented is the use of Codelyzer. Codelyzer offers a number of ts linting rules to detect accessibility issues, like the ones described above. It is built into Angular CLI and easily installed for any other framework. Just add the rules to tslint.json and you’re good to go! 

Do not remove outline

Outlines can be ugly and can ruin your beautiful design, but they are essential for screen readers and keyboard users. If you really want to remove them, at least keep them enabled for keyboard users. To accomplish this, you can use the polyfil focus-visible.

Instead of:

Do:

Headers are for structure, not for styling

Headers provide essential clues to screen readers about the layout of your page. They use the hierarchy of headers to infer structure. A page should contain one, and only one, h1 header. If the default h1 is too big for your design, fix it using styling, not by using another type of header. So keep structure and styling separate from each other.

Instead of:

Do:

Mind the document language

Not everyone is fluent in the language(s) your site offers. Luckily, some browsers have a function to automatically translate these pages. To fully take advantage of this, set the correct document language in your HTML. In addition, screen readers will use this attribute to provide the correct pronunciation. Added bonus: it’s also good for search engine optimization.

Instead of:

Do:

These are some simple things you can do to improve the accessibility for screen readers with other advantages such as support for keyboard users and search engine optimization. It’s more than a win-win.