We just ran our first user test of an accessible UI prototype with blind and partially-sighted testers. In spite of my efforts to follow the various recommendations and WCAG specifications, there were major issues.

By far the greatest of these was the confusion which arose about the screen reader reporting changes to aria-live regions, and the contiguity of those spoken reports with the reading of the UI accessible names in response to key navigation.

I should point out that our product is a first-aid training simulator. (Spoiler: Act quickly, or the patient dies).

It is a training product for a very wide audience, but far more like a game than a web 'page', although we are using the browser as a runtime.

An aria-live region might report "A paramedic has entered the room" or "The patient has opened his eyes". This happens as an indirect (and delayed) response to the user's actions.

Our testers sought a relationship between these kinds of reports, and their keyboard input. I am sure the real life situation is confusing and hurried, but at least you can tell the difference between your hands and someone else.

The chief problem (as I see it) is that both of these semantically distinct sets of content were read with exactly the same synthesised voice, and with no gaps. A cacophony resulted. Button labels were read out in a contiguous stream with reports about what was going on in the simulated world.

Such confusion does not arise with sighted users of our product because the fictional/diegetic/simulated world simply 'looks different' to the GUI used to interact with it.

I'm confident that we can get the UI to behave in an understandable way, but I am pretty stumped about how we might use aria-live regions for content which updates more than once per second without the whole experience descending into cacophony.

I was using "polite" aria-live regions, a setting which (per spec) promises to allow some kind of figure-ground relationship between different kinds of content, rather than a babble of competing word salads.

Most of the discussions about aria-live seem to assume 'page-like' or 'document-like' content. I've followed their recommendations and the result was so disappointing that I am now searching for any alternatives. There is a bit of scene growing around 'accessible gaming', but it appears to be mostly gamers, rather than developers. Discussions about techniques and implementations are almost as rare as rocking-horse dung.

I know there is a (contentious) effort to get screen readers to support CSS3 Speech, so that different semantics may be 'styled' with different voices.

This would be a very fine (and standard!) solution to our problem, but it appears that the screen reader 'community' (developers, engineers and users) regards this as either a low-priority feature, or actively argues against it (for reasons that mostly don't apply in our case). Certainly there are no implementations out there which we can reasonably rely on.

So my question is this: How do we design the UX of a relatively fast-moving 'game-like' app so that aria-live regions from the in-fiction (diegetic) universe 'sound different' to the UI?

I have a few ideas.

  • Handle the in-fiction/diegetic stuff with our own accessible audio (e.g. pre-recorded mp3 files) rather than relying on the mercy of how screenreader's treat aria-live. (More audio is more?).

  • Prefix the in-fiction/diegetic stuff with some kind of distinct 'beep' or other brief sound effect.

  • Try and choreograph the changes to aria-live regions so they are far less likely to interfere with UI label readings. ("polite" on steroids).

  • Offer a special 'training level' so that screenreader users can discover the UI without the simultaneous urgency of saving the life of an imaginary patient.

Can anyone report on whether any of these are obvious canards, and perhaps suggest some other areas of exploration?

1 Answer 1


Were the users in your study that used screen readers native screen reader users? Were they technology savvy? Sometimes live regions can be confusing unless you understand what they're for. I was curious if that knowledge might be skewing your results.

I was a little confused on your statement that said:

"Button labels were read out in a contiguous stream with reports about what was going on in the simulated world."

That made it sound like the entire UI was being read as a continuous stream rather than the user navigating around the page and only having the element that is in focus be read. If the user was tabbing through the interface and also a live region was updated, you'd hear both elements read, depending on whether you have a polite or assertive live region.

So are you trying to control the voice or tone that is read for normal UI elements vs text that's updated in a live region?

There are options in the screen reader itself that the user can set to be notified about font changes on the page, such as encountering bold text or font-family change. Many screen readers also change their inflection when capitalized words, or all caps, are used, or when parenthetical phrases are encountered, but again this is a user setting in the screen reader.

So you could potentially play some tricks by having capitalized words or phrases in parens to take advantage of screen reader settings.

You could even set the lang property on a phrase to cause the screen reader to change its accent, but yet again, that's up to the screen reader to honor it and the user would have to have that language pack installed. For example, if the page is in English, you could have <span lang="en-gb'> if you wanted a British accent, or <span lang="en-au'> for an Aussie, or <span lang="en-ca'> for Canadian (beauty!).

  • Thanks for the clarifying questions. Yes, they were familiar with screenreaders, although perhaps not with this kind of content. They were tabbing around the UI, 'discovering' it, and the live regions were changing simultaneously, causing the cacophony. > "So are you trying to control the voice or tone that is read for normal UI elements vs text that's updated in a live region?" Pretty much. Not so much to 'control' the voices, but to distinguish them. May 25, 2018 at 8:31
  • Your suggestions about using font/style changes or parentheses is not something I'd considered. I'm going to explore that right away. The lang idea is a very neat hack, but probably not viable in this case, since we expect to roll our product out to various different non-english-speaking regions. May 25, 2018 at 8:33
  • 1
    Just trying to think outside the box. I wouldn't really rely on either hack unless you had specific instructions for various screen reader users (jaws, nvda, voiceover) to tell them how to set their SR settings so they could take advantage of the hack. Without any hacks, as the SR user tabs through the interface to various elements, the role of that element (button, link, input, checkbox, etc) will be announced in addition to the accessible name. With your live regions, if they're just text, no role will be announced. (continued...) May 25, 2018 at 14:04
  • 1
    So that's one way a SR user will know the difference (role vs no role). But it might take some training. Also, a SR user doesn't have to tab through the interface. If they're using the virtual cursor to navigate the DOM, they'll hear all the text on the page. However, if all elements have semantic markup, they'll still hear the role of the element such as table, heading, list, etc. If your live region has a landmark role, the SR user will initially hear the landmark announced, but the role will not be repeated as the region updates. (continued...) May 25, 2018 at 14:04
  • 1
    So I think with some training, the user might be able to distinguish between things that are navigated to vs things that are updating. It won't be as obvious as it is for the sighted user, but it's still possible. Trying to distinguish the SR voice between the different elements is a novel idea but is not the way screen readers are intended to be used. May 25, 2018 at 14:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.