Accessibility
Build inclusive Aurelia 2 applications that work for everyone, including users with disabilities.
What you'll learn...
How to use ARIA attributes in Aurelia templates
Keyboard navigation patterns and implementation
Focus management techniques, especially in routed applications
Screen reader support best practices
Accessibility testing strategies
WCAG 2.1 compliance guidelines
Table of Contents
Why Accessibility Matters
Web accessibility ensures that people with disabilities can perceive, understand, navigate, and interact with your application.
Benefits:
🌍 Inclusivity: 15% of the world's population has some form of disability
⚖️ Legal compliance: Many regions require accessible public websites (ADA, Section 508, EAA)
📱 Better UX for everyone: Keyboard navigation, clear labels, and good contrast help all users
🔍 SEO improvements: Semantic HTML and proper structure improve search rankings
💼 Expanded market: Don't exclude potential users and customers
ARIA in Aurelia Templates
ARIA (Accessible Rich Internet Applications) attributes provide semantic meaning to assistive technologies when HTML alone is insufficient.
Basic ARIA Attribute Binding
Bind ARIA attributes just like any other HTML attribute in Aurelia:
ARIA Attribute Naming
In Aurelia templates, use kebab-case for ARIA attributes (e.g., aria-label, aria-describedby), just like standard HTML. The framework handles the attribute mapping correctly.
Common ARIA Patterns
Expandable Sections (Accordion)
Usage:
Modal Dialog
Tab Panel (Tabbed Interface)
Usage:
Semantic HTML
Use semantic HTML elements instead of generic <div> and <span> whenever possible. Semantic elements provide built-in accessibility.
Semantic Elements in Aurelia
Landmark Regions
Landmark regions help screen reader users navigate your application:
Headings Hierarchy
Maintain a logical heading hierarchy (h1 → h2 → h3, never skip levels):
Only One h1 Per Page
Each page should have exactly one <h1> that describes the main content. In routed applications, each routed component's main content should start with an <h1>.
Keyboard Navigation
All interactive elements must be operable via keyboard alone (no mouse required).
Tab Order and tabindex
Default Tab Order: Interactive elements (<a>, <button>, <input>, etc.) are focusable by default in document order.
tabindex Values:
tabindex="0": Element is focusable in natural tab ordertabindex="-1": Element is programmatically focusable but not in tab ordertabindex="1+": Avoid! Overrides natural tab order (confusing for users)
Avoid Positive tabindex Values
Using tabindex="1", tabindex="2", etc. creates a confusing tab order. Let the natural document order dictate focus flow.
Keyboard Event Handling
Handle keyboard events for custom interactive components:
Skip Links
Provide skip links to help keyboard users bypass repetitive navigation:
Keyboard Shortcuts
Implement keyboard shortcuts for common actions:
Best practices for keyboard shortcuts:
Use standard shortcuts (Ctrl+C, Ctrl+V, etc.)
Provide a way to discover shortcuts (help modal, documentation)
Don't override browser shortcuts
Test with screen readers (some shortcuts conflict)
Focus Management
Focus management is critical for keyboard users and screen reader users, especially in dynamic applications.
Focus Indication (Visual Focus Styles)
Always provide visible focus indicators. Never remove focus outlines without providing an alternative.
Focus Indicators Required
WCAG 2.1 requires a visible focus indicator with at least 3:1 contrast ratio against the background. Never hide focus styles without providing equally visible alternatives.
Managing Focus on Route Changes
When navigating between routes, focus should move to the new content:
Register the hook:
Focus Management in Modals
See the Modal Dialog example above for proper focus management:
Store the previously focused element
Move focus into the dialog when opened
Trap focus within the dialog
Restore focus when closed
Focus Management for Dynamic Content
When dynamically adding content, manage focus appropriately:
Screen Reader Support
Screen readers convert UI elements into speech or braille. Ensure your app provides a good screen reader experience.
Live Regions (ARIA Live)
Announce dynamic content changes to screen readers:
ARIA Live Attributes:
aria-live="off": No announcements (default)aria-live="polite": Announce when convenient (don't interrupt)aria-live="assertive": Announce immediately (interrupts current speech)aria-atomic="true": Announce entire region contentaria-atomic="false": Announce only changed nodes (default)
Example: Status announcements
Visually Hidden (Screen Reader Only) Content
Use a CSS class to hide content visually while keeping it accessible to screen readers:
Usage:
ARIA Labels and Descriptions
Provide accessible names and descriptions for elements:
When to use each:
aria-label: Simple label for icon buttons, landmarks without visible labelsaria-labelledby: Reference visible text as the labelaria-describedby: Additional context or instructions
Forms and Validation
Accessible forms are critical for all users.
Form Labels
Every form field needs an associated label:
Required Fields
Indicate required fields both visually and semantically:
Validation Errors
Associate error messages with form fields using aria-describedby:
Key accessibility features:
aria-invalid="true"when field has erroraria-describedbyreferences error messagerole="alert"on error to announce to screen readersVisual error styling
Fieldsets and Legends
Group related form fields with <fieldset> and <legend>:
Dynamic Content
Handle accessibility for dynamically loaded or changing content.
Loading States
Announce loading states to screen readers:
Infinite Scroll / Lazy Loading
Announce newly loaded content:
Client-Side Routing Announcements
Announce route changes to screen readers:
Testing for Accessibility
Automated and manual testing ensure your application remains accessible.
Automated Testing Tools
Browser Extensions:
axe DevTools - Comprehensive a11y scanner
WAVE - Visual feedback on accessibility issues
Lighthouse - Built into Chrome DevTools
Testing Libraries:
Example with Playwright:
Manual Testing
Automated tools catch only ~30-40% of accessibility issues. Manual testing is essential.
Keyboard Navigation Testing:
Unplug your mouse
Use Tab to navigate forward, Shift+Tab to navigate backward
Verify all interactive elements are reachable
Verify visible focus indicators
Test custom components (modals, dropdowns, etc.)
Verify Enter/Space activate buttons and links
Screen Reader Testing:
Test with popular screen readers:
Windows: NVDA (free) or JAWS
macOS: VoiceOver (built-in)
Linux: Orca
Mobile: VoiceOver (iOS), TalkBack (Android)
Basic VoiceOver commands (macOS):
Start: Cmd+F5
Navigate: Ctrl+Option+Arrow keys
Interact: Ctrl+Option+Shift+Down
Read all: Ctrl+Option+A
What to test:
All text is announced
Form labels are announced
Validation errors are announced
Dynamic content changes are announced
Keyboard focus is indicated
Color Contrast Testing
Ensure sufficient contrast between text and background:
Tools:
Browser DevTools (Chrome: "Show Accessibility" in Elements panel)
WCAG 2.1 Requirements:
Normal text: 4.5:1 contrast ratio (AA), 7:1 (AAA)
Large text (18pt+ or 14pt+ bold): 3:1 (AA), 4.5:1 (AAA)
UI components: 3:1 (AA)
WCAG 2.1 Compliance Checklist
Use this checklist to ensure WCAG 2.1 Level AA compliance.
Perceivable
Operable
Keyboard accessible:
All functionality available via keyboard
No keyboard traps
Visible focus indicators
Enough time: Users can extend time limits or no time limits exist
Seizures: No flashing content more than 3 times per second
Navigable:
Skip links provided
Page titles are descriptive
Logical focus order
Link purpose clear from context
Multiple ways to find pages (search, nav, sitemap)
Headings and labels are descriptive
Understandable
Readable:
Language of page is identified (
<html lang="en">)Language changes are identified (
<span lang="fr">)
Predictable:
Focus doesn't cause unexpected context changes
Input doesn't cause unexpected context changes
Navigation is consistent across pages
Input assistance:
Error messages are clear and helpful
Labels or instructions provided for user input
Error suggestions provided when possible
Confirm before final submission (legal/financial)
Robust
Compatible:
Valid HTML (no duplicate IDs, proper nesting)
Name, role, value available for all UI components
Status messages use
role="status"oraria-live
Related Documentation
Templates Overview - Template syntax and data binding
Forms - Form creation and validation
Validation Plugin - Input validation
Router Hooks - Focus management on route changes
Component Lifecycles - Managing focus in lifecycle hooks
Additional Resources
Standards and Guidelines
WCAG 2.1 Guidelines - Official WCAG quick reference
ARIA Authoring Practices Guide - ARIA patterns and examples
WebAIM - Web accessibility resources and training
Testing Tools
axe DevTools - Browser extension for a11y testing
Pa11y - Automated accessibility testing
WAVE - Web accessibility evaluation tool
Lighthouse - Built into Chrome
Screen Readers
NVDA - Free screen reader for Windows
JAWS - Popular commercial screen reader
VoiceOver - Built into macOS and iOS
TalkBack - Built into Android
Accessibility is a Journey
Building accessible applications is an ongoing process. Start with the basics (keyboard navigation, semantic HTML, ARIA), test regularly, and continuously improve. Every improvement makes your application more inclusive.
Last updated
Was this helpful?