Skip to content
Back to Blog
TechnicalAccessibilityHTML

ARIA labels aren't just for screen readers anymore

Agent Checker4 min read

ARIA was designed for screen readers. That was the original purpose, and it still serves that role well. But AI agents have quietly become one of the biggest consumers of ARIA attributes, and the way they use them changes how you should think about your markup.

How agents use ARIA attributes

When an AI agent needs to click a button, fill in a form, or understand what a section of the page does, it builds an accessibility tree from your HTML. The way you structure your HTML for agents determines the quality of that tree, and ARIA attributes are a major input.

An agent looking at a page sees something like this:

button "Submit Order" [aria-label="Submit Order"]
textbox "Email address" [aria-required="true"]
navigation "Main menu" [aria-label="Main menu"]
region "Search results" [aria-live="polite"]

Without ARIA labels, that same page might look like:

button ""
textbox ""
navigation ""
region ""

The agent cannot reliably interact with unlabelled elements. It might try to match by position or visual text, but that is fragile and slow.

The attributes that matter most

Not all ARIA attributes carry equal weight for agents. Focus on these:

aria-label: The most important one. It gives elements a human-readable name that agents can reference directly.

<!-- Bad: agent sees an unlabelled button -->
<button><svg>...</svg></button>

<!-- Good: agent knows exactly what this does -->
<button aria-label="Close dialogue"><svg>...</svg></button>

aria-describedby: Provides additional context. Agents use this when they need more information than the label gives.

<input type="password" aria-describedby="pw-help" />
<span id="pw-help">Must be at least 8 characters with one number</span>

aria-required: Tells agents which fields are mandatory. Without it, an agent might skip a required field and trigger a validation error.

aria-expanded and aria-haspopup: These tell agents about interactive state. A menu that is collapsed needs to be expanded before its items are accessible. Agents check these attributes to understand the current state.

role: While technically a separate spec, roles work closely with ARIA. Setting role="search" on a form tells the agent this is the search function, not a login form or newsletter signup.

Common mistakes that confuse agents

Duplicate labels. If you have three buttons all labelled "Submit", an agent cannot distinguish them. Be specific: "Submit order", "Submit review", "Submit enquiry".

Labels that do not match visible text. If a button displays "Buy now" but has aria-label="Add to cart", the agent may report the wrong action to the user. Keep labels consistent with what is displayed.

Missing labels on icon buttons. This is the most common problem we see. Icon-only buttons for search, menu, close, and settings are everywhere, and most lack any aria-label. An agent sees an anonymous clickable element and has to guess.

<!-- Before: agent has no idea what these do -->
<button class="icon-btn"><i class="fa-search"></i></button>
<button class="icon-btn"><i class="fa-bars"></i></button>
<button class="icon-btn"><i class="fa-times"></i></button>

<!-- After: clear purpose for each -->
<button class="icon-btn" aria-label="Search"><i class="fa-search"></i></button>
<button class="icon-btn" aria-label="Open menu"><i class="fa-bars"></i></button>
<button class="icon-btn" aria-label="Close"><i class="fa-times"></i></button>

Overusing aria-hidden="true". This attribute hides elements from the accessibility tree entirely. If you hide important interactive elements, agents simply cannot see them. Only use aria-hidden on truly decorative content.

Practical implementation checklist

Run through your site with these checks:

  1. Every <button> without visible text has an aria-label
  2. Every <input> has an associated <label> or aria-label
  3. Navigation landmarks use aria-label to distinguish them (main nav vs footer nav vs sidebar nav)
  4. Dynamic content areas use aria-live regions so agents know when content updates
  5. Expandable sections use aria-expanded to communicate state
  6. No meaningful content is hidden with aria-hidden="true"

The payoff is double

The good news is that fixing ARIA for agents simultaneously improves accessibility for screen reader users. This is the essence of progressive enhancement for humans and agents: you are doing one job that satisfies two audiences. Sites that score well on agent accessibility audits almost always score well on accessibility audits too.

ARIA is no longer a niche concern for accessibility specialists. It is infrastructure that AI agents depend on to interact with your site. Treat it with the same priority you give to responsive design or performance.