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.