Repository navigation
Snapshot labels now come from a real accessible-name computation instead of a placeholder/value guess.
What changed
labelFor() follows the HTML-AAM chain:
aria-labelledbyaria-label- associated
<label>— bothfor=and encapsulation titleplaceholder
The value attribute names only input[type=submit|button|reset].
Before this, form controls with perfectly ordinary markup returned empty labels, so an agent could not tell one textbox from another:
| 0.4.0 | 0.4.1 | |
|---|---|---|
<label>Customer name: <input></label> |
"" |
"Customer name:" |
<label for=e><img alt="Email"></label><input id=e> |
"" |
"Email" |
<label>Search <input> <button>Go</button></label> |
button "Go" |
button "Go" |
Behavior change — check your callers
Radios and checkboxes now report visible label text instead of their value attribute:
0.4.0: {"role": "textbox", "label": "small"}
0.4.1: {"role": "textbox", "label": "Small"}
They previously looked like they were reading labels. They were reading internal values. Anything matching on "small" or "bacon" needs to match "Small" or "Bacon".
Not included
Recursive ACCNAME computation, form-associated custom elements, and non-spec heuristics for names carried in preceding text or table cells. Tracked separately.
Form-associated custom elements are specifically blocked rather than unfinished: content scripts run in Chrome's isolated world and cannot see a custom-element registry the page defined in its main world. Closing it needs a main-world injection decision.
Install
npm install -g chrome-browser-control
npx -y chrome-browser-control setupPublishing is manual. This project holds no CI publish credentials.