# European Accessibility Act: what small sites must do > Who the European Accessibility Act covers, how the microenterprise exemption works, what compliance looks like for an online shop in practice, and a 90-day plan to get the purchase flow there. Updated 2026-09-25 · Accessibility · HTML version: https://getreport.app/guides/european-accessibility-act-what-small-sites-must-do Since 28 June 2025, a web shop that sells to consumers in the EU has to be usable by people with disabilities, and national authorities can enforce it. For a small business the questions are practical: does it apply to me, what exactly has to work, and how do I get there without a six-figure audit? This guide answers them in order and ends with a 90-day plan. It is an orientation, not legal advice: the Act is a directive, each member state wrote it into its own law, and the details that decide your case (exemptions, deadlines, penalties) are in your national text. ## Quick answer - The European Accessibility Act (Directive (EU) 2019/882) applies from 28 June 2025 to a list of products and services, including **e-commerce services**: selling to consumers online, through a website or an app. - **Microenterprises** providing services (fewer than 10 people and an annual turnover or balance sheet total of no more than EUR 2 million) are exempt from the service requirements. Check both numbers, and check your national law. - In practice, compliance is measured against the harmonised standard EN 301 549, which for web content points at WCAG level AA. Building to WCAG 2.2 AA is the safe target. - The whole purchase flow has to work: product pages, cart, checkout, account, payment, emails and documents, not only the home page. - Publish how your service meets the requirements (an accessibility statement) and offer a way to report problems. - Run the [accessibility checker](https://getreport.app/tools/accessibility-checker) on each step of the purchase flow, then test the same steps with a keyboard. ## Why the European Accessibility Act matters ### Who is in scope The Act lists its products (computers, smartphones, self-service terminals, e-readers and others) and its services: electronic communications, access to audiovisual media services, elements of passenger transport services (websites, apps, e-tickets), consumer banking, e-books, and e-commerce. The last one is the one most small sites meet. The Act defines it as services provided at a distance, through websites and mobile apps, at the individual request of a consumer, with a view to concluding a consumer contract. What that means in plain terms: - **An online shop selling to consumers in the EU** is in scope, and where the business is based does not change that. - **A booking or ordering flow** (a restaurant's online orders, a tour operator's booking form with payment) generally counts, because it concludes a consumer contract. - **A brochure site** with information and a contact form but no sale or booking is generally not in scope. - **B2B-only sales** are generally out of scope, because the definition is about consumer contracts. Grey areas exist (marketplaces, subscription sign-ups, donation forms). When your case is not obvious, your national enforcement authority's guidance is the place to check. ### The microenterprise exemption The Act exempts microenterprises that provide services from the service accessibility requirements. A microenterprise, in the Act's definition, employs fewer than 10 persons **and** has an annual turnover not exceeding EUR 2 million or an annual balance sheet total not exceeding EUR 2 million. Two things catch people out. Both conditions apply: nine staff and EUR 3 million turnover and balance sheet is not micro. And the exemption covers the service: if you also sell products that the Act itself covers (e-readers, computers, phones), obligations for those products may still apply to you as a distributor. National transpositions word this slightly differently, so read your own. Even when exempt, remember that the shoppers are the same. An inaccessible checkout loses the same sales whether or not a regulator can fine you for it. ### Timing and enforcement The obligations apply to services provided from 28 June 2025. The Directive let member states allow a transition period, until 28 June 2030 at the latest, for services provided with products that were already in lawful use before that date, and some member states used it; it is not a general five-year pause for websites. Enforcement is national: each member state names a market surveillance authority and sets its own penalties. ### Why it is worth doing anyway Around one in six people lives with a disability, and many more shop one-handed on a phone in bright sun. Every labelled field and every keyboard-reachable button is a sale that no longer depends on luck. ## How getReport checks it > **Free tool:** [Accessibility checker (WCAG 2.2)](https://getreport.app/tools/accessibility-checker): axe-core violations by impact, colour contrast, landmarks, form labels, link names, tap targets and zoom — measured on the rendered page, with the selectors to fix. The checker renders the page in Chromium and runs axe-core with the WCAG 2.0, 2.1 and 2.2 A and AA rules plus axe's best practices, then adds its own findings for landmarks, the skip link, form labels, link names, zoom and tap targets. Run it on every step of the purchase flow you can reach with a URL. ![The accessibility checker result for a test page with deliberate violations: a score of 69, axe-core reporting 4 critical, 4 serious, 3 moderate and 0 minor rules, and a findings list led by critical and serious violations, unlabelled form fields, unnamed links and disabled zoom](https://getreport.app/guides/img/european-accessibility-act-what-small-sites-must-do/panel.webp "The failed findings at the top of the list are the ones that block a purchase; fix them before anything else.") > **Check: No critical accessibility violations.** Critical issues stop some visitors from using the page at all, for example buttons a screen reader cannot name or forms that cannot be filled in. > > 1. Open the technical detail to see each rule and the elements affected. > 2. Fix the highest-count rule first; the same template usually causes most instances. > **Check: No serious accessibility violations.** Serious issues make parts of the page very hard to use with a screen reader, keyboard or zoomed-in display, so some visitors give up before they buy or get in touch. > > 1. Open the technical detail to see each rule and the elements affected. > 2. Fix the rule with the most elements first; it is usually one template or component. Critical and serious are axe's two highest impact levels. On a shop they are typically unnamed icon buttons (the cart, the menu, the quantity stepper), images without alternative text, and form controls with no label. The count in the title is the number of failing rules; the technical detail lists each rule and how many elements it affects. [Accessibility basics](https://getreport.app/learn/accessibility-basics) explains why these two levels come first. > **Check: Tap targets are at least 24×24 px.** Small links and buttons packed together cause mis-taps on phones, which means abandoned carts and wrong menu choices. WCAG 2.2 asks for at least 24×24 px or equivalent spacing. > > 1. Give links and buttons a minimum height of 24 px (44 px is comfortable) with padding rather than a bigger font. > 2. Add space between neighbouring targets such as icon rows, pagination links and footer menus. > **Check: Visitors can zoom the page on their phone.** Many people zoom web pages on their phone to read small text. A viewport tag with user-scalable=no or a low maximum-scale turns that off in Chrome on Android; only iOS Safari ignores it. > > 1. Change the viewport meta tag to . > 2. Remove user-scalable=no, and remove maximum-scale or set it to 5 or more; in WordPress this usually lives in the theme header or a mobile plugin. These two matter most on phones and are cheap to fix. Tap targets are the most common warning on shop themes (colour swatches, pagination, footer links); [target size: 24 pixels and the exceptions](https://getreport.app/guides/target-size-24-pixels-and-the-exceptions) explains what counts. A viewport tag that disables zoom is one line in the theme header; see [never disable pinch zoom](https://getreport.app/guides/zoom-and-viewport-never-disable-pinch-zoom). ### What needs a person Automated checks catch roughly a third of WCAG problems. The rest needs a keyboard and a few minutes of attention: whether focus is visible, whether a cart drawer traps focus or cannot be closed with Escape, whether error messages say what went wrong, whether a payment step announces itself to a screen reader. None of that shows up in a scan, and all of it decides whether a keyboard or screen reader user can pay. ## Step by step ### 1. Settle scope before anything else Write down your headcount, turnover and balance sheet total for the last closed year, and the services you sell to consumers. If you are clearly out of scope or exempt, keep the note on file. If you are in, list every template the purchase flow touches: home, category, search, product, cart, checkout steps, account sign-up and login, order confirmation, and the emails and documents that follow (confirmation email, invoice PDF, terms). ### 2. Know the standard you are measured against The Act states functional requirements: websites and apps must be perceivable, operable, understandable and robust, and identification, security and payment functions delivered as part of the service must be too. Meeting a harmonised standard gives a presumption of conformity. For web content, the reference in practice is EN 301 549, whose current version incorporates WCAG 2.1 AA; a revision aligned with WCAG 2.2 has been in preparation. Check which version your national authority references today, and build to [WCAG 2.2](https://www.w3.org/TR/WCAG22/) AA, which covers both. ### 3. Work through the checklist for a shop | Area | What has to work | How to check | | --- | --- | --- | | Keyboard | The whole purchase, from search to payment confirmation, with Tab, Enter, Space and Escape | Manual: unplug the mouse | | Focus | A visible focus indicator on every link, button and field | Manual | | Forms | A label on every field, required fields marked in text, not colour only | `form-labels` finding, then manual | | Errors | Error messages that name the field and the fix, announced to screen readers | Manual, submit empty forms | | Contrast | 4.5:1 for text, 3:1 for large text and UI controls | `contrast-summary` finding for text; controls by eye | | Zoom and resize | Pinch zoom works; text at 200 % does not overlap or cut off | `zoom-not-disabled`, then browser zoom | | Names | Every button and link has a name that says what it does | Link-names finding | | Images | Product photos described, decorative images `alt=""` | Image-alt finding | | Targets | Tap targets at least 24×24 px or spaced apart | `target-size` finding | | Media | Captions for product videos with speech, transcripts for audio | Manual | | Documents | Invoices, terms and size guides as accessible PDFs or HTML | Open with a screen reader | | Information | An accessibility statement and a feedback channel | Footer link | The statement is where you describe how the service meets the requirements and what does not work yet; [Accessibility statement: what to write](https://getreport.app/guides/accessibility-statement-what-to-write) has a template. ### 4. Run the checker on each template Run the report on the home page, one category, one product, and the cart. Checkout pages that need a session cannot be fetched by a tool that starts from a URL; test those in the browser with the keyboard and with axe's browser extension if you have it. Fix by template: one fix to the product template clears the finding on every product. ### 5. Test the flow with a keyboard Put a real product in the cart and pay with a test card using only the keyboard. Write down every point where focus disappears, jumps, gets stuck or reaches something invisible. [Focus order and keyboard traps](https://getreport.app/guides/focus-order-and-keyboard-traps) covers the usual causes. Then repeat with a screen reader on the product page and the checkout. ### 6. A 90-day plan - **Days 1–30: baseline.** Confirm scope and exemption. List templates. Run the checker on each and save the report links. Do the keyboard purchase test. Collect every problem in one list with its template and owner. - **Days 31–60: fix the blockers.** Everything critical and serious, form labels, focus visibility, zoom, contrast on buttons and prices, the cart drawer and the payment step. Re-run after each release. - **Days 61–90: the rest of the service.** Captions for videos with speech, accessible PDF invoices and terms, tap targets, the statement page, and a feedback address that someone reads. Train whoever adds products to write alt text. - **After day 90:** re-run the checker on the key templates every month and after every theme or plugin update, and review the statement at least once a year. ## Platform notes ### Shopify The checkout is hosted by Shopify, so its accessibility is largely Shopify's responsibility and outside your theme; test it anyway and report problems to Shopify. Everything before it is your theme: variant swatches built as clickable `div`s, cart drawers that do not move focus, quantity buttons labelled only "+" and "−", and sliders that autoplay are the usual findings. Theme updates can fix or reintroduce them, so re-run the checker after each one. ### WooCommerce The theme, WooCommerce's own templates and every checkout plugin (payment gateways, address lookup, upsells) each contribute markup. The block-based Cart and Checkout and the classic shortcode versions render different HTML, so test the one your store uses. Payment fields inside a gateway's iframe are the gateway's code: test them and ask the gateway if they fail. ### Squarespace and Wix Commerce checkout is hosted by the platform. Your levers are the template, colours, image alt text and the content you write. Pick high-contrast colour combinations in the site styles and fill in alt text for every product image. ### Overlay widgets An overlay or accessibility toolbar does not change the underlying code that WCAG is measured against, so it does not by itself make a site conform, and accessibility practitioners and disability organisations have repeatedly warned against relying on one. If you have one, treat it as optional and fix the site underneath. ## Verify - The accessibility checker shows "No critical accessibility violations" and "No serious accessibility violations" on the home, category, product and cart templates. - A keyboard-only test purchase completes with a visible focus at every step. - The statement page is linked from the footer, dated, and names a contact that answers. - Monthly report links sit in your tracking sheet, so you can show the work if an authority or a customer asks. ## Common mistakes - **Assuming the exemption.** "We are small" is not the test. Symptom: nine employees but a turnover and balance sheet above EUR 2 million. Fix: check both figures against your national text and keep the note. - **Fixing the home page only.** The home page is the best-tested page on most shops; the checkout is the worst. Fix: test every template in the purchase flow. - **No statement, no feedback channel.** Visitors who hit a barrier have nowhere to report it. Fix: publish a statement with an email address and a response time. - **Treating it as a one-off project.** A theme update, a new payment plugin or a seasonal banner can reintroduce failures. Fix: a monthly re-run on the key templates and a keyboard pass after every change to the checkout.