Originally published at A11yFix.
I've talked to a lot of people who know they should check their website's WCAG compliance but assume they need to hire a consultant or buy expensive software. You don't. At least not for a first pass. With free tools and about 30 minutes, you can identify the most critical accessibility issues on your site and start fixing them.
This isn't a replacement for a professional audit. But it will catch the low-hanging fruit and give you a clear picture of where your site stands against WCAG 2.1 AA -- the standard referenced by the European Accessibility Act and most accessibility legislation worldwide.
Here's the exact process I use for a quick wcag compliance check.
Step 1: Run axe DevTools (5 minutes)
Install the axe DevTools extension for Chrome or Firefox. It's free and it's the most reliable automated accessibility testing tool available. Open your website, click the axe extension icon, and hit "Scan." It will flag issues with severity levels (critical, serious, moderate, minor) and link to specific WCAG success criteria for each one.
Start with your homepage, then scan 2-3 of your most important pages. Look at the critical and serious issues first. axe is precise -- it has a very low false positive rate, so if it flags something, it's almost certainly a real problem.
One thing I appreciate about axe: it tells you exactly which HTML element has the issue and what to do about it. You don't need to be a developer to understand the results.
Step 2: Run WAVE (5 minutes)
WAVE is another free accessibility tool, this one from WebAIM. Install the WAVE browser extension or use wave.webaim.org. WAVE works differently from axe -- it overlays icons directly on your page showing where issues are. This visual approach makes it easier to spot problems in context.
Run WAVE on the same pages you tested with axe. You'll see some overlap, but WAVE catches things axe misses and vice versa. Pay special attention to contrast errors (WAVE highlights these clearly) and structural issues like missing headings or empty links.
Why use both tools? Each free accessibility tool has different detection heuristics. Running both gives you better coverage. Together, they catch roughly 30-40% of all possible WCAG issues -- which sounds low, but it's the easy 30-40% that often accounts for the majority of user-facing problems.
Step 3: Check with Lighthouse (5 minutes)
Open Chrome DevTools (F12), go to the Lighthouse tab, check only "Accessibility," and run the audit. Lighthouse uses axe-core under the hood, so there's overlap with Step 1, but it presents results differently and includes a score out of 100 that's useful for tracking progress over time.
I recommend running Lighthouse on both mobile and desktop. Accessibility issues can differ between viewport sizes, especially for navigation patterns and touch targets. A Lighthouse accessibility score below 90 means there are significant issues to address.
Don't obsess over getting a perfect 100. A score of 95+ with all critical issues resolved is a solid starting point. The score is a rough guide, not a definitive measure of accessibility.
Step 4: Keyboard Navigation Test (10 minutes)
This is where automated tools fall short. Put your mouse aside and try navigating your site using only the keyboard. Start at the top of the page and press Tab to move through interactive elements. Here's what to check:
Can you see where the focus is at all times? There should be a visible outline or highlight on the currently focused element. If focus seems to disappear, that's a critical issue. Many sites remove the focus outline for aesthetic reasons, which makes the site unusable for keyboard users.
Can you reach all interactive elements? Tab through the entire page and make sure you can access every link, button, form field, and menu item. If something is only reachable by mouse hover, keyboard users can't use it.
Can you operate everything? Try pressing Enter or Space on buttons and links. Test dropdown menus and modal dialogs. Press Escape to close things. If any interactive element doesn't respond to keyboard input, that's a WCAG failure.
Is there a skip navigation link? Press Tab once from the top of the page. The first thing you should see is a "Skip to content" link. If it's missing, keyboard users have to tab through your entire navigation on every page.
Step 5: Quick Manual Checks (5 minutes)
Finish with a few manual checks that tools can't fully automate. Right-click on your page, view source, and check: does the html tag have a lang attribute? Is it set to the correct language? Check that your page has exactly one H1, and that headings follow a logical order (H1 > H2 > H3, no skipping). You can use the HeadingsMap browser extension to visualize this quickly.
Also check a few images. Right-click, inspect, and verify they have meaningful alt text (not just "image1.jpg" or empty alt on informational images).
Putting It All Together
After these 30 minutes, you'll have a clear list of issues organized by severity. Here's how I prioritize the wcag audit results:
First, fix critical issues from axe DevTools -- these are the ones most likely to completely block users. Next, address serious keyboard navigation problems. Then work through the contrast errors WAVE identified. Finally, tackle the structural and semantic issues.
Keep your scan results. Run the same tests after making fixes to verify they're resolved, and re-test quarterly. Accessibility isn't a one-time project -- it's ongoing maintenance, like security updates.
The important thing is that you now have data. You know what's wrong, you know the severity, and you can make informed decisions about what to fix and when. That's a much better position than guessing.
If you're working on accessibility compliance, I put together a free 10-point EAA quick-check: Get the free checklist
Top comments (0)