FAQ

Probably, and increasingly so.

Public sector. Under the Web Accessibility Directive, public sector bodies across the EU — national and local government, public institutions, and bodies governed by public law — must meet accessibility requirements for their websites and mobile applications. This has been in force since 2019 for public sector websites and 2021 for mobile apps.

Private sector. Under the European Accessibility Act, private sector organizations providing services such as e-commerce, banking, transport, e-books, and electronic communications have been subject to the same obligation since June 2025 — and the obligation doesn't end at the first compliant version. Article 13(3) requires providers to have procedures in place so services remain in conformity, and Article 13(4) requires corrective action and authority notification if they fall out of it.

Non-compliance carries legal exposure, complaints through national enforcement bodies, and disqualification from public procurement. Both frameworks point to the same technical standard: EN 301 549.

The EAA applies to specific categories of products and services offered to consumers in the EU. On the services side, this includes:

• E-commerce
• Consumer banking services
• Electronic communications services
• Services providing access to audiovisual media
• Elements of air, bus, rail, and waterborne passenger transport services
• E-books and dedicated software

It also covers products including computers, smartphones, payment terminals, ATMs, ticketing machines, and e-readers.

Two things to note. Microenterprises providing services — fewer than 10 people and under €2 million annual turnover — are exempt from the service obligations, though this exemption does not extend to products. And national implementations vary, so the specifics of how the EAA applies depend on the member state you operate in. If you are unsure where your organization sits, get in touch and we will work through the scoping with you.

We help private and public sector organizations meet EU accessibility law against the European standard EN 301 549. Our work spans three services:

Audits & Remediation. Manual testing against EN 301 549, covering web, mobile apps, software, documents, and hardware. Findings are delivered in our platform: categorized, filterable, each with a clear issue description and an actionable fix. Includes a delivery meeting to walk through the platform and findings, a one-hour consultation on remediation, and — optionally — an Accessibility Conformance Report and Accessibility Statement.

Accessibility Compliance Platform. A web-based platform where you track your organization's accessibility compliance across every property you own: every audit, every issue, every fix.

Accessibility Consultancy. Strategic and technical expertise — compliance planning, remediation guidance, team trainings and workshops, technical guides and playbooks, and direct access to our specialists — without hiring a full-time accessibility officer.

An accessibility evaluation is a set of standardized tests assessing a digital platform against accessibility requirements. We combine manual expert testing with automated tooling.

Manual expert evaluation makes up at least 70% of the assessment. Our team — including UX/UI specialists experienced in usability, and people with disabilities — tests with assistive technologies including screen readers (NVDA, VoiceOver, TalkBack) and keyboard-only navigation, interacting with the platform directly. This is what surfaces issues automated tools cannot detect, and what allows findings to account for context and real use.

Automated tooling contributes up to 30%, scanning for code-level errors at scale.

Both are assessed against EN 301 549 and WCAG 2.1 AA, with evaluation up to WCAG 2.2 Level AAA available on request.

1. Get evaluated. A manual audit against EN 301 549 establishes where you actually stand, rather than assuming automated scan results are the full picture.
2. Turn findings into a plan. Issues need to be prioritized, assigned, and tracked through to a fix — not left as a static list nobody owns.
3. Document your position. A plain-language Accessibility Statement, backed by an Accessibility Conformance Report, gives you something to point to if your compliance is ever questioned.

We handle all three as part of our Audits & Remediation service, with findings delivered directly into a platform your team can act on.

Three things, mainly.

Scope. How many properties, and of what kind. A single website is a different exercise from a website, a mobile app, and a document library.

Complexity. The number of distinct templates, functionalities, and interaction patterns present. A large site built from a small set of repeating templates can be quicker to evaluate than a smaller one where every section is bespoke.

Documentation. Whether you need an Accessibility Conformance Report and Accessibility Statement alongside the evaluation, or the findings alone.
We scope each engagement individually rather than working from a fixed price list. Get in touch with your platform details and we will come back with a proposal covering both cost and timeline.

Yes. Most of our work is with platforms already in production — evaluation, remediation guidance, ongoing tracking, and consultancy to bring them into compliance and keep them there.

AxAll began over a decade ago as a design and development agency. That background is why our work goes beyond finding problems: we understand the systems producing them, and we know what it takes to change them — not just the fix itself, but the planning, the sequencing, and the follow-through as the product keeps changing.

It also shapes what we deliver. Rather than a report that goes stale the moment your team ships the next release, findings live in a platform that keeps audits, fixes, and compliance status current as the product evolves.

