search

w3c / at-driver

AT Driver defines a protocol for introspection and remote control of assistive technology software, using a bidirectional communication channel.
https://w3c.github.io/at-driver
Other
31 stars 4 forks source link

Request for comment: screen reader settings #16

Open jugglinmike opened 2 years ago

jugglinmike commented 2 years ago

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.
jscholes commented 2 years ago

@jugglinmike A couple to add to the list:

jugglinmike commented 2 years ago

Awesome, @jscholes! Those are all included in the table, now.

WestonThayer commented 2 years ago
WestonThayer commented 2 years ago

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.

jscholes commented 2 years ago

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.

jscholes commented 2 years ago

Pop-up dialogs are also not JAWS-specific. For example, NVDA has the startup/welcome UI, automatic updates, and data privacy.

jugglinmike commented 2 years ago

@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:

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?

jugglinmike commented 2 years ago

@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.

WestonThayer commented 2 years ago

@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).

jugglinmike commented 2 years ago

Got it--added that to the table

jscholes commented 2 years ago

@jugglinmike

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.

jugglinmike commented 2 years ago

Thanks, @jscholes. That's in the table, now, too.

zcorpan commented 2 years ago

From today's AT Automation Working Session, @jscholes and @mcking65 think we should first specify:

For each AT:

Later we can revisit convenience for shared settings between ATs.

lolaodelola commented 5 months ago

@jugglinmike is this still relevant?

jugglinmike commented 5 months ago

Yup!