How to Check If Your Website Is Accessible (Free + Paid)

Have you ever wondered if your website actually works for everyone who visits it? Not just the people on a desktop with perfect vision and a fast mouse, but the person navigating with a screen reader, the colleague with low vision, the user on a phone whose thumb keeps missing your tiny "close" button?

If you have, you are already further along than most site owners. The next step is figuring out how to actually check. And here's the thing - you do not need to spend a penny or hire a consultant to find the majority of the issues. You just need to know where to look. This guide walks through exactly how I check sites for accessibility, in the order I run the checks, with the free tools I rely on and the manual tests no tool can replace.

The quick answer: how do I check if my website is accessible?

To check if your website is accessible, run an automated WCAG checker (Lighthouse, axe DevTools, or WAVE), then manually test five things: keyboard-only navigation, colour contrast, screen reader behaviour, image alt text, and form labels. Automated tools catch about 30-40% of accessibility issues, so the manual checks are what find the rest.

That is the whole playbook. The next sections unpack each step with the specific tools and shortcuts that make this a 30-minute job per page rather than a half-day audit.

What does "accessible" actually mean?

A website is accessible when it can be used by people with disabilities - including those with visual, auditory, motor, and cognitive impairments - to the same level as everyone else. The international standard for measuring this is the Web Content Accessibility Guidelines (WCAG), currently at version 2.2.

WCAG breaks into four principles: content must be Perceivable (people can sense it), Operable (people can use it), Understandable (people can comprehend it), and Robust (it works with assistive technologies). Every test in this guide maps back to one of those four.

If you only remember one thing: accessibility is not about disability, it is about removing friction. A site that works well with a screen reader also tends to work well on a slow connection, on a small screen, and for search engines. It is a quality signal that benefits everyone.

Step 1: Run an automated accessibility checker

To run an automated accessibility check, open Chrome DevTools (right-click, Inspect), go to the Lighthouse tab, tick "Accessibility", and click "Analyse page load". You will get a score 0-100 and a list of specific failures with code snippets. The whole scan takes under 30 seconds.

I run three automated tools as a baseline because each catches slightly different issues:

Lighthouse - built into Chrome, no install needed, gives a single accessibility score and grouped failures
axe DevTools - browser extension by Deque, catches more issues than Lighthouse, especially around ARIA misuse
WAVE - WebAIM's free online checker, visualises issues directly on the page

Running all three on the same page takes about 5 minutes and produces a deduplicated list of programmatic failures. This catches things like missing alt text, low contrast colours, empty links, missing form labels, and broken heading hierarchy.

Important caveat: Lighthouse gives you a score out of 100. A score of 100 does not mean your site is accessible. It means there are no failures the automated tool could detect. The WebAIM Million report consistently finds that about 96% of homepages have detectable WCAG failures, and even the ones that pass automated tests still typically have issues that only manual testing catches.

If you would rather automate the whole 6-pillar audit (accessibility, SEO, security, performance, content quality, AI readiness) on a schedule, Kritano runs all three engines plus our own checks and tracks scores over time. But for a one-off audit, Lighthouse alone is a solid starting point.

Step 2: Test your site with the keyboard only

To test keyboard accessibility, click in the address bar, then use only the Tab, Shift+Tab, Enter, Space, and arrow keys to navigate the page. You should be able to reach every interactive element (links, buttons, form fields) in a logical order, see a clear focus indicator on whatever is currently selected, and activate every control without touching the mouse.

This is the single most revealing manual test I know. About 30 seconds in, you will find at least one of:

A button you cannot reach with Tab (probably a custom div that should be a real <button>)
A "skip to content" link that does not appear when you Tab from the top
A dropdown menu that opens on hover but cannot be opened with keyboard
A modal dialog that does not trap focus, so Tab takes you to elements behind it
A focus indicator so faint you cannot tell what is selected

If you cannot complete the most important task on your site (sign up, contact, buy) using only the keyboard, your site is failing roughly 8% of users who navigate this way by necessity - and a much larger group who do so by preference.

