WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Synchronic Alternatives for Sliders

for

From: office
Date: Feb 11, 2017 11:55AM

Thanks Birkir, but I have to precise my question:
The ARIA authoring practices spec for “slider” refers to an "input where the
user selects a value from within a given range". This is not my topic.
What causes me problems as a screen reader user and a11y expert are the
widgets, which move or change content within an area on the screen by time
(DIACHRONICALLY).
Here’s an example of what I mean: (One of the testfiles I'm working on to
understand and clear the problem - German language, but it’s moving
everywhere the same.)
http://www.zweiterblick.at/index.php?site=slider_css
Unfortunately the term “slider” is used homonymely in English for “turning
up or down a value” and a time-sensitive area for visual experience.
Confusing might also be that a “slider” contains “slides” (esp. in
diashows), which are something completely different.
Now to the problem:
One of my personal strategies to gather the content of a web side on a first
visit is to list up all headings and then links with jaws functionalities
(jawskey + F6 and F7).
By occasion I found out, that on the side, I just visited, was a slider and
jaws only listed up the heading and links of the current (SYNCHRONIC)
visible slide of the slider. On my next visit the recognised heading and
link were gone.
I then tested kinds of sliders on other sides with different technologies
(jquery, CSS3) and faced the same problem with JAWS and NVDA. And then I
surfed and googled like you suggested too ...
Users with screen readers miss content or functionalities by just listing up
the special type of element, since only the current displayed slide and its
elements are listed (i.e. 1 of x). They won't even get aware that there is a
time based change (slider, diashow, carousel) at all – without special
techs, but witch? I even found navigational areas for website access in a
slider!
Another experience: Stopping the slider ON FOCUS alone does not tell the
screen reader that there were more items or that there was a slider at all.
Fulfilling SC 2.2.2 doesn’t solve the problem.
So should we now:
A) Deprecate Sliders at all?
B) Tell users not to trust the described strategy?
C) Make the best out of Sliders - in a SYCHRONIC design (alternative or
with appropriate ARIA)?
How to make SYCHRONIC approach for the screen reader, is my technical and/or
usability question. My web researches and your links were not helpful
enough. (No best practise site uses sliders at all)
The aria authoring practises concern “sliders” as described above and don't
deal carousels, as far as I know.
Visiting http://www.w3.org/WAI/tutorials/carousels/functionality/ seemed
hopeful from the text, but the links to the examples brought “DOCUMENT NOT
FOUND”.
I also knew http://shouldiuseacarousel.com already. Seems, we googled the
same terms. Just press Jawskey + F6 on this site and you will find exactly 1
heading, while there where 10 slides with headings, if I counted correctly.
Also: Regions with aria-labels are not announced by tabbing or listing up
headings or links with SR functionalities. So landmark labels aren't
sufficient too.
Is aria-live the solution, and how? I’m not experienced with this property
and support in browsers and AT.
I’d prefer solutions that solve issues with deactivated JS or CSS at the
same time. Am I a dreamer?
PS:
This is my first inquiry on the webAIM mailing list and I see that I have to
be more precise with wording and texting. And I have to work on my account
(office@...). Thought that my name was presented in the “from” as I put in
the registration form.
Anyway, I have to keep the account settings first, since webAIM says that
changes might take a few days.
From the Alps
Wolfgang Berndorfer

-----Ursprüngliche Nachricht-----
Von: WebAIM-Forum [mailto: <EMAIL REMOVED> ] Im Auftrag
von Birkir R. Gunnarsson
Gesendet: Freitag, 10. Februar 2017 21:45
An: WebAIM Discussion List
Betreff: Re: [WebAIM] Synchronic Alternatives for Sliders

Check out the ARIA authoring practices spec for the slider widget:
https://www.w3.org/TR/wai-aria-practices-1.1/

The Paciello Group has a great tutorial on accessible sliders (though old):
https://www.paciellogroup.com/blog/2008/05/aria-slider-part-1/

For carousels,
Google "accessible carousel"
The first 3 matches are great resources.
especially http://www.w3.org/WAI/tutorials/carousels/functionality/

Also check out: http://shouldiuseacarousel.com for a humorous take on
the problem.
With carousels:
User has to be able to stop them (either by clicking a button, or
focus them with the keyboard).
The screen reader user has to figure out what is the carousel area
(you can use regions with aria-labels).
If carousel is stopped but you can still flip thorugh it, screen
reader and keyboard only users need to be able to flip (if there are
next/prev buttons they have to be accessible).


Schnappy Schnappy Schnapp.
-B


On 2/10/17, <EMAIL REMOVED> < <EMAIL REMOVED> > wrote:
> 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
>
> > > > >
> > > > >


--
Work hard. Have fun. Make history.