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>
</button>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;
- David MacDonalds on what happens with aria-label on static HTML elements (opens in new window),
- Adrian Roselli’s Speech Viewer Logs of Lies (opens in new window).
