Skip to content

v0.4.1 — accessible-name snapshot labels

Latest

Choose a tag to compare

@vKongv vKongv released this 14 Sep 18:34
· 5 commits to main since this release
70d4d87

Snapshot labels now come from a real accessible-name computation instead of a placeholder/value guess.

What changed

labelFor() follows the HTML-AAM chain:

  1. aria-labelledby
  2. aria-label
  3. associated <label> — both for= and encapsulation
  4. title
  5. placeholder

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 setup

Publishing is manual. This project holds no CI publish credentials.