Practical Example: ARIA & Headings

Status message using aria-live

In this example, we randomly update the status of the text below (the cost of a coffee in Soho) to a number between 1 and 1,000 every 30 seconds.

With the aria-live role on the parent element, a screen reader will notify the user each time it changes, even if they're reading other content.

Of course you wouldn't use aria-live in this way as it is far too intrusive, but it acts as a good example of how you can inform screen reader users of a change in status or the result of an action, even whilst they're browsing.

Accessible slider

As we covered in the book, here is an example of an HTML input providing a range between two values that a user can choose a number between using the slider. We use aria-valuenow to return the value they've selected (this will update as they interact with the slider).

The text below this slider gives a visual representation of the current value, which you can compare to what the screen reader outputs to confirm that they match.

Volume is now:

50

Section heading

This is text following a heading. That title gives this text proper context.

Checkbox ARIA role

This example shows two checkboxes: the first is a custom checkbox created using a <span> tag (although the tag isn't important here), and the second is a native checkbox. Using the ARIA role of checkbox, along with a small amount of CSS and JavaScript code, allows us to create something that functions in the same way as a native checkbox.

The reason this example is here is that many people decide to create custom checkboxes, but often forget that they need to add some attributes in order to ensure that screen readers can recognise their purpose and interact with them. Those attributes are role="checkbox" so a screen reader recognises it as such, aria-checked (which we change on click or key press to mimic 'toggling'), tabindex="0" to ensure keyboards can interact with it, and aria-labelledby so that the checkbox can be toggled by clicking its label like a native checkbox can.

Please note that this is purely an example of how to make a checkbox with custom markup accessible - I in no way advocate this. Wherever possible you should use the native checkbox input. They can be styled in the same way as above, I have merely kept it unaltered to show you default style. The other benefits of using the native inputs are that it leaves less to chance on whether your page will be accessible, doesn't require you to add custom CSS and JavaScript to make it work in the first place, and makes it easier to understand the code.

aria-hidden

This example simply shows a piece of content that, with the aria-hidden="true" attribute added, is ignored by screen readers.

In most cases, if content is being hidden from users, that content should be hidden from all users. For this reason, it's important that you only hide content that is purely for decorative or visual purposes, and that you're not inadvertently removing useful information for users using assistive technologies.

A good example of this is below, where we hide the icon next to the text with aria-hidden="true", as it's purely decorative and no meaning is lost to screen readers without it:

Offscreen Headers

There are some occasions where information is apparent visually, but may not be apparent to screen reader users. Hypothetical examples could be content trapped inside visuals (which should be avoided at all costs), or actions represented by images, icons, or even animations that make it obvious what is required of the user provided they can see them. In these cases, it is important to provide that context to screen readers but in a way that doesn't impact a page's design.

Below I have positioned a header offscreen just above the text content. You won't be able to see it, but you can discover it by right-clicking and selecting Inspect Element, or by firing up a screen reader and listening to the section. Go ahead and try it!

Heading structure

In the chapter we discussed the importance of a clear heading structure, and ensuring that the hierarchy is laid out correctly in order to make it easier for screen readers to navigate the page via headers alone if they wished to.

All headers full under the main page heading of "Joe's website emporium", and there is a consistent use of level 2 headings throughout the page. In certain instances where we address more than one topic in a section, or we are displaying an example, a heading level 3 is used. This shows that it is important but within the context of the level 2 heading section in which it sits.

aria-labelledby

You can sometimes use your heading structure to greater benefit screen readers by associating a title within a section with the section itself. You can achieve this using aria-labelledby, and the result is that when it reaches the section, a screen reader will announce the section followed by the contents of the title - providing greater context: