The European Accessibility Act: a plain-language checklist for small WordPress sites

The European Accessibility Act (EAA) has been in force since June 2025. Many site owners outside the EU assume it does not concern them. It does, if you sell goods or services to customers in the EU — an online shop in Serbia, Ukraine or Kazakhstan with European buyers falls under it just the same.

The good news: for a small WordPress site, the practical part of the law fits on one page. The technical standard it references is WCAG 2.1 AA, and most of it is common sense once you strip the formal language.

What the law actually requires

Three things matter in practice:

• Your e-commerce service must be perceivable, operable, understandable and robust — the four WCAG principles.
• You must publish an accessibility statement describing the state of your site and how to report problems.
• You must respond to accessibility complaints — realistically, fixing what a user reports.

Enforcement is per-country, and the realistic first wave targets large marketplaces and airlines. But small shops are not exempt — they are just lower in the queue. Getting ready now costs an evening or two; retrofitting after a complaint costs more.

The evening checklist

1. Keyboard only. Unplug your mouse. Can you reach every button, open the menu, and complete checkout? Tab order and visible focus are the core of WCAG.
2. Alt texts. Every meaningful image describes what is on it. Decorative images get empty alt="". Product photos — the product name at minimum.
3. Contrast. Grey text on a dark background is the most common failure. There are free checkers; aim for 4.5:1 for normal text.
4. Forms with labels. Every input field needs a visible label, not a placeholder that disappears on focus. Error messages in text, not just red borders.
5. Heading order. One h1 per page, sections in h2, subsections in h3 — without skipping levels.
6. Zoom to 200%. The layout must not break and content must not disappear.
7. No keyboard traps. If you open a modal, Esc or Tab must be able to leave it.
8. Multimedia. Videos with sound need captions or a transcript.
9. Language attribute. The page declares its language (lang attribute) — screen readers pick pronunciation from it.
10. Accessibility statement. A page stating what works, what does not yet, and where to write about problems.

What about automated tools?

Automated scanners catch roughly a third of WCAG issues: contrast, missing alts, empty buttons, missing labels. They cannot check whether your keyboard path through checkout makes sense. Use a scanner to clear the mechanical layer fast, then do the keyboard walk yourself.

If you are on WordPress, our A11yFix plugin runs that automated layer on schedule and the EAA Statement plugin generates the required statement page — but the checklist above works with any stack, including no plugins at all. The law does not care which tools you used; it cares that the site is usable.

The honest bottom line

Accessibility is not a one-time certificate, it is a property of how you build. The evening you spend on this checklist buys you: fewer abandoned checkouts (keyboard and contrast issues hit everyone, not only disabled users), a legal position you can defend, and a site that simply works for more people. That is a rare case where the law, common sense and conversion point in the same direction.