Request for comment: screen reader settings #16
Comments
|
@jugglinmike A couple to add to the list:
|
|
Awesome, @jscholes! Those are all included in the table, now. |
|
|
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:
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 :)
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"?
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 |
Yes and yes. |
|
Thanks, @jscholes. That's in the table, now, too. |
|
@jugglinmike is this still relevant? |
|
Yup! |
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.
* 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.
The text was updated successfully, but these errors were encountered: