References — HTML as an Application Platform

Specifications

• WHATWG HTML Standard — the source. Particularly §4.10 Forms, constraint validation, and the dirty value flag (search that term — it explains experiment 3's trap).
• WHATWG HTML — dialog — modality, top layer, focus behaviour.
• HTML — Popover API
• WAI-ARIA 1.2 and ARIA in HTML — which ARIA is allowed on which element.
• Accessible Name and Description Computation — how the name column in experiment 1 is derived.
• HTML AAM — the normative HTML-element → accessibility-API mapping.

Practice

• ARIA Authoring Practices Guide — patterns for controls with no native equivalent. Read the keyboard interaction sections before committing to a custom control; that list is what you are agreeing to own.
• The First Rule of ARIA Use
• MDN — Client-side form validation
• MDN — ValidityState
• Adrian Roselli, Under-Engineered series — restyling native controls instead of replacing them; unusually rigorous and tested with real AT.
• Scott O'Hara, component write-ups — especially <dialog> and disclosure widgets, including where native still falls short.
• Inclusive Components — Heydon Pickering; the reasoning behind each pattern.

Tooling

• Chrome DevTools — Accessibility features — the Accessibility pane and full-page tree.
• CDP — Accessibility domain — getFullAXTree, used by experiment 1.
• NVDA (free, Windows) · VoiceOver (built into macOS, ⌘F5)
• axe-core — useful as a regression guard; see docs/observation.md on its limits.

Deliberately excluded

Component libraries presented as accessibility solutions. Some are excellent, but adopting one does not transfer understanding, and this module's point is that the element choice is the decision. Evaluate libraries with the behaviour table from experiment 2 — several popular ones fail rows a native <dialog> passes.