WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Detlev Fischer
Date: Oct 19, 2018 3:12AM

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