WCAG Robust Principle
Principle 4: Robust
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
Why Robustness Matters
The Robust principle ensures that content works with current and future technologies. As browsers, screen readers, and assistive technologies evolve, robust content will continue to be accessible. Poorly coded content may work in one browser but fail in another, or may not be interpretable by assistive technologies at all.
JAWS
Most popular commercial screen reader (Windows)
NVDA
Free, open-source screen reader (Windows)
VoiceOver
Built-in screen reader (macOS, iOS)
How Assistive Technologies Work
Screen readers and other assistive technologies create an "accessibility tree" from your HTML. They rely on semantic markup, ARIA attributes, and valid code to understand and convey content to users. Invalid or ambiguous code can cause the accessibility tree to be incomplete or incorrect.
Guideline 4.1: Compatible
Maximize compatibility with current and future user agents, including assistive technologies.
Originally required that content be parseable without duplicate IDs, proper nesting, etc. While no longer a formal requirement, these practices remain important:
Best Practices for Valid HTML:
- Unique IDs: Each ID should appear only once per page
- Proper Nesting: Elements should be opened and closed in correct order
- Complete Elements: Required closing tags should be present
- Valid Attributes: Use only defined attributes for each element
For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes is available to user agents, including assistive technologies.
Understanding Name, Role, Value:
| Component | Description | Example |
|---|---|---|
| Name | The accessible name/label for the element | "Submit Order" button, "Email Address" input |
| Role | What type of element it is | Button, checkbox, link, textbox, slider |
| Value | The current value or state | Checkbox: checked/unchecked; Slider: 50 |
How to Meet This Criterion:
Use Native HTML
Native HTML elements (<button>, <input>, <select>) have built-in name, role, and value.
Use ARIA When Needed
For custom widgets, use ARIA roles, states, and properties to communicate to assistive technologies.
In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.
Types of Status Messages:
- Success messages: "Your order has been submitted"
- Error messages: "Unable to save - please try again"
- Progress updates: "Uploading: 45% complete"
- Wait messages: "Loading results..."
- Search results: "25 results found"
Implementation with ARIA Live Regions:
<!-- For important status messages -->
<div role="status" aria-live="polite">
Form saved successfully
</div>
<!-- For urgent/error messages -->
<div role="alert" aria-live="assertive">
Error: Please check your entries
</div>
<!-- For progress indicators -->
<div role="progressbar" aria-valuenow="45" aria-valuemin="0" aria-valuemax="100">
45% complete
</div>ARIA Best Practices
ARIA (Accessible Rich Internet Applications) is essential for making custom widgets accessible, but it must be used correctly.
- Use native HTML elements when possible
- Add ARIA only when needed
- Keep ARIA roles and states synchronized with visual state
- Test with actual screen readers
- Use aria-label for icons and images with actions
- Add role="button" to actual buttons
- Override native semantics unnecessarily
- Use ARIA to make non-interactive elements interactive
- Forget to manage focus for custom widgets
- Leave aria-hidden="true" on content that should be accessible
The First Rule of ARIA
"If you can use a native HTML element or attribute with the semantics and behavior you require, instead of repurposing an element and adding an ARIA role, state or property, then do so." - W3C WAI-ARIA Authoring Practices
Common ARIA Roles for Custom Widgets
| Widget | ARIA Role | Key Attributes |
|---|---|---|
| Tab Panel | tablist, tab, tabpanel | aria-selected, aria-controls |
| Accordion | button, region | aria-expanded, aria-controls |
| Dialog/Modal | dialog | aria-modal, aria-labelledby |
| Dropdown Menu | menu, menuitem | aria-haspopup, aria-expanded |
| Tree View | tree, treeitem | aria-expanded, aria-level |
| Slider | slider | aria-valuenow, aria-valuemin, aria-valuemax |
| Tooltip | tooltip | aria-describedby |
Common Robust Issues in Audits
| Issue | Prevalence | How to Fix |
|---|---|---|
| Missing accessible names | 50% of sites | Add aria-label or visible labels to all interactive elements |
| Empty buttons/links | 27% of sites | Add text content or aria-label to buttons and links |
| Duplicate IDs | 25% of sites | Ensure all ID attributes are unique per page |
| Incorrect ARIA usage | 35% of sites | Review ARIA against WAI-ARIA Authoring Practices |
| Missing status announcements | 60% of dynamic sites | Use aria-live regions for dynamic content updates |
Testing Robust Requirements
- W3C HTML Validator
- WAVE accessibility checker
- axe DevTools
- Browser accessibility inspector
- NVDA (Windows, free)
- JAWS (Windows)
- VoiceOver (macOS/iOS)
- TalkBack (Android)
- Chrome DevTools > Accessibility
- Firefox Accessibility Inspector
- Safari Web Inspector
Related WCAG Principles
Related Laws
Key Principle
"If you can use a native HTML element, do so." Native elements have built-in accessibility that's hard to replicate with custom code.
Common Issue
60%
of dynamic sites miss status announcements