The search widget renders two accessibility defects that axe-core reports. Both
are inside the widget's shadow root, so a site cannot fix them in a template.
Found with zensical==0.0.53 (modern theme), audited by Lighthouse 12.6.1 with
axe-core 4.13.0.
1. The search input claims role="combobox" without the required attributes
The input is constructed with role="combobox", but no aria-expanded and no
aria-controls:
N("input", { ..., placeholder: "Search", spellcheck: false, role: "combobox", dir: "auto" })
axe-core reports aria-required-attr:
Required ARIA attributes not present: aria-expanded, aria-controls
There is also no role="listbox" on the results container, no role="option"
on the results, and no aria-activedescendant, so the combobox contract is not
implemented anywhere in the widget. A screen reader announces a combobox whose
advertised expanded state never arrives.
The widget does implement arrow-key navigation over results, so completing the
contract looks like the right fix rather than dropping the role: mark the
results container as a listbox, mark each result as an option, and keep
aria-expanded / aria-activedescendant in sync as the user types.
2. The icon-only buttons have no accessible name
Both buttons beside the input render an icon and nothing else:
- the
lucide-search button
- the
lucide-list-filter button
axe-core reports button-name:
Element does not have inner text that is visible to screen readers;
aria-label attribute does not exist or is empty
They are announced only as "button", so neither is distinguishable by a screen
reader.
Impact
On a docs site gated on a Lighthouse accessibility budget, these two audits cost
20 weighted points and can push a page below a passing threshold. More
importantly, the search box is not usable with a screen reader as it stands.
Reproduction
- Build any site with the modern theme and open a page.
- Open search.
- Run axe-core (or Lighthouse's accessibility category) against the page.
aria-required-attr and button-name both fail, with the offending nodes
inside the widget's shadow root.
The search widget renders two accessibility defects that axe-core reports. Both
are inside the widget's shadow root, so a site cannot fix them in a template.
Found with
zensical==0.0.53(modern theme), audited by Lighthouse 12.6.1 withaxe-core 4.13.0.
1. The search input claims
role="combobox"without the required attributesThe input is constructed with
role="combobox", but noaria-expandedand noaria-controls:axe-core reports
aria-required-attr:There is also no
role="listbox"on the results container, norole="option"on the results, and no
aria-activedescendant, so the combobox contract is notimplemented anywhere in the widget. A screen reader announces a combobox whose
advertised expanded state never arrives.
The widget does implement arrow-key navigation over results, so completing the
contract looks like the right fix rather than dropping the role: mark the
results container as a listbox, mark each result as an option, and keep
aria-expanded/aria-activedescendantin sync as the user types.2. The icon-only buttons have no accessible name
Both buttons beside the input render an icon and nothing else:
lucide-searchbuttonlucide-list-filterbuttonaxe-core reports
button-name:They are announced only as "button", so neither is distinguishable by a screen
reader.
Impact
On a docs site gated on a Lighthouse accessibility budget, these two audits cost
20 weighted points and can push a page below a passing threshold. More
importantly, the search box is not usable with a screen reader as it stands.
Reproduction
aria-required-attrandbutton-nameboth fail, with the offending nodesinside the widget's shadow root.