4 ms·

I'm new to getting my designs working well with assistive tools. What do you use for testing and what are the prominent tools that should be targeted?

eyelidlessness 5y ago
Admittedly I have a better track record saying than doing. So I’ll double down on that and repeat what all of the a11y advocates I follow say: - you want to at least test with JAWS, NVDA and VoiceOver - automated tooling isn’t great and you probably need to manually verify things - axe does help spot problems just don’t rely on it completely
- decremental 5y ago
  Thanks for the tips. I'll check those out.
- runarberg 5y ago
  As a linux user I do most of my assistive technology testing with Orcas. Do you have any insight into that? Do many assistive technology users use Orcas? Is Orcas behavior significantly different from the more popular once?
  - eyelidlessness 5y ago
    No, I wish I had insight here but I don't. I'm sorry I can't be any more help.
  - extra88 5y ago
    In the last WebAIM Screen Reader survey [0], if anyone answered they primarily use Orca, they got lumped into "Other"; out of over 1,000 respondents, 7 primarily use Chromevox so the Orca number must be lower than that. If some use Orca sometimes, they must have been less than 1% of the respondents and got lumped into Other for that question as well. That doesn't mean that Orca doesn't do a good job or that it works very differently than other screen readers. The A11ySupport site [1] does have some data on Orca's support for specific code. For instance, it fully supports the aria-expanded attribute but has no support for description list elements. If you have an iOS or Android device, using their built-in screen readers might be more instructive. [0] https://webaim.org/projects/screenreadersurvey8/ https://webaim.org/projects/screenreadersurvey8/ [1] https://a11ysupport.io/ https://a11ysupport.io/
- extra88 5y ago
  > you want to at least test with JAWS, NVDA and VoiceOver It depends on what the stakes are but if you’re consistently confirming things work with just one screen reader, that makes most of the difference. NVDA with Firefox or Chrome is probably the best to test with; it’s free, probably the most common choice now, and it has a lot in common with JAWS. But if testing with Windows is inconvenient, testing VoiceOver with Safari for Mac is still very useful, in part because it’s very similar to VoiceOver on iOS.
pickpuck 5y ago
I would recommend getting comfortable using the built-in screen readers on your own devices (VoiceOver, Narrator, etc). Lots of people use those same tools. You'll probably just want to mute the screen reader and use the developer option to display what's being announced on screen as text. Get comfortable navigating web pages using the various functionalities available (the ability to scan only headlines, for example). I also open the accessibility tab in the web inspector in Chrome or Firefox to see the accessibility tree, which is like a simplified version of the DOM tree that gets exposed to assistive technologies.
mpol 5y ago
The most simple way to test accessibility is to only use a keyboard. Use tab ir shift-tab to switch between elements. Tab only browses through links and form elements. Use enter to follow links or buttons. Simple things like 'outline' on focused or activated elements are easy things to pick up. Elements that are changed by JavaScript should not only change on a mouseclick or touch, but also on pressing Enter or ESC.

eyelidlessness 5y ago

Admittedly I have a better track record saying than doing. So I’ll double down on that and repeat what all of the a11y advocates I follow say: - you want to at least test with JAWS, NVDA and VoiceOver - automated tooling isn’t great and you probably need to manually verify things - axe does help spot problems just don’t rely on it completely

decremental 5y ago
Thanks for the tips. I'll check those out.
runarberg 5y ago
As a linux user I do most of my assistive technology testing with Orcas. Do you have any insight into that? Do many assistive technology users use Orcas? Is Orcas behavior significantly different from the more popular once?
- eyelidlessness 5y ago
  No, I wish I had insight here but I don't. I'm sorry I can't be any more help.
- extra88 5y ago
  In the last WebAIM Screen Reader survey [0], if anyone answered they primarily use Orca, they got lumped into "Other"; out of over 1,000 respondents, 7 primarily use Chromevox so the Orca number must be lower than that. If some use Orca sometimes, they must have been less than 1% of the respondents and got lumped into Other for that question as well. That doesn't mean that Orca doesn't do a good job or that it works very differently than other screen readers. The A11ySupport site [1] does have some data on Orca's support for specific code. For instance, it fully supports the aria-expanded attribute but has no support for description list elements. If you have an iOS or Android device, using their built-in screen readers might be more instructive. [0] https://webaim.org/projects/screenreadersurvey8/ https://webaim.org/projects/screenreadersurvey8/ [1] https://a11ysupport.io/ https://a11ysupport.io/
extra88 5y ago
> you want to at least test with JAWS, NVDA and VoiceOver It depends on what the stakes are but if you’re consistently confirming things work with just one screen reader, that makes most of the difference. NVDA with Firefox or Chrome is probably the best to test with; it’s free, probably the most common choice now, and it has a lot in common with JAWS. But if testing with Windows is inconvenient, testing VoiceOver with Safari for Mac is still very useful, in part because it’s very similar to VoiceOver on iOS.

pickpuck 5y ago

I would recommend getting comfortable using the built-in screen readers on your own devices (VoiceOver, Narrator, etc). Lots of people use those same tools. You'll probably just want to mute the screen reader and use the developer option to display what's being announced on screen as text. Get comfortable navigating web pages using the various functionalities available (the ability to scan only headlines, for example). I also open the accessibility tab in the web inspector in Chrome or Firefox to see the accessibility tree, which is like a simplified version of the DOM tree that gets exposed to assistive technologies.

mpol 5y ago

The most simple way to test accessibility is to only use a keyboard. Use tab ir shift-tab to switch between elements. Tab only browses through links and form elements. Use enter to follow links or buttons. Simple things like 'outline' on focused or activated elements are easy things to pick up. Elements that are changed by JavaScript should not only change on a mouseclick or touch, but also on pressing Enter or ESC.