Skip to content

Quick A11y Checks (QAC! 🦆)

Every year I try and learn more about accessibility and refine my approach and tools that I use. In particular, I’m interested in the MVP, smallest, versions of things. What’s low effort and high impact?

Here are three quick checks you can do to test the accessibility of your UI: keyboard, headings, axe DevTools. These are a remix and update and revision of various lists from workshops and talks from the past few years. Yes, I did jiggle the name so that I could have QAC as the acronym and use the duck emoji 🦆.

1. Keyboard

Why do it

People with physical impairments often use a keyboard (or other non-pointer device) instead of a mouse as it doesn’t require precise movements. Power users often prefer using the keyboard as it’s faster.

What to do

Browse your site using only your keyboard. Use Tab and Shift + Tab to navigate forwards and backwards on the page. Use arrow keys to move between options. Use Enter and Space to activate things.

Things to check

  • Can you interact with every element on the page?
  • Can you see where you are on the page? Look for a visible :focus indicator as you navigate.
  • Can you use functionality (like tooltips) that you usually see on :hover?

How serious it is

Any issues found here are Critical severity: they stop our users from accessing content or completing a task.

FED notes

buttons, links, and form elements get focus automagically. If something’s not getting focus, check if it’s a div or a span. Check if you can use a different, more semantically appropriate, element.

2. Headings

Why do it

Screen reader users often use headings to navigate around a page. Sighted users often scan a page’s headings to get a quick summary of the content.

What to do

Note: if the Headings Accessibility Bookmarklet doesn’t work, try Ad hoc tools > Headings of Microsoft’s Accessibility Insights.

Things to check

  • Is everything that looks like a heading marked up as a heading?
  • Are the headings nested correctly?

How serious it is

Any issues found here are High severity: they cause serious problems or major inconvenience to our users.

FED notes

Use h1 to h6 elements, and don’t skip levels. Use the semantically correct element for the heading level in the HTML. If the heading needs to look bigger or smaller to match the design, change the look with CSS instead of changing the heading level.

3. axe DevTools

Why do it

axe aims to return zero false positives, so it’s a good one to try. It’s great at picking up any big accessibility problems (such as form controls missing labels).

What to do

Things to check

Does axe find any issues?

How serious it is

axe will report the severity of any issues it finds.

FED notes

axe is particularly good at picking up missing accessible names. For buttons and links that will often mean missing alt text on an image (inside the button or link). Form element labelling methods in order of preference:

  • a visible label;
  • aria-labelledby with visible text;
  • visually hidden text (in a label);
  • aria-label.