Which controls on this page can an agent not name?
Load a URL in a real EU browser and get the interactive elements that have no accessible name, no role, or no way to be reached except by a script. A browser agent and a screen reader fail on the same elements, and this scan lists them.
Enter a page with forms or an app-like interface; the start page of a shop or a portal is a good first test.
This check opens a real browser on our servers and needs JavaScript in yours.
Observations, not verdicts. What you enter is processed for this result and written to a usage journal described in the privacy policy; nothing else is stored.
How the scan reads the page
-
Load and settle
A fresh browser opens the URL, rejects the consent banner and waits for the page to stop changing. What the agent sees is the same page tree the agent view shows.
-
Collect every control
Links, buttons, inputs, selects, and every element that is clickable for another reason: a role, a tabindex, or a script handler that the perception layer detected.
-
Ask each one three questions
Does it have an accessible name? Does it have a role a person or a machine can act on? Can it be reached without a script, or only through one?
-
Group the findings
Inputs without a label, buttons whose only content is an icon, clickable elements without a role, and controls that only respond to a script handler, each with the element's position and a snippet.
The four groups
Inputs without a name
A text field with no label element, no aria-label and no aria-labelledby has a placeholder at best. An agent asked to type an IBAN sees a field and guesses; a screen reader reads edit text and nothing else.
Icon-only buttons
A button whose content is an SVG or an icon font and nothing else has no name unless someone added one. The magnifier, the basket, the hamburger and the close cross are the usual suspects.
Clickable elements without a role
A div with an onclick is clickable for a mouse and invisible to everything else. The perception layer detects the handler, marks the element jsClickable, and this group is those elements minus the ones that also declare a role.
Script-only reachability
Elements the agent could only act on by evaluating script, because they are not focusable and not in the accessibility tree. An agent that reaches them anyway is doing something a person could not.
Why an agent and a screen reader fail on the same elements
A browser agent does not look at pixels first. It reads a tree: every element that can be acted on, with a role (button, link, textbox), a name (the text a person would use to refer to it) and a set of reasons why it counts as clickable. That tree is derived from the same accessibility information a screen reader consumes, plus signals a screen reader ignores, such as script handlers and pointer styles. An element that has a role and a name can be given as an instruction: press the button called Submit order. An element that has neither can only be described by position or by its markup, and both descriptions break the next time the page changes.
The same defects therefore hurt both audiences. An unlabeled input is a field the agent cannot be told to fill. An icon-only button is a control the agent can see but cannot be told to press. A clickable div without a role is invisible to the tree entirely, and the agent finds it only because the perception layer records the click handler as a signal and marks the element jsClickable with a reason.
What the scan reports
Each finding names the group, shows the element's tag, its outer markup trimmed to a line, its position on the page and, where the perception layer had a partial name, what it had. A page summary counts controls in total and per group, so two scans of the same page can be compared. The counts are facts about the page as it rendered for one visitor; they are not a score.
What it is not
This is not a WCAG audit and does not claim to be one. WCAG covers contrast, focus order, timing, motion, language and dozens of criteria this scan never looks at. It looks at one thing, whether interactive elements can be named and reached, because that one thing is what decides whether an agent can operate the page. Since 28 June 2025 the Barrierefreiheitsstärkungsgesetz (BFSG) has applied to a range of consumer-facing digital services in Germany, and the criteria it points to include the ones this scan touches; whether a page meets the law is a question for an accessibility professional working from the full criteria, not for a tool that checks four groups.
The scan does not judge intent either. A decorative icon inside a button that also has visually hidden text is fine, and the scan sees the hidden text. A button with a title attribute but no accessible name is listed, because a title is a tooltip, not a name.
A scan is a metered browser session of a dedicated organisation, capped per visitor and per day. The URL and the findings are returned to you and discarded; the usage journal keeps a timestamp and the size of the response, as the privacy policy describes.
Note · Observations from one page load, not an audit
The findings are what one EU browser saw on one visit with cookies rejected. A page that renders differently after login, on a phone, or after a delay can produce a different list. Nothing here is a statement about legal accessibility requirements.
Questions about agent legibility
What makes a page legible to an agent?
Controls that have a role and a name: a button called Add to basket, a textbox labelled Postcode. The agent can then be told what to do in words, and the instruction survives a redesign that moves the element.
Is this the same as an accessibility check?
It overlaps with one criterion of accessibility, that interactive elements have names and roles, and stops there. Contrast, keyboard order, motion and the rest are not covered.
Does it relate to the BFSG?
The BFSG, in force since 28 June 2025, requires accessibility of certain consumer-facing digital services and points to the European standard whose criteria include named, operable controls. This scan reports on those controls only and makes no statement about whether a page meets the law.
Why is a button listed that has a title attribute?
A title is shown as a tooltip and is not a reliable accessible name. Add visually hidden text or an aria-label and the button will have a name.
How do I fix a clickable div?
Make it a button, or give it role=button, tabindex=0 and a keyboard handler. The agent, the screen reader and the keyboard user all benefit from the same change.
Are the findings stored?
No. They are shown to you and dropped. The usage journal keeps the time and the size of the run.
Related tools and guides
Run an agent against the page and see where it stalls
Five browser hours, no card. Give the agent a task on the page you just scanned and watch the live view.