In one paragraph
ARIA attributes must be used as specified for the element's role means a conditional constraint failed, not merely that an attribute was misspelled. Review the actual native state, effective role, and surrounding structure. Remove redundant conflicting ARIA or implement the correct complete widget. Do not change an ordinary table into a treegrid solely to make a few hierarchy attributes pass.
Why it matters
Native form controls already expose useful state. A checkbox's current checked property and indeterminate state should remain aligned with its visible and submitted behaviour. Redundant aria-checked can create contradictory declarations instead of improving access.
Rows also depend on context. Hierarchy and expand-collapse semantics can require a suitable structured widget rather than an ordinary data table. Adding a treegrid role imposes a broader contract, including appropriate interaction and relationships; it is not a cosmetic workaround.
This conditional check differs from tests of attribute spelling, value type, or general role compatibility. An attribute can be a recognised name with a valid token yet still be wrong in the particular native or structural context.
How WebAuditOS evaluates this finding
The supplied aria-conditional-attr implementation describes three main cases: certain hierarchy attributes on rows outside its accepted treegrid context, inconsistent aria-checked on native checkboxes, and inconsistent aria-checked on native radios.
Serious impact maps to high severity. Its rendered snapshot does not activate every control, so a state that becomes inconsistent only after interaction can be missed. Exact conditions depend on the deployed axe version and supported ARIA model; absence here does not validate every conditional restriction.
How to fix it
- Inspect the flagged element's native type, computed role, current DOM properties, and ancestor structure. For a checkbox, distinguish initial checked markup from the current checked property after user input.
- Prefer native state where a native control already supplies it. For example:
<label><input type="checkbox" name="updates"> Receive product updates</label>This fragment does not need redundant aria-checked to announce ordinary native checked state. Implement any additional real behaviour separately.
- For an indeterminate native checkbox, manage the supported native property and the actual selection model correctly. Do not use an unrelated ARIA string to conceal a mismatch between visual, programmatic, and submitted state.
- Keep custom widgets distinct. A role=checkbox control built without native semantics has its own state and keyboard responsibilities. Removing its required aria-checked simply because native inputs do not need it would create another failure.
- Review row attributes in the real table or grid. Remove accidental hierarchy declarations when the content has no such function. If a genuine hierarchical interactive table is required, implement and test the full treegrid pattern rather than changing one container role.
- Fix the library or shared component producing the conflict. Search for a duplicated state source, default prop, or renderer that writes attributes irrespective of context.
- Test initial, toggled, mixed, reset, loading, and disabled states as applicable. Confirm what the user sees, what assistive technology receives, and what the application actually does.
- Rescan and review neighbouring name, value, and compatibility checks. A conditional fix can reveal another issue that was previously obscured by conflicting semantics.
What the fix can break
Removing redundant ARIA can affect scripts or tests that incorrectly used it as the application's source of truth. Migrate those dependencies to a deliberate state model.
Changing a table role alters interaction expectations. A keyboard user should not receive a rich-widget announcement for ordinary static cells with no corresponding behaviour.
Do not assume a quiet scan means state remains correct after a click. Add functional tests at the component transitions that update accessibility properties.
Questions
Should a native checkbox normally need aria-checked?
No. Prefer its native checked and indeterminate mechanisms and avoid conflicting duplicate state.
Should I convert every expandable row to treegrid?
Not automatically. Select the complete appropriate pattern for the task and verify its requirements, not just one allowed attribute.
Does this rule validate attribute spelling too?
That is covered by separate checks. Conditional validity is another layer of evaluation.
Which related checks help?
Review supported attributes, permitted attributes, and the automation limits guide.
What severity does this get in the report?
High. An axe finding takes its severity from the impact axe reports for the element that failed, and the report maps critical and serious to high, moderate to medium, minor to low. axe declares this rule serious, so a failure arrives as high. The panel above shows a conformance level because for axe rules severity comes from the scan.