Browser’s accessibility tree and screen-readers speech log aren’t always sincere

(Read 231 times)

Accessibility tree in browser and screen-reader’s speech logs are extremely valuable tools when we want to check how HTML, CSS and ARIA translate to assistive technologies like screen-readers, no doubt about that. But please make sure to go through to the end – do listen to your screen-readers and in different combinations with browsers. As sometimes that’s the only way to find out about real problems.

Personally I really enjoy digging into accessibility tree directly inside my browsers to check what’s exposed to assistive technologies. And I also like to make screenshots with screen-reader output visible to document problems. The idea to automate screen-reader testing is not new and I’ve seen that some folks are making amazing progress. This is also an interesting thing that could potentially make automatic testing more efficient.

But after my recent experiences that are reflected in the title – we can’t trust browser’s accessibility tree and screen-readers speech log in absolutely all cases. And that should be taken into consideration when we try to offload manual accessibility testing. Once again adding to complexity of the field. If you can’t trust the debugging tools, what can you trust.

Personal experience – don’t trust, verify

I did an audit and stumbled upon a HTML button element that was visually an arrow to the left (and another button with same code that pointed to the right). Known pattern. At least for carousels and similar widgets.

Inside the button there was a UTF-8 arrow and beside it a span element with aria-label and words “Previous” (and “Next on the other button). At first sight code looked a bit suspicious to me as I would move the aria-label on the button if I was coding it like that.

<button type="button">
  <span aria-label="Next">›</span>

So I checked the accessibility tree and it actually looked fine (in Chrome and Firefox). That made me wonder – what does it sound in screen-reader? So I tested it without my headphones and found out that NVDA speech viewer seemed to work. Well, at least the UTF-8 arrow was being announced.

Waaait for a second, what? Shouldn’t the “Next” be announced like it was suppose to be according to the accessibility tree?

Yes, but no – it wasn’t. And then I hot my headphones on and listened to NVDA.

“Button”. That was it. The UTF-8 character was visually correct in the speech viewer so if I was to interpret the visuals only I would say that it kind of works. I was expecting to see “Next” as it was the name of the button according to accessibility tree, but no, it didn’t work.

So lesson learned – don’t just trust accessibility tree in your browser and don’t trust your screen-readers speech log.

After some online searching it was clear to me that it’s a common problem. This is the complexity of standard implementations and interpretations being joined with operating systems, user agents and screen-readers. As mentioned in post about program bugs that make accessibility even harder, we need to understand the complexity and find solutions based on compromises. Until things work in similar way (I hope they will soon).

Some references to similar findings;

Author: Bogdan Cerovac

I am IAAP certified Web Accessibility Specialist (from 2020) and was Google certified Mobile Web Specialist.

Work as Agency co-owner web developer and accessibility lead.

Sole entrepreneur behind IDEA-lab Cerovac (Inclusion, Diversity, Equity and Accessibility lab) after work.

Living and working in Norway (🇳🇴), originally from Slovenia (🇸🇮), loves exploring the globe (🌐).

Nurturing the web from 1999, this blog from 2019.

More about me and how to contact me: