Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Assistive technologies like screen readers should inform the user when they reach the end or beginning of a slider #412

Open
shirsha opened this issue Apr 5, 2021 · 12 comments
Labels
Agenda+Test Writing For discussion during the next teleconference related to test writing and manual test runs AT: JAWS Related to expectations associated with JAWS screen reader testing AT: NVDA Related to expectations associated with NVDA screen reader testing AT: VoiceOver for macOS Related to expectations associated with VoiceOver for Mac screen reader testing tests About assistive technology tests

Comments

@shirsha
Copy link

shirsha commented Apr 5, 2021

When a user is interacting a slider, a visual user knows when they reach the end or beginning of the slider.
For screen reader users there is no sound or any other indication to inform them about the end or beginning of the slider.

https://www.w3.org/TR/wai-aria-practices/examples/slider/slider-1.html

@shirsha shirsha added the bug Something isn't working label Apr 5, 2021
@jscholes
Copy link
Contributor

jscholes commented Apr 5, 2021

@shirsha A screen reader does technically indicate that you've reached the beginning or end of a correctly coded slider by simply not saying anything when you try to adjust it further in the given direction (which is the case for NVDA at least). Could you describe how you feel this relates to ARIA-AT specifically, rather than being an issue to be raised with a specific screen reader vendor, the WAI-ARIA Authoring Practices examples or both?

@JAWS-test
Copy link

A slider has aria-valuemin/max. The question would be whether there is an expectation that the two values will be output by the screen reader without reaching the beginning or end of the slider. For example, if I am at the value 50, it would be good to know if that is in the middle, or rather in the first third or last quarter...

@jscholes
Copy link
Contributor

jscholes commented Apr 6, 2021

@JAWS-test, @shirsha Is this something you'd like us to add to the agenda of an upcoming community group meeting for discussion, in terms of how we assert the presence of aria-valuemin and aria-valuemax on sliders?

@JAWS-test
Copy link

@jscholes I don't even know if the slider is currently being tested. If this is the case, it should be considered when creating the test cases whether screen readers are expected to output aria-valuemin/max

@jscholes
Copy link
Contributor

jscholes commented Apr 6, 2021

@JAWS-test Sliders are very much on our minds right now. I'll add this to a future meeting agenda, would you or @shirsha be interested in attending to provide suggestions?

@jscholes jscholes added Agenda+Test Writing For discussion during the next teleconference related to test writing and manual test runs AT: JAWS Related to expectations associated with JAWS screen reader testing AT: NVDA Related to expectations associated with NVDA screen reader testing AT: VoiceOver for macOS Related to expectations associated with VoiceOver for Mac screen reader testing tests About assistive technology tests and removed bug Something isn't working labels Apr 6, 2021
@JAWS-test
Copy link

JAWS-test commented Apr 6, 2021

As far as I know, aria-valuemin/max is not output by any screen reader (regardless of the role used). I think it makes sense if aria-valuemin/max is output by screen readers without having to change the value. I have already mentioned the reasons for this above.

I see the output of aria-valuemin/max problematic only in connection with aria-valuetext. Because then e.g. with an element for the selection of a weekday as aria-valuetext "Tuesday" is output and as minimum value 1 and maximum value 7, whereby it is unclear whether 1 stands for "Monday" or "Sunday" or another weekday. But even then the output of aria-valuemin/max would be better than no output at all.

So far, the output of aria-valuemin/max does not seem to be checked for sliders (#403)

@JAWS-test
Copy link

At NVDA, for example, there is an error ticket for the missing output of aria-valuemin/max: nvaccess/nvda#6906

@jscholes
Copy link
Contributor

jscholes commented Apr 7, 2021

But even then the output of aria-valuemin/max would be better than no output at all.

I'm not sure I agree with that, particularly in a slider using aria-valuetext where the accepted range (e.g. days of the week) could potentially be inferred by the user. Really, I'm not sure why aria-valuemintext/aria-valuemaxtext (or similar) don't exist.

Regardless though, this is good input for a meeting topic. Thanks for providing additional context and thoughts. I will post back here once it has been discussed.

@JAWS-test
Copy link

related: w3c/aria#1128

@JAWS-test
Copy link

Bug for JAWS: FreedomScientific/standards-support#513

@mcking65
Copy link
Contributor

mcking65 commented Apr 9, 2021

@jscholes
I encouraged @shirsha to raise this issue after a discussion in the APG call. I think there is room for an optional assertion. Personally, I don't think silence is a useful response. I'd rather have the screen reader do something to indicate the slider is at max. In beginner verbosity, it could say something like "Slider_Name Already at maximum value of MAX_Value". In lower verbosity modes, the screen reader could just issue a boink sound or something like that. This is one of those opportunities for screen readers to be far more friendly and helpful than they are now.

I look forward to a discussion in a meeting.

@jscholes
Copy link
Contributor

jscholes commented Apr 9, 2021

To provide some talking points for the call, there are multiple aspects to consider here:

  1. Whether or not/how a screen reader should convey the values of aria-valuemin and aria-valuemax when a user arrives on a slider.
  2. Same as #1, but how those values should be conveyed when the slider uses aria-valuetext.
  3. Whether or not/how a screen reader should convey that the minimum and maximum value has been reached when a user sets the slider to that value.
  4. Whether or not/how a screen reader should convey that the minimum and maximum value has been reached when they try to decrease or increase it further.

#4, was referenced by @mcking65 above:

it could say something like "Slider_Name Already at maximum value of MAX_Value".

I'm not sure how this would work with ARIA sliders. The page is responsible for handling keyboard behaviour, and wouldn't fire an event if the user tried to decrease/increase past the permitted range. The screen reader could guess, I suppose, like:

  1. user is on a slider;
  2. current value of slider matches programmatically specified minimum/maximum;
  3. sliders usually work via the arrow keys; ergo
  4. I'll speak this message about the min/max having already been reached when users press the arrow keys.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Agenda+Test Writing For discussion during the next teleconference related to test writing and manual test runs AT: JAWS Related to expectations associated with JAWS screen reader testing AT: NVDA Related to expectations associated with NVDA screen reader testing AT: VoiceOver for macOS Related to expectations associated with VoiceOver for Mac screen reader testing tests About assistive technology tests
Projects
None yet
Development

No branches or pull requests

4 participants