Start here
Before You Fix It: What This Check Means
Accessible names let assistive technology describe control purpose instead of generic roles. In plain terms, this tells you whether people using keyboards or assistive tech can use the page reliably. Scavo scans interactive controls in the HTML snapshot, including.
Why this matters in practice: issues here can block completion for assistive-tech users and create compliance exposure.
How to use this result: treat this as directional evidence, not final truth. Automated checks do not replace complete manual assistive-technology validation. First, confirm the issue in live output: verify with keyboard flow and at least one assistive-technology pass Then ship one controlled change: Enforce an accessible-name requirement in your shared button/link/form components. Finally, re-scan the same URL to confirm the result improves.
Background sources
TL;DR: Buttons, links, and form controls lack accessible names, leaving screen reader users unable to understand what elements do.
When interactive elements don't have accessible labels, screen readers announce them as "button" or "link" with no context — forcing blind users to guess what each control does. Notable accessibility settlements include Bashin's $2M settlement and accessiBe's $1M FTC settlement (Accessibility.Works, 2024). Proper ARIA labels are foundational accessibility requirements under WCAG 2.1.
What Scavo checks (plain English)
Scavo scans interactive controls in the HTML snapshot, including:
- Links (
<a href>) - Buttons
- Non-hidden form controls (
input,select,textarea) - Common ARIA widget roles (
button,link,menuitem,tab,switch,checkbox,radio,combobox,option)
For each visible control, Scavo looks for an accessible name signal in this order:
aria-labelaria-labelledbywith resolvable texttitle- Associated
<label>(for form controls) - Non-empty visible text content
How Scavo scores this check
Result behavior:
- Pass: all sampled controls have names
- Warning: some controls unlabeled, but below fail threshold
- Fail: 3+ unlabeled controls, or unlabeled ratio >= 25%
- Info: no interactive controls found
In your scan report, this appears under What failed / What needs attention / What is working for aria_labels, followed by Recommended next steps and Technical evidence (for developers) when needed.
- Scan key:
aria_labels - Category:
ACCESSIBILITY
Why fixing this matters
When labels are missing, keyboard and screen reader users cannot reliably complete navigation or conversion flows. This creates drop-off in forms, checkout/account actions, and trust.
For teams, unlabeled controls are also a regression signal: icon-only UI updates often ship quickly and silently remove text equivalents unless labeling is enforced in component standards.
Common reasons this check fails
- Icon-only buttons without
aria-label. - Custom role-based widgets without accessible names.
aria-labelledbypoints to missing/empty IDs.- Controls rely on visuals only (no machine-readable label).
If you are not technical
- Ask for a short video proof using a screen reader quick pass on key pages.
- Prioritize fixes on nav, search, login/signup, checkout, and form actions first.
- Require component-level standards so new controls inherit good labeling.
- Re-run Scavo and confirm unlabeled count drops.
Technical handoff message
Copy and share this with your developer.
Scavo flagged ARIA Labels (aria_labels). Please ensure every visible interactive control exposes a valid accessible name (aria-label, aria-labelledby, or equivalent semantic text/label), and share before/after evidence on key flows.If you are technical
- Enforce an accessible-name requirement in your shared button/link/form components.
- Add
aria-labelfor icon-only controls. - Validate
aria-labelledbyreferences resolve to meaningful visible text. - Avoid role-only custom controls without naming semantics.
- Add automated tests for unlabeled interactive elements on core templates.
How to verify
- Inspect rendered HTML for control naming signals.
- Use browser accessibility tree tools to confirm computed names.
- Run keyboard + screen reader smoke tests on primary flows.
- Re-run Scavo and verify unlabeled ratio and count decrease.
What this scan cannot confirm
- It does not assess full interaction behavior (focus order, state announcements, keyboard traps).
- It does not replace manual assistive-technology testing.
- It evaluates a page snapshot, not every dynamic state.
Owner checklist
- [ ] Assign accessibility owner for interactive component standards.
- [ ] Add CI checks for unlabeled buttons/links/widgets.
- [ ] Include screen-reader smoke test in release QA for key journeys.
- [ ] Re-audit after design-system component refactors.
FAQ
Is visible button text always enough?
Usually yes for native controls, but icon-only controls and custom widgets still need explicit accessible naming.
Should we use title as the main label?
Prefer semantic labels or aria-label/aria-labelledby. title is less reliable as a primary naming strategy.
Can too many ARIA labels cause problems?
Yes if they conflict with visible names. Keep one clear naming source per control.
What should we fix first?
Start with unlabeled controls on high-impact pages and primary conversion actions.
Sources
- W3C APG: Names and descriptions
- WCAG 2.2: Label in Name (2.5.3)
- WCAG 2.2: Name, Role, Value (4.1.2)
- MDN:
aria-label
Need a component checklist your designers and developers can both use? Send support your control library list.
