Valid ARIA Attributes

Why It Matters

• Invalid attributes are silently ignored. If you misspell aria-label as aria-lable or use aria-checked on an element that does not support it, nothing breaks visually. But screen readers ignore the invalid attribute entirely, and the accessibility improvement you thought you added does not exist.
• It creates a false sense of accessibility. Developers see ARIA attributes in their code and assume the element is accessible. Without validation, there is no feedback that the attribute is invalid. The gap between intended and actual accessibility widens silently.
• Context matters for ARIA. An attribute that is valid on one role may be invalid on another. aria-checked works on checkboxes and switches but not on buttons or links. Using the right attribute on the wrong element is just as ineffective as using a misspelled one.
• It is a foundational accessibility requirement. Accessibility guidelines require that all ARIA attributes be valid for their context. Invalid ARIA fails accessibility reviews and can indicate deeper structural problems with how interactive elements are built.

How to Fix It

1. Check attribute names against the spec. Verify that every ARIA attribute you use exists in the WAI-ARIA specification. Common misspellings like aria-lable, aria-decribedby, or aria-labelled-by are invalid and do nothing.
2. Verify attributes match the element's role. Look up which attributes are supported for each role. A button supports aria-pressed and aria-expanded but not aria-checked. A textbox supports aria-required but not aria-selected.
3. Use automated validation tools. Accessibility linting tools and browser extensions can scan your page and flag invalid ARIA attributes instantly. Run these checks as part of your development workflow to catch mistakes before they reach production.
4. Prefer native HTML over ARIA when possible. A native <button> element does not need role="button" or most ARIA attributes — it comes with built-in accessibility. Using native elements reduces the chance of ARIA errors because there is less ARIA to get wrong.
5. Test with a screen reader. After fixing validation issues, verify with a screen reader that the attributes are producing the intended announcements. Valid attributes that are technically correct but semantically wrong still create confusing experiences.

Common Mistakes

• Misspelling attribute names. ARIA attributes have specific, exact names. aria-labeledby is wrong — the correct form is aria-labelledby. These typos are easy to make and impossible to catch visually since the page looks and behaves normally.
• Using deprecated or non-existent attributes. Inventing attributes like aria-description (which did not exist until recently and has limited support) or aria-tooltip (which does not exist) adds code that does nothing.
• Applying attributes to the wrong role. Adding aria-selected="true" to a regular list item does nothing because the default list item role does not support selection. The element needs to have an appropriate role like option or tab first.
• Assuming more ARIA is better. Piling on ARIA attributes without understanding which ones are valid and meaningful creates noise, not accessibility. Each attribute should have a clear purpose and be validated against its element's role.