fw-12 — Analysis
Why three subjects are one module
Testing libraries, browser automation, and devtools are all instrumentation: making a running system observable, from three angles. Building small versions teaches what your tools actually do, which is what lets you diagnose them when they lie.
Required invariants
- A query by role must reflect what assistive technology computes, not what the DOM contains.
- Synthetic events are not user input and must never be presented as equivalent.
- An observability layer must not perturb what it measures.
Accessible name computation is an algorithm
Precedence, roughly: aria-labelledby → aria-label → native labelling (<label for>, wrapping
label, alt, <caption>, <legend>) → subtree text if the role permits name-from-content →
title.
Consequences that matter in real code:
aria-labelledbybeats visible text, so an element can display "Submit" and be announced as something else. Visual review never catches this.- Name-from-content depends on role, which is why
<div onclick>is invisible to a role query. - The algorithm recurses, and whitespace normalisation matters — naive comparison makes tests flaky.
The table that changes test strategy
dispatchEvent(new MouseEvent('click')) | Real input / CDP | |
|---|---|---|
isTrusted | false | true |
| Hit testing | skipped | performed |
| Compositor | not involved | involved |
| User activation | not granted | granted |
A synthetic click on an element covered by an overlay still fires. Your test passes; the user cannot click the button. This is the single most valuable fact about testing tools, and it is why CDP-driven tests catch a class of bug that jsdom-based tests structurally cannot.
APIs gated on user activation — fullscreen, clipboard write, autoplay with sound — reject synthetic events by design.
The strategy consequence: a component test with synthetic events verifies handler logic. It does not verify the element is reachable, visible, unobstructed, or activatable. Knowing which question each layer answers is test-strategy design; "we have 90% coverage" tells you nothing about which.
DevTools is a protocol client
Not privileged internals — a web application speaking CDP. Therefore: remote debugging works; automation uses the same protocol; anything DevTools shows you, you can obtain programmatically.
That last point is underused. Traces, coverage, heap snapshots, accessibility trees, and layer counts are all scriptable. Most teams look at these manually once and never again; wiring the important ones into CI is the Principal-level move.