1–10 of 118 posts
If not, what are some best practices people use to maintain accessibility? Does anyone write tests for this functionality? Would love to learn more, top resources, checklists people use, etc.
Also, being able to use the website with a screen reader (with your eyes closed) is a good metric.
Doing this manually with Chrome's Audit tool for each route is time consuming.
Having a partially sighted consultant come in and point out the deficiencies and how they use devices was extremely helpful. A lot of sight impaired people use Apple devices as their voiceover support is excellent, Android is getting better but you will find a lot of differences between their implementations in versions which is extremely frustrating. For desktop on windows JAWS seems to be the most used which again has its own way of parsing.
I don’t know if it’s changed but my advice would be plenty of manual testing, there’s really not much else than actually using the devices with voiceover enabled to test if things actually work properly. And it’s also a case of compromise and picking what devices to support as fixing something on one reader will inevitably break another.
Hope that helps :)
But in all seriousness, I use aXe-Coconut[1], headingsMaper[2]. Then tab through the page and make sure you can get from top left to bottom right. The cursor[focus state /ouline] should be visible the whole time and you should never lose your place.
When you are done that, if you have a Mac turn on voiceover with Command+F5 and use Safari or Chrome (more aria-support). On Windows, download NVDA[3] and FireFox. Again use the keyboard to go through the page, but listen to the screen reader and make sure everything is spoken like it looks. So a button should say, "Submit Form Button" etc. Anything that doesn't say anything, ie, " button" or say something different from what you see needs work.
The general consense of the community is that automated testing only finds 30% of issues, so you've got to test manually.
[1] https://chrome.google.com/webstore/detail/axe-coconut/iobddm... [2] https://chrome.google.com/webstore/detail/headingsmap/flbjom... [3] https://www.nvaccess.org/
If you can afford in your project, use a external service that tests with people with different disabilities.
Use aXe for automated tests and test everything manually with JAWS + Firefox (most popular screen reader Desktop combination) and iOS VoiceOver (most troubling mobile issues in my experience). If you can afford in your project, use a external service that tests with people with different disabilities.
[1] https://webaim.org/projects/screenreadersurvey7/#browsercomb...