Elements Have Clear Names and Roles for Accessibility
What this criterion checks
This criterion maps to 4.1.2. Name, role, value (A). A detailed plain-language description is maintained in the WebLens criteria catalogue; the WCAG sub-test breakdown below describes exactly what the agent checks and what it does not.
How it's assessed
WebLens walks each user journey, captures a screenshot at every step, and an agent reasons over that evidence. See the how WebLens works for the full pipeline and the deterministic checks layered in for accessibility.
Sub-test coverage
4.1.2. Name, role, value (A) is broken into 5 sub-tests. Coverage is honest about where the agent is reliable, where it only partially checks the requirement, and where a human reviewer is still needed.
1 full2 partial2 not covered
- Name is programmatically determinableFull
Our tool comprehensively checks accessible names across UI components: buttons (button-name), image map areas (area-alt), form inputs (label), select elements (select-name), input-type buttons (input-button-name), ARIA command widgets (aria-command-name), ARIA input fields (aria-input-field-name), ARIA toggle widgets (aria-toggle-field-name), ARIA tooltips (aria-tooltip-name), frames (frame-title), and summary/details elements (summary-name). It also ensures frames have unique titles (frame-title-unique) and ARIA IDs are unique (duplicate-id-aria).
- Role is programmatically determinablePartial
Our tool validates that ARIA roles used are recognized valid roles (aria-roles), not deprecated (aria-deprecated-role), and that ARIA attributes are permitted for the element's role (aria-allowed-attr). It also detects nested interactive elements that cause role conflicts (nested-interactive). However, it cannot detect custom components (e.g., a div styled as a button) that are missing a role attribute entirely — it only validates roles that are present.
- States and properties are programmatically determinablePartial
Our tool checks that required ARIA attributes are present (aria-required-attr), attribute names are valid (aria-valid-attr), attribute values are correct (aria-valid-attr-value), conditional attributes are properly applied (aria-conditional-attr), prohibited attributes are not used (aria-prohibited-attr), and braille equivalents are correct (aria-braille-equivalent). However, it performs static analysis and cannot verify that states update correctly when users interact with components.
- Change notifications are available to assistive technologiesNot covered
Verifying that changes to component name, role, state, or value are communicated to assistive technologies in real time requires dynamic behavioral testing. Our tool does ensure the document body is not hidden from assistive technologies (aria-hidden-body) and that aria-hidden elements do not contain focusable content (aria-hidden-focus), which prevents notification delivery issues.
- Values can be programmatically setNot covered
Verifying that component values can be programmatically set by assistive technologies requires dynamic testing with actual assistive technology. Not automatable with static code analysis.
How reliable it is
This criterion agrees strongly with expert review, so you can rely on its findings and spot-check as you see fit. See Accuracy & confidence for how the confidence tags are set.