A quick fix for missing focus indicators: never remove the browser default outline in CSS without replacing it with something equally clear. The pattern I use is :focus-visible { outline: 3px solid #4F46E5; outline-offset: 2px; }.

Step 3: Check colour contrast

To check colour contrast, open Chrome DevTools, inspect any text element, and look at the "Contrast" line under the colour swatch in the Styles panel. It will tell you the current ratio and whether it passes WCAG AA (4.5:1 for normal text, 3:1 for large text) or AAA (7:1 and 4.5:1).

For a faster sweep, use a dedicated tool:

WebAIM Contrast Checker - paste two hex codes, get a verdict
axe DevTools - flags every contrast failure on the page in one pass
Chrome DevTools' Rendering panel has a "Emulate vision deficiencies" option (Blurred vision, Achromatopsia, Deuteranopia) that lets you see the page through different impairments

The biggest contrast offender I see on small business sites is placeholder text in form fields. Most CSS frameworks default to a placeholder colour around #9CA3AF on white, which scores 2.85:1 - failing AA. Bump it to #6B7280 or darker and you are compliant.

The second offender is light grey body text on white - a design trend that has been around since 2014 and that quietly fails accessibility on most sites that use it. WCAG AA needs 4.5:1 for body text. If you are using #999 on #FFF you are at 2.85:1, well below compliant.

To test with a screen reader, turn on the one built into your operating system (VoiceOver on Mac with Cmd+F5, Narrator on Windows 11 with Ctrl+Win+Enter, NVDA on Windows as a free download) and navigate your homepage by listening rather than looking. You should hear meaningful announcements for headings, links, buttons, and images, in a logical reading order, without dead ends or repeated "link" "link" "link" with no context.

Honestly, the first time you do this it is uncomfortable. You realise how much of your page the screen reader announces as "image, image, image, link, link, link" with no actual information. That is the experience your screen-reader users have on every visit.

A few things to listen for:

Headings: press the heading-navigation shortcut (H in NVDA, Ctrl+Option+Cmd+H in VoiceOver) and listen to your H1, H2, H3 list. Does it tell a story without seeing the page? If not, your heading hierarchy needs work.
Links: a screen reader can pull up all links on a page in a flat list. If yours is full of "click here", "read more", "more info", screen reader users have no idea where any of them go.
Images: every meaningful image should announce its alt text. Decorative images should be silent (empty alt="").
Forms: each input should announce its label. If you hear "edit, blank" with no label, your form is broken for screen reader users.

You do not need to learn the full set of screen reader shortcuts. Five minutes of basic navigation tells you 80% of what is wrong. Deque has a free cheat sheet for VoiceOver and NV Access publishes one for NVDA that fit on a single page.

Step 5: Spot-check images, forms, and links

To spot-check the three highest-failure areas, do this: open your page source (Ctrl+U / Cmd+Option+U), search for <img and verify every image has either a meaningful alt attribute or alt="" if decorative. Then search for <input and verify every input has a <label> or aria-label. Finally, search for >here< and >read more< to find vague link text.

These three patterns alone account for the majority of WCAG failures on most sites:

Images without alt text is the single most common WCAG failure according to the WebAIM Million - present on about 56% of homepages
Form inputs without labels are the next most common
Ambiguous link text ("click here", "more") fails WCAG 2.4.4 and confuses screen reader users

If you want a one-page reference for the 20 most-common WCAG failures and the exact fix for each, we have packaged them into a free WCAG quick reference card - it covers everything in this list plus 15 more.

The limits of automated testing (what tools miss)

Automated accessibility tools catch roughly 30-40% of WCAG issues. They are excellent at detecting machine-checkable failures (missing alt, low contrast, missing labels) and useless at detecting judgment-based failures (is this alt text meaningful, is this heading hierarchy logical, does this language change match the content).

A site can score 100 in Lighthouse and still be unusable with a screen reader. I have audited several that did exactly that. The tool checked that every image had alt text - it did not check that the alt text was "image.png".

This is why I never deliver an accessibility report based on automated scores alone. The score gets you started. The keyboard test, screen reader test, and spot checks find the issues that actually matter.

If you want context on why the 96% failure rate has barely moved in five years despite better tooling, the state of web accessibility in 2026 goes into the specifics.

How often should you check accessibility?

Check accessibility every time you ship new content or features, and run a full audit at least quarterly. Major redesigns or framework migrations require a full re-audit because component-level changes often introduce new ARIA mistakes that did not exist before.

Practically, that breaks down as:

Per pull request: run Lighthouse (CI-friendly) or axe-core against changed pages. Catches regressions before they hit production.
Monthly: spot-check 3-5 high-traffic pages with keyboard + screen reader.
Quarterly: full audit of the whole site, ideally against the current WCAG 2.2 AA standard, with a written report and fix tickets.
On any major change: redesign, new framework, new CMS, new third-party widget - assume nothing carried over correctly and re-audit.

The trap most teams fall into is treating accessibility as a one-off compliance project. A site is accessible at a point in time. It stops being accessible the next time you push an "improvement" without checking.

Common accessibility issues to look for first

The five highest-impact issues to check before anything else are: missing alt text on meaningful images, form inputs without programmatic labels, colour contrast failures on body text and buttons, links and buttons that cannot be reached with the keyboard, and missing or skipped heading levels.

Beyond those, the next tier I look for:

Modal dialogs that do not trap focus or do not announce themselves to screen readers
Custom dropdowns and tabs built with divs instead of native <select> or <button> elements
Auto-playing video or audio without a clear way to pause
Cookie banners that trap focus or cannot be dismissed with the keyboard
Accessibility overlay widgets - despite the marketing, these widgets do not make a site accessible and frequently make things worse for actual screen reader users

That last one matters because the overlay industry is huge. If a vendor is selling you a one-line script that "makes your site WCAG compliant", they are lying to you. Real accessibility comes from the underlying code, not a JavaScript overlay.

The bottom line

Checking if your website is accessible is genuinely a one-evening job for a single page, and a one-day job for a small site. The tools are free, the manual tests are simple, and the impact is significant - both for the users who actually need accessibility and for SEO, since accessible sites consistently rank higher.

If you want the full picture of where accessibility fits into a wider site audit, the complete guide to web accessibility goes into the WCAG framework, the legal landscape (including the recent ADA deadline extension), and the tools worth paying for if you want to automate this.

If you just want a quick scan right now, Kritano runs a free accessibility audit alongside checks for SEO, security, performance, content quality, and AI readiness, and tracks your scores over time so you can see what is getting better and what is not. Either way, the next 30 minutes of keyboard-only navigation on your own site will teach you more about your visitors' experience than any audit report.

FAQs

How do I check if my website is accessible?

Check your website's accessibility by running an automated checker (Lighthouse, axe DevTools, or WAVE) and then manually testing five things: keyboard-only navigation, colour contrast, screen reader compatibility, image alt text, and form labels. Automated tools catch 30-40% of issues, so the manual checks find the rest. The whole process takes about 30 minutes per page.

What is the best free accessibility checker?

The best free accessibility checkers are Lighthouse (built into Chrome DevTools), axe DevTools (browser extension by Deque), and WAVE (online tool by WebAIM). Each catches slightly different issues, so running all three on the same page produces the most thorough automated baseline. None of them replaces manual testing.

How accurate are automated accessibility tools?

Automated accessibility tools detect roughly 30-40% of WCAG failures. They reliably catch machine-checkable issues like missing alt attributes, low colour contrast, and missing form labels, but they cannot assess judgment-based criteria like whether alt text is meaningful, whether headings tell a logical story, or whether the experience makes sense for a screen reader user. A perfect automated score does not mean a site is accessible.

Can I check accessibility without any tools?

You can do a meaningful accessibility check without any tools by using only your keyboard to navigate the site and turning on your operating system's built-in screen reader (VoiceOver on Mac, Narrator on Windows). These two manual tests reveal the issues that automated tools cannot detect: keyboard traps, missing focus indicators, illogical reading order, and uninformative announcements. Together they find issues that account for a significant portion of real-world accessibility complaints.

What does WCAG mean and which version should I check against?

WCAG stands for Web Content Accessibility Guidelines - the international standard for web accessibility, published by the W3C. The current version is WCAG 2.2, released in October 2023, and you should check your site against WCAG 2.2 Level AA. Level AA is the legal compliance baseline in most jurisdictions including the EU's European Accessibility Act and US ADA Title III guidance.