For teams working on accessibility
Find the buttons and links a screen reader cannot name
List every control on the rendered page with the name a screen reader would announce, and find the ones that have none.
The problem
An icon-only button with no label is announced as "button" and nothing more. It looks fine to every sighted reviewer, passes visual tests, and turns up in exactly the components that get reused most: close buttons, menu toggles, social links.
How domscout handles it
semanticNodes: true returns interactiveNodes, every interactive element on the rendered page with its role and the name assistive technology would announce, resolved the way a screen reader resolves it: visible text, then aria-label, aria-labelledby, value, title, placeholder and alt. nameSource says which one supplied the name, and an element with empty text and a nameSource of null has no accessible name at all. This is one check, not an audit: it does not test colour contrast, keyboard order or anything a person has to judge.
Where it shows up
- A CI check that no unlabelled controls ship on key pages.
- A sweep of a component library's demo pages.
- A list of fixes for the team that owns each template.
The request
POST /screenshot. Available on every plan, including the free Hobby plan, at 1 credit a page. To check focus styling as well, forceState can hold an element in its focus state for the screenshot.
Go further
More in Testing and QA: Responsive layout checks · Visual regression testing · JavaScript error checks · Signup and checkout flow checks · Hover, focus and dark mode screenshots · Localization screenshots · A screenshot of every step · Embedded widget checks · Screenshots for support tickets · Ad landing page checks · Before and after hydration · Selectors for test automation · Print layout checks · All use cases
Give your product a browser.
Get clean web content and visual proof into your workflow in minutes.