Accessibility Robust

Accessibility — Robust

WCAG Principle 4: content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies.

The two sub-criteria, simplified:

1. Compatible — markup is parsed correctly; name, role, and value are programmatically determinable for every UI component.
2. Status messages — programmatically-conveyed status updates without focus shifts.

Robustness is the layer most often broken by frameworks that abstract away HTML semantics. A <div>-based UI may be visually identical to a semantic one and entirely opaque to assistive tech.

1. Compatible

Semantic HTML first

Use the right HTML element for the job. Browsers and assistive tech understand semantic elements without further annotation.

The reason isn't aesthetic; semantic elements come with built-in:

• Keyboard handling (<button> activates on Enter/Space).
• Focus management (<a href> is in tab order).
• Accessibility tree role (<nav> is announced as "navigation landmark").
• Default styling that can be overridden but indicates affordance.
• Form submission, validation, and serialization.

A <div role="button" tabindex="0" onclick onKeyDown> is almost a button — and you've rebuilt 80% of what <button> provides for free, often imperfectly.

Name, Role, Value

Every interactive component must have:

• Name — what is it? ("Save," "Email field," "Open menu")
• Role — what kind of thing is it? ("button," "textbox," "menu")
• Value — what's its current state? ("checked," "expanded," "disabled," current text)

Native HTML elements provide all three for free. For custom components, you provide them via ARIA.

<!-- Native: name from text, role from <button>, value from disabled state -->
<button disabled>Save</button>

<!-- Custom: must declare all three -->
<div role="button"
     tabindex="0"
     aria-disabled="true">
  Save
</div>

When to use ARIA

The first rule of ARIA: don't use ARIA. The second rule: don't use ARIA when a native element will do. The third rule: when you must use ARIA, use it correctly.

Use ARIA when:

• Building a custom component for which no native element exists (combobox, tablist, treegrid, slider) — use the appropriate WAI-ARIA pattern.
• Adding state to a component that has no native attribute (aria-expanded, aria-current, aria-pressed, aria-selected).
• Providing an accessible name when no visible label exists (aria-label, aria-labelledby).
• Associating descriptions or errors with controls (aria-describedby).
• Marking dynamic content for announcement (aria-live).

Don't use ARIA to:

• Reinvent native semantics (role="button" on <button>).
• Override semantics that work (role="presentation" on a <table> of tabular data).
• "Fix" inaccessible custom components without also adding keyboard support and state management.

ARIA roles, properties, states

A few of the most-used:

The WAI-ARIA Authoring Practices Guide documents complete patterns for: combobox, dialog, disclosure, feed, grid, listbox, menu, menubar, radiogroup, slider, tablist, treeview, and more. Reach for these patterns rather than inventing.

Don't break native semantics

A common mistake: applying ARIA roles that conflict with the underlying element.

<!-- Wrong: <a href> is already a link; role="button" overrides -->
<a href="/save" role="button">Save</a>

<!-- Wrong: <ul> already has list semantics; role="navigation" doesn't help -->
<ul role="navigation">...</ul>

<!-- Wrong: <table> for tabular data with role="presentation" strips semantics -->
<table role="presentation">...</table>

If you must override semantics (rare), you almost always have the wrong base element.

Validate your HTML

Invalid HTML can cascade in unpredictable ways through accessibility tree construction. Validate occasionally with the W3C HTML Validator.

Common offenders:

• Duplicate IDs (breaks aria-labelledby and aria-describedby).
• Nested interactive elements (<button> inside <a>, <a> inside <button>).
• <button> inside <button>.
• Form controls not associated with <label>.

2. Status messages

Dynamic content updates that don't shift focus need to be announced to screen readers via live regions.

Live regions

<!-- Polite: announce when convenient (after current speech) -->
<div aria-live="polite" id="search-results-status"></div>

<!-- Assertive: interrupt; for critical messages only -->
<div aria-live="assertive" id="error-status"></div>

When you populate the live region, the screen reader reads the new content. The region must:

• Be present in the DOM before content is added (live regions don't announce content present at page load).
• Have only the new message inside it, replacing previous content.
• Be visible to assistive tech (don't display: none; use sr-only if you don't want it visible).

role="status" and role="alert"

Convenience roles with built-in aria-live settings:

• role="status" ≈ aria-live="polite". For non-critical updates ("Saved," "Loaded 24 results").
• role="alert" ≈ aria-live="assertive" plus aria-atomic="true". For urgent updates ("Connection lost," "Form has 3 errors").

<!-- Toast notification (status) -->
<div role="status">Changes saved</div>

<!-- Form error summary (alert) -->
<div role="alert">
  Please fix the following: Email is invalid; Password is too short.
</div>

Use role="alert" sparingly — it interrupts whatever the screen reader is doing. Reserve for genuine emergencies.

Common live-region patterns

• Toast notifications — role="status" for success, info, warning; role="alert" for error.
• Search results count — <div role="status">Showing 24 results</div> updates as the user filters.
• Form validation summary — after a failed submit, populate <div role="alert"> with the error count and let screen reader read it.
• Auto-saving indicator — <div role="status">Saving... Saved at 3:42 PM</div> updates during background saves.
• Real-time data updates — chat messages, stock prices: aria-live="polite" so the user hears them when convenient.