You do not need a developer or a special tool to find many accessibility problems on your website. You need a keyboard, a phone, about an hour and a list of what to look for.
The eleven tests below come from the Web Content Accessibility Guidelines, WCAG 2.2, the W3C standard most organisations aim for at level AA. Each test says what to check, how to check it and how to fix what you find. Mark each one Pass, Fail or Not sure as you go, and the board builds your list of fixes.
Accessible sites work better for everyone. Clear labels, readable contrast and pages that work without a mouse help a tired buyer on a phone as much as someone using a screen reader.
A note on the law. Rules differ by country and by what you sell. In the EU, for example, the European Accessibility Act has applied since 28 June 2025 to certain products and services, including e-commerce services for consumers, with an exemption for microenterprises that provide services. Check what applies to you with a specialist; this checklist is not legal advice.
The short answer
You can find many accessibility problems yourself in about an hour: use the page with a keyboard only, check text contrast, zoom to 200 percent, read the alt text and headings, and test your links, forms, videos, page language and tap targets. The tests map to WCAG 2.2, the W3C standard. They will not prove a site is accessible, but they show you where to start.
0 of 0 tests run
Pick one important page, such as your home page or contact page, and run each test on it.
Keep going. Mark "Not sure" when you cannot tell; those are worth a closer look by a specialist.
One test to go.
All eleven tests run. Start with anything marked Fail, in the order shown under "Fix these first".
0 pass0 fail0 not sure
Fix these first
1. Use the whole page with a keyboard
Some people cannot use a mouse, and many screen reader users move around a page with the keyboard. If a menu, a slider or a form only works with a mouse, it does not work for them. WCAG covers this under Keyboard.
How to test
Put the mouse aside. Press Tab to move forward and Shift and Tab to go back. Use Enter to follow links and press buttons, Space to tick boxes, and the arrow keys inside menus and radio groups.
Can you reach and use every link, menu, field and button? Can you close pop-ups and the chat window with Esc?
How to fix
- Use real links and buttons instead of clickable boxes.
- Make menus open with Enter, not only on hover.
- Make sure focus never gets stuck inside a pop-up.
2. Always see where you are
Keyboard users need to see which element they are on. WCAG asks for a visible focus indicator, and version 2.2 added that the focused element must not be completely hidden by other content, such as a sticky header or a cookie banner.
How to test
During the keyboard test, watch the outline or highlight on each element. Does it ever disappear? Does a sticky header, a cookie banner or a chat button cover the item you are on?
How to fix
- Never remove the browser's focus outline without a clear replacement.
- Add scroll padding so sticky headers do not cover focused items.
3. Check text and icon contrast
Low contrast is easy to miss on a good monitor indoors and hard to read on a phone in daylight. At level AA, WCAG asks for a contrast ratio of at least 4.5 to 1 for normal text and 3 to 1 for large text, and 3 to 1 for icons, input borders and other parts of the interface people need to see.
Large text means at least 18 point, or 14 point bold. W3C's explanation of the contrast rule puts that at roughly 24 pixels, or about 18.5 pixels in bold, on screen.
Free tool
Colour contrast checker
Enter your text and background colours as hex codes, or pick them. The ratio is never rounded up, so a result just under a threshold fails, as it should.
Enter each colour as a hex code, such as #1D1936.
Large text sample
Normal text sample: request a quote for your next project.
Contrast ratio 4.54 to 1
- Normal text, level AA (4.5 to 1)Pass
- Large text, level AA (3 to 1)Pass
- Icons, borders and form fields (3 to 1)Pass
- Normal text, level AAA (7 to 1)Fail
- Large text, level AAA (4.5 to 1)Pass
How to test
Check body text, pale grey captions, placeholder text, text over images, button labels and links. Test your brand colours too, especially light ones.
How to fix
- Darken the text or lighten the background.
- For text over photos, add a solid or semi-transparent panel behind it.
4. Zoom to 200 percent, then narrow the window
Many people enlarge text to read comfortably. WCAG asks that text can be resized to 200 percent without losing content or function, and that content reflows at a width of 320 CSS pixels without scrolling in two directions.
How to test
Press Ctrl and + (Cmd and + on a Mac) until the browser shows 200 percent. Then go to 400 percent on a desktop browser, which is close to a 320 pixel wide screen. Can you read everything without scrolling sideways? Does anything overlap or vanish?
How to fix
- Use responsive layouts.
- Avoid fixed heights on boxes that hold text.
- Never put important text inside images.
5. Give images useful alt text
Screen readers read out an image's alt text. Without it, a chart, a product photo or a linked logo becomes silence, or worse, a file name. WCAG covers this under Non-text Content.
How to test
Right-click an image and choose Inspect, or use an accessibility browser extension, to read each alt attribute. Informative images should describe what matters. Decorative images should have empty alt text, written alt="". A linked logo should say where it goes.
How to fix
- Write alt text for meaning, not keywords: "Calibration lab with three test benches" beats "image1" or "lab".
- Mark purely decorative images with empty alt text so screen readers skip them.
6. Use headings in a logical order
Screen reader users jump from heading to heading to scan a page, the way sighted readers skim. That only works when headings are real heading tags, in a sensible order, that describe the section that follows. Structure shown visually must also be available in the code.
How to test
List the headings with a headings extension or your browser's accessibility panel. Is there one H1 that names the page? Do the levels follow in order? Is any large bold text pretending to be a heading?
How to fix
- Choose heading levels for structure, then style them however you like.
- Turn bold paragraphs that act as headings into real headings.
7. Make every link make sense
Screen reader users can bring up a list of every link on a page. Ten links that all say "Read more" tell them nothing. WCAG asks that the purpose of each link is clear from its text, or from its text together with the surrounding context.
How to test
Search the page for "click here", "read more" and "learn more". Would someone hearing only the link text know where each one goes?
How to fix
- Put the destination in the link: "Read the calibration case study" instead of "Read more".
- Make links look like links, not only by colour.
8. Label every field and explain every error
Forms are where accessibility problems cost enquiries directly. Every field needs a label or instructions, and when something goes wrong, the error must be identified and described in text.
How to test
Click each label: does it put the cursor in its field? Submit the form empty. Are the errors described in words next to the right fields, or only shown as a red border? Does the hint inside a field vanish as soon as you start typing, taking the instructions with it?
How to fix
- Use visible labels; placeholder text is not a label.
- Write errors that say what to do: "Enter a work email, such as name@company.com".
- Keep what people typed when an error appears.
9. Caption videos and let people stop motion
Videos with speech need captions. Audio that plays on its own for more than three seconds needs a way to pause it or turn it down. And carousels or animations that move for more than five seconds need a way to pause, stop or hide them.
How to test
Play each video with the sound off. Are there accurate captions, not just unedited automatic ones? Does anything move or play without you asking? Can you stop it?
How to fix
- Correct automatic captions before you publish.
- Add pause controls to carousels and background video, or remove the motion.
10. Set the page language
Screen readers use the page's language setting to choose how words are pronounced. Without it, a French page may be read aloud with English rules. It is a one-line fix in your template.
How to test
View the page source and look at the html tag on the first lines. It should carry a lang attribute, such as lang="en", with the right code on each language version.
How to fix
- Set lang in the site template, per language version.
- Google does not use this attribute to detect language, but screen readers do. For the search side, see our international SEO checklist.
11. Make tap targets big enough
Small buttons are hard to hit with a finger, and harder still for people with a tremor. WCAG 2.2 added a minimum target size of 24 by 24 CSS pixels, with exceptions such as links inside a sentence and targets with enough space around them.
How to test
On a phone, try the small things: close buttons, social icons, pagination, checkboxes and footer links. Do you ever hit the wrong one?
How to fix
- Add padding around small icons and links.
- For main buttons, go well beyond the minimum.
Then Run an Automated Check
Automated checkers are fast and catch problems you might miss, such as missing labels in code. They cannot do the job alone: W3C is clear that evaluation tools can only assist a person in judging accessibility. Use one alongside the tests above, not instead of them.
- Lighthouse in Chrome: open DevTools, choose Lighthouse and run the accessibility category on each page template.
- W3C's Easy Checks: the first review guide from W3C covers several of these tests in more depth.
- A specialist audit: worth it for web applications, complex forms, or when you need a formal conformance report.