A short list of checks does most of the work Accessibility work usually starts when a customer complains or a procurement form asks for it. The good news is that most of the value comes from a short list of checks, and half of them are quick.
Run a scanner first, but know its limit
An automated scanner finds missing alternative text, empty buttons and links, form fields with no label, colour contrast failures, missing page language and broken heading order. That is genuinely useful, and it is cheap to run on every build. It also only detects a minority of real problems, because a scanner cannot tell whether your alternative text is meaningful or whether a custom dropdown actually works.
Then unplug the mouse
The keyboard pass is the single most valuable manual test. Tab through the whole page and check that every interactive element can be reached, that the focus outline is always visible, that the order follows the visual layout, that Escape closes dialogs, and that focus is trapped inside a modal while it is open and returns to the trigger when it closes. Skip links, custom dropdowns, date pickers and carousels are where this usually falls apart.
Listen to one page
You do not need to be a screen-reader expert to find the big problems. Turn on VoiceOver or NVDA and listen to one important page. Are headings announced in a sensible order? Do links say where they go, or do six of them just say "read more"? Are images described, and are decorative images silent? Do error messages get announced when they appear?
Check the things WCAG 2.2 added
- Focus not obscured: the focused element must not be hidden behind a sticky header or a cookie banner.
- Target size: interactive controls need enough space around them, which matters most on mobile toolbars.
- Dragging alternatives: anything you can do by dragging must also be doable with a single pointer action.
- Accessible authentication: do not force a user to solve a puzzle or retype a code from memory to log in.
- Consistent help: help links stay in the same place across pages.
Report findings so they can be fixed
Every finding should name the exact success criterion, the element, the browser and assistive technology used, what happened, what should happen, and a suggested fix. A report that just says "contrast issues" gets ignored. Apex Automation Team delivers findings in that format, retests each fix, and can add the automated checks to your pipeline so regressions are caught early. See software testing and QA or ask for an accessibility review.
This is engineering guidance and not legal advice on your obligations.
Quick checklist
- Run an automated scan on every build
- Tab through the whole page with no mouse
- Confirm focus is always visible and never hidden by sticky bars
- Check dialogs trap focus and return it on close
- Listen to one key page with a screen reader
- Check target sizes and dragging alternatives on mobile
- Name the exact success criterion in every finding
Frequently asked
Does a scanner make us compliant?
No. Automated tools detect only a minority of real barriers. The keyboard and screen-reader passes are where the important problems are found.
Can you add accessibility checks to our pipeline?
Yes. We wire the automated checks into GitHub or GitLab so regressions fail the build, and run the manual pass each release.