Published at
Updated at
Reading time
3min

Sara Soueidan just published a free chapter of her Practical Accessibility course; with no surprise, it's high quality.

The chapter is split into two blog posts:

I strongly suggest you read these, but disclaimer: you'll need a while to make yourself through them.

For my archive, here are some rough notes from reading the chapter.

Live region roles vs. the aria-live attribute

To define an element as a live region, you can use the aria-live attribute or go with a live region role (alert, status, log, marquee or timer). From all these roles, alert and status are fair game because they're well supported.

Regions have one advantage over the aria-live attribute.

Another advantage to using a live region role over aria-live is that live region roles accept an accessible name.

Sara explains this fact with a shopping cart.

<span id="cart"><strong>Shopping cart:</strong></span>
<span role="status" id="status" aria-labelledby="cart">
  0 items
</span>

The span comes with role="status", and because of the region role, the element can have an accessible name. The accessible name is defined by aria-labelledby. Cool!

When this live region is announced, the announcement includes the accessible name: "Shopping cart: 0 items". 100 points! 👏

What screenreaders actually announce

I always expected the following fact, but here it is black on white.

The screen reader will announce the entire contents of a live region as one long string of text, without any of the structure.

A live region announcement is just a long string. There are no semantics. There's no structure. That's why good announcements should be short — no one wants to be interrupted by a novel or confusing message.

And because semantics are stripped, there's another problem with a very common notification pattern: toast widgets that include interactive elements like a "dismiss" button are unsuitable for live regions.

Live regions should not be used for messages or notifications that contain interactive elements, particularly if the user may need to act on those notifications.

What should you do instead? Sara describes how proper focus handling often helps to avoid live regions altogether.

For example, here's her recommendation on how to make SPA navigations more accessible.

Instead of relying on a live region to announce the page change, you could send keyboard focus to the main "h1" of the page which, as we mentioned in the heading structure chapter, should describe the primary topic of the contents of the page and ideally be identical to the page’s "title".

I love it!

A Chrome extension to debug live regions

I haven't tried it, but I trust Sara's recommendation here. NerdeRegion allows you to quickly debug Aria Live Regions in your developer tools.

NerdeRegion extension visualizing different region announcements.

Sara also links to Considering dynamic search results and content as an example of an accessible live search experience. Disclaimer: I haven't read it yet, but it looks like a valuable bookmark.

Alright, here's the end of my rough notes. Go ahead and read Sara's free chapter. It's worth it, I promise!

Was this post helpful?
Yes? Cool! You might want to check out Web Weekly for more WebDev shenanigans. The last edition went out 4 days ago.
Stefan standing in the park in front of a green background

About Stefan Judis

Frontend nerd with over ten years of experience, freelance dev, "Today I Learned" blogger, conference speaker, and Open Source maintainer.

Related Topics

Related Articles