search

w3c / aria-at

Assistive Technology ARIA Experience Assessment
https://aria-at.netlify.app
Other
152 stars 27 forks source link

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

Open shirsha opened 3 years ago

shirsha commented 3 years ago

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

jscholes commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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

JAWS-test commented 3 years ago

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 (https://github.com/w3c/aria-at/issues/403)

JAWS-test commented 3 years ago

At NVDA, for example, there is an error ticket for the missing output of aria-valuemin/max: https://github.com/nvaccess/nvda/issues/6906

jscholes commented 3 years ago

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 commented 3 years ago

related: https://github.com/w3c/aria/issues/1128

JAWS-test commented 3 years ago

Bug for JAWS: https://github.com/FreedomScientific/VFO-standards-support/issues/513

mcking65 commented 3 years ago

@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 commented 3 years ago

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.