Accessibility

Build inclusive Aurelia 2 applications that work for everyone, including users with disabilities.

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

WCAG Standards

The Web Content Accessibility Guidelines (WCAG) 2.1 define three conformance levels:

  • Level A: Minimum accessibility (serious barriers removed)

  • Level AA: Recommended target for most websites (addresses major barriers)

  • Level AAA: Highest level (not always achievable for all content)

This guide focuses on achieving WCAG 2.1 Level AA compliance.


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:

Common ARIA Patterns

Expandable Sections (Accordion)

Usage:

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):


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 order

  • tabindex="-1": Element is programmatically focusable but not in tab order

  • tabindex="1+": Avoid! Overrides natural tab order (confusing for users)

Keyboard Event Handling

Handle keyboard events for custom interactive components:

When to Use Native Elements

Before creating custom components, consider using native elements:

  • Use <button> instead of <div role="button">

  • Use <a href="..."> for navigation

  • Use <input type="checkbox"> instead of custom toggles

Native elements have built-in keyboard support, focus management, and screen reader compatibility.

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.

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:

  1. Store the previously focused element

  2. Move focus into the dialog when opened

  3. Trap focus within the dialog

  4. 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 content

  • aria-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 labels

  • aria-labelledby: Reference visible text as the label

  • aria-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 error

  • aria-describedby references error message

  • role="alert" on error to announce to screen readers

  • Visual error styling

See: Validation documentation

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:

Testing Libraries:

Example with Playwright:

Manual Testing

Automated tools catch only ~30-40% of accessibility issues. Manual testing is essential.

Keyboard Navigation Testing:

  1. Unplug your mouse

  2. Use Tab to navigate forward, Shift+Tab to navigate backward

  3. Verify all interactive elements are reachable

  4. Verify visible focus indicators

  5. Test custom components (modals, dropdowns, etc.)

  6. 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:

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

Understandable

Robust



Additional Resources

Standards and Guidelines

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

Last updated

Was this helpful?