E-mail List Archives
Thread: Synchronic Alternatives for Sliders
Number of posts in this thread: 8 (In chronological order)
From: office@zweiterblick.at
Date: Tue, Feb 07 2017 2:03AM
Subject: Synchronic Alternatives for Sliders
No previous message | Next message →
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
From: office@zweiterblick.at
Date: Fri, Feb 10 2017 8:02AM
Subject: Re: Synchronic Alternatives for Sliders
← Previous message | Next message →
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 ADDRESS REMOVED = ] Im Auftrag
von = EMAIL ADDRESS REMOVED =
Gesendet: Dienstag, 07. Februar 2017 10:03
An: = EMAIL ADDRESS 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
From: Birkir R. Gunnarsson
Date: Fri, Feb 10 2017 1:45PM
Subject: Re: Synchronic Alternatives for Sliders
← Previous message | Next message →
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 ADDRESS REMOVED = < = EMAIL ADDRESS 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 ADDRESS REMOVED = ] Im Auftrag
> von = EMAIL ADDRESS REMOVED =
> Gesendet: Dienstag, 07. Februar 2017 10:03
> An: = EMAIL ADDRESS 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.
From: Bryan Garaventa
Date: Fri, Feb 10 2017 4:30PM
Subject: Re: Synchronic Alternatives for Sliders
← Previous message | Next message →
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 ADDRESS REMOVED =
415.624.2709 (o)
www.SSBBartGroup.com
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: Friday, February 10, 2017 7:02 AM
To: 'WebAIM Discussion List' < = EMAIL ADDRESS 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 ADDRESS REMOVED = ] Im Auftrag von = EMAIL ADDRESS REMOVED =
Gesendet: Dienstag, 07. Februar 2017 10:03
An: = EMAIL ADDRESS 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
From: office@zweiterblick.at
Date: Sat, Feb 11 2017 11:55AM
Subject: Re: Synchronic Alternatives for Sliders
← Previous message | Next message →
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 ADDRESS 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 ADDRESS REMOVED = < = EMAIL ADDRESS 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 ADDRESS REMOVED = ] Im Auftrag
> von = EMAIL ADDRESS REMOVED =
> Gesendet: Dienstag, 07. Februar 2017 10:03
> An: = EMAIL ADDRESS 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.
From: office@zweiterblick.at
Date: Sat, Feb 11 2017 1:14PM
Subject: Re: Synchronic Alternatives for Sliders
← Previous message | Next message →
Thanks Bryan too!
It seems that "Slider" is in English spontaneously understood as the form
element and not the visual design element, as I already discovered in
Birkirs reply. Is the German usage of this term really so different?
On your link:
http://whatsock.com/tsg/Coding%20Arena/Carousels,%20Slideshows,%20and%20Wiza
rds/Carousel%20(Flat%20from%20XML%20with%20Overrides)/demo.htm I found my
problem again. Try it yourself:
1. Press Jawskey + F3 for "Virtual HTML Functions" (This should be rather
the English translation for the German translation, which I get.)
2. Press (perhaps) G for "graphics" to list up the alt-texts for images or
some other info about the images to list them up.
3. Review the result again and again and you'll find different results.
This is the problem, I want to have discussed.
Sorry, I didn't expect the terminology problems!
From the origin country of the Terminator!
Wolfgang Berndorfer
The Terminologytator
-----Ursprüngliche Nachricht-----
Von: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] Im Auftrag
von Bryan Garaventa
Gesendet: Samstag, 11. Februar 2017 00:30
An: WebAIM Discussion List
Betreff: Re: [WebAIM] Synchronic Alternatives for Sliders
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%20Wiza
rds/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 ADDRESS REMOVED =
415.624.2709 (o)
www.SSBBartGroup.com
-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
Of = EMAIL ADDRESS REMOVED =
Sent: Friday, February 10, 2017 7:02 AM
To: 'WebAIM Discussion List' < = EMAIL ADDRESS 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 ADDRESS REMOVED = ] Im Auftrag
von = EMAIL ADDRESS REMOVED =
Gesendet: Dienstag, 07. Februar 2017 10:03
An: = EMAIL ADDRESS 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
http://webaim.org/discussion/archives
http://webaim.org/discussion/archives
From: Jonathan Cohn
Date: Sun, Feb 12 2017 12:10PM
Subject: Re: Synchronic Alternatives for Sliders
← Previous message | Next message →
To re-phrase your issue if I am understanding you correctly...
1. A slider is what we in the US call a carousel, an area of the screen where graphics with links are scrolled in one act a time.
2. You want to be able to get a complete list of all the elements of the slider/ or Carousel.
I think the only way to do this would be to create a button or link to a static view of all the images in the carasel.
Best wishes,
Jonathan Cohn
> On Feb 11, 2017, at 3:14 PM, < = EMAIL ADDRESS REMOVED = > < = EMAIL ADDRESS REMOVED = > wrote:
>
> Thanks Bryan too!
> It seems that "Slider" is in English spontaneously understood as the form
> element and not the visual design element, as I already discovered in
> Birkirs reply. Is the German usage of this term really so different?
> On your link:
> http://whatsock.com/tsg/Coding%20Arena/Carousels,%20Slideshows,%20and%20Wiza
> rds/Carousel%20(Flat%20from%20XML%20with%20Overrides)/demo.htm I found my
> problem again. Try it yourself:
> 1. Press Jawskey + F3 for "Virtual HTML Functions" (This should be rather
> the English translation for the German translation, which I get.)
> 2. Press (perhaps) G for "graphics" to list up the alt-texts for images or
> some other info about the images to list them up.
> 3. Review the result again and again and you'll find different results.
> This is the problem, I want to have discussed.
> Sorry, I didn't expect the terminology problems!
> From the origin country of the Terminator!
> Wolfgang Berndorfer
> The Terminologytator
>
> -----Ursprüngliche Nachricht-----
> Von: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] Im Auftrag
> von Bryan Garaventa
> Gesendet: Samstag, 11. Februar 2017 00:30
> An: WebAIM Discussion List
> Betreff: Re: [WebAIM] Synchronic Alternatives for Sliders
>
> 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%20Wiza
> rds/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 ADDRESS REMOVED =
> 415.624.2709 (o)
> www.SSBBartGroup.com
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of = EMAIL ADDRESS REMOVED =
> Sent: Friday, February 10, 2017 7:02 AM
> To: 'WebAIM Discussion List' < = EMAIL ADDRESS 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 ADDRESS REMOVED = ] Im Auftrag
> von = EMAIL ADDRESS REMOVED =
> Gesendet: Dienstag, 07. Februar 2017 10:03
> An: = EMAIL ADDRESS 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
>
> > > http://webaim.org/discussion/archives
> >
> > > http://webaim.org/discussion/archives
> > > > > >
> > > >
From: office@zweiterblick.at
Date: Sun, Feb 12 2017 2:08PM
Subject: Re: Synchronic Alternatives for Sliders
← Previous message | No next message
Hi Jonathan!
Yes, my issue is about carousels. And I want to get a list of all the
elements in them.
But a button for all elements won't b listed up with SR mechanisms for
headings and links. So again:
A) Should we instruct the SR-users not to trust in listing up headings and
links?
B) Find a solution for the strategy?
Wolfgang
-----Ursprüngliche Nachricht-----
Von: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] Im Auftrag
von Jonathan Cohn
Gesendet: Sonntag, 12. Februar 2017 20:11
An: WebAIM Discussion List
Betreff: Re: [WebAIM] Synchronic Alternatives for Sliders
To re-phrase your issue if I am understanding you correctly…
1. A slider is what we in the US call a carousel, an area of the screen
where graphics with links are scrolled in one act a time.
2. You want to be able to get a complete list of all the elements of the
slider/ or Carousel.
I think the only way to do this would be to create a button or link to a
static view of all the images in the carasel.
Best wishes,
Jonathan Cohn
> On Feb 11, 2017, at 3:14 PM, < = EMAIL ADDRESS REMOVED = >
< = EMAIL ADDRESS REMOVED = > wrote:
>
> Thanks Bryan too!
> It seems that "Slider" is in English spontaneously understood as the form
> element and not the visual design element, as I already discovered in
> Birkirs reply. Is the German usage of this term really so different?
> On your link:
>
http://whatsock.com/tsg/Coding%20Arena/Carousels,%20Slideshows,%20and%20Wiza
> rds/Carousel%20(Flat%20from%20XML%20with%20Overrides)/demo.htm I found my
> problem again. Try it yourself:
> 1. Press Jawskey + F3 for "Virtual HTML Functions" (This should be rather
> the English translation for the German translation, which I get.)
> 2. Press (perhaps) G for "graphics" to list up the alt-texts for images or
> some other info about the images to list them up.
> 3. Review the result again and again and you'll find different results.
> This is the problem, I want to have discussed.
> Sorry, I didn't expect the terminology problems!
> From the origin country of the Terminator!
> Wolfgang Berndorfer
> The Terminologytator
>
> -----Ursprüngliche Nachricht-----
> Von: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] Im Auftrag
> von Bryan Garaventa
> Gesendet: Samstag, 11. Februar 2017 00:30
> An: WebAIM Discussion List
> Betreff: Re: [WebAIM] Synchronic Alternatives for Sliders
>
> 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%20Wiza
> rds/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 ADDRESS REMOVED =
> 415.624.2709 (o)
> www.SSBBartGroup.com
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of = EMAIL ADDRESS REMOVED =
> Sent: Friday, February 10, 2017 7:02 AM
> To: 'WebAIM Discussion List' < = EMAIL ADDRESS 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 ADDRESS REMOVED = ] Im Auftrag
> von = EMAIL ADDRESS REMOVED =
> Gesendet: Dienstag, 07. Februar 2017 10:03
> An: = EMAIL ADDRESS 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
>
> > at
> http://webaim.org/discussion/archives
> >
> > at
> http://webaim.org/discussion/archives
> > > > > >
> > > >