Website accessibility is checked against a single standard: semantic markup, contrast, keyboard navigation, alt text, and working forms. Automated scanners catch part of the violations, but the final check happens manually - with a keyboard and a screen reader. For companies operating in the EU market, this check turned from a good practice into a legal requirement in 2025.
WCAG (Web Content Accessibility Guidelines) is an international set of guidelines from the W3C consortium for making websites accessible to people with visual, hearing, motor, and cognitive impairments. On June 28, 2025, the European Accessibility Act (EAA) - EU directive 2019/882 - came into force, requiring digital products and websites operating in the EU market to meet a baseline level of accessibility.
According to the annual WebAIM Million report, which scans the accessibility of a million homepages, automatically detectable WCAG violations are found on 95-96% of websites every year, consistently. In Exceltic.dev projects, we regularly see the same picture on headless websites: accessibility gets addressed last, only after the main components are already built.
Next: what WCAG actually requires, where accessibility most often gets lost in headless architecture, and which mistakes automated scanners simply cannot catch.
A typical scenario: a team launches a website on a headless stack, passes a Lighthouse score of 90+, and considers the matter closed. A few months later, the legal department of an EU partner sends an accessibility questionnaire, or a user with a visual impairment can’t complete the application form. Reworking semantics and focus management on a finished site costs more than building these requirements in during component markup.
Why accessibility is no longer optional
The EAA directive doesn’t apply only to companies registered in the EU. It covers any website that sells products or services to consumers in the European Union, including companies from the US, the UK, and other jurisdictions outside the EU. National regulators in EU countries already have the authority to fine and require fixes for non-compliant websites.
Beyond the legal risk, there’s a commercial one. B2B buyers in the EU increasingly include accessibility questions in vendor due diligence and tender documentation - failing to give a clear answer lowers your chances of making the shortlist. For companies entering the EU market through their website as the primary sales channel, accessibility becomes part of the technical architecture, not a separate task after launch.
This is the same type of technical risk as consistently ignoring GDPR cookie consent on a headless site - both tasks look secondary until they turn into a fine or a lost deal.
The reputational consequences are less measurable but no less real. A user with a visual or motor impairment who can’t complete an application form goes to a competitor and doesn’t come back.
What WCAG actually requires
WCAG is divided into three conformance levels - A (minimum), AA (standard, used in most regulations, including the EAA), and AAA (extended, for specialized services). For most commercial websites, the practical target is level AA.
All WCAG requirements are built around four principles, abbreviated as POUR:
- Perceivable - content is available through at least one sensory channel: text is read by a screen reader, video is accompanied by captions.
- Operable - all functionality is accessible from the keyboard, without requiring a mouse.
- Understandable - the interface and text are predictable, errors are explained in plain language.
- Robust - markup is correctly interpreted by different browsers and assistive technologies.
The technical standard referenced by the EAA (EN 301 549) is fundamentally based on WCAG level AA. The checklist for legal compliance and the checklist for a practical accessibility audit are essentially the same list.
Where accessibility most often gets lost in a headless stack
Headless architecture - Astro, Next.js, a decoupled frontend on top of a headless CMS - delivers speed and flexibility, but creates three specific sources of accessibility problems that don’t exist on classic server-rendered sites.
The first is dynamically inserted content. Modals, tabs, and carousels are often built as custom JS components without the right ARIA attributes. Visually everything works, but a screen reader has no way to know that a modal opened or a tab changed.
The second is custom components without semantics. A <div> styled like a button with a click handler looks like a button but isn’t one to assistive technologies: it doesn’t receive keyboard focus and isn’t announced as an interactive element. This is a systemic problem with design systems built on top of component libraries without built-in accessibility.
The third is focus management on client-side transitions. When navigating between pages via client-side routing, keyboard focus stays on the element from the previous page, and a screen reader user gets no signal that the content changed. On a classic multi-page site, the browser resets focus to <body> on a full page reload - on a headless stack with partial DOM updates, this behavior has to be emulated manually.
Separately, there’s rich text content from a headless CMS: if a block content editor (Sanity, Contentful, Storyblok) outputs generic markup without semantic tags, headings and lists in articles lose their structure before they even reach the frontend.
Five checklist items before launch
1. Semantic markup
Use native HTML elements instead of <div> with handlers: <button> for buttons, <nav> for navigation, <main>, <header>, <footer> for the page’s navigational regions. Headings follow a hierarchy without skipping levels - this is both an accessibility requirement and a structural signal for search engines.
Example of semantic navigation and heading markup
<nav aria-label="Main navigation">
<ul>
<li><a href="/blog/">Blog</a></li>
<li><a href="/web-dev/">Web Development</a></li>
</ul>
</nav>
<main>
<h1>Page heading</h1>
</main>2. Contrast and color
Text contrast must be at least 4.5:1 for regular text and 3:1 for large text, per WCAG level AA. Information must not be conveyed by color alone: a form error is marked with both text and an icon, not just a red field border.
3. Keyboard navigation
All interactive elements - links, buttons, form fields, custom components - receive focus via Tab in a logical order and have a visible focus indicator. Modals trap focus within themselves without letting it escape, and return focus to the element that opened the modal after it closes.
4. Alt text and ARIA
Every informative image gets a descriptive alt, decorative images get an empty alt="" so screen readers skip them. ARIA attributes (aria-label, aria-expanded, aria-live) should only be added where native HTML semantics don’t cover the component’s behavior - excessive ARIA does as much harm as none at all.
5. Forms and validation errors
Every form field is linked to a <label> via for/id, required fields are marked programmatically (aria-required), and validation errors are announced through an aria-live region so a screen reader reports them immediately, not just visually in red text.
What automated tools catch and what they don’t
Tools like axe and the Lighthouse accessibility score quickly scan the DOM and find objectively verifiable violations: missing alt attributes, insufficient contrast, unlabeled fields. This is a useful first line of checking and worth building into your site’s build process.
The problem is that automation, according to estimates common in the accessibility testing industry, catches roughly 30-40% of WCAG violations. The rest can’t be evaluated programmatically: whether the focus order makes sense, whether an error message is understandable to a person, whether an ARIA attribute actually describes what’s happening visually.
In our experience, on a mid-sized headless site - 30-50 pages managed by a headless CMS - a manual audit after automated scanning usually takes 12-20 hours of specialist work. This is exactly the stage where focus management and custom component issues surface - problems scanners simply can’t catch, since they can’t evaluate behavior during real keyboard navigation.
Manual testing, at minimum, includes a full pass through the site without a mouse, checking core scenarios with a screen reader enabled (NVDA or VoiceOver), and checking with browser text zoomed to 200%.
The most common recurring mistakes
- Decorative icons have alt text, but informative images don’t - or the alt text duplicates the adjacent link text.
- Custom dropdowns respond only to mouse clicks, not the keyboard.
- Modals don’t trap focus:
Tabmoves the user onto elements on the background page. - Text on a gradient or image background looks great visually but fails the 4.5:1 contrast threshold.
- The focus indicator was removed via
outline: nonefor aesthetics, with no alternative visible style put in its place.
Who this check matters most for
First and foremost, companies that sell products or services to consumers in the EU through their website as the primary channel: the EAA applies based on your presence in the European market, not where your business is registered. It also matters for e-commerce and SaaS businesses with a large share of EU traffic, where the website is a transactional channel, not a brochure. Especially if the site is already multilingual and targets several EU countries at once.
A separate category: companies with an existing website where accessibility has never been checked deliberately. For them, a full site rebuild usually isn’t necessary - targeted fixes to specific components are enough: navigation, forms, and modals, which typically create the main risk.
Frequently asked questions
What is WCAG in plain terms?
WCAG (Web Content Accessibility Guidelines) is a set of technical guidelines from the W3C consortium on how to make a website accessible to people with visual, hearing, motor, and cognitive impairments. The official text is published on the W3C website and serves as the reference point for most national digital accessibility laws, including the European Accessibility Act.
Which WCAG level should you start with - A, AA, or AAA?
For the vast majority of commercial websites, the practical target is level AA: it’s what the European Accessibility Act and most national regulations reference. Level AAA is excessive for a typical site and is applied selectively for specialized services.
Are companies actually fined for non-compliance with the European Accessibility Act?
Yes, but the mechanism and size of fines are set individually by each EU country as part of the national transposition of the directive - there’s no single fixed EU-wide fine schedule. The official text of directive 2019/882 is available on the EUR-Lex portal.
Does a perfect Lighthouse score guarantee full accessibility?
No. Lighthouse and axe only check criteria that can be evaluated programmatically - roughly 30-40% of WCAG requirements, according to estimates common in the accessibility testing industry. A high automated score doesn’t replace a manual check with a keyboard and screen reader before launch.
How long does an accessibility audit of a headless site take before launch?
For a typical 30-50 page site, a manual audit after automated scanning usually takes 12-20 hours of specialist work - the exact figure depends on the number of custom interactive components and form complexity. On larger sites, time scales with the number of unique templates, not the total URL count.
What to do next
Accessibility on a headless stack isn’t a pre-release check - it’s part of component architecture: semantics, focus management, and ARIA get built in alongside the markup, not bolted on after the site is done. Keep automated scanners in your build process, but always run the final check manually.
If you’re preparing a website for the EU market or received an accessibility request from a partner, tell the Exceltic.dev team about your situation. We’ll run a technical audit against the WCAG checklist and estimate the scope of work needed.