WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Synchronic Alternatives for Sliders

for

From: Bryan Garaventa
Date: Feb 10, 2017 4:30PM

Hi,
Regarding sliders, the only way to make JavaScript enabled drag and drop slider controls accessible at present is by using ARIA as documented in the spec. You can see an example of this here which uses all of these attributes:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Sliders/Horizontal/demo.htm

Making a simulated slider control keyboard accessible without also including these ARIA attributes and dynamic behavior will result in an inaccessible slider for non-sighted screen reader users regardless.

This is more fully documented in the ARIA Role Matrices table at
http://whatsock.com/training/matrices/#slider

If you are sighted, you can use Visual ARIA to examine this role usage as these ARIA attributes are dynamically updated in realtime, available at
http://whatsock.com/training/matrices/visual-aria.htm

There are some caveats related to such sliders however to be aware of. Drag and drop sliders that use JavaScript like this are not natively accessible in iOS, requiring users to double tap and hold with one finger when VoiceOver is running to pass the key through then drag one finger in order to move the slider. Another option is to add a Decrement and Increment button on the left and right side of the slider so that tapping one or the other will cause the slider to move accordingly on touch screen devices.

The ARIA Slider control referenced above includes this capability if anyone wishes to add it by including event hooks that can be tied to such buttons to programatically update the slider like this. This code is included in the TSG archive at
https://github.com/accdc/tsg

Regarding carousels, Birkir is right, the W3C tutorial is meant to provide the clearest guidance for making carousels accessible, because there is a lot that goes into making this work. I worked with the authors when this was written to help make this as clear as possible.
http://www.w3.org/WAI/tutorials/carousels/

You can see a live example of these concepts at
http://whatsock.com/tsg/Coding%20Arena/Carousels,%20Slideshows,%20and%20Wizards/Carousel%20(Flat%20from%20XML%20with%20Overrides)/demo.htm

The code for which is also included in the above GitHub project for review.



Bryan Garaventa
Accessibility Fellow
SSB BART Group, Inc.
<EMAIL REMOVED>
415.624.2709 (o)
www.SSBBartGroup.com

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of <EMAIL REMOVED>
Sent: Friday, February 10, 2017 7:02 AM
To: 'WebAIM Discussion List' < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Synchronic Alternatives for Sliders

Hi once more!
I still have the question: How to make sliders, carousels and slideshows as accessible as possible?
Was my question not understood or is there no answer?
Thanks, Wolfgang

-----Ursprüngliche Nachricht-----
Von: WebAIM-Forum [mailto: <EMAIL REMOVED> ] Im Auftrag von <EMAIL REMOVED>
Gesendet: Dienstag, 07. Februar 2017 10:03
An: <EMAIL REMOVED>
Betreff: [WebAIM] Synchronic Alternatives for Sliders

Hi!

Sliders are a problem, but sometimes considered as necessary for design. So I think about ways to make the best out of them.

Problem of perception with screen readers:

When I list up element types like headings, links or form elements with screen reader functionalities (e.g. JAWS+F7), only the elements of the current slide are listed. Using a screen reader, You would probably not recognize the existence of other content or functionalities, which appear at another time.

I don't think, a button, which fans out contents and functionalities of a time based (= diachronic) slider in a synchronic alternative is sufficient.
If You list up links or headings with Your screen reader, You might miss the mechanism of a button. Or is this the only way to treat the problem?

And should the alternative be hidden for the SR only?

I'm curious about opinions and best practise examples!

Wolfgang Berndorfer

Innsbruck, Austia