Accessibility used to be something European businesses could postpone. Since 28 June 2025, for a wide range of consumer-facing digital services, it is a legal requirement — and WCAG is the yardstick most organisations use to meet it.
A short note before we start: this article is an educational overview, not legal advice. Whether and how the Act applies to your specific organisation is a question for a lawyer. What this guide can do is explain the shape of the requirement, the practical standard behind it, and the concrete failures that trip up most websites.
What is the European Accessibility Act?
The European Accessibility Act (EAA) is an EU directive that requires many consumer-facing products and digital services — including e-commerce, banking, transport booking and e-books — to be accessible to people with disabilities. It has applied since 28 June 2025, with each member state enforcing it through national law.
The significant shift is scope. Earlier EU accessibility rules focused on the public sector; the EAA extends the obligation to private businesses serving consumers. If your website lets consumers buy something, book something or manage an account, there is a fair chance the Act is relevant to you — which is exactly the question to put to your legal adviser rather than assume either way.
Does the EAA require WCAG compliance?
The Act sets functional accessibility requirements rather than naming a technical standard, but in practice the Web Content Accessibility Guidelines (WCAG) are the yardstick used across the EU to assess whether a website meets them. Working towards WCAG level AA is the widely accepted way to address the web-related requirements.
WCAG's usefulness is that it turns an abstract obligation — "perceivable, operable, understandable, robust" — into testable criteria: does this image have a text alternative, can this form be completed with a keyboard, does this text have enough contrast against its background. That testability is what makes accessibility something you can measure and track rather than debate.
What are the most common accessibility failures?
The same handful of issues appears on most websites: images without alt text, form fields without labels, text with insufficient colour contrast, pages that do not declare their document language, and heading hierarchies that skip levels. All five are detectable with automated testing and are usually inexpensive to fix.
Each has a real user on the other end:
- Missing alt text leaves screen-reader users with "image" — or worse, the file name — where sighted visitors see a product photo or a chart.
- Unlabelled form fields turn a checkout or signup form into guesswork: the screen reader announces "edit text" with no clue what belongs in the box.
- Poor contrast affects far more people than any assistive-technology statistic suggests — anyone with low vision, ageing eyesight, or simply a phone in sunlight.
- Missing document language makes screen readers guess at pronunciation; English text read with the wrong language voice can be unintelligible.
- Heading jumps — an
h1followed by anh4— break the page outline that screen-reader users navigate by, the way a broken table of contents breaks a book.
Accessibility overlaps with SEO and usability
The work is rarely wasted on the accessibility case alone. Alt text describes images to search engines as well as screen readers. A clean heading hierarchy is precisely what search crawlers use to understand a page's structure. The document language attribute helps translation tools and search engines classify your content. Labelled forms produce fewer abandoned checkouts for everyone, and higher contrast is simply easier to read on every screen.
This is why accessibility findings sit naturally alongside SEO and performance findings: they are all facets of the same underlying question — does this page work properly for whoever, or whatever, is trying to read it?
How can I audit my own website for accessibility?
Start with an automated scan using an engine such as axe-core, which catches issues like missing alt text, unlabelled form fields and contrast failures. Then test by hand: navigate your key pages using only the keyboard and check that menus, forms and dialogues remain usable. Automated tools find a substantial share of problems, but manual checks are needed for the rest.
A workable self-audit routine looks like this: run the automated scan across the whole site, not just the homepage; fix the recurring template-level issues first, since one fix in a template repairs every page using it; then walk your most important journeys — search, product page, checkout, contact — with the keyboard alone. Finally, make the scan recurring. Accessibility regressions arrive with every redesign and every new component, so a one-off audit has a short shelf life.
Where SiteControl fits
SiteControl, the website quality product in TrustCtrl, runs accessibility checks per WCAG using axe-core on every crawl — alt text, form labels, ARIA usage, heading hierarchy and document language among them — so regressions surface as findings instead of accumulating silently. Because the crawler renders pages in headless Chromium, single-page applications are checked as users actually experience them.
Accessibility findings appear alongside SiteControl's technical SEO, Core Web Vitals and security-header checks, each with a plain-language explanation, likely causes and step-by-step remediation — so the person fixing the issue does not need to be a WCAG specialist to know what to do.