WebAIM - Web Accessibility In Mind

E-mail List Archives

JAWS 15 Vs JAWS 16 (Carousel widget example)

for

From: Robert Fentress
Date: Feb 9, 2016 12:22PM

This is very dated, but in searching the list for suggestions on how
to implement a carousel pattern I came across this message. Though
the page Jon referenced is gone, I thought I'd offer up my experience,
for what it's worth.

I don't think listbox is semantically appropriate, as that is, as best
I can tell from the ARIA Authoring Practices document, intended to be
like a combobox that supports pictures. Structured content would not
map to the accessibility API. Basically, anything that would go in an
option would just be an accessible name, all read out as one blob.
Thus, things like headings and links, which you'll often see in
carousels, would not respond to virtual cursor-type navigation. If
all each carousel slide contains is an image, maybe this would be
okay, but, even then, it seems more wrong than right.

I don't particularly care for the WAI implementation Jennifer
mentioned, either. If I've navigated past the carousel, I certainly
don't want whatever I'm doing to be interrupted by an aria live region
announcing the contents of a slide, however politely. I suppose you
could make the argument that it is providing "equivalent"
functionality, in that a sighted user is also jolted out of whatever
it is they were focusing on, but I would hope the goal is to make
things more usable, not less.

The best I've been able to do is to use a sort of modified tab panel
structure. I add hidden text to the little bullets that let you
navigate between slides (making them bigger) and make these have the
tab role and wrap them in container set to the tablist role. The
container for the content of the slide is assigned the tabpanel role.
I set aria-controls and aria-selected appropriately and create
listeners for the up/down and left/right arrow events as ways of
moving between slides. Then, I add a play/pause button and recommend
that it start in the paused state (though, realistically, that advice
is not likely to be taken by folks).

One important thing I noticed is that you must handle focus
appropriately. For instance, if the user is on the tablist and the
carousel progresses to the next slide, you'll need to make sure to
move focus to the newly selected tab, or else it will be lost
entirely. Of course, you would only do this when you are interacting
with the tablist.

It would probably also be good to add a screen reader-only description
in there somewhere about how this is really a carousel, so that the
user isn't totally surprised about how this "tab panel" is behaving.
If you do feel it is important to notify user of changes, you could
compromise and use a polite live region to announce just the heading
of the slide.

I don't see a need to use the application role.

This is all horrible, I recognize, but its the best I, personally,
have been able to come up with. If best practice has evolved since
the original message was posted, I'd love to hear about it.

Best,
Rob

On Thu, Mar 12, 2015 at 4:12 PM, Jennifer Sutton < <EMAIL REMOVED> > wrote:
> Greetings, all:
>
> I wanted to post a pointer to this WAI carousel tutorial, in case folks
> don't know about it and might find it handy and/or might wish to provide
> comments for improvement, based on experience.
>
> See:
>
> http://www.w3.org/WAI/tutorials/carousels/
>
> Best,
> Jennifer
>
>
> > > --
Robert Fentress
Senior Accessibility Solutions Designer
540.231.1255

Technology-enhanced Learning & Online Strategies
Assistive Technologies
1180 Torgersen Hall
620 Drillfield Drive (0434)
Blacksburg, Virginia 24061