Request for comment: screen reader settings
Opened this issue · 15 comments
Although all of the project's tests are currently written for screen readers operating with their default settings, we are interested in one day writing tests for behavior with alternate settings. This will require extensions to the test design, to the automated test running software, and possibly even to the screen readers themselves. Before all of that, it would be helpful to identify the settings which the future ARIA-AT tests will need to control.
In this issue, I'd like to gather input on which screen reader settings are potentially of interest. We can use that information to prioritize this work among the other goals of the project, organize prospective settings according to their relevance/impact, and finally tackle the more technical tasks I mentioned above.
If you know of a setting which may be of interest, please add a comment below. ARIA-AT is currently targeting NVDA, JAWS, and VoiceOver; if you happen to know which of those supports the setting you're suggesting, that would be helpful, too.
I'll keep the following table updated with the input we receive.
| setting | application* | NVDA | JAWS | VoiceOver |
|---|---|---|---|---|
| text-to-speech voice | uniform | yes | yes | yes |
| disable automatic updates | uniform | yes | yes | yes (system-wide) |
| disable telemetry | uniform | yes | yes | yes (system-wide) |
| enunciate capital letters | conditional | yes | yes | yes |
| enunciate punctuation | conditional | yes | yes | yes |
| enunciate mode changes | conditional | yes | yes | no |
| quick Navigation on/off | conditional | no | no | yes |
| single-Key Quick Navigation on/off | conditional | no | no | yes |
| keyboard layout | uniform | yes | yes | no |
| disable say all on page load | uniform | yes | yes | yes |
| disable mouse tracking | uniform | yes | yes | yes |
| enable visual focus indicators | uniform | yes | yes | yes |
| disable popup: welcome | uniform | yes | no | no |
| disable popup: first-run | uniform | no | yes | no |
| disable popup: "fsCasts" | uniform | no | yes | no |
| disable popup: update availability | uniform | yes | yes | no |
| configure Tab key to move focus between all controls | uniform | no | no | yes (system-wide) |
| set audio output device | uniform | yes | yes | yes |
* note on "application"
Some settings directly impact screen reader behavior (e.g. the vocalization of punctuation), and those might be required by some tests but not for others. Other settings concern operational details beyond the presentation of content (e.g. automatic update functionality), but the project might nonetheless recommend their use in general. I'll try to capture that distinction with the column titled "application," where "conditional" describes the former type of setting, and "uniform" describes the latter.
@jugglinmike A couple to add to the list:
- enunciate mode changes (conditional), JAWS/NVDA. Required to be able to assert mode changes or the lack thereof; both JAWS and NVDA use sounds to convey mode changes by default without accompanying speech. Could be combined with an additional, programmatic check of the current mode after the test has run, e.g. to confirm whether there were interim mode changes that would confuse users.
- Quick Navigation on/off (conditional), macOS VoiceOver. Currently, all tests are carried out with Quick Nav disabled, but it's feasible that the state of this setting causes behaviour to differ, and therefore I think desirable to test it.
- Single-Key Quick Navigation on/off (conditional), macOS VoiceOver. This is related to the previous command. With Quick Navigation enabled, users are able to toggle "single-key navigation", which allows commands like H to jump to next heading, numbers on the number row to jump by heading level, etc. These types of commands are available by default on Windows for reading mode tests, but are not tested on the Mac.
Awesome, @jscholes! Those are all included in the table, now.
- For NVDA/JAWS, maybe choosing between desktop/laptop keyboard shortcut layouts?
- The "say all on page load" feature is often handy to turn off
- If running locally, turning off "mouse tracking" could help reduce noise
- Nice to have: turn on visual focus indicators — could be super handy for debugging a failing test by watching a screen recording
- For VoiceOver, usually Safari and System Preferences are configured as https://www.scottohara.me/blog/2014/10/03/link-tabbing-firefox-osx.html
Oh and JAWS-specific: It can pop several dialogs. There's the activation dialog of course, then there's a "first run" wizard modal, and finally "fsCasts" popups, which notify you about new podcasts. We'll need to suppress all of those.
Another one that comes to mind, and applies to all screen readers: audio output, or ensuring that a screen reader is okay without having access to one.
Pop-up dialogs are also not JAWS-specific. For example, NVDA has the startup/welcome UI, automatic updates, and data privacy.
@WestonThayer Thanks! I've added most of your suggestions to the list. I'm waiting to add just this one until I understand it better:
- For VoiceOver, usually Safari and System Preferences are configured as https://www.scottohara.me/blog/2014/10/03/link-tabbing-firefox-osx.html
Is this a general tip about where we should expect to find settings that influence VoiceOver? Or is it a suggestion to extend the above table with a specific setting for VoiceOver, "Tab to move focus between all controls"? Or something else?
@jscholes thanks for even more ideas :)
Another one that comes to mind, and applies to all screen readers: audio output, or ensuring that a screen reader is okay without having access to one.
To fit this into the table, would it be accurate to call the setting, "Audio output device"? And does that imply that we would need some "null" device? Or is the setting more like "Disable audio output"?
Pop-up dialogs are also not JAWS-specific. For example, NVDA has the startup/welcome UI, automatic updates, and data privacy.
Good point. I think I'd like to track the disabling of each pop-up separately rather than describing the general need with a catch-all entry. That granularity will give us a clearer picture of the development effort.
@jugglinmike it's in the same category as disabling popups and keyboard layout — initial configuration that we want in place before running a test, but likely not settings we need to change within a test. It should probably be noted in Configuring Screen Readers for Testing as well, since tests like 'Navigate forwards to a collapsed disclosure button' will fail without those settings enabled (TAB will not focus buttons).
Got it--added that to the table
To fit this into the table, would it be accurate to call the setting, "Audio output device"? And does that imply that we would need some "null" device?
Yes and yes.
Thanks, @jscholes. That's in the table, now, too.
@jugglinmike is this still relevant?
Yup!