This checklist aims to quickly help identify the most obvious accessibility issues for WCAG 2.0 and 2.1 AA compatibility. It is not intended to be exhaustive but should act as a way to quickly assess a page in a multi-pass approach. It would be recommended to use a screen reader such as VoiceOver when conducting the assessment.
1. Visual Design
Consider users who have sight impairments not necessarily just those using a screen reader.
| Color contrast of text and links | Use a colour contrast checker to validate contrast ratios |
| Color is not only way to communicate information | Reinforce colours with clear text information |
| Text-only zoom | +200% zoom & -50% text zoom ensure text is legible, and there is no horizontal scrolling |
| Pinch zoom (Touch devices) | Pinch zoom must be available on touch devices, at least to x2 |
| Animation / flashing | No content that flashes more than 3 times/second, prevents triggering seizures. |
| Non-text content | Ensure there are text-based alternatives to key content, doesn’t apply to presentational content. |
2. Page Structure
Consider users who rely on a screen reader and need the page to be read out to them.
| Appropriate and unique page title | Keep the most page relevant text at the beginning |
| Logical heading structure | Ensure heading levels are not missed, i.e. h2, then a h4 |
| Meaningful headings & links | Enough context? Check the screen reader’s web rotor |
| Semantic mark-up | Is semantic mark-up used throughout the page so it makes sense? Usage of lists, nav sections, field sets, etc. |
| Tabular data | Tables should be used to mark-up tabular data, and appropriate scope and captions should be utilized. |
| Progressive enhancement | If JavaScript is disabled, can a user still complete the task? |
| Image alt tags | Remember if left empty, screen readers skip the image |
3. Keyboard Navigation
Consider screen reader users and those using keyboard-only or switch controls because of motor disabilities preventing them from using a mouse/track-pad.
| Fully keyboard accessible | All functions are available to keyboard only users |
| Visible focus | Focus outline is visible and not visually lost on the page |
| No keyboard traps | Focus is managed correctly where necessary |
| Clear screen reader focus outline | Screen reader focus outline clearly encloses the area it is currently announcing |
| Focus management | Focus is managed appropriately for errors, dialogs, form elements, non-native elements, etc. |
| Focus order | Focus order is clear and logical |
| No context change on focus | Element doesn’t change context on focus, i.e. a drop down doesn’t submit upon option selection |
| Timing | Give users enough time to complete an action, or the ability to extend the time frame by at least 10 times (exceptions are real-time events like auctions etc). |
4. Forms & Interactive Elements
Consider error management and providing feedback for interaction.
| Links & Buttons | Rule of thumb: links perform navigation, buttons perform actions |
| Programmatic association of labels and form elements | Labels should be linked programmatically with form elements, so they are announced correctly |
| Clearly identify errors | Error attributes on form elements (aria-invalid, aria-describedby) need to be maintained and managed in the appropriate states. |
| Programmatically associated errors | Errors for a form element should be linked programmatically, using aria-describedby |
| Clear error instructions | Error messages should clearly indicate how to resolve the issue. |
| Custom widgets | Non-native widgets need to have appropriate roles and behaviours manually applied to them, so screen readers can interpret them correctly, and keyboard only users can interact with them. |
| Opening new windows | When opening new windows, make it clear that the link opens in a new window |
| Live regions | Utilize live regions carefully, example applications could be when feedback is needed with complex in-page updates are occurring. |
5. Multimedia
Consider audio and visual content and how blind and deaf users will access this content.
| Provide audio/video transcripts | Text alternatives to time-based media |
| Provide audio descriptions | Have descriptions available for pre-recorded video |
| Provide captions | Have synced subtitles for audio/video content |
| CAPTCHA user verification | Avoid CAPTCHA if possible, must have an audio alternative if used |
Recommended WAI-ARIA Usage
Try to utilize native HTML elements and attributes wherever possible, before using ARIA attributes.
For example, utilize native form elements wherever possible, otherwise when non-native elements are used a lot of extra work (primarily scripting) will need to be done to mimic native component behaviors to ensure a consistent and expected behavior for all users.
Screen reader tips
Spend some time listening to the actual output of the screen reader audio, elements such as dates, times, prices, units of measure are not always announced as expected, ensure that this information is appropriately conveyed to those relying solely on the announcements.
Use the web rotor to review page structure and content out of context. Seasoned screen reader users hop around page content quickly, is the content appropriately landmarked and headings deployed to facilitate this behavior?
Guides & Resources
Apple Voice Over Guide
https://support.apple.com/guide/voiceover-guide/welcome/web
Other accessibility audit checklists
https://webaim.org/standards/wcag/checklist
WCAG 2.1 at a glance
https://www.w3.org/TR/WCAG21/
Tools
Color Oracle – View screens through colour blind users’ eyes
http://colororacle.org
Colour Contrast Analyser – Check contrast ratios meet WCAG 2.0 succcess criteria
http://www.paciellogroup.com/resources/contrastanalyser/
WAVE Toolbar/extensions
http://wave.webaim.org/extension/ Chrome
https://wave.webaim.org/toolbar/ Firefox