What we check, and why
Twenty-five checks drawn from WCAG 2.2 AA - the standard nearly every accessibility law in the world points at. Here is each one, what it looks for, and who it shuts out when it fails.
What an automated check can and cannot tell you
Start here, because it changes how you should read your score.
Deque, who build the engine most of the industry uses, studied 300,000 real accessibility issues and found automated testing fully covers about 57% of them. The rest needs a person. A machine can prove an image has no description; it cannot tell you whether the description is any good. It can see that captions exist; it cannot tell you whether they match the audio. It can measure colour contrast; it cannot tell you whether your page makes sense read aloud from top to bottom.
So a clear result here means nothing obvious is broken. It is a good place to start from. It is not a certificate, and this tool will never tell you that you comply with a law, because no automated scan honestly can.
The four principles everything hangs off
WCAG groups every criterion under four ideas. They are worth knowing, because they are how auditors and lawyers talk about this.
Fail the first and nothing after it matters: someone who cannot perceive your content has nothing to operate.
Accessibility — 21 checks, 165 points
Weighted by who gets shut out, not by how hard it is to fix. An unlabelled form field costs more than a missing table header because it stops someone buying from you.
Where the points sit
The four in yellow are the ones that shut people out of doing something, rather than making it harder.
-
Do images describe themselves?
15What we look for. Every image, checked for a text alternative - and for alt text that is really a filename or the word 'image'.
Why it matters. The most cited failure in accessibility complaints. To someone using a screen reader, an undescribed image is either silence or a filename read out letter by letter. An image that carries no meaning should say so, with an empty alt, so it is skipped rather than announced.
-
Is every form field labelled?
15What we look for. Each input, select and textarea, checked for a label a machine can connect to it.
Why it matters. This is where inaccessibility costs money. An unlabelled checkout field is announced as 'edit text' and nothing more, so the person cannot tell what to type. They do not complain - they leave. A placeholder does not count: it disappears the moment someone types.
-
Does everything work without a mouse?
14What we look for. Controls that respond to a click but cannot be reached or activated by keyboard, and anything that scrambles the tab order.
Why it matters. Someone with a tremor, a motor impairment, or using a screen reader drives the page entirely from the keyboard. A div wired up to a click handler is invisible to all of them - it is not a control, it just looks like one.
-
Is the text readable against its background?
12What we look for. Colour pairs declared in your stylesheets, measured against the 4.5:1 minimum for normal text.
Why it matters. One of the two most common reasons a site fails an audit. It affects far more people than most owners expect - anyone over about forty, anyone with reduced vision, and everyone trying to read a phone in sunlight.
-
Do the headings make a sensible outline?
10What we look for. One h1 per page, and levels that descend in order without skipping.
Why it matters. Headings are how most screen reader users skim. Pull up the heading list on a page with none, or with levels jumping about, and there is nothing to navigate by - you have to listen to the whole thing.
-
Is the accessibility markup sound?
10What we look for. Roles that actually exist, and aria attributes that point at elements that are really there.
Why it matters. Broken ARIA is worse than none at all. A screen reader repeats what it is told, so a mistyped role means it confidently describes the page wrongly, and the person has no way to know.
-
Can people enlarge the text?
8What we look for. The viewport tag, for settings that stop pinch-zooming.
Why it matters. One line of code decides whether someone with low vision can read your site at all. It is usually copied in from a template without anyone meaning to block anything.
-
Do video and audio have captions?
8What we look for. Whether a caption or subtitle track is declared. Decorative silent video is exempt.
Why it matters. Without captions, deaf and hard of hearing visitors get nothing from your video. We can see whether a track exists; whether the captions are accurate needs a person to watch them.
-
Can keyboard users see where they are?
8What we look for. Stylesheet rules that remove the focus outline without putting a visible replacement back.
Why it matters. Remove the focus ring and a keyboard user is navigating blind - tabbing with no idea what they are about to activate. It is usually removed for looks, and it is easy to restyle rather than delete.
-
Does link text say where it goes?
8What we look for. Links reading 'click here' or 'read more', and links with no readable text at all.
Why it matters. Screen reader users often pull up a list of every link on the page, stripped of its surroundings. Twelve entries all reading 'read more' is a useless list.
-
Can people skip to the content?
6What we look for. Whether the page marks out its main content and navigation.
Why it matters. Landmarks let someone jump straight to what they came for instead of sitting through the header and menu on every single page.
-
Does the page declare its language?
6What we look for. A valid lang attribute on the html element.
Why it matters. Without it a screen reader guesses, and English read in a French voice is close to unintelligible. It costs one attribute.
-
Does each page have its own title?
6What we look for. Titles that exist, say something, and differ from one another.
Why it matters. The title is the first thing announced when a page opens, and how anyone tells one tab from another.
-
Are required fields explained?
6What we look for. Required fields, checked for an explanation a screen reader can read.
Why it matters. Marking a field required with a red asterisk and nothing else means people find out only after the form is rejected - and often cannot tell which field caused it.
-
Do tables have proper headers?
5What we look for. Data tables, checked for header cells.
Why it matters. Read aloud, a table without headers is a stream of numbers with nothing to say what any of them refer to.
-
Is there a skip link?
5What we look for. A link near the top of the page that jumps past the navigation.
Why it matters. Without one, every visit means tabbing through the whole menu again before reaching the content.
-
Are element identifiers unique?
5What we look for. Duplicate id values across each page.
Why it matters. Browsers take the first and ignore the rest, so a duplicate id can silently detach a label from its field.
-
Does anything play sound by itself?
5What we look for. Media set to autoplay without being muted.
Why it matters. Sound starting on its own talks over a screen reader, and the person cannot hear well enough to find the control to stop it.
-
Can browsers fill in known details?
5What we look for. Fields asking for names, addresses and the like, checked for an autocomplete hint.
Why it matters. Autofill is a real saving for anyone with a motor or memory difficulty. Leaving the hint off makes them type it all again.
-
Are messages announced?
4What we look for. Whether pages with forms have a region set up to announce updates.
Why it matters. A confirmation that appears without reloading is shown silently. Unless it is in a live region, a screen reader user never learns it happened.
-
Are tap targets big enough?
4What we look for. Reported for checking by hand - real target size depends on padding and layout, which cannot be resolved from a stylesheet.
Why it matters. Small targets are hard for anyone with a tremor and fiddly for everyone on a phone. We would rather tell you to check it than guess and be wrong.
Legal Readiness — 4 checks, 70 points
What the law asks for beyond the technical criteria. A site can meet every criterion and still fall short of the UK and EU rules by having no accessibility statement.
-
Is there an accessibility statement?
25What we look for. A statement page, or a link to one.
Why it matters. Required of public bodies in the UK and across the EU, and the first thing an auditor looks for anywhere else. It is also the clearest way to show you have taken the issue seriously, which matters if anyone ever asks.
-
Does the statement say what it must?
20What we look for. Whether it covers conformance, known problems, how to report a barrier, what to do if you are not satisfied, and when it was reviewed.
Why it matters. The UK regulations set out this list. A page headed 'Accessibility' with two sentences under it does not meet it.
-
Can people tell you about a barrier?
15What we look for. How many ways there are to make contact.
Why it matters. Offer at least two, because the barrier someone is reporting may be the contact form itself. Having no route at all is its own failing under the UK and EU rules.
-
Is the statement dated?
10What we look for. A date on the statement saying when it was prepared or reviewed.
Why it matters. An undated statement tells a regulator you stopped looking. It should be reviewed at least once a year.
The laws, and who they apply to
Nine sets of rules across the places most people trade. Which apply to you depends on where you sell and who you are, not on where your server sits.
-
European Accessibility Act
European UnionApplies to. Private businesses selling into the EU - e-commerce, banking, transport, e-books and consumer devices - as well as the public sector. It reaches companies based outside the EU that sell into it.
Standard. EN 301 549, which incorporates WCAG 2.1 Level AA
In force. 28 June 2025. Products already on the market have until 28 June 2030, as long as they are not substantially changed.
-
Web Accessibility Directive
European UnionApplies to. Public sector websites and mobile apps.
Standard. EN 301 549 / WCAG 2.1 Level AA
In force. 2016, in force across member states. Also requires a published accessibility statement.
-
Equality Act 2010
United KingdomApplies to. Every business and organisation providing goods or services to the public.
Standard. No standard named in law. WCAG is how you show a court or regulator that you took reasonable steps.
In force. 2010. The duty is to make reasonable adjustments. There is no compliance certificate to earn - what matters is whether you can show you acted.
-
Public Sector Bodies Accessibility Regulations 2018
United KingdomApplies to. Public sector websites and mobile apps.
Standard. WCAG 2.2 Level AA
In force. 2018. A published accessibility statement is mandatory, and must say how well the site conforms and how to report problems.
-
ADA Title II
United StatesApplies to. State and local government, public universities, courts and special districts.
Standard. WCAG 2.1 Level AA
In force. Rule published April 2024. Deadlines were put back a year in April 2026: 26 April 2027 for public bodies serving 50,000 or more people, 26 April 2028 for smaller ones.
-
ADA Title III
United StatesApplies to. Businesses open to the public.
Standard. No standard named in law. Courts have generally treated WCAG 2.1 AA as the benchmark.
In force. 1990. This is where most US web accessibility lawsuits are brought.
-
Section 508, Rehabilitation Act
United StatesApplies to. Federal agencies, and anyone selling technology to them.
Standard. WCAG 2.0 Level AA
In force. Refreshed 2017. Matters commercially: failing it can rule you out of federal contracts.
-
Accessible Canada Act, and AODA in Ontario
CanadaApplies to. Federally regulated organisations; in Ontario, most businesses with 50 or more employees.
Standard. WCAG 2.0 Level AA
In force. AODA web requirements since 2021. Ontario requires larger organisations to file an accessibility compliance report.
-
Disability Discrimination Act 1992
AustraliaApplies to. Anyone providing goods, services or facilities.
Standard. WCAG 2.1 Level AA, through government guidance
In force. 1992. Government services are held to WCAG 2.1 AA by the Digital Service Standard.
How the scoring works
Each check returns green, amber or red and earns all, some or almost none of its points. Your percentage is what you earned out of what was available. Findings are ordered worst first and heaviest first, so the top of your report is always the thing most worth doing.
Where something cannot be measured, we say so rather than guessing. If no colour pair is declared together in your stylesheets, we tell you it needs checking by hand instead of inventing a result.
Run a scan, or read our own accessibility statement - a tool that marks other people down for not having one ought to have its own.