In one paragraph
Required ARIA attributes must be provided means a tested explicit role lacks a state or property the engine expects. Use native semantics where they already provide the information, and supply required author-managed properties for genuine custom widgets. Keep every value aligned with real behaviour. A non-empty attribute can pass presence validation while remaining invalid, misleading, or inconsistent with the user's actual selection.
Why it matters
Some widgets depend on declared state. A custom checkbox needs an appropriate checked state, and a custom heading needs a meaningful level when native markup does not already provide it. A role without its supporting model can leave users with incomplete information.
Native elements can supply semantics and state without redundant ARIA. Adding a duplicate declaration can create a conflict if one source changes and the other does not. Prefer one coherent implementation rather than copying every property into every component.
Requirement lists, default values, and exceptions are role-specific and can evolve. A checker exception is not a universal permission to omit a property required by the actual specification or pattern. Separate presence, value validity, conditional compatibility, and truthful behaviour.
How WebAuditOS evaluates this finding
The supplied aria-required-attr rule inspects applicable explicit roles and counts the required properties or recognised native equivalents. It documents special handling for cases including closed comboboxes, slider value text, and nonfocusable separators.
Critical impact maps to high severity. The check primarily confirms its presence conditions, not actual correctness or every interaction. Hidden widgets and states appearing after input can be outside the snapshot. Do not treat a slider exception in this engine as general advice that readable value text always replaces a required numeric value.
How to fix it
- Identify the computed role, native host, and actual task. Decide whether a native control can supply the semantics more simply and reliably than a custom implementation.
- For a normal checkbox, use native state where appropriate:
<label><input type="checkbox" name="updates"> Receive updates</label>Do not add an unsynchronised aria-checked merely to make the component appear more thoroughly annotated.
- For a necessary custom widget, consult the current role and pattern requirements, including supported states, defaults, and parent-child relationships. Do not reuse a generic attribute bundle for unrelated roles.
- Initialise real values before the component becomes available. A required name or state should not be absent while the control is already operable, and unknown data should not be replaced with an invented current value.
- Update visible, programmatic, and submitted state together. Include pointer and keyboard changes, resets, validation, indeterminate states where supported, and asynchronous updates.
- Review ID relationships and dynamic targets. A closed popup or a static separator can have different requirements from an active expanded widget or adjustable separator; apply the actual context.
- Test computed output and complete interaction, not just source attributes. A native h2 has a level, while a div role=heading depends on the appropriate author-managed level.
- Rescan required, valid-value, role-compatibility, conditional-state, and name checks. Keep component tests around transitions that a no-interaction scan cannot exercise.
What the fix can break
Adding attributes can make wrong information actively exposed. Do not fill every missing field with false or zero without understanding its meaning.
A component's state may be managed differently from the native DOM property. Resolve the data flow rather than leaving redundant declarations that happen to agree on the first render.
Do not remove a role solely to avoid its requirements while the interface still depends on that function. Provide a suitable complete pattern or a genuine simpler native alternative.
Questions
Does every native checkbox need explicit aria-checked?
No. Native checked state already provides the relevant information for an ordinary native control.
Does a present property guarantee it is true?
No. Presence validation does not establish agreement with the actual interface.
Can engine exceptions be copied as universal authoring rules?
No. Check the current role specification and pattern rather than treating one implementation's acceptance as permission.
Which related checks help?
Review valid values, valid roles, 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. This rule is declared critical in axe-core 4.13.0, so every failure arrives as high.