← Back to Blog

How to Check Website Accessibility in 2026

6 min read

Web accessibility is no longer optional. With WCAG 2.2 now the established standard and legal requirements tightening in the US, EU, and beyond, every development team needs a reliable process for checking accessibility. This guide walks through a practical, three-layer approach: automated scanning, manual testing, and assistive technology verification.

Why Accessibility Testing Matters

Over one billion people worldwide live with some form of disability. When your website has accessibility barriers, you exclude real users from completing real tasks. Beyond the ethical imperative, inaccessible websites face concrete business risks: lawsuit exposure under the ADA, EAA (European Accessibility Act) penalties taking effect in June 2025, and lost revenue from users who simply leave.

The Web Content Accessibility Guidelines (WCAG) 2.2, published by the W3C, define the success criteria your site should meet. Most regulations reference WCAG Level AA as the minimum conformance target. Checking your site against these criteria is the foundation of any accessibility practice.

Step 1: Automated Scanning

Automated tools can detect roughly 30 to 50 percent of WCAG violations instantly. They are the fastest way to catch low-hanging fruit like missing alt text, insufficient color contrast, and missing form labels. Start here before investing time in manual review.

Browser-Based Scanners

The most accessible entry point (no pun intended) is a browser extension that scans the current page and reports violations inline. Popular options include:

  • axe DevTools by Deque — the industry standard engine (axe-core) wrapped in a Chrome DevTools panel. The free version covers the core ruleset; paid tiers add guided testing and intelligent recommendations.
  • WAVE by WebAIM — overlays icons directly on the page to show errors, alerts, and structural elements. Great for visual learners, though the overlay can be overwhelming on complex pages.
  • A11yMate — a free Chrome extension that runs axe-core under the hood and provides fix guides with code examples for every violation it finds. Particularly useful if you want actionable next steps, not just a list of failures.

Lighthouse Accessibility Audit

Chrome DevTools ships with Lighthouse, which includes an accessibility category. Open DevTools, navigate to the Lighthouse tab, check “Accessibility,” and run the audit. Lighthouse uses a subset of axe-core rules and returns a score from 0 to 100 along with specific failures. It is a solid first pass, but be aware that a perfect 100 does not mean your site is fully accessible — automated tools have inherent limitations.

CI/CD Integration

For ongoing protection, integrate accessibility checks into your build pipeline. Tools like axe-core/cli, pa11y, and @axe-core/playwright let you fail builds when new violations appear. A typical setup runs axe against your rendered pages in a headless browser during CI, catching regressions before they reach production.

Step 2: Manual Testing

Automated tools cannot evaluate whether alt text is actually meaningful, whether focus order is logical, or whether custom components behave as users expect. Manual testing fills these gaps.

Keyboard Navigation

Put your mouse aside and navigate your entire site using only the keyboard. Press Tab to move forward through interactive elements, Shift+Tab to move backward, Enter or Space to activate controls, and Escape to dismiss dialogs. Watch for these common failures:

  • No visible focus indicator — can you always tell which element is focused?
  • Focus traps — does focus get stuck in a modal or widget with no way to escape?
  • Illogical tab order — does the focus sequence follow the visual layout?
  • Unreachable controls — can you reach every button, link, and form field?

Zoom and Reflow

WCAG 1.4.4 requires that text can be resized up to 200% without loss of content or functionality. Zoom your browser to 200% and verify that no text is clipped, overlapping, or hidden. At 400% zoom (WCAG 1.4.10 Reflow), content should reflow into a single column with no horizontal scrolling at 1280px viewport width.

Content Review

Review your page for semantic correctness. Check that heading levels follow a logical hierarchy (no skipping from h1 to h4), that link text is descriptive (not “click here”), and that images have alt text that conveys their purpose. Decorative images should have empty alt="" attributes so screen readers skip them.

Step 3: Screen Reader Testing

Screen readers interpret the accessibility tree — the structured representation of your page that the browser builds from your HTML and ARIA attributes. Testing with a screen reader reveals problems that no automated tool or visual inspection can catch.

Which Screen Readers to Test

  • NVDA (Windows, free) — the most widely used free screen reader. Pair it with Firefox or Chrome.
  • VoiceOver (macOS/iOS, built-in) — activate with Cmd+F5 on Mac. Essential for testing Safari behavior.
  • JAWS (Windows, paid) — dominant in enterprise environments. Important if your audience skews toward corporate users.
  • TalkBack (Android, built-in) — necessary if you support mobile web users on Android.

What to Listen For

Navigate through your page and pay attention to whether the screen reader announces elements correctly. Buttons should be announced as buttons, links as links, form fields with their labels, and images with their alt text. Custom components built with div and span often fail here because they lack the implicit ARIA roles that native HTML elements provide.

Step 4: Color Contrast Verification

WCAG 2.2 requires a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text (Level AA). Tools like the Chrome DevTools color picker show contrast ratios inline when you inspect an element. For bulk checking, the axe-core “color-contrast” rule catches most violations automatically, but it cannot evaluate text rendered over images or gradients — those require manual verification with a tool like the WebAIM Contrast Checker.

Step 5: Document Your Findings

Create a structured report that maps each finding to a specific WCAG success criterion, includes the severity level, and provides a recommended fix. This gives your team a clear remediation backlog. If you are using A11yMate, the extension generates this mapping automatically, linking each violation to its WCAG criterion along with a step-by-step fix guide.

Building a Sustainable Process

A one-time audit is useful, but accessibility is an ongoing practice. The most effective teams combine automated scanning in CI (to catch regressions), regular manual audits (quarterly or per release), and screen reader testing for any new interactive component. Treat accessibility as a quality dimension alongside performance and security — not as a separate project.

Get Started with A11yMate

A11yMate is a free Chrome extension that scans any webpage for WCAG 2.2 violations using the axe-core engine. Unlike raw scan results, it provides fix guides with code examples for every issue it finds, so you know exactly how to resolve each violation. No account required, no data collection, and it works entirely in your browser.

Try A11yMate free →