EN 301 549 is the Harmonised European Standard for accessibility requirements for ICT products and services, published by ETSI together with CEN and CENELEC. It is the standard referenced by both the Web Accessibility Directive and the European Accessibility Act.

WCAG covers web content. EN 301 549 incorporates WCAG 2.1 Level AA and extends beyond it to mobile applications, non-web documents, software, and hardware. Evaluating against EN 301 549 therefore covers the relevant WCAG requirements while also addressing the parts of your digital estate that WCAG alone does not reach.

We use a strategic sampling approach rather than assessing every page. The sample covers the range of templates, functionalities, and content types present on the platform, which surfaces the issues that recur across it.

The specific selection depends on the diversity of design elements and user interactions. Get in touch for an overview and a proposal for your platform.

Overlays are third-party tools intended to enhance a website's accessibility after the fact. Per WCAG and the consensus among accessibility experts and the broader accessibility community, websites should be inherently accessible rather than dependent on an overlay.

Overlays create a superficial layer that leaves underlying issues in place. They can confuse users, interfere with assistive technologies, and lag behind evolving standards — and they do not resolve legal exposure.

Our approach integrates accessibility into the core of digital platforms. For more detail, read our article on why you should avoid accessibility overlays.

An accessibility evaluation tests against a standard. Usability research goes further, working with people with disabilities and older users to understand how a product performs in real use, beyond what conformance criteria capture.

This is best done at the outset of a project, but it can be introduced at any stage to inform adjustments and refinement.

A web-based platform where your organization's accessibility compliance lives in one place — every audit, every issue, every fix, across every property you own.

It exists because the law doesn't treat compliance as a one-time event. Under Article 13(3) of the EAA, service providers are required to have procedures in place so their services remain in conformity — not just pass an initial check. An audit report describes a platform on the day it was tested; within a release cycle it's already out of date, and remediation tracking scatters across spreadsheets, tickets, and email threads until nobody can say with confidence where compliance actually stands.

What it includes:

• Compliance requirement matrix, so you can see what applies to you before you are asked by a Market Surveillance Authority
• A full issue workspace per property — issues, status, assignment to team members, disputes, and remediation notes
• A hosted ACR status page at your own subdomain, continuously updated as fixes are verified
• Portfolio view, so compliance status across all properties is visible in one dashboard rather than assembled on request
• Shared knowledge library, so every team learns from every other team's fixes instead of solving the same problem independently
• Yearly regression check, so compliance does not quietly drift between audits

Built for organizations managing more than one site, app, or platform — where compliance cannot live in a spreadsheet. It also means that once the system is running, full re-audits become rare, scoped events rather than the default.

Compliance is not a one-time exercise. Once issues are identified, the work is keeping them fixed as the product changes:

Implement the fixes. Your in-house team or ours, working from the findings.

Track remediation in one place. Every property gets an issue workspace with status, assignment, disputes, and notes, so nothing depends on someone remembering to update a spreadsheet.

Keep documentation current. Your ACR status page updates continuously as fixes are verified, so it reflects reality rather than the state of things at audit time.

Build internal capability. Team trainings, workshops, and technical guides so your designers, developers, and content creators can maintain accessibility without external help on every decision.

Monitor over time. A yearly regression check, plus evaluation of new pages and features as they ship.

At minimum annually, in line with EU recommendations. In practice, the more useful question is what happens between audits — which is what continuous tracking and evaluation of new features as they ship is for.

Usually not. Focus on what has changed — functionality, framework, visual elements, or interface — and update the accessibility statement for the affected areas.

The better strategy is to build accessibility requirements into the initial brief and architecture planning, so less needs correcting later. Where that is not possible, introduce accessibility criteria into QA for modified segments. For visual and UI changes, embed accessibility principles into brand guidelines and content administration guidelines. We provide checklists and guides for development, brand updates, and content administration to support this.

Yes. Our workshops and trainings are designed to build internal capability and buy-in so accessibility becomes part of how your teams work rather than an external requirement.

There is also a compounding effect to remediation itself: as issues are fixed, teams learn. The platform's shared knowledge library captures this — every team learns from every other team's fixes, rather than each solving the same problem independently.

Through the compliance state visible in the platform: which issues are open, which are fixed and verified, which have been accepted as won't-fix, and how that has changed across audits.

The Accessibility Conformance Report is the external proof point. Alongside it, organizations build internal assets that compound over time — an accessibility solutions library for development, design, and content; internal checklists; accessibility requirements for suppliers; and trained teams. Together these reflect an organization's growing capability to deliver services that work for everyone.