A Website Accessibility Audit Checklist

We've all been there. The developers have merged their final pull requests. The pipelines have all passed. The design team has approved. The staging website has passed QA. Ready for production. Right? 😃

Then you remember all the "I'll check accessibility later" promises your team made. Now the clock is ticking to go live and you have to make good on all those promises and hope that the website "just works" 😓.

First of all, please don't do that. Seriously, it's bad. Accessibility needs to be considered from the start and not treated as an enhancement or an afterthought. Secondly, even if you have been checking accessibility throughout the development process it's good practice to do a final check to make sure everything works correctly so as not to exclude users from your creation.

The problem is that there are so many factors that must be taken into account to ensure that a website is accessible and inclusive that doing so can seem overwhelming. So to help ease you into it, I have put together a short checklist of a basic accessibility checks to help ensure your website is more inclusive.

Visual checks

1. Check that there are no animations shown to users that prefer reduced motion. To test this first turn on reduced motion system wide:

   Mac OS : System Preferences > Accessibility > Display > Check the Reduce motion checkbox:

Windows 11: Settings > Accessibility > Visual Effects > Turn off Animation Effects:

Then check all interactions that produce animations to make sure they are not shown.

2. Check that all text colours have sufficient contrast against their background colour. For colours that seem to have low contrast use WebAIM Contrast Checker and make sure both normal text and large text pass at least WCAG AA checks.

3. Check that all key elements of the website are visible in High Contrast Mode. To test this first turn on high contrast mode system wide:

   Mac OS : System Preferences > Accessibility > Display > Check the Invert colours checkbox:

   

   Windows 11: Settings > Accessibility > Contrast Themes > Select a contrast theme using the drop down selector then click Apply:

   

Keyboard checks

1. Reload the page and interact using the keyboard Tab key. Make sure the first element to receive keyboard focus is logically the correct element.

2. Check that there's a skip to content button if there are many focusable elements before the main content, for example in the navigation menu. If using a skip to content button check that it is the first focusable element after any modals, dialogs, pop-ups or other "take-over" elements.

3. Check that the cookie consent banner's focusable elements receive focus first, even before the skip to content button and even if the banner is anchored to the bottom of the viewport.

4. Check that the focus states of all focusable elements are visually distinct from their normal state. For more information on this, consult W3C's Focus Appearance Success Criterion.

5. Check that all interactable components, other than those from third-party accessible component libraries such as ACE 😃, are fully keyboard usable and conform to the patterns described in W3C's ARIA Authoring Practices Guide Patterns. In particular:

   1. Check that modals and dialogs are completely usable by keyboard:

      1. Check that the first focusable element in the modal receives focus.
      2. Check that focus is trapped within the modal or focus is sent from the modal's first and last focusable elements to the browser, preventing the website's focusable elements outside the modal from receiving focus.
      3. Check that the Esc key closes modals.
      4. Check that when modals close, focus is returned to the last element that had focus before the modal became visible.

   2. Check that carousels are completely usable by keyboard:

      1. Check that the carousel previous, next and slide picker buttons are focusable and work with the keyboard.
      2. Check that automatic carousels pause when an element in a carousel slide has focus.

Screen reader checks

For help with using screen readers see my blog post A Screen Reader Quickstart Guide.

1. Check that all landmark regions are picked up by the screen, e.g. search bars, navigation, main, footer. To test this view the screen reader's landmarks:

   1. VoiceOver: Activate the rotor using Control + Alt + U, then press the left arrow key repeatedly until Landmarks is visible.
   2. NVDA: Show the Elements list using Insert + F7.

2. Check that the heading hierarchy makes sense, i.e. they are ordered logically for example <h1> headings at the top followed by <h2> headings, which are in turn followed by <h3> headings etc. To test this view the screen reader's headings overview:

   1. VoiceOver: Activate the rotor using Control + Alt +U, then press the left arrow key repeatedly until Headings is visible.
   2. NVDA: Show the Elements list using Insert + F7.

3. Check that the navbar is read out as such and that the navbar items are in a <ul> or <ol> element.

4. Check that all content is read out with correct and appropriate context.

5. Check that all images are either ignored by the screen reader or read out with appropriate context.

6. Check that grouped elements that can be read out as a list are in a <ul> or <ol> element and that the list has an appropriate title which is read out by screen readers e.g. Main menu, List, 7 items. For more info on how to achieve this see MDN's guide on Associating annotated elements with their details.

7. Check that all alerts, pop-ups, warnings, notifications etc., and changes to the content and structure of the site are announced by the screen reader. For more info on how to achieve this see MDN's guide on ARIA live regions.

8. Check that all interactable components, other than those from third-party accessible component libraries such as ACE 😃, are fully usable with a screen reader and conform to the patterns described in W3C's ARIA Authoring Practices Guide Patterns. In particular:

   1. Check that modals and dialogs are fully usable with a screen reader:
      1. Check that modals are announced when they become visible.
      2. Check that the modals conform to the W3C WAI-ARIA authoring practices for modals.
   2. Check that carousels are fully usable with a screen reader:
      1. Check that any automatic carousels slide changes are not announced.
      2. Check that the carousels conform to the W3C WAI-ARIA authoring practices for carousels.

Further checks

As I mentioned, this was just a basic checklist of a few things that will help make your site more inclusive. If you find yourself interested in this topic or have more time available for accessibility improvments, you should check out WebAIM's WCAG 2 Checklist, which is a more extensive list of accessibility checks. For accessibility guidance specifically for common UI components, such as carousels & modals, have a look at W3's ARIA Authoring Practices Guide.

Hopefully you found this checklist useful for discovering any accessibility oversights, and improving the experience for certain users by creating a more inclusive website.