Introduction
At minimum, all new or updated code must conform to WCAG 2.0 at Level AA. Wherever possible, code should conform to WCAG 2.1 at Level AAA.
ARIA
WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications), commonly known as ARIA, is a technical specification written by the W3C that provides a framework to improve accessibility and interoperability on the web. When implemented properly, ARIA enhances accessibility of interactive controls like drag and drop interfaces and tree menus, communicates dynamic updates to users via live regions, increases support for keyboard accessibility and interactivity, and much more.
There are 5 rules for ARIA usage:
- Don't use ARIA as a replacement for native semantic HTML
- Don't change an element's native semantics
- All ARIA interactive controls must be usable with a keyboard
- Don't use role="presentation" or aria-hidden="true" on a focusable element
- All interactive elements must have an accessible name
There are three main features defined in the ARIA spec: roles, properties, and states. Roles define what an element is or does, and properties and states enhance the semantic value of an element. Many of the ARIA "landmark" roles are duplicative of HTML5 semantic elements, e.g.: role="navigation" and <nav>. However, there are some roles that define common patterns that lack corresponding semantic elements, e.g.: role="tabgroup". And while properties and states are similar, they differ in that properties do not change during the lifecycle of an app and states change to reflect the current condition of an element.
Note: ARIA implementation is not to be taken lightly. Oftentimes, not adding attributes is more accessible than including ARIA attributes with incorrect values. Please reach out to the Anatomy team with any questions about ARIA.
Additional resources
Development
Specifications
- Web Content Accessibility Guidelines (WCAG)
- WCAG quick reference
- HTML elements reference
- HTML specification
- ARIA use in HTML
- ARIA roles
- ARIA properties and states
- ARIA authoring practices guide (APG)
Guides
- WebAIM's guide to writing alternative text
- W3C's guide to writing alternative text for complex images
- CSUN's best practices for accessible images
- WebAIM's guide to keyboard accessibility and testing keyboard interactions
- Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile
Accessibility testing
- How To Do an Accessibility Review
- Testing for Accessibility
- 18F Accessibility Testing Checklist
- ARIA APG patterns
- Keyboard testing
- NVDA Screen Reader
- Screen Reader Keyboard Shortcuts and Gestures
- Automated code quality tools
- Note: Only 25% to 35% of possible WCAG conformance failures can be detected by automated tooling, which means the lack of detectable errors does not guarantee that a site is accessible or compliant.
- WebAIM Contrast Checker
- Accessible Colors Contrast Checker