AccessScanRun a free scan

Guide

The 2026 Accessibility Compliance Checklist: WCAG 2.2 AA, Statements, Monitoring, and EAA Readiness

If you own a website and you are not sure where you stand legally, you need a plan specific enough to act on. This accessibility compliance checklist breaks the work into four parts you can tackle in order: the WCAG 2.2 AA technical essentials, a published accessibility statement, ongoing monitoring, and the European Accessibility Act readiness steps that have applied since mid-2025.

The aim is not to recite the law. It is to give you a concrete, testable list so you know what "done" looks like for each item, what to check it with, and where the common traps are. Work top to bottom and you will close most of the gaps that actually get sites complained about.

Start by knowing your standard

Before you check a single box, fix your target. In 2026 the safe single goal is WCAG 2.2 Level AA. Here is why one target covers the major regimes:

  • The European Accessibility Act (Directive (EU) 2019/882) has applied since 28 June 2025. Its technical baseline is WCAG 2.2 Level A and AA, pulled in through the harmonized standard EN 301 549.
  • The ADA names no WCAG version, but courts and settlements treat 2.1/2.2 AA as the working bar in the US.
  • Section 508 (Revised) and Canada's AODA formally require WCAG 2.0 AA; Canada's federal Accessible Canada Act also drives accessibility obligations. The EU Web Accessibility Directive (2016/2102) covers public-sector sites via EN 301 549.

Building to 2.2 AA satisfies the highest of these at once. If you want the version-by-version differences, our WCAG overview and the EN 301 549 explainer lay them out.

Part 1: The WCAG 2.2 AA technical essentials

These are the success criteria that fail most often on real sites, plus the new ones WCAG 2.2 introduced. Treat each as a pass/fail item with a defined test.

Perceivable

  • Color contrast: at least 4.5:1 for normal text and 3:1 for large text (18pt, or 14pt bold) and for UI components and graphical objects (1.4.3 Contrast (Minimum), 1.4.11 Non-text Contrast). Verify with a contrast checker.
  • Text alternatives: every meaningful image has alt text that conveys its purpose; decorative images use empty alt. Check images and follow your alt-text guidance.
  • Text Spacing (1.4.12, AA): content stays readable when users override line height and letter or word spacing.
  • Content on Hover or Focus (1.4.13, AA): tooltips and popovers are dismissible, hoverable, and persistent.

Operable

  • Full keyboard operation with a visible focus indicator, and focus is not hidden behind sticky headers (2.4.11 Focus Not Obscured (Minimum), AA).
  • Bypass Blocks (2.4.1, A): a skip link or landmarks let users jump past repeated navigation.
  • Dragging Movements (2.5.7, AA): any drag action has a single-pointer alternative, such as tap-to-select.
  • Target Size (Minimum) (2.5.8, AA): interactive targets are at least 24x24 CSS pixels, or have adequate spacing. This catches cramped icon rows and mobile menus.

Understandable and robust

  • Language of Page and Parts (3.1.1, A; 3.1.2, AA): set a valid lang attribute and mark inline language changes.
  • Error handling on forms: identify errors in text (3.3.1, A), suggest fixes (3.3.3, AA), and let users review or reverse important submissions (3.3.4, AA).
  • Consistent Help (3.2.6, A) and Redundant Entry (3.3.7, A): keep help in the same place across pages and do not force users to re-enter data they already gave you.
  • Accessible Authentication (Minimum) (3.3.8, AA): do not require a cognitive memory test such as transcribing a code with no alternative; allow password managers and paste.
  • Status Messages (4.1.3, AA): announce dynamic updates like "3 results found" to assistive technology without moving focus. Note that 4.1.1 Parsing was removed in WCAG 2.2, so it is no longer a separate requirement.

For a deeper, component-level walkthrough, our accessibility checklist page expands each of these with examples.

Part 2: Publish an accessibility statement

A statement does not make a site compliant, but the EAA and EN 301 549 expect one, and it is the document a regulator or a frustrated user looks for first. A credible statement includes:

  • The conformance target and level you claim (WCAG 2.2 AA) and the date you last assessed it.
  • Known limitations stated honestly, for example a third-party map widget or a legacy PDF archive you have not yet remediated.
  • A feedback and contact channel so users who hit a barrier can reach a real person, plus a target response time.
  • The assessment method, such as automated scanning plus manual and screen-reader testing.

Generate a first draft with the accessibility statement generator, then keep your claims honest so you do not over-claim conformance you cannot back up.

Part 3: Set up ongoing monitoring

Accessibility can regress the moment a developer ships a new template or marketing pastes in an inaccessible embed. Compliance is a state you maintain, not a project you finish.

  • Automated coverage on every change: scanners reliably catch issues such as missing alt text, low contrast, broken heading structure, and missing labels. A free scan at /#scan gives you a baseline in seconds.
  • Manual checks each release on critical flows: tab through sign-up, checkout, and search using only the keyboard, then run a screen reader over them.
  • A fuller audit periodically, with results fed back into your statement.
  • An owner: assign accessibility to a named person or team so issues have somewhere to go.

Automation covers only part of WCAG; whether alt text is meaningful or focus order makes sense always needs a human. Use scanning to catch regressions fast and free up that human time for the judgment calls.

Part 4: EAA readiness steps

If you sell to consumers in the EU, the European Accessibility Act likely applies regardless of where your company is based. It covers e-commerce, consumer banking, e-books, electronic communications, transport ticketing, and many consumer-facing digital services. Some microenterprises providing services may be exempt, but check rather than assume.

  • Confirm scope: read the European Accessibility Act overview and check which services and obligations apply to you.
  • Map your standard to EN 301 549, which is the conformance route EU member states use to enforce the EAA.
  • Cover the whole purchase journey, not just the homepage: product pages, cart, payment, account creation, and order confirmation all need to pass.
  • Document conformance and keep evidence of your testing, since the burden is on the provider to show the service meets the requirements.

On the right platform, much of this is configuration and discipline rather than a rebuild. The usual gaps tend to hide in checkout, forms, and third-party embeds, so test those first.

Work the checklist in order

Run the technical essentials first because they fix the actual user barriers and are what any audit measures. Publish an honest statement second so your claims match reality. Put monitoring in place third so you do not slide backward. Then confirm your EAA position so a legal obligation does not catch you off guard. Start with a free scan at /#scan to see where you stand today.

Check your site against AccessScan

See your issues ranked by impact in seconds — free.

Run a free accessibility scan

FAQ

What is an accessibility compliance checklist?

It is a structured list of the technical and procedural steps a website must complete to meet a recognized standard, usually WCAG 2.2 Level AA. A good checklist pairs each item with how to test it (for example, contrast ratios, keyboard operation, focus visibility) and covers process steps too, such as publishing an accessibility statement and scheduling re-testing. The goal is to turn a vague obligation into discrete, verifiable tasks.

Which WCAG version do I need to target in 2026?

Target WCAG 2.2 Level AA. The European Accessibility Act references EN 301 549, which is built on WCAG 2.2 Level A and AA. ADA case practice treats 2.1/2.2 AA as the de facto bar in the US, while Section 508 (Revised) and AODA formally require WCAG 2.0 AA. Building to 2.2 AA satisfies the highest of these, so it is the safe single target.

Does an accessibility statement make my site compliant?

No. A statement documents your conformance level, known limitations, and a contact route for users who hit barriers. It is expected under the EAA and EN 301 549 and is good practice everywhere, but it describes the state of the site rather than fixing anything. You still need the underlying WCAG 2.2 AA work done and verified.

Can I automate the whole checklist?

No. Automated scanners catch only part of WCAG issues, mainly things like missing alt text, low contrast, and broken heading order. Criteria such as keyboard operability, accessible authentication, focus order, and whether alt text is meaningful require manual and assistive-technology testing. Use automation for fast coverage and regression monitoring, then layer manual checks on top.

How often should I re-check accessibility?

Treat it as continuous, not annual. Run an automated scan on every significant template or component change and in your deploy pipeline, do a focused manual pass each release on key flows like checkout or sign-up, and schedule a fuller manual audit periodically. Update your accessibility statement whenever the conformance picture changes.

More guides