I can not emphasize this enough – (front-end) developers should use screen-readers to test their code. At least the more interactive code. Testing common patterns with screen-readers may not be the most cost efficient way of doing it, but testing custom and interactive widgets made with JavaScript and enriched with ARIA should always be tested with screen-readers and the earlier the better. Developer baking the interactivity into the code is therefore in my opinion the first one to test with screen-reader. Then we should include the designer as well. Developer alone should not have the full responsibility and interaction designer should be proficient enough to define screen-reader interactivity and together they should be able to establish if user experience is good enough. But where to start?
Understanding the basics of screen-readers first – start with mobile
I think we should start with simple tasks first. And really get the basics. Screen-readers on desktops can be quite advanced and therefore we can start with their simple versions on mobile devices. All smart phones have screen-readers built in or at least available for free from their app stores. iPhones and iPads have VoiceOver and Android has TalkBack. Ideally we should be familiar with both – we must test on both platforms anyway – but they are quite similar and I guess it’s OK to just start with device that is at our hand.
Basics are what you suspected – how to turn the screen-reader on and off is crucial. Especially when we are testing and get stucked. Or maybe if we need to do some advanced action not related to testing at all – we should be able to turn the screen-reader off quickly and not get stucked in its mode. Then there are the different mode – for example what kind of elements will be used for advancement with basic gestures. Call it context menus or rotors – the screen-reader modes that we can use for accessing different parts of web pages or applications, for example headings, links, forms and so on. This is also the basics – to know how to operate the menu of the screen-reader.
When we get around this we can then start to experiment with keyboard use and if we need or like we can also use Braille keyboard.
When we manage to get around and get familiar with gestures we can then visit or favorite and known web pages and applications and try them with screen-reader. It is also good to visit webpages that are known to be accessible, to get a feeling about their internals. Especially more interactive parts like navigation and forms should be our focus.
Screen-readers on mobile devices are quite simple when we get over the basics and can also be very useful when we test our own work. It was quite useful for me to test my input type range that I made with help of ARIA only to find out that it seemed perfect in the accessibility tree but was not very usable when I tested it with screen-reader on mobile and was not able to move it at all.
After the basics – get to screen-readers on desktop
As a developers we are probably already very used of keyboard shortcuts. With screen-readers on desktops (especially on Windows and Linux) we get hundreds of possibilities and all of them can have their own keyboard shortcuts. So we need to go on a journey to understand them first before we can use the screen-reader effectively. There are hundreds of different versions of screen-readers out there and some of them share keyboard shortcuts so I suggest that you check on the vendors pages for so called cheat-sheets that provide short descriptions for most common keyboard shortcuts of your version of screen-reader.
Do screen-reader users use all shortcuts? No, I don’t think so. As with all users – we are all different and can use our software differently and screen-readers are not any exception. We do not need to know all possible shortcuts and we can help ourselves with these cheat-sheets and other resources but it does pay off to be familiar with them in the start.
Turn off the screen and disconnect the mouse
Now we are maybe ready for a real screen-reader testing experience. No cheating with checking the screen and moving the mouse. It is not like we have to do it every time. But it can reveal some basic problems and it does help us to be better with screen-readers and understanding. Again – after we get familiar with basics – I would not suggest to test that all of headings still work as they ought to. We need to concentrate on the advanced parts after we are confident that basics still work – no need to test heading levels if we know that they are set correctly in the code. Or to test skip to content links each and every time if we know that it is working and our automatic tools did not report otherwise in a regression test.
Cooperate with real users
We must not be arrogant here – even if we master all aspects of screen-readers and maybe even multiple different screen-readers at once – we will never be the real user. It may come as surprise to us when working with different users that need to use screen-readers on a daily basis. Some of them are maybe blind and some not, and some of them are experts and some only use the basics. So it may help us to help them and make some simplifications or maybe change the user experience because real users used screen-reader in a way that we would never even imagine.
The basics of screen-reader testing helps us to make better products as we design or develop them but we must be wise enough to not get our own user preferences in our way, so testing with real users still matters a lot.
