The quarterly board meeting of a mid-sized online retailer selling into Germany, Austria and the Netherlands. The general counsel puts a slide on the screen: since 28 June 2025, the shop must meet accessibility requirements under the European Accessibility Act, and in Germany the national law allows fines of up to EUR 100,000. The CEO asks the obvious question: “Do we comply?” The head of e-commerce answers honestly that he does not know. The agency that ran last year’s redesign says “everything is WCAG compliant”, but nobody has seen a report. Someone suggests a plug-in at fifty euros a month that “does accessibility automatically”.
That scene has played out in hundreds of European companies since mid-2025. The rules are new, the deadline has passed, and the market is full of offers ranging from “WCAG certificate in 48 hours” to free scanners. The board needs three answers: does this apply to us, what exactly has to be checked, and what will it cost in time and money.
This article is written for the person who has to make that decision: a CEO, a product owner or a head of digital. We explain who the European Accessibility Act covers, how a real accessibility audit differs from a scan, what makes up the price, how long the work takes, what belongs in the contract with the vendor and how to recognise an offer you should turn down.
Who does the European Accessibility Act cover?
The European Accessibility Act is Directive (EU) 2019/882. Member states had to transpose it by 28 June 2022 and apply it from 28 June 2025. Each country did this through its own law: Germany through the Barrierefreiheitsstärkungsgesetz (BFSG), Poland through the act of 26 April 2024 on ensuring accessibility requirements for certain products and services, and so on. The requirements are harmonised; enforcement and penalties are national.
The Act does not cover “all websites”. It lists specific services provided to consumers. For digital businesses, the important ones are:
- e-commerce services, meaning the sale of products or services to consumers at a distance through a website or app,
- consumer banking services,
- electronic communications services and services providing access to audiovisual media,
- e-books and dedicated software,
- elements of air, rail, bus and waterborne passenger transport: websites, mobile apps, electronic tickets and travel information.
It also covers products such as general-purpose computers and their operating systems, smartphones, ATMs, ticketing machines, payment terminals and e-readers. If your company does not make hardware, the service part is what matters to you.
Two exemptions matter in practice. First, microenterprises providing services are exempt (Article 4(5) of the Directive). A microenterprise is defined as one with fewer than 10 employees and an annual turnover or balance sheet total not exceeding EUR 2 million. Second, the rules concern services to consumers. A B2B portal used only by business customers is generally out of scope, although the line blurs when the same shop serves both companies and private buyers.
For UK companies the question is not whether the UK adopted the Act, because it did not. The question is whether you offer covered services to consumers in the EU. If your shop sells to customers in France or Germany, the national law of those countries applies to that service, regardless of where your company is registered. Domestically, UK businesses also have duties under the Equality Act 2010, which is a separate regime.
One caveat: this article describes the law as written, but it is not legal advice. If your service sits on the edge of scope, for example a subscription platform with B2B elements, confirm the classification with a lawyer before ordering an audit. A technical audit tells you whether a service is accessible, not whether it has to be.
What happens to a company that does not meet the requirements?
Enforcement is national, so the details depend on the market. The pattern is similar across member states: market surveillance authorities can investigate on their own initiative or after a complaint, require corrective action within a deadline, restrict or prohibit the service, and impose fines.
Two examples show the range. In Germany, § 37 BFSG allows fines of up to EUR 100,000 for the most serious offences and up to EUR 10,000 for the rest. In Poland, the authority can order corrective action with a deadline of up to 120 days, ban the service for up to 180 days and impose a fine of up to ten times the national average monthly wage, capped at 10% of turnover. At 2025 wages, as published by the Polish statistics office in February 2026, that cap works out at about PLN 89,000. Poland also lets anyone file a complaint about an inaccessible service with the central supervisory body, without going to court.
For a large retailer, a five- or six-figure fine does not change the year’s results. That is why, in a board discussion, two other risks matter more. The first is a ban or forced suspension of the service: for a company that earns its money online, even a short interruption costs more than the fine. The second is lost customers and reputation. People with disabilities, older customers and their families are a large group of buyers, and many accessibility barriers, such as poor contrast, unlabelled form fields or no keyboard support, make shopping harder for people with no disability at all.
There is also a transition period that is often misunderstood. Under Article 32 of the Directive, service providers may continue to use products they were already using to provide similar services until 28 June 2030, and member states may allow service contracts agreed before that date to continue unchanged until they expire, but for no longer than five years. Poland, for example, used that option. This does not mean an online shop has until 2030. Each new order placed through the site is a new contract, and the site itself is a service being provided today.
What is an accessibility audit and how is it different from a scan?
An accessibility audit is an assessment of whether a digital service meets a defined standard, usually WCAG at level AA, carried out by people using a repeatable method, not only by software. A scan is running an automated tool that checks the page code against the rules a machine can detect.
The difference is not academic. The WebAIM Million report for 2026, which analyses the home pages of the top one million websites every year, detected WCAG failures automatically on 95.9% of pages, with an average of 56.1 errors per page. The most common were low-contrast text (83.9% of pages), missing image alt text (53.1%), missing form labels (51%) and empty links (46.3%). That is a useful baseline, but it only covers what tools can detect.
What can a tool not judge? Whether alt text describes the product or reads “IMG_2024_final”. Whether the order in which the Tab key moves through elements makes sense. Whether a screen reader announces anything after a product is added to the basket. Whether an error message in the payment form is understandable. Whether the delivery options dialog can be closed without a mouse. Deque, the maker of the axe tools, published a study in 2021 based on more than 2,000 audits, which found that automated tests fully covered on average 57% of issues when counted by volume. Deque itself notes that the result depends on how you count, and that common industry estimates were lower. Whichever number you prefer, a large share of problems needs human judgement.
A good audit combines three layers:
- Automated tests across the whole sample to collect repetitive issues such as contrast and missing attributes quickly.
- Manual expert review of each WCAG success criterion on the selected templates: keyboard, focus, heading structure, forms, dynamic messages, media.
- Assistive technology testing on the key journeys: screen readers (NVDA or JAWS on Windows, VoiceOver on macOS and iOS, TalkBack on Android), zoom to 200% and 400%, keyboard-only navigation.
The W3C document WCAG-EM (Website Accessibility Conformance Evaluation Methodology) describes how to pick the sample. The auditor does not test every URL but a representative set: each template type, the key task journeys and a random selection of pages. That has a direct impact on price, which we come back to below.
If you are starting from zero and want to understand the WCAG principles first, our earlier article on how to get started with accessibility testing and WCAG covers the basics. This one assumes you are already facing a purchasing decision.
Which WCAG version should you use as the benchmark?
Neither the Directive nor the national laws name WCAG directly. They refer to harmonised standards: a service that conforms to the relevant harmonised standards is presumed to meet the accessibility requirements to the extent those standards cover them (Article 15 of the Directive). In practice that means the European standard EN 301 549, which refers to WCAG for websites and apps.
In 2026 this became more complicated. ETSI, CEN and CENELEC published EN 301 549 V4.1.1 on 2 September 2026, the first version prepared specifically for the European Accessibility Act. According to Deque, which tracks the process, V4.1.1 adopts WCAG 2.2 level AA and is expected to be cited in the Official Journal of the EU around 30 November 2026. Only that citation gives it presumption of conformity. At the time of writing, the citation had not yet been published.
WCAG 2.2 has been a W3C Recommendation since 5 October 2023. It adds nine new success criteria, four of them at level AA, including focus not obscured, minimum target size and an alternative to dragging movements. Content that conforms to WCAG 2.2 also conforms to WCAG 2.1, so the higher standard breaks nothing.
The practical recommendation for the board: when you order an audit today, write WCAG 2.2 AA into the contract as the benchmark, or at least WCAG 2.1 AA with a separate list of the criteria added in 2.2. An audit done only against WCAG 2.1 will need topping up within a year, and the extra effort is small compared with the cost of a second engagement. Also decide whether the audit should cover requirements beyond WCAG, such as the accessibility information that service providers must publish.
What should the scope of an accessibility audit include?
The scope document drives everything else: price, timeline and whether the report will be useful. Before you ask for quotes, prepare answers to six questions.
Which platforms? Responsive website, separate mobile site, iOS app, Android app, logged-in customer account. Each platform is a separate sample with its own set of assistive technologies.
Which templates? List the unique screen types: home page, product listing, product page, search with filters, basket, each checkout step, login, registration, customer account, returns form, content pages, terms. In a typical shop that is somewhere between a dozen and a few dozen templates, even if there are tens of thousands of URLs.
Which task journeys? The law covers the service, not individual pages, so the audit must check that whole tasks can be completed: find a product, add it to the basket, choose delivery, pay, receive a confirmation, file a return. Three to five journeys usually cover what matters most.
Which third-party elements? Payment gateway, chat widget, pick-up point map, review system, cookie consent banner. They often come from other vendors, but from the customer’s point of view they are part of your service. The audit should flag them even if only their supplier can fix them.
Which documents? Invoice PDFs, terms and conditions, downloadable product manuals. Older archived documents may be excluded under national rules, but new ones are not.
Which standard and level? WCAG 2.2 AA or 2.1 AA as discussed above, and whether the auditor should also review the service’s accessibility information.
A well-written scope shortens negotiations and makes quotes comparable. If three vendors receive the same document, differences in price come from method and rates, not from each one reading the task differently. General principles of test planning and management are covered in our quality assurance knowledge hub.
What drives the cost of an accessibility audit?
We will not give a single figure, because an honest one does not exist. We also have not found an independent, methodically collected survey of accessibility audit prices in Europe. What we can do is show how the price is built so that you can estimate it yourself and compare quotes.
An audit is expert work billed in person-days. The price is roughly person-days × day rate, plus any retest. The factors in the table below drive the number of person-days.
| Factor | What increases effort | What reduces it |
|---|---|---|
| Unique templates | Many different screen types, a large account area | A consistent component library, few exceptions |
| Platforms | Web + iOS + Android, separate mobile site | One responsive site |
| Task journeys | Multi-step checkout, configurators, calculators | A simple purchase in a few steps |
| Dynamic elements | Filters without reload, modals, carousels, chat | Classic forms and navigation |
| Assistive technologies | Several screen readers on several systems | One screen reader per platform |
| Standard | WCAG 2.2 AA plus information requirements | WCAG 2.1 AA only |
| Report depth | Code-level recommendations, priorities, fix estimates | A plain list of failures |
| Retest | Several rounds of fix verification | A single retest |
To turn this into money, use market day rates. At ARDURA Consulting, QA specialist rates on our testing services page range from about EUR 130 to 335 per day for manual testers and EUR 165 to 465 for automation engineers. That is not an accessibility audit price list, only the day-rate range of the roles that do the work.
An estimate you can derive from it: if auditing a shop with a dozen or so templates on one platform takes, say, 8 to 15 person-days, and a senior tester’s day rate is EUR 250 to 335, the audit itself would cost roughly EUR 2,000 to 5,000. A service with apps on two platforms and a large account area may need two to three times as much. To be clear, this illustrates the method, it is not a quote. The actual number of days comes from the scope and is fixed before work starts. Rates in Western Europe are typically higher than in Poland, so the same person-day estimate costs more with a local vendor in Munich or Amsterdam.
One more budget point. The audit is usually the cheapest part of an accessibility project. Fixing code, redesigning components, correcting content and retesting cost more than the diagnosis. A good report should therefore contain not only a list of issues but also priorities and fix guidance, so the development team can estimate its own work. A board that approves a budget for the audit alone will, three months later, receive a report and a question about where the money for the rest comes from.
How long does the audit take and what does the schedule look like?
Duration depends on the same factors as price. As an estimate, for a site with a dozen or so templates on one platform, the work from signed contract to report takes one to three calendar weeks. Several platforms and many journeys take longer. A typical schedule looks like this.
Week 0: scoping. A session where the product team walks through the service and the auditor selects the sample using WCAG-EM. The output is a list of templates, journeys, platforms and assistive technologies, signed off in writing. This is also when access to a test environment and test accounts is arranged, including accounts that can complete a payment without a real transaction.
Week 1: automated tests and expert review. The auditor runs tools across the whole sample and then works manually through the success criteria on each template. This is the most labour-intensive part.
Weeks 1–2: assistive technology testing. The key journeys are completed with a screen reader, keyboard only and with zoom. This is where the problems that block a purchase, rather than merely reduce comfort, come out.
Weeks 2–3: report and walkthrough. The report goes to the team, and the auditor walks the product owner and developers through it so everyone understands the priorities.
After fixes: retest. Verification of the fixes on the same sample, usually a few days of work depending on the number of issues.
The most common cause of delay is not on the auditor’s side. It is a missing test environment, missing test accounts, broken test payments or changes deployed during the audit. If the shop releases a new version every week, agree a scope freeze for the testing period or audit a staging environment with a fixed version.
What should the accessibility audit report contain?
The report is the product you pay for. Ask for a sample before you sign and check that it includes the following.
An executive summary. One or two pages: can people using assistive technologies complete the key tasks in the service as it stands, how many critical issues there are, what the main risks are and what to do first. No jargon.
A list of failures mapped to criteria. Each issue assigned to a specific WCAG success criterion, with its location (template, component, journey step), a screenshot or recording and steps to reproduce.
Priority by user impact. A missing label on the newsletter field in the footer and the inability to confirm payment with the keyboard are both failures, but only one prevents a purchase. The report should distinguish them, for example on a scale of blocker, serious, moderate and minor.
Fix recommendations. For each issue: what to change in the code or content, ideally with an example. Repeated issues should be grouped at component level, because one fix in the component library resolves hundreds of occurrences.
Method and sample. Which pages, journeys, browsers and assistive technologies were tested, in which versions and when. Without this, the report has no evidential value when a supervisory authority asks on what basis you claim the service is accessible.
Input for your accessibility information. Service providers must publish information on how the service meets the accessibility requirements, usually in the terms and conditions or an equivalent document. The report should give your lawyer and product team the material to write that text.
Note one thing that should not be in the report: an EAA compliance certificate. The Directive does not provide for certification of services by private bodies. The service provider assesses conformity itself and is responsible for that assessment. The auditor provides evidence and recommendations, not an official seal.
Which red flags in a vendor’s offer should worry you?
The post-2025 accessibility market has attracted firms that sell reassurance rather than work. These are the warning signs to know before you talk to a vendor.
A “WCAG certificate” or “EAA certificate” in a few days. As above, there is no official certificate for services. A stamped document does not transfer your responsibility to the vendor.
An overlay as the compliance solution. Widgets that promise “automatic compliance” after adding one line of script do not fix the site’s code. In April 2025 the US Federal Trade Commission finalised an order against accessiBe, which had to pay USD 1 million over misleading claims that its widget could make any website WCAG compliant. The order bars the company from making such claims without evidence. It is a US decision, but the argument is universal: conformance comes from code and content, not from an overlay.
A report that is a tool export. If the sample report is a table with thousands of rows generated by a scanner, with no priorities, no journeys and no screen reader testing, you are paying someone to run a program you could run yourself.
No information on who tests and with what. Ask whether the auditor uses a screen reader in daily work, which systems they test on and whether anyone in the team uses assistive technology. Not every audit needs testing with disabled users, but the vendor should be able to say when it would be advisable.
Pricing per URL. Quoting “per page” encourages testing thousands of similar pages rather than representative templates and journeys. A sensible quote is based on a sample and person-days.
No retest in the offer. An audit without fix verification ends with a report that, three months later, no longer reflects the service. A retest should be in the offer, either priced or as an option.
How do you plan remediation so you do not end up back at the start?
A report with several hundred issues can freeze a product team. A few principles help move from diagnosis to a service that stays accessible.
Blockers on purchase journeys first. Anything that stops a keyboard or screen reader user from finding a product, ordering and paying goes to the top of the queue. Those issues decide whether the service is accessible in the legal sense, and they are the ones that cost sales.
Fix components, not pages. Most issues repeat because they come from one component: a button, a form field, a modal dialog. A fix in the component library or design system resolves the issue across the site. Good collaboration with designers helps here, because some problems, such as contrast or touch target size, start in UX/UI design rather than in code.
Put accessibility into the definition of done. Every new feature should pass basic accessibility checks before release: an automated scan in CI, a keyboard walkthrough, a label check. Otherwise next year’s audit will find new problems in new features.
Add accessibility checks to regression testing. Automated accessibility tests can run in the CI pipeline alongside functional tests. They will not replace manual review, but they catch regressions such as a removed attribute or worsened contrast. We cover how to build such a suite under regression testing.
Schedule periodic reviews. The service changes every sprint. A sensible rhythm is a manual review of key journeys with every major change and a fuller audit every year or at each rebuild. Service providers are required to keep their conformity up to date as the service and the standards change, so a one-off assessment does not close the topic.
External audit or in-house capability?
This is the question the board should ask before ordering anything. The answer depends on how many digital services the company runs and how often it changes them.
A one-off external audit makes sense when you need an independent baseline, when the team has no accessibility experience, or when a rebuild is coming and you want to know what not to repeat. It gives a fresh perspective and a document you can show the board or a supervisory authority.
An accessibility tester in the team makes sense when the service evolves every sprint and remediation will take months. A person who knows WCAG and assistive technologies works alongside the developers, verifies fixes as they land and makes sure new features do not introduce new problems. Through staff augmentation, such a specialist joins your team for a defined period, for example the remediation and stabilisation phase, without a permanent hire.
A mixed model is usually the most sensible: an external audit at the start and once a year, with in-house capability in between. The annual auditor should not be the same person who signs off fixes day to day, otherwise independence is lost.
At ARDURA Consulting, accessibility testing against WCAG 2.1 is part of our software testing services, alongside functional, regression, mobile and automation testing. We can run an assessment against a scope agreed in writing or provide testers who join your team for remediation and retests. If WCAG 2.2 is to be the benchmark, we write that into the scope before work starts. For context on what testing capacity costs from Poland compared with Western Europe, see our overview of QA outsourcing rates in Poland and CEE.
How do you prepare for the audit so you do not overpay?
Preparation on the buyer’s side can shorten the audit by several days and improve the results. Here is a list of things to do before sending a request for quotation.
Confirm the legal scope. Agree with your lawyer which services fall under the Act in which markets and whether any of them benefit from the transition period. A technical audit cannot decide whether you are a microenterprise or whether your platform is B2C.
List templates and journeys. A list of unique screen types and three to five key customer tasks is the most valuable document for a vendor. It allows an accurate quote rather than a guess.
Prepare environment and test accounts. A staging environment with a version that will not change during the audit, test accounts with different roles and the ability to complete a test payment.
Collect third-party supplier data. Who provides the payment gateway, chat, pick-up map and cookie banner. Ask them for their accessibility statements before the auditor finds problems in their components.
Run a free scan yourself. Browser extensions for automated accessibility testing will show whether you have a handful of issues or hundreds. That does not replace an audit, but it helps you judge whether a vendor is proposing a sensible scope.
Name an owner for the remediation plan. A report without an owner becomes a document on a shared drive. Before you order the audit, decide who will take the priorities forward and who approves the remediation budget.
Ask about method and a sample report. Ask three vendors for a description of their method, sample and report. Compare who tests with screen readers, who prioritises, who offers a retest. Price is only the fourth criterion. Our regulatory compliance glossary entry explains how to fit this into a wider compliance process.
What should you remember before ordering an accessibility audit?
The European Accessibility Act has applied since 28 June 2025 and covers digital services for EU consumers: e-commerce, banking, electronic communications, e-books and parts of transport. Microenterprises providing services are exempt. UK and other non-EU companies are in scope when they sell covered services to EU consumers. Penalties are national, from up to EUR 100,000 in Germany to service bans in Poland, and a forced suspension usually costs more than the fine.
An accessibility audit is an expert assessment, not a scan. It combines automated tests, manual review of WCAG criteria and testing of key journeys with screen readers. Use WCAG 2.2 AA as the benchmark, because the new version of EN 301 549 is built on it. The price comes from person-days, driven by templates, platforms, journeys and report depth. The audit is usually cheaper than the fixes, so budget for the whole job.
Turn down offers of certificates, overlays and tool-export reports. Demand a described method, priorities, fix recommendations and a retest. After the audit, fix components rather than pages and build accessibility into your delivery process so you do not end up back at the start next year.
If you want to agree the scope of an accessibility assessment for your service or add testers to your team for the remediation phase, see our software testing services or book a scoping call. We will tell you which sample is worth testing, how much work it means and what you can do yourself before paying anyone.