Free Website Accessibility Checker
Automated testing catches roughly a third of the WCAG success criteria — the mechanical ones, in the markup. This checks that third on any page you give it, names what it found and what to do about it, and is straight with you about the two thirds that still need a person with a keyboard and a screen reader.
What this checks
Alt attributes: images with no alt attribute at all, images correctly marked as decorative with alt="", and alt text that is a filename or starts with "image of".
Form labels every input, textarea, and select, and whether each one has a label a screen reader can find — a label for, a wrapping label, or an aria-label.
Link purpose links with no text, no image alt and no aria-label, and links that read "click here" or "read more" and mean nothing out of context.
Heading outline: whether the levels step down one at a time or jump from H2 to H4, which is how a screen reader user meets a missing section.
Skip link: whether a "skip to content" link sits near the top of the document so a keyboard user does not tab through the whole menu on every page.
Landmarks: main, nav, header, and footer regions, which assistive technology offers as a shortcut menu instead of one long ribbon of text.
Tab order and focus traps: positive tabindex values that pull elements to the front of the tab order, and aria-hidden containers that still contain focusable links and buttons.
Page language: the lang attribute on the HTML tag, which decides how a screen reader pronounces every word on the page.
Frames and media iframes with no title — maps and video embeds, usually — and video or audio set to autoplay without being muted.
Zoom and text size a viewport tag that disables pinch zoom, body text below the readable floor, and tap targets too small to hit reliably.
What automated accessibility testing can and cannot find
Start with the number, because everything else depends on it. Automated tools find roughly a third of the WCAG success criteria. That figure is well established, and it has not moved much in years, and it is not a limitation of this particular tool — it is what happens when you ask software to judge things that are questions of meaning and behaviour rather than markup.
A machine can tell you an image has no alt attribute. It cannot tell you whether alt=" team photo" describes the chart you actually used the image for. It can tell you a form field has no label. It cannot tell you whether the label makes sense, whether the error message is announced when validation fails, or whether the custom dropdown three fields down can be opened with a keyboard at all. It can read a heading outline; it cannot tell you the page makes sense when read in order.
So treat a clean result here as what it is: the mechanical faults are not present. That is genuinely worth having, because the mechanical faults are the ones that turn up everywhere and are cheapest to fix. The other two-thirds need someone to put the mouse down, tab through the page from the top, and then listen to it with a screen reader. That is a couple of hours of work by a person, and there is no software substitute for it.
The four faults behind most real barriers
Large-scale surveys of the web find the same small group of failures on the overwhelming majority of home pages, year after year. Between them they account for most of what actually stops someone using a site. Three of the four are visible in markup, which is why this tool finds them. The fourth is not, and that matters. None of them is difficult and none of them is expensive. They persist because nobody is looking: the person building the page can see it, so the alt text goes unwritten and the label gets left as a placeholder. Clearing these four is the bulk of the mechanical work on a typical small business site.
- Missing alt text: an image with no alt attribute is read out as its filename, so the listener hears "IMG_4471.jpg" when you meant them to see your work. Add it in the media library, and it applies everywhere the image is used. alt="" is the correct answer for decoration and is not the same as leaving it out.
- Unlabelled form fields: the screen reader announces "edit text," and the visitor guesses. Placeholder text does not fix it, because a placeholder vanishes the moment someone types. This is the most common serious fault there is, and it lands on the contact form — the page that is supposed to earn you money.
- Links with no discernible text, icon links in headers and social icons in footers, announced as "link" and nothing else. Screen reader users commonly pull up a list of every link on a page to navigate it, and that list is where "read more" repeated nine times becomes unusable.
- Poor colour contrast: light grey text on white, and pale text over a photograph. This one cannot be checked from markup — the colours come from stylesheets, inherited rules, and images — so it is not in this report. Run your palette through a contrast checker such as the WebAIM one, and aim for 4.5:1 on body text.
Accessibility and SEO are largely the same work
This surprises people and it should not. A search engine crawler and a screen reader are both software reading a page without seeing it. They want the same things from your markup, for the same reason, and the overlap is big enough that most accessibility work pays for itself twice.
Alt text describes an image to a listener and to Google Images at once. Descriptive link text tells a screen reader user where a link goes and hands a search engine the anchor text signal it uses to work out what the linked page is about. A heading outline that steps down one level at a time gives assistive technology a table of contents and gives a crawler the structure of your argument. Semantic landmarks — main, nav, header, footer — tell both which part of the page is the content and which part is furniture repeated on every page.
Which is why this tool runs the on-page SEO checks alongside the accessibility ones and shows them together. It is not padding. If you fix the findings in this report you will have improved both, and if somebody tells you accessibility is a cost with no return, they have not noticed that they are describing the same afternoon of work twice.
A plain word about accessibility overlays
Overlays are the widgets sold as one line of JavaScript that makes a site accessible — usually a little person-shaped button in the corner that opens a panel of contrast and font-size controls. They are marketed hard, often with the suggestion that installing one protects you from being sued. It is worth knowing what disability advocates think of them before you buy one.
What they think is documented, public, and blunt. Thousands of accessibility professionals and screen reader users have signed an open letter asking that overlays not be used, and the objections are consistent: the tools they duplicate are already built into the operating system and the browser, the automatic repairs frequently guess wrong and make the underlying markup harder to use rather than easier, and the widget itself can interfere with the screen reader the visitor has already set up the way they want it. Some users now block these scripts on sight.
The uncomfortable part is that an overlay does not touch the code underneath. The alt text is still missing, the form field is still unlabelled, the dropdown still cannot be opened from a keyboard — there is now a widget sitting on top of all of it. Fixing the markup costs more and takes longer, and it is the only thing that actually helps the person trying to use your website.
What this accessibility checker cannot see
It reads the HTML your server sends for one page. It does not render the page, does not run your JavaScript, does not operate anything and does not listen to the result. So colour contrast is out of reach, because the colours live in stylesheets and images. Focus order is out of reach, because it depends on how the rendered page behaves. Whether a modal traps focus, whether an error is announced, whether a carousel can be paused, whether your alt text is true — all of that needs somebody to try it.
This does not test your site against a legal standard and it does not certify anything. No automated tool can, whatever it says on the box. A page with no findings here has passed the mechanical checks a machine can perform; it has not been assessed against WCAG, it has not been reviewed by an accessibility specialist, and it should not be described to anyone as compliant on the strength of this report.
Use it the way it is meant: as the first pass that clears the cheap faults and tells you whether the site has been thought about at all. Then do the part that matters. Unplug the mouse and tab through the page from the top — you will find the invisible focus outline and the menu you cannot open inside two minutes. Then turn on VoiceOver on a Mac or NVDA on Windows, both free, and try to send yourself an enquiry. That half hour will teach you more than any report, including this one.
Questions people ask
Does this make my site WCAG compliant?
No. It cannot, and neither can any other automated tool. Automated testing covers roughly a third of the WCAG success criteria, so passing every check here tells you the mechanical faults a machine can detect are absent — nothing more than that.
Conformance is a claim about the whole site measured against a specific standard at a specific level, and reaching it takes manual testing with a keyboard and a screen reader, judgement about content that software cannot make, and usually a specialist review documented in an accessibility statement. Treat this report as a starting point that finds the obvious problems, and treat any tool that offers you a compliance badge for running a scan with suspicion.
Do I legally have to make my website accessible?
It depends on where you are, what sector you are in and who you serve, and this is not legal advice. Public sector bodies in the UK and the EU have had explicit obligations for years. Broader equality and disability discrimination law is widely understood to apply to services delivered online, and in some countries — the United States most visibly — a great deal of litigation has followed from that. Other jurisdictions have their own rules and their own deadlines.
If the answer matters to your business, ask a solicitor who works in this area rather than a web agency or a scanning tool. What we would say regardless of the law is that the work is worth doing, it overlaps almost entirely with good SEO and good usability, and the sites that get into trouble are usually the ones where nobody ever looked.
Are accessibility overlay widgets a fix?
The people the widgets are sold on behalf of say no, loudly and in writing. Thousands of accessibility professionals and assistive technology users have signed a public open letter asking organisations not to use them, and screen reader user surveys consistently report that overlays help very few people and actively get in the way of some.
The core problem is that an overlay leaves the underlying code untouched. Your unlabelled form field is still unlabelled; there is now a script trying to guess a label for it. Spend the same money on fixing the markup — it helps everyone, it does not interfere with the assistive technology your visitor has already configured, and it does not need renewing every year.
Why does this not check colour contrast?
Because contrast cannot be judged from markup. The colour of a piece of text is the end result of stylesheets, inherited rules, custom properties, a builder's design system, and sometimes a background image, and none of that is knowable without rendering the page as a browser would.
Check it directly instead. Put your text and background colours into a contrast checker such as the WebAIM one, or use the contrast readout built into Chrome and Firefox developer tools, which samples the rendered pixels. Aim for at least 4.5:1 on body text and 3:1 on large headings. The two places it usually fails are pale grey placeholder text and white text laid over a photograph.
Is this accessibility checker free?
Yes, on any page you like, within a fair-use limit that stops it being used as a bulk scanning service. No account, nothing to install, no trial that expires.
Do I have to give you my email address?
The score, the breakdown and the first few findings are shown to everyone. The rest of the fix list asks for an email address, because that is how a free tool pays for itself. You are never asked twice, and the findings are the same whether or not you hand it over.
Does running this change anything on my site?
No. It requests the page the way a visitor does and reads the HTML that comes back. It does not log in, does not submit forms, does not install anything and does not alter a single file. Nothing about your site is different after running it.
I have a long list of findings. What should I fix first?
Form labels first, every time. An unlabelled field on a contact or checkout form is the fault that stops someone completing the thing your site exists to do, and it is usually a ten-minute fix in whichever form plugin you use. Then the images with no alt attribute, starting with the ones that carry information rather than decoration.
After that, links that announce nothing — normally the social icons in the footer, fixed with an aria-label each. Then the page language attribute and the skip link, both one-line changes that apply across the entire site. Heading order and landmarks come next, and they usually get sorted as a side effect of the first four.
Want the other two-thirds checked by a person?
We fix the findings in this report and then go through the page properly — keyboard only, then with a screen reader — which is the only way to know how it behaves for someone using one. Send us the address and we will tell you what we found and what it would take to put right.
