WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Rendering a carousel as simple list for screen reader users?

for

From: Jonathan Avila
Date: Oct 19, 2018 10:06AM

> 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 REMOVED> > On Behalf Of Detlev Fischer
Sent: Friday, October 19, 2018 5:12 AM
To: <EMAIL 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