The European Accessibility Act Is Being Enforced. Can You Show What Your Site Looked Like?

The European Accessibility Act (EAA) stopped being a future deadline on 28 June 2025. Online shops, consumer banking, e-books, passenger transport ticketing and a list of other services sold to people in the EU now have to be accessible, and national authorities are handling complaints. Most teams have spent the last year on audits and fixes. Far fewer can answer the question that comes up the moment a complaint arrives: what exactly did this page look like, and when did it change?

This post covers who the EAA applies to, why a dated visual record of your site is worth having, and a lightweight way to build one without buying an enterprise archiving suite.

Who the EAA covers (it’s wider than people think)

The EAA is an EU directive, so each member state writes it into national law with its own enforcement body and penalties. The scope is broadly the same everywhere:

• E-commerce. Any website or app selling products or services to consumers: product pages, basket, checkout, account area.
• Banking and payments. Consumer banking sites and apps, plus card terminals and ATMs.
• Transport, e-books and communications. Ticketing and travel information, e-readers and e-book stores, phone and messaging services.
• Businesses outside the EU. If you sell to consumers in the EU, the rules apply to that offer, whether you’re based in Berlin, Boston or Brisbane.

The main carve-out is for microenterprises providing services (fewer than 10 staff and no more than €2 million annual turnover or balance sheet). Everyone else is expected to meet the accessibility requirements, which in practice are measured against EN 301 549 and, through it, WCAG 2.1 level AA. Check the national law where you sell, and talk to a lawyer about your specific situation. This post is practical advice, not legal advice.

The problem: websites have no memory

Your site changes every week. A designer tweaks the checkout, a plugin updates, a marketing banner covers the skip link for a fortnight. When a customer complains that the payment step couldn’t be used with a keyboard “last month”, there is usually nothing to look at except today’s version.

That causes trouble both ways. If the problem was real and you’ve fixed it, you can’t easily show when you fixed it. If the complaint is mistaken, you can’t show the page as it really was. Many organisations also publish an accessibility statement saying what they’ve fixed and what’s still in progress. A statement is far more convincing when you have dated evidence behind it.

What a useful record looks like

You don’t need an archive of every pixel. You need a few things you can find quickly:

1. The critical journeys, captured on a schedule. Home, a product page, basket, checkout, sign-up, contact. These are the pages complaints are about.
2. Before and after captures around every fix. Capture the page the day you start remediation and again the day it ships. That pair is your change log.
3. A recording of the journey itself. Static screenshots can’t show focus order or a modal that traps the keyboard. A short video of someone tabbing through checkout can.
4. Dates you can trust. Every capture should carry the date it was taken, kept somewhere other than the site being captured.

How to build it with Scrollify in an afternoon

Scrollify wasn’t built as an accessibility tool, and it won’t audit your code or make you compliant. What it does do well is capture what a page looks like, reliably and with a date, which happens to be exactly what this record needs.

• Full-page scroll captures. Paste a URL and export an MP4 or GIF that scrolls the whole page, plus stills. Each export sits in your library with its capture date. See compliance page archiving for how teams use this.
• Scheduled captures. Set your critical pages to re-capture weekly or monthly so the record builds up without anyone remembering to do it.
• Mobile viewports. Capture the same journey at phone width. Many accessibility failures only appear on small screens.
• Keyboard walkthroughs with Record a Tab. Open your checkout, start Record a Tab, and move through the whole flow using only Tab, Shift+Tab, Enter and Space. The recording shows the focus outline, the order it moves in, and anywhere it gets stuck. That’s worth more to a developer, and to a regulator, than a paragraph of description.
• Fingerprints for the strict cases. Exports can be hashed, so if a capture is ever disputed you can show the file hasn’t been altered since it was made.

A simple routine that holds up

Teams that do this well keep it boring:

1. List your five to ten critical URLs. Put them on a monthly scheduled capture.
2. Record one keyboard-only walkthrough of checkout or sign-up each quarter, and after any redesign.
3. When an audit flags an issue, capture the page, fix it, capture again. Note both dates in your ticket.
4. Link the latest captures from your internal accessibility statement notes, so whoever answers a complaint can find them in a minute.

None of this replaces fixing the issues. It means that when someone asks what you did and when, the answer is a link rather than a guess.

Start your record today

The best time to start keeping a record was June 2025. The second best is now, before the next complaint, redesign or plugin update overwrites what your site looks like today. Create a free Scrollify account, paste your checkout URL and you’ll have your first dated capture in under a minute. Then record a keyboard walkthrough with Record a Tab. When you’re ready to put your critical pages on a schedule, compare plans, or read how regulated teams handle this in archiving pages for compliance.