E-mail List Archives
Thread: Rendering a carousel as simple list for screen reader users?
Number of posts in this thread: 10 (In chronological order)
From: Emmanuel Pelletier
Date: Fri, Oct 19 2018 1:31AM
Subject: Rendering a carousel as simple list for screen reader users?
No previous message | Next message →
Hi everyone,
I'm wondering about what would be an ideal way to build an accessible
carousel.
The idea was: since a carousel is basically a list of items you navigate
into, a screen reader should only announce the list of items. It should
not be aware of the usual carousel navigation buttons, the notion of a
currently visible element, etc. The user should navigate like he would
normally do in any other list.
So I tried to implement that: rendering a carousel with items,
navigation buttons, current slide indication, etc, for people not using
a screen reader, but possibly using a keyboard; and making it that the
exact same HTML makes screen readers only know about the list of items.
But I couldn't figure it out.
For example, I tried adding a `aria-hidden="true"` attribute on the
navigation buttons (despite the 4th rule of ARIA use, I know). The idea
was that a screen reader would not announce the buttons for users
navigating with arrow keys. The problem is it would still announce a
"blank" button for screen reader users navigating with tab key. I could
add a `tabindex="-1"`, but the problem would now be for users not having
a screen reader and using a keyboard.
I encountered other similar problems, all caused by the fact that I want
a different behavior for screen reader users and keyboard users not
using a screen reader.
So, what do you think? Is the original idea OK? Do you see a way to
actually implement it? If this ends up in the trashcan, I'm curious of
your other ideas to make something accessible and not too cumbersome for
screen reader users.
Thank you,
Emmanuel Pelletier
Web developer, Empreinte Digitale
From: Patrick H. Lauke
Date: Fri, Oct 19 2018 2:55AM
Subject: Re: Rendering a carousel as simple list for screen reader users?
← Previous message | Next message →
On 19/10/2018 08:31, Emmanuel Pelletier wrote:
> Hi everyone,
>
>
> I'm wondering about what would be an ideal way to build an accessible
> carousel.
>
> The idea was: since a carousel is basically a list of items you navigate
> into, a screen reader should only announce the list of items. It should
> not be aware of the usual carousel navigation buttons, the notion of a
> currently visible element, etc. The user should navigate like he would
> normally do in any other list.
>
> So I tried to implement that: rendering a carousel with items,
> navigation buttons, current slide indication, etc, for people not using
> a screen reader, but possibly using a keyboard; and making it that the
> exact same HTML makes screen readers only know about the list of items.
>
> But I couldn't figure it out.
>
> For example, I tried adding a `aria-hidden="true"` attribute on the
> navigation buttons (despite the 4th rule of ARIA use, I know). The idea
> was that a screen reader would not announce the buttons for users
> navigating with arrow keys. The problem is it would still announce a
> "blank" button for screen reader users navigating with tab key. I could
> add a `tabindex="-1"`, but the problem would now be for users not having
> a screen reader and using a keyboard.
>
> I encountered other similar problems, all caused by the fact that I want
> a different behavior for screen reader users and keyboard users not
> using a screen reader.
>
>
> So, what do you think? Is the original idea OK? Do you see a way to
> actually implement it? If this ends up in the trashcan, I'm curious of
> your other ideas to make something accessible and not too cumbersome for
> screen reader users.
In general, I'd say: you can't find a solution here that works both for
screenreader users and non-AT keyboard users. Controls need to be
focusable/actionable, but you can't hide them and make them
non-focusable JUST for screenreader users. That's a circle that can't be
squared currently, unfortunately.
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Graham Armfield
Date: Fri, Oct 19 2018 2:57AM
Subject: Re: Rendering a carousel as simple list for screen reader users?
← Previous message | Next message →
I'm sure you're aware that many people on this list would be 'taking
against' carousels - including me to a certain extent. There's also
research I'm told that site visitors don't often interact with them.
But if you want to build on...
Another way of looking at it would be to model the carousel as a tab panel
construct with some extra functionality.
Many carousels have navigation 'blobs' to allow users to jump to specific
panels (items). If properly labelled, these could be your tab headers - so
should come first in the content order. They can be positioned using CSS.
If you're intending for the carousel to 'spin' automatically then obviously
there should be a pause button early in the content flow also.
The panels themselves would follow, and then you could have the
previous/next arrows at the end of the content order if you wish to use
them.
Regards
Graham Armfield
coolfields.co.uk <http://www.coolfields.co.uk/>;
M:07905 590026
T: 01483 856613
@coolfields <https://twitter.com/coolfields>
On Fri, Oct 19, 2018 at 8:31 AM Emmanuel Pelletier <
= EMAIL ADDRESS REMOVED = > wrote:
> Hi everyone,
>
>
> I'm wondering about what would be an ideal way to build an accessible
> carousel.
>
>
From: Detlev Fischer
Date: Fri, Oct 19 2018 3:12AM
Subject: Re: Rendering a carousel as simple list for screen reader users?
← Previous message | Next message →
In my view, carousel buttons do not need to be keyboard-accessible if
they are redundant, i.e., if tabbing through content will advance the
carousel; in other words, bring the next slide into view and focus its
content (e.g., linked teaser headings). (However, I am not sure whether
it is feasible to keep the visual carousel position and the virtual
cursor position in synch when arrowing through the caroussel with a
screen reader. If there is no match, it might be an issue for mixed mode
use, like someone consuming the carousel content visually but turning
on the screenreader in addition, e.g., to read small or longish text.
Any thoughts?
Am 19.10.2018 um 10:55 schrieb Patrick H. Lauke:
> On 19/10/2018 08:31, Emmanuel Pelletier wrote:
>> Hi everyone,
>>
>>
>> I'm wondering about what would be an ideal way to build an accessible
>> carousel.
>>
>> The idea was: since a carousel is basically a list of items you
>> navigate into, a screen reader should only announce the list of
>> items. It should not be aware of the usual carousel navigation
>> buttons, the notion of a currently visible element, etc. The user
>> should navigate like he would normally do in any other list.
>>
>> So I tried to implement that: rendering a carousel with items,
>> navigation buttons, current slide indication, etc, for people not
>> using a screen reader, but possibly using a keyboard; and making it
>> that the exact same HTML makes screen readers only know about the
>> list of items.
>>
>> But I couldn't figure it out.
>>
>> For example, I tried adding a `aria-hidden="true"` attribute on the
>> navigation buttons (despite the 4th rule of ARIA use, I know). The
>> idea was that a screen reader would not announce the buttons for
>> users navigating with arrow keys. The problem is it would still
>> announce a "blank" button for screen reader users navigating with tab
>> key. I could add a `tabindex="-1"`, but the problem would now be for
>> users not having a screen reader and using a keyboard.
>>
>> I encountered other similar problems, all caused by the fact that I
>> want a different behavior for screen reader users and keyboard users
>> not using a screen reader.
>>
>>
>> So, what do you think? Is the original idea OK? Do you see a way to
>> actually implement it? If this ends up in the trashcan, I'm curious
>> of your other ideas to make something accessible and not too
>> cumbersome for screen reader users.
>
> In general, I'd say: you can't find a solution here that works both
> for screenreader users and non-AT keyboard users. Controls need to be
> focusable/actionable, but you can't hide them and make them
> non-focusable JUST for screenreader users. That's a circle that can't
> be squared currently, unfortunately.
>
> P
--
Detlev Fischer
Testkreis
Werderstr. 34, 20144 Hamburg
Mobil +49 (0)157 57 57 57 45
http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
From: Swift, Daniel P.
Date: Fri, Oct 19 2018 6:13AM
Subject: Re: Rendering a carousel as simple list for screen reader users?
← Previous message | Next message →
What about if you made the entire container aria-hidden true and used JS to replicate just the list components and present them in a container as SR-only?
Dan Swift
Senior Web Specialist
Enterprise Services
West Chester University
610.738.0589
From: Emmanuel Pelletier
Date: Fri, Oct 19 2018 7:15AM
Subject: Re: Rendering a carousel as simple list for screen reader users?
← Previous message | Next message →
Thanks for the confirmation.
On 10/19/18 10:55 AM, Patrick H. Lauke wrote:
> On 19/10/2018 08:31, Emmanuel Pelletier wrote:
>> Hi everyone,
>>
>>
>> I'm wondering about what would be an ideal way to build an accessible
>> carousel.
>>
>> The idea was: since a carousel is basically a list of items you
>> navigate into, a screen reader should only announce the list of
>> items. It should not be aware of the usual carousel navigation
>> buttons, the notion of a currently visible element, etc. The user
>> should navigate like he would normally do in any other list.
>>
>> So I tried to implement that: rendering a carousel with items,
>> navigation buttons, current slide indication, etc, for people not
>> using a screen reader, but possibly using a keyboard; and making it
>> that the exact same HTML makes screen readers only know about the
>> list of items.
>>
>> But I couldn't figure it out.
>>
>> For example, I tried adding a `aria-hidden="true"` attribute on the
>> navigation buttons (despite the 4th rule of ARIA use, I know). The
>> idea was that a screen reader would not announce the buttons for
>> users navigating with arrow keys. The problem is it would still
>> announce a "blank" button for screen reader users navigating with tab
>> key. I could add a `tabindex="-1"`, but the problem would now be for
>> users not having a screen reader and using a keyboard.
>>
>> I encountered other similar problems, all caused by the fact that I
>> want a different behavior for screen reader users and keyboard users
>> not using a screen reader.
>>
>>
>> So, what do you think? Is the original idea OK? Do you see a way to
>> actually implement it? If this ends up in the trashcan, I'm curious
>> of your other ideas to make something accessible and not too
>> cumbersome for screen reader users.
>
> In general, I'd say: you can't find a solution here that works both
> for screenreader users and non-AT keyboard users. Controls need to be
> focusable/actionable, but you can't hide them and make them
> non-focusable JUST for screenreader users. That's a circle that can't
> be squared currently, unfortunately.
>
> P
From: Emmanuel Pelletier
Date: Fri, Oct 19 2018 7:20AM
Subject: Re: Rendering a carousel as simple list for screen reader users?
← Previous message | Next message →
Oh, I'm well aware! But clients are often hard to convince and carousels
are in the end something we have to deal with regularly.
Thanks for the idea, I also thought of a tabpanel implementation. What I
was afraid about was maybe it was kinda "heavy" on the screen reader
user for this use case.
Emmanuel
On 10/19/18 10:57 AM, Graham Armfield wrote:
> I'm sure you're aware that many people on this list would be 'taking
> against' carousels - including me to a certain extent. There's also
> research I'm told that site visitors don't often interact with them.
>
> But if you want to build on...
>
> Another way of looking at it would be to model the carousel as a tab panel
> construct with some extra functionality.
>
> Many carousels have navigation 'blobs' to allow users to jump to specific
> panels (items). If properly labelled, these could be your tab headers - so
> should come first in the content order. They can be positioned using CSS.
>
> If you're intending for the carousel to 'spin' automatically then obviously
> there should be a pause button early in the content flow also.
>
> The panels themselves would follow, and then you could have the
> previous/next arrows at the end of the content order if you wish to use
> them.
>
> Regards
> Graham Armfield
>
> coolfields.co.uk <http://www.coolfields.co.uk/>;
> M:07905 590026
> T: 01483 856613
> @coolfields <https://twitter.com/coolfields>
>
>
> On Fri, Oct 19, 2018 at 8:31 AM Emmanuel Pelletier <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> Hi everyone,
>>
>>
>> I'm wondering about what would be an ideal way to build an accessible
>> carousel.
>>
>>
> > > > > .
>
From: Emmanuel Pelletier
Date: Fri, Oct 19 2018 7:32AM
Subject: Re: Rendering a carousel as simple list for screen reader users?
← Previous message | Next message →
That's a fine idea.
But if I do that, the interactive stuff in the carousel is still
focusable via the tab key while using a screen reader.
I'd say this makes it not okay to do. There was a conversation about
this a few days ago in this list and it didn't seem right to conclude
"screen reader = not using tab", but maybe I'm wrong.
Emmanuel
On 10/19/18 2:13 PM, Swift, Daniel P. wrote:
> What about if you made the entire container aria-hidden true and used JS to replicate just the list components and present them in a container as SR-only?
>
> Dan Swift
> Senior Web Specialist
> Enterprise Services
> West Chester University
> 610.738.0589
>
>
From: Swift, Daniel P.
Date: Fri, Oct 19 2018 8:12AM
Subject: Re: Rendering a carousel as simple list for screen reader users?
← Previous message | Next message →
Ah - I hadn't considered SR users tabbing through. Well that doesn't solve the problem at all then :-D
Dan Swift
Senior Web Specialist
Enterprise Services
West Chester University
610.738.0589
From: Jonathan Avila
Date: Fri, Oct 19 2018 10:06AM
Subject: Re: Rendering a carousel as simple list for screen reader users?
← Previous message | No next message
> In my view, carousel buttons do not need to be keyboard-accessible if they are redundant, i.e., if tabbing through content
I would be concerned about requiring the keyboard user to have to tab through all pages of carousel content to skip past the carousel. Having only the next, previous and current carousel content in the focus order seems better from a keyboard only perspective. In my experience visual indication of focus in these situations is also problematic because the carousels don't know the page was advanced when only tab is used.
Jonathan
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Detlev Fischer
Sent: Friday, October 19, 2018 5:12 AM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] Rendering a carousel as simple list for screen reader users?
In my view, carousel buttons do not need to be keyboard-accessible if they are redundant, i.e., if tabbing through content will advance the carousel; in other words, bring the next slide into view and focus its content (e.g., linked teaser headings). (However, I am not sure whether it is feasible to keep the visual carousel position and the virtual cursor position in synch when arrowing through the caroussel with a screen reader. If there is no match, it might be an issue for mixed mode use, like someone consuming the carousel content visually but turning on the screenreader in addition, e.g., to read small or longish text.
Any thoughts?
Am 19.10.2018 um 10:55 schrieb Patrick H. Lauke:
> On 19/10/2018 08:31, Emmanuel Pelletier wrote:
>> Hi everyone,
>>
>>
>> I'm wondering about what would be an ideal way to build an accessible
>> carousel.
>>
>> The idea was: since a carousel is basically a list of items you
>> navigate into, a screen reader should only announce the list of
>> items. It should not be aware of the usual carousel navigation
>> buttons, the notion of a currently visible element, etc. The user
>> should navigate like he would normally do in any other list.
>>
>> So I tried to implement that: rendering a carousel with items,
>> navigation buttons, current slide indication, etc, for people not
>> using a screen reader, but possibly using a keyboard; and making it
>> that the exact same HTML makes screen readers only know about the
>> list of items.
>>
>> But I couldn't figure it out.
>>
>> For example, I tried adding a `aria-hidden="true"` attribute on the
>> navigation buttons (despite the 4th rule of ARIA use, I know). The
>> idea was that a screen reader would not announce the buttons for
>> users navigating with arrow keys. The problem is it would still
>> announce a "blank" button for screen reader users navigating with tab
>> key. I could add a `tabindex="-1"`, but the problem would now be for
>> users not having a screen reader and using a keyboard.
>>
>> I encountered other similar problems, all caused by the fact that I
>> want a different behavior for screen reader users and keyboard users
>> not using a screen reader.
>>
>>
>> So, what do you think? Is the original idea OK? Do you see a way to
>> actually implement it? If this ends up in the trashcan, I'm curious
>> of your other ideas to make something accessible and not too
>> cumbersome for screen reader users.
>
> In general, I'd say: you can't find a solution here that works both
> for screenreader users and non-AT keyboard users. Controls need to be
> focusable/actionable, but you can't hide them and make them
> non-focusable JUST for screenreader users. That's a circle that can't
> be squared currently, unfortunately.
>
> P
--
Detlev Fischer
Testkreis
Werderstr. 34, 20144 Hamburg
Mobil +49 (0)157 57 57 57 45
http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus