This one may be obvious for all developers that already work with accessibility in mind, but it should be introduced as a best practice for all developers. At least front-end developers that is. With screen-reader testing one can get valuable feed-back early on and therefore also prevent some obvious accessibility errors early.
Screen-reader helps with understanding the code
When I run a quick test with screen-reader I can immediately check the code that I wrote – starting with semantic HTML regions for example. Some websites or web application can get quite complex document object model (DOM) trees and inspecting them in the elements tree inside web browsers can quickly get complicated or at least needs a lot of clicking and scrolling. With screen-reader it is extremely easy to check the page semantic structure as they allow navigating by regions and landmarks. It is also very easy to discover needs for (better) naming of some regions – for example primary navigation and secondary navigation, different types of asides and so on.
Some ARIA code can also be easily understood when we use screen-reader to test it. For example expanded and controls and so on. It is quickly hearable presentation of the code that may help with better understanding. At the same time it can be useful to prevent overuse of ARIA as well. For example adding aria-pressed to all buttons etc.
Sighted users of screen-readers may unwillingly use them wrongly
There are also downsides of developers using screen-readers – especially wrong assumptions about “real” screen-reader users. I’ve observed some screen-reader users that are blind and therefore depend on their screen-reader literacy on a daily basis and I must say that some patterns were quite interesting for me. How intuitive their usage was, how fast they would get around basic errors and that some of them disagree about things that I though were de-facto principles.
One huge example was navigation with lists – I’ve listened to quite opposite advice from two users – one was saying it is very useful to hear how many links are in a navigation (when links are wrapped in a unordered list) and the other one was almost furious about developers using lists for that.
Then it was also the site exploration screen-reader user journeys – how did they explore the site that they had never visited before. One was using headings and the other landmarks and then links and headings.
Platforms, operating systems and screen-readers offer additional complexity
The platform, operating system and screen-reader also has a say in the overall user experience. VoiceOver seems way less complicated than JAWS and NVDA are. At the same time JAWS and NVDA users may become much more efficient in operations with almost unlimited possibilities for custom shortcuts and quite amazing ways of operating the browser and web technologies. And mobile screen-readers are way less complicated than desktop screen-readers. It seems that VoiceOver on mobile and desktop are almost the same – with the rotor and possibilities. And Android’s TalkBack is not so bad as some VoiceOver users will claim. At the same time there is also a giant leap between Microsoft Narrator and JAWS/NVDA.
It is maybe unrealistic for developers to use all of possible combinations – we have to be aware that some screen-readers work better with some browsers as well, so at the end there is quite an interesting matrix of combinations and variations. And it does not end there – we must be aware that screen-readers are software as any other – and therefore they also have their own problems. For example – some ARIA or even native HTML is not supported in all screen-readers. Some screen-readers even have known bugs that have to be resolved before users can really use web technologies as developers made them.
How should developers cope with additional levels of complexity added by screen-reader diversity?
I can not promise a solution that fits all but I like to present a viable possibility for my teams. The first step is to know the user base. We may fail to support all possible variations and combinations of screen-readers and browsers but we should prevent the most problematic accessibility errors. So the first rule of ARIA – do not use ARIA (if there is a native HTML element that does the work well) is still very relevant. Then I try to collect data about users. Especially the platforms and operating systems – for example Apple devices that may prevail in the mobile and tablet devices and then also browsers. Based on that we can estimate approximate screen-reader users as well.
There is no way to detect screen-readers on the web (it is possible to detect screen-reader with native mobile and PDF technology, but it is not possible to detect screen-readers with JavaScript and HTML and CSS for example). That is a good thing in my book (privacy and preventing even more discrimination or even second class treatment of some groups of users) and it should stay so. So developers should try their best to use code that works for majority of screen-readers and browser combinations and test them based on the analytics (for example at least one mobile and one desktop screen-reader).
But it also depends on the site or web application’s reach. Some critical webpages and web applications are more critical than others and they demand even more effort to really make them robust. There it may even be the right thing to keep things a bit on the old-school and really make them progressive enhanced. Currently there are a lot of websites that are used for Covid vaccination and if I am sincere they should work for wider audience than my personal blog. The developers should put down the cool new tools and make them as simple and as close to raw HTML as possible. I would not be happy if my “super-duper” single page application for vaccination would fail for a user that was maybe forced to stay on older hardware with older browser and screen-reader and therefore prevent them of getting into vaccination line. Would you?
