Ten checks · twenty minutes · a keyboard and one page
A WCAG checklist you can run yourself, before anyone audits you.
Checklists that list all 56 criteria are useless to someone who has never done this: they are a standard reprinted, not a method. This one is the opposite. Ten checks, in the order that finds the worst problems first, each written so that a person with no technical training can carry it out on their own site this afternoon and know by the end whether the situation is tidy or structural.
This list finds common failures. It does not replace testing.
Before you start
Pick the page where your business happens: the checkout, the booking form, the contact page, the application form. Not the home page, which is usually the best-built page on any site and therefore the least informative.
Put the mouse out of reach. That single act is most of the method: almost every serious barrier we find is invisible to somebody using a pointer, and becomes obvious within a minute to somebody who is not.
The ten checks
Work down them in order. The first four find the failures that stop a task completely; the rest find the ones that make it harder than it should be.
- Tab through the whole page. Press Tab repeatedly from the top. Can you reach every link, button and field, in an order that matches what you see? If something is skipped, that is a finding.
- Watch for the focus. At every stop, can you see where you are? An invisible focus outline makes keyboard use guesswork, and it is the most common single defect on the web.
- Open and close everything. Menus, modals, cookie banners, pop-ups. Do they open with Enter or Space, close with Escape, and return you where you were? If focus is stuck inside, you have found a blocker.
- Fill the form wrong on purpose. Submit with an empty required field. Is the error visible, does it say which field and what to do, and does the focus move to it? Errors in red text alone fail this.
- Zoom to 200 percent. Does the content reflow, or does it overlap and clip? Then try 400 percent, which is the level the standard actually asks about.
- Read the link text out of context. List every link on the page. Do they still make sense on their own, or are they nine variations of read more?
- Look at the images. Which ones carry information that exists nowhere else on the page? Each of those needs a text description; decorative ones need an empty alternative, not a file name.
- Check colour is never the only signal. Required fields, errors, statuses, chart legends. If the meaning disappears in greyscale, it disappears for some users too.
- Measure the contrast of your buttons. Body text is usually fine; buttons, placeholder text and light grey captions are usually not. Check the actual values from your design system.
- Turn off the sound and play a video. Are there captions, and do they carry the information the audio carries? If the video sells something, this is not optional.
If checks one to four pass on your most important page, your situation is probably tidy. If any of them fails, you have a structural problem that a statement cannot describe away.
What to do with what you found
| Finding | Who fixes it | Usual effort |
|---|---|---|
| Focus not visible | Developer, CSS | Under an hour |
| Keyboard trapped in a pop-up | Plugin setting or developer | Setting, or half a day |
| Form errors not announced | Developer | Half a day |
| Link text meaningless | Content team | Minutes per page |
| Missing alternative text | Content team | Minutes per image |
| Low contrast buttons | Design and CSS | Under an hour |
| Text inside images | Content team | Retype as text |
| No captions on video | Marketing or supplier | Per video |
Four of the eight need no developer at all, which is why we hand the content half of every findings report to the people who publish pages rather than to engineering.
What this checklist cannot tell you
Being explicit about the limits is what separates a useful list from a marketing one. Ten checks cover the failures that occur most often; they do not cover the criteria that need assistive technology to evaluate, and they say nothing about what a screen reader announces as you move through a custom component.
They also cover one page. Sites fail unevenly: the home page is polished, the checkout is inherited from a template, the account area was built in a hurry three years ago. And they cannot see documents, video descriptions, or anything behind a login.
So treat a clean result as encouraging rather than conclusive, and a failed result as decisive: if the checkout cannot be completed with a keyboard, you already know the answer to the question you were going to ask an auditor.
From checklist to audit
The audit starts where this list stops. Automated checking clears the mechanical defects, then a person works through the real flows with keyboard and screen reader, at 400 percent zoom and at 320 pixels wide, checking names, roles, states, announcements, focus management and error recovery across every task your users perform.
What comes out is a findings report ordered by what a person cannot do, a statement written from those findings and signed by a company established in your jurisdiction, a public verification code, a hosted feedback channel, monthly re-testing and five years of records. The method is described in detail on the audit page, and what the resulting document looks like on the example page.
Run it again in three months
The value of this list is not the first pass, it is the habit. Sites degrade: a campaign banner arrives, a plugin updates, a new template ships, and the focus style somebody added in March disappears in July. Ten minutes on the critical page each quarter catches most of that, and it costs nothing.
If you would rather not remember, that is exactly what the monthly re-test in the plan does: each run compared with the last, and a short message when something moves. Either way, the point is the same — accessibility is a state that has to be maintained, not a project that gets finished.
Five minutes more, if you have a screen reader
This is optional, and it is the single most useful optional thing on the page.
Every modern operating system ships one, and switching it on for five minutes changes how the whole team thinks about the site. You do not need to be proficient. Turn it on, close your eyes for the first thirty seconds so you stop reading the screen, and listen to three things.
The buttons. Move to each control and listen to what is announced. If you hear the word button with no name, or a file name, or nothing at all, you have found the defect that blocks more tasks than any other.
The headings. Most screen readers can list the headings on a page. That list is the outline a person navigates by, and if it reads as a jumble of sizes rather than a structure, the page is far harder to use than it looks.
The form errors. Submit the form wrongly again and listen. Silence here means the customer is stuck with no idea why, which in a checkout is money leaving the building.
Turn it off afterwards. The purpose is not to simulate anybody's experience, which you cannot do in five minutes, but to hear the difference between what your page shows and what it actually exposes.
Two checks for phones
Everything above assumes a desktop, and most of your traffic is not. Two extra checks take two minutes each on a phone. First, rotate the device: does the page work in both orientations, or does it lock to portrait and hide content in landscape? Locking orientation breaks the experience for anyone whose phone is mounted on a wheelchair or a stand. Second, try the small controls: the close button on a pop-up, the quantity stepper, the icons in a toolbar. If you miss them with a fingertip, so does everybody else, and WCAG 2.2 now has a criterion about exactly that.
How to record what you find
Write one line per finding, in the form: on this page, trying to do this, this happened. That is all a developer needs to reproduce it, and it is far more actionable than a criterion reference. Avoid the temptation to guess at the technical cause: a note saying the date picker cannot be reached with the keyboard is useful, and a note guessing at a missing ARIA attribute sends somebody down the wrong path.
Keep the list somewhere the whole team can see, and mark each item with what it stops a person doing rather than with a severity number invented on the spot. When the audit arrives, those notes fold into the findings report instead of being replaced by it, and the team recognises the problems because they found half of them themselves.
Questions about using this list
What is this checklist for?
Working through your own site before an audit, so you know what you are dealing with and can fix the easy things first.
Does passing this checklist mean I conform?
No. It covers the failures that appear most often, not all 56 criteria at level AA.
What do I need to run it?
A keyboard, a browser, twenty minutes and your most important page. A screen reader helps but is not required for the first pass.
Can my marketing team do this?
Most of it, yes. Four of the ten checks need no technical knowledge at all.
How long does a full pass take?
Twenty minutes for one page, a couple of hours for a small site.
What if I find a problem?
Write it down with the page and what you were trying to do. That note is already more useful than a tool score.
Should I fix before ordering an audit?
Fix what is obvious. The audit will find what a checklist cannot, and the ordering does not change the price.
Which check matters most?
The keyboard pass. If a task cannot be completed without a mouse, nothing else on the list outweighs it.
Do I need a screen reader?
For a thorough result yes, but the first pass finds plenty without one.
Is contrast something I can check myself?
Yes, with a free contrast checker and the colour values from your design system.
Does this replace an audit?
No, and no honest checklist does. It tells you whether you have a small problem or a structural one.
What is out of scope here?
Documents, video captions, native apps and anything behind a login: those need the full audit.
How does the audit differ?
All criteria, real assistive technology, every flow, findings by severity, and a signed statement at the end.
What does the audit cost?
690 € a year for the EU, 890 CAD for Canada, 1,290 € for three domains, 1,990 € for all three regions.
How long does the audit take?
Five business days from a complete form.
Can I publish a statement after this checklist?
You can publish one after testing. A checklist is not testing, and a statement written from it will be wrong in the parts that matter.
Do you provide the fix list?
Yes, ordered by what a user cannot do, with the change to make.
Where do I start?
Run the free scan, then this checklist, then decide.