Free tool · Runs in your browser
What will a screen reader, or an AI agent, call this?
Paste HTML and see the accessible name and role of every control, computed the way browsers do it and shown the way a browser-use agent receives it. Unnamed buttons, image links without alt text and fields without labels are the failures screen reader users hit first, and since agents read the same tree, they are the failures that make a site unusable by automation too.
Rendered in a sandboxed frame with scripts disabled. Nothing leaves your browser.
The agent view
(run to see the tree)
This is the shape of the accessibility tree a browser-use agent is given: role, then name. A line that reads only button is a control the agent cannot tell apart from any other unnamed button, and a screen reader announces the same way.
Paste markup, or pick an example, then run.
| # | Element | Role | Accessible name | Name comes from | Description |
|---|---|---|---|---|---|
| Nothing to show yet. | |||||
Why the name is the whole thing
Every control on a page reaches assistive technology as a role and a name. The role says what it is (button, link, checkbox); the name says which one. Sighted users get the name from a label, an icon or its position. Everyone and everything else gets it from the accessibility tree, and if the tree has no name for it, there is nothing to announce and nothing for an agent to target.
This is why missing names are what litigation turns on. The complaint in Robles v. Domino's pleaded buttons with no accessible name; the plaintiff in Gil v. Winn-Dixie testified that nine in ten controls did nothing for his screen reader; the Target site read out file names because its images had no alt text. WebAIM's 2026 evaluation found empty links on 46.3% of the top million home pages and empty buttons on 30.6%.
Browser-use agents changed the audience for this without changing the fix. Anthropic's browser tool, OpenAI's computer-using agent and Google's Mariner all ground their actions in the accessibility tree, the same names and roles a screen reader uses. A site that cannot be used by a blind customer cannot be used by an agent acting for a sighted one.
How to give a control a name
| Control | What fails | Fix |
|---|---|---|
| Icon-only button | SVG or icon font with no text | Visible text, or aria-label on the button, with the icon aria-hidden |
| Image link | img without alt inside a link | alt text that names the destination, not the picture |
| Form field | placeholder used as the label | A label element, visible, associated by for and id |
| Custom control | div or span with a click handler | A button element, or role plus tabindex plus keyboard handling |
| Repeated links | Several links that all say Read more | Make the visible text specific, or add aria-label with the subject |
| Embedded frame | iframe with no title | A title attribute that says what the frame contains |
The relevant criteria are 4.1.2 Name, Role, Value, 1.1.1 Non-text Content, 2.4.4 Link Purpose and 3.3.2 Labels or Instructions, all Level A. For the full rules see the guide to using ARIA.
Frequently Asked Questions
What is an accessible name?
The text assistive technology uses to identify an element: what a screen reader announces for a button, link or field, and what an AI agent reads in the accessibility tree. It is computed from the markup by the W3C accessible name algorithm, in a fixed order: aria-labelledby, then aria-label, then native sources such as a label element, alt text or the control's own text, then the title attribute.
Why does an AI agent care about accessible names?
Browser-use agents from Anthropic, OpenAI and Google operate pages through the accessibility tree rather than the pixels. Each control reaches the agent as a role and a name. A button with no name arrives as just 'button', indistinguishable from every other unnamed button on the page, so the agent cannot reliably act on it. The same failure is why a screen reader user cannot use it.
Which WCAG criteria does this relate to?
4.1.2 Name, Role, Value requires that user interface components expose a name and role. 1.1.1 Non-text Content requires text alternatives for images, which become link and button names when an image is the only content. 2.4.4 Link Purpose requires link text that makes the purpose clear. 3.3.2 Labels or Instructions requires labels for form fields. Missing names are among the five most common failures in WebAIM's annual evaluation of a million home pages.
Is this the same as what a screen reader says?
It is the name part. A screen reader adds the role and state in its own words, for example 'Add to basket, button', and different screen readers phrase things differently. This tool uses dom-accessibility-api, the accname implementation used by Testing Library and jsdom, so the names match what those tools and most browsers compute. Always confirm important flows with a real screen reader.
Why does a div with onclick show as not in the tree?
A div has no role, so it is not exposed as a control at all. A screen reader user cannot tab to it and an agent does not see it as something that can be pressed. Use a button element, or add role="button", tabindex="0" and keyboard handling.
Essential Accessibility Resources
Comprehensive tools, checklists, and guides to help you create inclusive digital experiences