What are required ARIA states and properties?

Some roles are meaningless without certain attributes. A role=checkbox must have aria-checked; a role=slider must have aria-valuenow; a role=heading must have aria-level. The validator flags these as missing because assistive technology cannot convey the widget's state without them.

Which attributes are prohibited on a role?

Certain roles cannot carry an accessible name. role=presentation (and synonyms like none, generic, paragraph, strong) prohibit aria-label and aria-labelledby because the element is meant to be ignored semantically. Applying a name to them is invalid and the validator flags it.

Should I use ARIA roles or native HTML?

Native HTML first, always. A button element already has role=button and full keyboard support; a div with role=button needs you to add tabindex, key handlers, and focus styles yourself. The first rule of ARIA is not to use ARIA when a native element does the job.

Does this validate the full WAI-ARIA specification?

No. It covers the common roles you meet in everyday front-end work across landmark, widget, structure, window, and live-region categories, with their key required and prohibited attributes. For exhaustive coverage including every inherited state, consult the official WAI-ARIA 1.2 specification.

What is the difference between aria-label and aria-labelledby?

Both give an element an accessible name. aria-label takes the name as a literal string; aria-labelledby references the id of another element whose text becomes the name. Use labelledby when visible text already describes the element, and label when no such text exists.

ARIA Role Reference & Attribute Validator

ARIA roles tell assistive technology what an element is when the HTML alone cannot. Get the required states wrong and a screen reader announces a broken or silent widget. This tool is a fast offline reference plus a validator that checks a pasted element’s role and aria-* attributes against the rules.

How it works

Paste an element tag and the validator parses out the role value and every aria-* attribute, then applies two checks for that role:

Required states/properties — attributes the role cannot function without. role="checkbox" requires aria-checked; role="slider" requires aria-valuenow; role="combobox" requires aria-expanded. Missing ones are flagged.
Prohibited attributes — roles like presentation/none and the various generic roles cannot carry an accessible name, so aria-label and aria-labelledby on them are invalid and flagged.

The reference list below the validator is searchable by name, category, or keyword and shows each role’s purpose, its required states, commonly supported properties, and a note steering you toward the native HTML element where one exists.

Worked example

<div role="checkbox">Subscribe</div>

This is flagged: role="checkbox" requires aria-checked, which is missing — a screen reader would announce “checkbox” with no checked/unchecked state. The fix:

<div role="checkbox" aria-checked="false" tabindex="0">Subscribe</div>

Better still, use the native control, which carries the role and state for free:

<input type="checkbox" id="sub"><label for="sub">Subscribe</label>

Notes

The role categories follow WAI-ARIA: landmark (banner, navigation, main), widget (button, checkbox, slider, tab), structure (list, heading, img), window (dialog, alertdialog), and live regions (alert, status).
Live-region roles like alert and status carry an implicit aria-live value — do not also set aria-live on them.
This reference covers the common roles, not the entire specification. For edge cases and full inherited-state tables, consult the official WAI-ARIA 1.2 document.