When I sat down with my brand new work computer, I wanted to get set up to manually test accessibility using as many browsers as I could. This meant keeping in mind a few key things and going through some extra steps. These steps are for using free screen readers with a Mac development environment.
I’m going to lay out:
- Free Screen Readers
- Browser/Screen Reader combinations
- Extra configuration needed to test your project on different platforms
While this post will focus solely on setup, later posts in this series will cover other parts of accessibility manual testing.
Please reach out if there are other topics you’d like to hear about!
- VoiceOver (made by Apple, pre-installed)
- VoiceOver (made by Apple, pre-installed)
- TalkBack (made by Google, pre-installed)
When working on a11y at a previous company, I worked closely with a team at Microsoft. They recommended that I only test Internet Explorer with NVDA and Edge with Narrator. This notion of technology pairings is important for testing since some combinations do not play well together and some combinations aren’t widely used.
Below are pairings in order of usage (omitting paid screen readers) according to a September 2019 survey of screen reader users:
- NVDA & Firefox
- NVDA & Chrome
- VoiceOver & Safari
- VoiceOver & Chrome
- NVDA & Internet Explorer
Narrator & Edge is not explicitly in the survey but I think it’s still worth testing as Edge’s adoption increases.
Safari requires an extra setting to allow keyboard navigation:
- Open up Preferences > Advanced in Safari
- check “Press Tab to highlight each item on a webpage” under the “Accessibility” section
If you have an IRL mobile device you’d like to use to test out mobile screen readers and other assistive apps you can reach localhost there too!
To access localhost from your Android device you’ll need to do (more than) a few things:
- First off, make sure your phone has developer options. You can do this by navigating to
Settings > System > About Phoneand then tapping Build number (the very bottom entry) seven times.
- Now there should be a new list of settings under
Settings > System > Advanced > Developer Options. Go here and enable USB Debugging
- Connect your device to your development machine via USB.
- From Chrome, access the remote devices panel in DevTools (under
More Tools > Remote Devices).
- You should see that there is a pending device at the top of the list of devices. Your phone should have a pop-up prompt asking you to accept remote debugging. Accept remote debugging from your phone.
- Now you need to enable Port Forwarding from Settings in the Remote devices tab in DevTools. (Settings are at the very bottom of the list of devices so you may have to scroll down to find them) Check the box to enable it and then click the Add Rule button to create a port for your phone to access what’s in your browser. Type in the port you want to use on your phone on one side (e.g.
3000) and the local address you want to access from your computer (e.g.
http://localhost:9000/for a served Gatsby site)
- Boom! If you go to
http://localhost:3000/on your phone you’ll see your site!
- Make sure both your device and your computer are on the same WiFi network.
- Make sure you specify the host as
0.0.0.0when you run your server. (e.g.
gatsby serve --host=0.0.0.0)
- On your Mac, go to
Settings > Sharing. You can find the address for your computer’s localhost in fine print under where it says “Computer Name.” It will be in the format of
computer-name.local. You can edit this address by clicking the “Edit…” button. (e.g. I changed mine to
gatsby.localso it would be easier to type on my device)
- On your iOS device, navigate to the address determined in the previous step with your port specified. (e.g.
NOTE: My device tried to fill in the URL by adding
www. at the beginning. If you’re having trouble reaching your localhost, make sure there is no
www. in your address bar.
I downloaded a Windows 10 virtual machine from the Windows Dev Center
You can access your host computer’s localhost from
Parallels is a paid product, but since it requires extra configuration to access localhost I figured I’d cover that here too.
When serving your site, make sure you are hosting it on
0.0.0.0. For example, if I am running a Gatsby site I’d do
gatsby serve --host=0.0.0.0
Then, from your Parallels machine you can access localhost from
There will be more posts in this series to equip you to manually test the accessibility of websites. For now, topics and timing are still up for discussion.
I hope to cover topics like:
- Navigating the web using the keyboard
- Screen reader tips and shortcuts
- Testing techniques and methods
- Other assistive technologies
What would you like to see? Do you have tips you’d like to share?