Tree views keyboards can't open and screen readers flatten

An app's help centre has a sidebar of topics in three sections: Getting started, Billing and Account. Click a section and its pages unfold beneath it, indented, and its arrow turns down. Inside Billing, Payment methods is a section of its own, holding Cards and Bank transfer one level deeper. The sections are divs with click handlers. Put the mouse aside and press Tab: focus moves through the links that happen to be showing, Plans and prices and Invoices, then leaves the sidebar for Contact support. Getting started, Payment methods and Account can't be opened, so the pages inside them can't be reached. A screen reader hears the visible links one after another, with nothing to say they belong to Billing, and the section names as plain text with no sign that they open.

The team then makes it a tree the quick way: role="tree" on the sidebar, role="treeitem" on every section and link, and nothing else. For the keyboard, nothing changes: Tab still passes over every section. A screen reader now calls the sidebar a tree, but the arrow keys do nothing in it, every item is announced at level 1, "Invoices, tree item, level 1", and no section says whether it is open.

Success criterion 2.1.1 Keyboard asks that everything the mouse can do, the keyboard can do. Opening a section is done only by clicking a div, which takes no focus, so the pages inside a closed section can't be reached without a mouse. Adding the tree roles changes nothing here: the sections still take no focus, and the arrow keys a tree promises do nothing.

Success criterion 4.1.2 Name, Role, Value asks that controls expose their role and state. The div sections expose neither: no role that says they can be pressed, and no expanded or collapsed state. The tree's sections have the role but still no aria-expanded, so a screen reader can't tell an open section from a closed one, or a section from a page.

Success criterion 1.3.1 Info and Relationships asks that structure shown on screen is in the code. The indentation shows that Invoices belongs to Billing and that Cards is a level deeper. In the divs, nothing in the markup says so. With the tree roles, browsers work out each item's level from the nesting of group elements, and with none there, every item is level 1. The roles make the wrong structure official.

Help centres, documentation and account settings often put every page behind a sidebar like this, and a narrow screen usually moves the same sidebar into a menu, where the failure follows it. A section that can't be opened hides its pages 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 can't open a section built from a div, so every page inside a closed section is out of reach. Adding tree roles to the same divs changes nothing for them: the sections still take no focus, and the arrow keys do nothing.
• Without vision Screen reader users hear the pages as one flat run of links or tree items, all at level 1, with no word of which section each is in or whether a section is open, so they can't tell where they are or that closed sections hold more pages.

Divs with click handlers have no role, so axe has nothing to check in the first sidebar. The tree roles pass axe: every treeitem sits in a tree, and every one has a name. axe checks the shape of a tree's roles (a treeitem outside a tree or group is reported as aria-required-parent, and a tree with no items is sent for review under aria-required-children), never whether a key does anything or whether the levels match the indentation.

The audit presses the keys. In each tree whose items share one Tab stop, it focuses that item and presses the arrow keys; if focus never moves, the other items can't be reached, and that is reported. A section treeitem whose group is hidden but which has no aria-expanded is reported too. It sends to review a tree where more than one item is a Tab stop and the arrows do nothing, a tree with no group and no aria-level whose items are indented on screen, and a container named as a tree, built from divs, with clickable rows Tab never reaches. A div sidebar with no telling class names is not found, and no check can tell whether the levels make sense to a listener.

The second sidebar is what an AI fix can produce: it adds role="tree" and role="treeitem" to the existing divs and stops there, and the result passes axe. A fix can also put tabindex="0" on every row, or add aria-level but no aria-expanded.