Carousels that keyboard and screen reader users can't use

A city museum opens its homepage with a carousel of three slides: the autumn exhibition, late opening on Fridays, and membership. Each slide has a heading, a line of text and a link. An arrow at each side and three dots underneath change the slide on a click, and the dot for the slide on show is filled in. The arrows and dots are divs and spans with click handlers. Pressing Tab goes from the first slide's link straight to the next link on the page, so a keyboard user only ever sees the first slide. A screen reader never hears the arrows or dots, the filled dot is only a colour, and when a mouse user changes the slide, nothing is read out.

Many carousels get halfway: the arrows and dots are real buttons with names, so the keyboard can change the slide. Even then, a screen reader user who presses Next hears nothing at all, and on the dots hears "Slide 2, button" with no word of which slide is the current one. They can control the carousel but can't tell what it is showing.

Success criterion 2.1.1 Keyboard asks that everything the mouse can do, the keyboard can do. Showing the second or third slide is done only by clicking a div or a span, which take no focus, so the keyboard can't do it at all. Success criterion 4.1.2 Name, Role, Value asks that controls expose a name, a role and their current state. The arrows and dots expose no name and no role, and the dots show which slide is current only by colour, a state that is never exposed.

Turning the arrows and dots into buttons is not enough on its own. The current dot still shows its state only by colour, which fails 4.1.2 in the same way. And pressing Next swaps the content beside the button while focus stays on it, so a screen reader user hears nothing and can't tell whether the press did anything, or which slide they are now on. The ARIA Authoring Practices carousel reads the new slide out through a polite live region, and the fix below does the same.

The carousel is the first thing on the homepage, and the slides after the first hold the late opening and the membership offer. Anyone who can't use a mouse, or can't see the dots, never learns they are there.

2 of 10 groups affected

• No vision (affected)
• Low vision (not affected)
• Colour vision (not affected)
• No hearing (not affected)
• Hard of hearing (not affected)
• No speech (not affected)
• Motor (affected)
• Reach, strength (not affected)
• Cognitive (not affected)
• Seizures (not affected)

• Limited manipulation The arrows and dots take no focus, so keyboard, switch and voice control users can't show the second or third slide, or reach the links on them.
• Without vision The arrows and dots are never read, the current dot is only a filled circle, and a new slide arrives without a word, so a screen reader user can't tell there are other slides, which one is showing, or that it changed.

Arrows and dots built from divs and spans have no role, so axe has nothing to check. The audit reports them when they sit inside an element whose class names it as a carousel, slider or slideshow, have class names such as prev, next, arrow, dot or bullet, show a pointer cursor and never take focus. That covers the arrows of Swiper without its accessibility module and the dots of older Owl and Flickity versions, but not arrows a site has named some other way. When the arrows are buttons with only an icon, axe reports the missing name as button-name. No check can tell whether the current dot says it is current, or whether a new slide is read out. AI fixes often add role="button" and tabindex="0" to the divs and stop there, which gives a Tab stop that Enter and Space do nothing on; put aria-label on a div with no role, which many screen readers ignore; or add aria-live="assertive" with a "Slide changed" message, which interrupts and still doesn't say what the slide is.