Expandable table rows a keyboard can't open

A team's project tracker lists its tasks in a table with three columns, Task, Assignee and Due, and a header row of th cells, so the table itself is sound. A task with subtasks has an arrow before its name: click the arrow and its subtasks unfold under it, indented, and the arrow turns down. Each task's name is a link to its page. Launch the spring catalogue is open, Renew the domain has no subtasks, and Plan the summer sale is closed. The arrow is an empty span drawn by CSS, with a click handler. Put the mouse aside and press Tab: focus moves from one task link to the next, the subtasks that happen to be showing included, then leaves the table for Completed tasks. Plan the summer sale can't be opened, so Book the newsletter slot can't be reached. A screen reader reads the visible rows as rows of a table, with nothing to say that a task opens, whether it is open, or that Write product copy is a subtask of the task above it.

This is how the DataTables plugin's own example of rows that open is written: the click handler is on a table cell, with no tabindex and no key handling. The team then makes it a tree grid the quick way: role="treegrid" on the table, and nothing else. For the keyboard, nothing changes: Tab still passes every arrow. A screen reader now calls the table a tree grid, but the arrow keys do nothing in it, no row says what level it is at, and no task says whether it is open.

Success criterion 2.1.1 Keyboard asks that everything the mouse can do, the keyboard can do. A task is opened only by clicking a span, which takes no focus, and the browser turns Enter and Space into a click only on a native control. The subtasks of a closed task can't be reached without a mouse. role="treegrid" changes nothing here: the arrows still take no focus, and the arrow keys that a tree grid promises do nothing.

Success criterion 4.1.2 Name, Role, Value asks that every control's name, role and state can be determined by software. The arrow is a control: a click on it opens the task. As an empty span it has no role, no name and no expanded or collapsed state, so a screen reader can't tell that a task opens, or an open task from a closed one. W3C documents this as failure F59, script that makes a span or div a control without giving it a role, and more broadly as failure F15, a custom control that doesn't use the accessibility API, or uses it only in part.

Success criterion 1.3.1 Info and Relationships asks that structure shown on screen is in the code. The indentation shows that Write product copy belongs to Launch the spring catalogue. In the table, nothing in the markup says so: every row is a row like any other, and the nesting is padding. A tree grid's rows have no group elements to nest in, so their levels come only from aria-level; with none, the role adds a grid of rows and still leaves out which task a subtask belongs to.

Tables whose rows open sit behind project and task trackers, order histories whose orders open into their parcels, budgets whose categories open into their lines, and file lists whose folders open into their files. The rows under a task are often the only way to reach them, and a row that can't be opened hides them from anyone who can't click it.

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 Keyboard and switch users never land on the arrow, so a closed task's subtasks are out of reach. Adding role="treegrid" to the table changes nothing for them: the arrows still take no focus, and the arrow keys do nothing.
• Without vision Screen reader users hear the task names that happen to be showing, with nothing to say that a task opens, whether it is open, or that the rows under it are its subtasks rather than tasks of their own.

axe has nothing to check in the first table: a span with a click handler has no role, so no rule asks it for a name or a state, and the table's headers are sound. role="treegrid" on the same table passes axe's WCAG rules too: every row sits in the tree grid and every cell in a row. axe checks the shape of the roles (a row outside any table or grid is reported as aria-required-parent, and a treegrid with no rows as aria-required-children), never whether a key does anything or whether a row says its level.

The audit presses Tab through the page. An arrow in a table cell that opens a row, found by its class name (such as toggle, expander or DataTables' dt-control) and its pointer cursor, that Tab never reaches is reported, the cell itself included when the cell carries the class, as in DataTables. In each tree grid whose rows share one Tab stop, it focuses that stop and presses Down, Up, Right, End and Home; if focus never moves, the other rows can't be reached, and that is reported, as is a tree grid in which nothing takes focus at all. A row with aria-level whose next row is a level deeper and hidden, but which has no aria-expanded, is reported too. It sends to review a tree grid where several links are Tab stops and the arrows do nothing, which is the second table. An arrow with no telling class name is not found, and no check can tell whether the levels make sense to a listener.

The second table is what an AI fix can produce: it adds role="treegrid" and stops there. A fix can also give the span role="button" and tabindex="0", which Tab then reaches, but Enter and Space still do nothing, as div buttons that can't be reached with Tab shows.