Lifecycle / Accessibility

Accessibility

What was tested, how, and — the part usually left out — what has not been verified yet.

Status

AREASTATEHOW IT IS VERIFIED

Automated rule checksPassingaxe-core 4.13, 11 components × 5 states, in CI

LabellingPassingEvery component asserted to associate its label with a real control

Keyboard operationPassing9 tests covering every interactive element

Error announcementPassingaria-describedby + role=alert, and silence before first blur

Reduced motionPresentprefers-reduced-motion honoured in the stylesheet

Forced coloursPresentforced-colors block in the stylesheet

Colour contrastNot machine-checkedjsdom has no layout engine; needs a real browser

Screen readersNOT VERIFIEDNo NVDA, JAWS or VoiceOver run has been performed

The largest gap

Screen readers have not been tested. Automated tooling catches structural problems — a missing name, a broken role relationship — but it cannot tell you whether the experience is usable, and only the second question matters to somebody actually using the field.

Until that is done, the honest description of this library is structurally accessible, not yet screen-reader verified. It needs a human with a screen reader and there is no automated substitute.

Four real bugs the audit found

BUGCOMPONENTFIX

role="combobox" on a <textarea>MentionInputInvalid per ARIA 1.2. Removed; a polite live region announces the count

role="dialog" with no namePhoneInputIt is a filtered listbox, not a dialog. Role removed

Unnamed listboxPhone, Mentionaria-label added to both

<li> breaking listbox → optionPhone, MentionWrappers now carry role="presentation"

One of these was in a test, too

A test of mine had asserted the invalid combobox role. The test encoded the bug, so axe was right and the test was wrong; both were corrected. That is the argument for running a rule engine over something you already have tests for.

Target: WCAG 2.2 AA. The full audit, including the disabled-rule list and the reasons, is in ACCESSIBILITY.md in the repository.