The fact that screen-readers work differently with different browsers is not very known but I guess is logical. As with all software – also screen-readers have their bugs and different implementations. Then add the accessibility APIs and browsers to the show and you have yourself a problem. Or not. Depends how to think about it.
Ideally all screen-readers would work alike with all browsers. But we know that there are no ideals. Operating system and their accessibility APIs differ, so do the browsers and so do screen-readers. Sure, there are standards that all of them should respect, but then again, in reality coverage of all standards takes time and effort and sometimes even the standards allow some interpretation that can make things work differently.
I was recently testing some live regions with different browsers and screen-readers just to find out what should I use in production. And it was in theory simple – a single event that updates three different live regions. Made it quickly and started testing with screen-readers.
To my surprise – the tests were not consistent. Sometimes first change was read and sometimes last. And it was really nothing I could see in my code that was the reason. Testing with different screen-reader – different results. Quite annoying when I think about it – what will happen if I get to test other versions of screen-readers and then add also other versions of browsers and maybe also operating system to the tests?
Well, I found the simple solution – emitting single message for all states. That helped a lot. The order was always correct and I didn’t need to debug and investigate and loose time with that.
If you want you can test my proof of concept where a single event (click) triggers three live region updates (both polite and assertive);
You can test multiple updates to multiple live regions here (opens in new window).
Conclusion? Try to make it standard and simple and then test with multiple screen-readers and browsers.
