Part 0 · 2 chapters · ~20 min

Accessibility in Depth: The Tree and the Standard

The accessibility tree the browser derives from the DOM (roles, the accessible name computation, states and properties, what ARIA cannot do, how to inspect it), and WCAG as four principles, thirteen guidelines and levels, with the laws that point at AA and the criteria products fail most.

1

The accessibility tree

what assistive technology actually reads
  1. The derivation: from the DOM, CSS and ARIA the browser computes, per element, whether it is in the tree (not display: none, visibility: hidden, aria-hidden or inert), its role, its name, description, value, states and properties, and its position. Generic containers with no role are omitted or flattened. Assistive technology walks this tree, not the DOM.
  2. The accessible name computation, in order: aria-labelledby, aria-label, the native label (a label element, an image's alt, a table's caption, a button's or link's text), the title attribute last. The first that yields text wins; an icon button with none has no name and is announced as "button". The name is what the screen reader says.
  3. Roles: native elements carry implicit roles and bring keyboard behaviour and states with them; ARIA roles override or add structure (tablist, tab, tabpanel, dialog, alert) and bring only the role. The first rule of ARIA: a native element before a role on a div.
  4. States and properties: aria-expanded, aria-selected, aria-checked, aria-disabled (still focusable, unlike the attribute), aria-invalid with aria-describedby to the error, aria-current, aria-live, aria-controls, aria-haspopup, aria-activedescendant. Facts the tree carries and the component must keep true (the Design course part 2's primitives); a stale state is a lie.
  5. What ARIA cannot do: add behaviour (role="button" on a div gives no Enter, no Space, no focus), fix missing structure (a table of divs needs every row and cell role), hide the visual, or make bad markup good by decoration. Every interactive element has a name; native semantics are not changed without need.
  6. Inspecting it: the DevTools Accessibility pane (role, name and its source, states) and the full-page tree view (the DevTools course part 1); axe and Lighthouse check it mechanically (part 5). Reading the tree for a widget is its first accessibility test, before any screen reader.
THE ACCESSIBILITY TREE
what the browser derives from the DOM, what assistive technology reads, and how ARIA edits it
swipe the figure sideways, or tap expand for full screen
1/6
the derivation
The derivation: for each DOM element the browser computes whether it is in the tree (not display: none, not visibility: hidden, not aria-hidden, not an inert subtree), its role (from the element: button → button, h2 → heading level 2, a with href → link, input type=checkbox → checkbox; or from an explicit role attribute), its name (the accessible name computation), its description, its value, its states and properties (from attributes and DOM state), and its position among siblings. Generic containers (div, span) with no role are omitted or flattened.
2

WCAG: structure, principles, levels, law

the standard and what it requires
  1. Perceivable: text alternatives (1.1), media alternatives (1.2), adaptable structure and reading order (1.3), distinguishable (1.4: contrast 4.5:1 and 3:1, resize to 200%, reflow at 320px, text spacing, no audio autoplay). Does the content reach the senses it can?
  2. Operable: keyboard for everything with no traps (2.1), enough time (2.2), no flashing over three a second (2.3), navigable (2.4: skip links, titles, focus order, focus visible and not obscured), input modalities (2.5: pointer alternatives, 24×24 targets at AA in 2.2, label in name). Can the user drive it?
  3. Understandable and robust: language declared (3.1), predictable (3.2: no context change on focus or input), input assistance (3.3: errors identified and described, labels, and error prevention for legal and financial actions: the Trust course's review step is criterion 3.3.4), compatible (4.1: valid name, role and value; status messages announced).
  4. Levels: A is the floor; AA the standard target and the gate; AAA specialised and per feature. Conformance is all-or-nothing per level per page; a claim lists the level, the pages and the technologies relied on.
  5. The law: the ADA (through the courts) and Section 508 in the US; the European Accessibility Act, in force for banking and e-commerce among others, via EN 301 549 (WCAG 2.1 AA plus); the Equality Act in the UK; local regulators for finance. For a fintech AA is a requirement; the Trust course's surfaces are where suits land.
  6. What products fail most: contrast, missing names, keyboard reach and traps, focus not visible, unlabelled forms and unassociated errors, images without alternatives, no skip link and wrong headings, undeclared language, unannounced status messages. Each mechanically checkable (part 5) except keyboard and screen-reader behaviour, which need a human.
the exercise
Open the DevTools Accessibility pane on your product's main action and read its role, name and name source. Then Tab to it from the top of the page and count the stops; the number and the name are the first two audit findings or the first two passes.
WCAG: STRUCTURE, PRINCIPLES, LEVELS, LAW
perceivable, operable, understandable, robust; the success criteria; A, AA, AAA; and what is required where
swipe the figure sideways, or tap expand for full screen
1/6
perceivable
Perceivable: text alternatives for non-text content (1.1); captions and alternatives for media (1.2); content that can be presented in different ways without losing structure (1.3: semantic markup, reading order, orientation, input purpose); distinguishable (1.4: contrast, resize to 200%, reflow at 320px, text spacing, no audio autoplay). The criteria about whether content reaches the senses it can.