Why ARIA Attributes Must Use Valid Values

ARIA is a set of HTML attributes that communicate meaning, state, and relationships to assistive technologies such as screen readers. These attributes follow strict value rules defined by the WAI-ARIA specification.

If an ARIA attribute contains an invalid value, misspelt, unsupported, or inappropriate for that attribute, browsers ignore it. When that happens, assistive technologies never receive the intended information. In practice, this means the ARIA either works exactly as defined or not at all.

WCAG Success Criterion

Success Criterion 4.1.2 — Name, Role, Value (Level A)

User interface components must have a name and role that can be programmatically determined, and states, properties, and values that can be programmatically set and announced to assistive technologies.

ARIA attributes are one way authors expose state and value programmatically. When ARIA values are invalid, those states or values cannot be determined, causing a failure of SC 4.1.2.

How ARIA Actually Works

What Is ARIA?

ARIA (Accessible Rich Internet Applications) is a specification that allows authors to add semantic information to HTML when native HTML alone is not sufficient.

ARIA does not change visual appearance. It changes what assistive technologies perceive.

What Is the Accessibility Tree?

Browsers do not expose raw HTML to screen readers.

Instead, they build an accessibility tree from:

• The DOM
• Native HTML semantics
• Valid ARIA roles, states, and properties

Screen readers read this tree, not your HTML source. If ARIA values are invalid, browsers cannot include them in the accessibility tree.

What Does “Programmatically Determined” Mean?

It means software, not sight, can reliably determine:

• What an element is (role)
• What state it is in (checked, expanded, disabled)
• What value or description it has

If a value cannot be parsed and exposed in the accessibility tree, it is not programmatically determinable, even if it looks correct visually.

State vs Property

• State: Something that can change (checked, expanded, selected)
• Property: A characteristic or relationship (controls, described-by, level)

ARIA defines which values are allowed for each state or property. Anything else is ignored.

What This Rule Checks

This rule verifies that:

• Every aria-* attribute uses a value explicitly allowed by the ARIA specification
• Token-based attributes use only permitted tokens
• Boolean and tristate attributes use supported values
• ID references resolve correctly

If the value is invalid, browsers treat the attribute as if it were not present.

What Happens When a Value Is Invalid

When an ARIA value is invalid:

• Browsers ignore the value during accessibility tree construction
• The state or property is not exposed
• Assistive technologies fall back to defaults or expose nothing

This behaviour can vary slightly across browser/AT combinations, but the result is always unreliable.

What Users Experience

Example: Invalid checkbox state

<div role="checkbox" aria-checked="yes">Accept terms</div>

What the user may hear:

“Accept terms, checkbox”

State is missing.

Correct version

<div role="checkbox" aria-checked="true">Accept terms</div>

What the user hears:

“Accept terms, checkbox, checked”

Invalid value → state ignored → broken announcement.

Correct vs Incorrect Examples

Boolean ARIA attribute

<div aria-hidden="true"></div>

✔Valid

<div aria-hidden="rtue"></div>
<div aria-hidden="pizza"></div>

✖ Invalid
Invalid values are ignored as if aria-hidden were not present.

Tristate ARIA attribute

Some ARIA states support three values. Example: aria-checked

Allowed values:

• true
• false
• mixed

<div role="checkbox" aria-checked="mixed"></div>

✔ Valid

<div role="checkbox" aria-checked="yes"></div>

✖ Invalid — state not exposed

Note: The role does not have values. The state (aria-checked) does.

ARIA Value Types

ARIA defines allowed value types. These are not abstract—they directly affect user output.

Boolean (true / false)

Used for binary states like expanded or hidden.

<button aria-expanded="false"></button>

Defaults vary by attribute and role. Do not assume false.

Tristate (true / false / mixed)

Used when partial states exist (e.g., indeterminate checkbox).

Token

One value from a fixed set.

aria-live="polite"

Allowed tokens:

• off
• polite
• assertive

Anything else is ignored.

Token List

A space-separated list of allowed tokens.
Each token must be valid.

ID Reference

References one element in the same document.

<input aria-describedby="hint">

Requirements:

• ID must exist
• ID must be unique
• Referenced element must not be display: none or aria-hidden="true" if it’s meant to contribute text

ID Reference List

<input aria-labelledby="label required">

Important nuances:

• IDs are resolved in order
• Text is concatenated in that order
• Any broken reference silently fails

Case Sensitivity Clarification

ARIA tokens are defined in lowercase.

In HTML:

• Attribute values are generally case-insensitive
• “True” may work in some browsers

However:

Do not rely on this behaviour.
Use lowercase tokens exactly as specified to ensure consistent cross-browser and AT behaviour.

Native HTML vs ARIA (Critical Nuance)

Native HTML controls already expose correct semantics.

Example:

<input type="checkbox" checked>

✔ No ARIA required.

Adding incorrect ARIA:

<input type="checkbox" checked aria-checked="yes">

✖ Can override or mask correct native behaviour.

Incorrect ARIA on native elements can be worse than no ARIA at all.

HTML Validity vs WCAG Compliance (2025 Context)

• Invalid ARIA values do not break HTML parsing
• WCAG 2.2 removed SC 4.1.1 (Parsing)
• Invalid ARIA values still cause failures when they prevent states or values from being programmatically determined

This rule maps directly to SC 4.1.2.

Common Causes of Failure

• Typos in token values
• Guessing allowed values
• Confusing role names with state values
• Reusing ARIA patterns without understanding constraints
• Framework abstractions passing booleans incorrectly

Dynamic Updates (JavaScript Reality)

element.setAttribute("aria-expanded", true);

Results in:

aria-expanded="true"

✔ Correct

But property reflection varies by browser and framework. Always verify the final DOM value, not just JS intent.

How This Is Tested

Audits typically include:

• Automated detection of invalid ARIA values
• DevTools → Accessibility panel inspection
• Verifying computed accessible name/state
• Screen reader testing (NVDA, JAWS, VoiceOver)

Automation finds errors.
Manual testing confirms user impact.

How to Fix the Problem

• Use only values explicitly allowed by the ARIA specification
• Match spelling exactly
• Use lowercase tokens
• Remove invalid ARIA instead of guessing
• Prefer native HTML whenever possible

Wrapping Up

ARIA values are strictly defined because assistive technologies depend on them being unambiguous.

Invalid values are ignored.
Ignored values expose no state.
No exposed state means no accessibility.

ARIA either works exactly as defined, or it does nothing.