Seat maps keyboards can't use and screen readers can't read

A cinema's booking page shows the seats for one screening as a map: four rows, A to D, six seats in each, under a bar marked Screen. Free seats are green and taken seats red, and a click turns a free seat blue, chosen. A key above the map names the three colours, and a line says that rows A and B cost $10 and rows C and D $14. With a mouse, choosing two seats side by side in row C takes two clicks.

Put the mouse aside and press Tab. Focus goes from the top of the page straight to Continue, past every seat: no seat can be chosen. A screen reader reading the page hears "Screen", then "A", "B", "C" and "D", the row letters, and nothing between them, because the seats are empty divs. And someone who sees red and green as one colour sees a map of seats that look alike: row C's free seats 1, 2, 5 and 6 are the same shade as its taken seats 3 and 4.

The team then turns each seat into a button. Tab now stops on every seat, but a screen reader hears "button" on each of the 24, with nothing to say which row a seat is in, its number or its price. Taken seats are buttons too, and pressing one does nothing, with nothing said. When a seat is chosen, only its colour changes, so the screen reader says "button" again, as it did before.

Success criterion 2.1.1 Keyboard asks that everything a mouse can do, a keyboard can do. Here the only way to choose a seat is to click a div, and a div takes no focus and answers no key, so no seat can be chosen without a pointer.

Success criterion 4.1.2 Name, Role, Value asks that every control has a name and a role, and that its state is exposed to assistive technology. A seat is a control: it can be chosen, and it is free, taken or chosen. The divs have no role and no name, so a screen reader passes over them as if nothing were there. The buttons have a role, but no text and no name. In both, the states are only the classes taken and chosen and their colours. Browsers build what assistive technology reads from elements and attributes, not from class names or background colours, so the state never reaches it.

Success criterion 1.4.1 Use of Color asks that colour is not the only way information is shown. Each seat has only its fill to say whether it is free, taken or chosen: no mark, shape or word. The key above the map has words, but they are matched to the seats by colour alone. The green, the red and the blue are within 1.46:1 of each other in lightness, the red and the blue only 1.11:1, so without their hues they look nearly the same, and to someone with the common red–green colour vision deficiencies, the green and the red look nearly the same.

Cinemas, theatres, concert halls, stadiums, airlines and trains put a map like this in the middle of buying a ticket. When the map is the only way to choose, a seat that can't be chosen is a ticket that can't be bought. Some sites offer a Best available button beside the map, but it chooses for people: they can't ask for an aisle seat, a seat beside the person they came with, or the row they always sit in.

4 of 10 groups affected

• No vision (affected)
• Low vision (affected)
• Colour vision (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)

• Without vision Screen reader users hear the word Screen and the row letters with nothing between them when the seats are empty divs, and only "button" on each seat when they are buttons. No seat says which row it is in, its number or its price, or whether it is free, taken or chosen, so they can't book a seat without help.
• Limited manipulation Keyboard and switch users can't choose a seat at all when the seats take only a click: Tab goes from the top of the page to Continue, past the whole map.
• Without perception of colour People who don't see red and green apart see free and taken seats as one colour, and find out a seat is taken only when clicking it does nothing. Without any hue, the three colours are almost the same shade.
• Limited vision In a Windows contrast theme, which replaces the fill colours, every seat is drawn the same, and partial sight often comes with weaker colour vision, so free, taken and chosen seats are hard to tell apart.

The empty divs have no role, so axe has nothing to check in the first map, and its colour contrast rule looks at text, not at what a fill colour means. axe does report the empty buttons of the second map, as button-name: each has no text and no name. It can't tell that a button is a seat, or that its classes say it is taken or chosen while its markup says nothing.

The audit looks for seats by their class names, seat and its common variants, in divs, spans and SVG shapes. A seat map where Tab reaches no seat, nor anything else in the map, is reported, and so is one whose seats can be reached but whose class says taken or chosen while the seat has no disabled, aria-disabled, checked, aria-pressed, aria-checked or aria-selected to say so. Every seat map that Tab reaches goes to review, so a person checks that each name gives the row and the number, and that the states show without colour, and so does a canvas whose id or class names it a seat map. A map drawn from shapes with no telling class names is not found, and no check can tell whether a seat's name makes sense to a listener.

Widely copied seat booking tutorials are built the first way, an empty div per seat and one click listener on the map. An AI assistant asked to make one accessible can change the divs to buttons and stop there, which is the second map, or give every seat the same name, such as aria-label="Seat".