Recently, while writing WCAG 2.1 explained, I ran axe-core over 10 cometweb.io pages. A scan like that is the first step of an accessibility audit, and it found one violation, on my own pricing page.
Six small 12 px hints had contrast of 4.49:1 and 3.81:1 against the required 4.5:1. The first one missed by a hundredth. A scanner can compute the contrast of text on a solid background to two decimal places. But whether a customer can reach the payment step with a keyboard is something the scan result is silent on.
You check the rest yourself, and below is the checklist, plus what the European Accessibility Act (EAA) asks of an online shop.
Accessibility audit: WCAG, the EAA, national law and EN 301 549
An accessibility audit is a check of whether people can perceive the content and complete a task: find a product, fill in a form, sign in or pay. WCAG only describes technical requirements, while the legal obligations come from Directive (EU) 2019/882, the European Accessibility Act, and the national law of each Member State that transposes it.
I'm working from the EU directive here. Polish law shows up only as a labelled example of one national transposition, and the details differ between Member States.
| Term | What it defines | How to use it in an audit |
|---|---|---|
| WCAG | Success criteria for accessible content, at levels A, AA and AAA | Record the version, the level and the evidence for each criterion assessed |
| EAA | EU Directive 2019/882 on accessibility requirements for specified products and services | Establish the type of business, the scope and which national rules apply |
| National transposing law | The Member State law that puts the EAA into effect, e.g. Poland's Act of 26 April 2024 | Check requirements, exemptions, information duties and the supervising authority |
| EN 301 549 | The European ICT accessibility standard, broader than websites alone | Check the edition, the relevant requirements and whether it can support a presumption of conformity |
WCAG 2.2 Level AA conformance means meeting every Level A and AA success criterion within the evaluated scope, plus the conformance requirements W3C sets out.
EN 301 549: publishing an edition vs citing it in the Official Journal
In September 2026, AccessibleEU announced the publication of EN 301 549 V4.1.1, the edition that adopts WCAG 2.2. Citing a standard in the Official Journal of the EU is a separate step, though. According to the ETSI foreword to V4.1.1, the previous edition, V3.2.1 (2021), based on WCAG 2.1 AA, was cited only under the Web Accessibility Directive for public-sector websites.
Under Article 15 of Directive 2019/882, products and services that conform to harmonised standards whose references are published in the Official Journal are presumed to conform, as far as those standards cover the requirements. For the EAA, no edition gives that presumption today, and V4.1.1 will only give it once it's cited.
As the technical target for a new audit, I'd recommend WCAG 2.2 AA, with legal and contractual requirements spelled out separately in the purchase order. "WCAG audit" or "EAA audit" on its own leaves the scope to guesswork.
Who is covered by the European Accessibility Act?
The EAA required Member States to apply their national measures from 28 June 2025, so that date has passed. The directive covers specified products and specified services provided to consumers (services from microenterprises are exempt). They include e-commerce, consumer banking, e-books and dedicated software, electronic communications, access to audiovisual media services and certain elements of passenger transport services.
The obligation comes from the service you're providing, and your website is only where you provide it. If you run an online shop, what counts is the whole path to a contract with a consumer, including the product page, identification, security and payment. Annex I, Section IV of the directive lists the e-commerce requirements. In Poland, for example, they sit in Article 18 of the national act, and the Ministry of Digital Affairs describes them for e-commerce (in Polish).
Before you decide whether the obligation applies to you, answer three questions:
- What service do you provide?
- Who do you offer it to?
- Does a legal exemption apply?
A contact form on your informational blog still leaves it a blog, and a "B2B" label settles nothing if consumers use the platform too. One caveat: this is informational and technical material, not legal advice or a conformity assessment of any particular business, so confirm the classification of your own business with a lawyer.
Microenterprises, older services and third-party components
The directive exempts microenterprises providing services from the accessibility requirements for those services and the obligations tied to them. Product-related obligations of the same company stay in place.
The directive defines a microenterprise as one that employs fewer than 10 persons and has an annual turnover or balance sheet total of EUR 2 million or less. National law may add its own wording, so check that too.
The EAA's transitional provisions are narrow. Service contracts agreed before the obligations started may continue without alteration until they expire, for at most five years from that date. Until 28 June 2030, service providers may also keep using products they were already lawfully using for similar services.
"It's a third-party plugin" needs more behind it, too, because the exclusion only covers third-party content that's neither funded, developed by nor under the control of the business concerned. A cart or payment component you've bought needs the same assessment, so agree the scope of fixes with the supplier.
Relying on fundamental alteration or disproportionate burden requires a documented assessment, and you must send that information to the authority that checks compliance of services. For a disproportionate burden, you renew the assessment when the service changes, when the authority asks, and at least every five years. "We have no budget right now" doesn't replace that procedure.
What can automation check, and what needs a person?
Automation is good at catching regressions, but what a result covers depends on the tool's rules and the state of the page. A scan run without signing in is silent about the customer account, and a scan of a form before submission skips its error messages. W3C's guide to selecting evaluation tools says tools can't evaluate every aspect of accessibility. So you can't derive a reliable "accessibility percentage" from the number of rules passed.
| Area | Useful automation | Assessment you must not skip |
|---|---|---|
| Names and semantics | Finding some missing names, labels and ARIA errors | Whether the name describes the purpose, the role matches the behaviour and the state is understandable |
| Contrast | Calculating contrast for known text and background | Images and gradients behind text, interactive states, elements that need interpretation |
| Keyboard | A script that checks a predefined focus sequence | Full operation of the component, focus visibility and whether the order makes sense |
| Forms | Selected associations between labels, errors and fields | Instructions, recovering after an error, correcting the data |
| Dynamic messages | Presence and change of a given region or state | Whether the user learns about the change at the right moment |
| Content and media | Presence of selected attributes or text tracks | Meaning of descriptions, caption accuracy, need for audio description, clarity of instructions |
A browser test can open a modal, submit an empty form and check focus, but it only assesses conditions someone wrote down in advance. That's why, for every result, I ask what was checked, and how. A scan is good at clearing everything that can be computed off your list. But in my scan of cometweb.io, axe still left part of the contrast undecided.
Example: a named button with a keyboard trap
I built two local teaching fixtures with an order button labelled "Zamów" (Polish for "Order"). In both, Chromium exposed the role button and the name Zamów.
The first variant had a deliberate block on the Tab key. After three presses of Tab, and separately of Shift+Tab, focus was still on the button. In the second, without the block, Tab moved focus to the next link and Shift+Tab to the previous field.
In plain English: a correct name and role sat right next to a trap a keyboard user would get stuck on. Only a separate interaction test exposed it, in a verified lab example run in Playwright without axe-core or a screen reader.
So it isn't a CometWeb audit or a measure of scanners, and I wrote up the method and results (in Polish) separately.
Keyboard traps fall under success criterion 2.1.2 No Keyboard Trap. Keeping focus inside an open modal can be fine, as long as you're able to operate the component and leave it with the keyboard.
How do you plan an audit of the whole user journey?
Your audit plan starts with user tasks, and you'll pick the URLs after that. One page often has several states that matter, e.g. empty form, validation, loading, timeout and success. In a single-page application the URL can stay the same while the screen changes completely.
For your shop, an example scope covers searching for an offer and filtering, choosing a variant and the cart, customer details and delivery, then payment and order confirmation. Add the failure paths too: an invalid postcode, a declined payment, an expired session and going back without losing data. The consent banner and the menus or messages that appear on top of the content belong in scope as well. That's my suggested plan, because the law leaves the list open.
In the scope document, record the application version, test accounts for each role, language versions and the documents covered. Add the devices, browsers and assistive technologies you actually used, with versions, e.g. Windows with a screen reader or Safari with VoiceOver. Finally, list the exclusions, with the reason for each.
Manual testing checklist after a scan
The checks below cover selected WCAG criteria, and you can run most of them for free in an ordinary browser.
Keyboard: you can complete the whole journey without a mouse
Go through the most important journey using Tab and Shift+Tab. Every element you need, e.g. a button, an option picker, a menu or a modal, should be reachable and operable. Assess the focus order, where focus returns after a layer closes, and check for traps. In the report, keep an operation problem separate from a focus-visibility problem (WCAG conformance requirements).
Under success criterion 2.4.11 (AA), a focused element can't be entirely hidden by author-created content (Focus Not Obscured, Minimum).
Zoom and spacing: text and layout survive user settings
Check text resizing up to 200% with the conditions and exceptions of criterion 1.4.4 Resize Text. Then check reflow at a width equivalent to 320 CSS pixels, which is 1.4.10 Reflow.
According to W3C, a 1280 CSS pixel wide viewport at 400% zoom gives you that effective width, so setting 400% on any screen you happen to use is the wrong test. Reflow has exceptions for content that needs a two-dimensional layout, but those don't exempt the whole page.
For criterion 1.4.12 Text Spacing, set line height to 1.5 times and spacing after paragraphs to 2 times the font size. Then set letter spacing to 0.12 and word spacing to 0.16 times the font size, and check that content and functionality stay available. It's a test of resilience to user settings, so your design can keep its own default values. In DevTools, add a CSS rule with those values for all elements.
Contrast: text reaches at least 4.5:1 in the component's real state
WCAG AA requires at least 4.5:1 for normal text and 3:1 for large text, with specified exceptions (1.4.3 Contrast, Minimum). "Large" has a precise definition in the criterion, so check the actual size, whatever the heading level. Check error messages and labels as well as body copy.
Contrast of interface components and their states is a separate criterion, 1.4.11 Non-text Contrast. A 3:1 border on every button goes beyond what it asks.
You can check a colour pair for free with the Contrast Checker. Whole pages go through the accessibility module in CometWeb Insight, our website audit app. It shows the barriers that can be measured automatically, contrast included, and gives each finding a WCAG criterion and evidence on the affected element.
Forms and sign-in: you can fix an error without losing data
Submit the form with empty and invalid data, then check the error description and its association with the field. Also check whether you can correct it without losing what you've already typed (3.3.1 Error Identification). The label should stay understandable once the user's typed something, and a placeholder disappears as you type (3.3.2 Labels or Instructions).
For dynamic messages, check that assistive technology conveys the information without moving focus unnecessarily. Criterion 4.1.3 Status Messages doesn't require aria-live="assertive" on every notification.
For sign-in, check that it works with a password manager and that you can paste credentials or codes. Criterion 3.3.8 (AA) restricts requiring a cognitive function test without an allowed alternative or supporting mechanism, and it has exceptions. You won't find a ban on every CAPTCHA in it, or a duty to remove security measures.
WCAG 2.2: six additional A and AA criteria
When you're updating an audit from WCAG 2.1, add the criteria below to the ones that already apply. The full list of changes and exceptions is in the WCAG 2.2 normative text.
| Criterion | Example check | Condition that is easy to forget |
|---|---|---|
| 2.4.11 AA: Focus Not Obscured (Minimum) | Tab past a sticky bar | The minimum concerns the element not being entirely hidden |
| 2.5.7 AA: Dragging Movements | Reorder items without dragging | A single-pointer alternative is needed; the keyboard alone does not meet this requirement |
| 2.5.8 AA: Target Size (Minimum) | Check small icons and their spacing | The rule is 24 × 24 CSS pixels, with exceptions, including one for spacing |
| 3.2.6 A: Consistent Help | Compare repeated contact mechanisms | It is about their relative order; the criterion does not require adding a chat |
| 3.3.7 A: Redundant Entry | Go through the checkout steps | It concerns the same data in the same process, and has exceptions |
| 3.3.8 AA: Accessible Authentication (Minimum) | Use a password manager and paste | Assess the cognitive requirement, the supporting mechanism and allowed alternatives |
An unconditional "every button must be 44 × 44" doesn't follow from 2.5.8 Target Size, Minimum, because the criterion has exceptions you assess in the context of each element.
What should an accessibility audit report look like?
An accessibility audit report should let you reproduce the problem and verify the fix. So for each finding, record the screen and state, the application version and environment, and the steps to reproduce. Next to them, put the observed result and the expected result, the related criterion and evidence, and the impact on the user.
Give each task an owner and a retest condition you can check, and anonymise the evidence you collect. Here's a teaching template, not a defect from a real shop.
Title: Focus stays inside the closed cart panel.
Scope: product view, panel opened from the "Cart" button.
Environment and app version: enter the ones actually used.
Steps: open the panel with the keyboard, close it, press Tab.
Observation: note the element that actually receives focus.
Expected: focus moves to a logical element on the visible page;
usually the button that opened the panel, unless the flow has changed.
Mapping: assess 2.4.3; do not add other failures without confirming them.
Retest: repeat the sequence and check the next Tab and Shift+Tab.
Status: NOT TESTED. Fill in after running the test.Level A or AA and task priority are two different things. Set priority by the impact on users:
- whether the barrier blocks payment,
- how many journeys it affects,
- whether a genuinely accessible workaround exists.
In the results, distinguish at least five statuses: "met in the evaluated scope", "not met", "needs assessment", "not tested", and "not applicable" with a reason. Missing data is missing data, never a pass. WCAG-EM 2.0, which W3C published as a Group Note in July 2026, gives a "conforms" status only to screens in the sample. The WCAG map in Insight's accessibility module works the same way, with the statuses "checked automatically", "issue found", "needs manual review", "not applicable" and "no data".
Retesting and maintenance: when is a problem really closed?
You can call a problem closed when a user gets through the scenario that used to block them. After a change, rerun the relevant automated test and repeat that scenario. Also check neighbouring states and the same component elsewhere, e.g. the cart modal in sign-in.
On my pricing page, a rescan with axe of both language versions was enough, and it showed zero contrast violations. A keyboard trap only gets closed by repeating the Tab and Shift+Tab sequence by hand.
Record the fix version, the date, who checked it and the result. If only the code change has been confirmed, keep any tests still to run open as separate items.
For a service covered by the EAA, you keep conformity up after the first report too, because the directive requires procedures for that and corrective measures when the service falls short. So tie rechecks to changes in key journeys (sign-in, cart, payment), content and components. A yearly date in the calendar falls behind your releases.
What documentation does an e-commerce service need?
The accessibility statement comes from the Web Accessibility Directive, Directive (EU) 2016/2102, and the national laws that transpose it (in Poland, the 2019 Act on digital accessibility). Check before you copy that template onto a private shop, and don't assume the EAA replaced those rules.
If you're the service provider, you assess conformity yourself, and the directive doesn't create a universal duty to buy an external "WCAG certificate". A document from a contractor may confirm that an assessment was carried out, so check its scope and basis, plus the date of its evidence. An audit report shows readiness and the evidence behind it, and a certificate of conformity is a separate thing.
Where a service falls short, the provider must immediately inform the competent national authorities of the Member States where it's provided, with details of the non-compliance and the corrective measures taken. Which authority that'll be depends on national law. In Poland it's the minister responsible for computerisation for e-commerce services, as the Ministry of Digital Affairs explains (in Polish).
When you prepare the documentation, a simple map helps: requirement → part of the service → evidence → limitation → action and retest. Publish only the conformity claims your own findings support.
Where should you start an accessibility audit of your own product?
The easy part is the scan. The hard part is getting through the cart with a keyboard and honestly writing down what's still untested. Here are the four steps, in the order I'd take them:
- Name the person responsible and list the key user tasks.
- Choose the scope of the first evaluation.
- Run a scan and do the interaction tests.
- From confirmed findings, set the order of fixes and the retest plan.
Check your scan's scope in the CometWeb methodology, and plan the tests outside it separately. You can organise selected checks with the accessibility checklist and document the work with templates for audit scope, findings and retests (in Polish), though the templates cover only selected criteria.
If you'd rather start from a list of barriers, create an Insight account and run your first audit. You'll still do the keyboard test yourself. And if you plan audits differently and it's working for you, tell me: maciej@cometweb.io.
Frequently asked questions about accessibility audits
Does a score of 100 in a scanner mean WCAG conformance?
No. A score of 100 only means that tool's rules found nothing in the tested state of the page, calculated the tool's own way. WCAG conformance requires assessing the success criteria and the conformance requirements, and a check of a representative sample has clearly defined limits on what you can conclude from it.
Does every online shop have to buy an external EAA audit?
There's no single rule requiring every online shop to buy an external EAA audit. First establish whether the EAA, as transposed in the relevant national law, applies to you, exemptions included. A covered service provider assesses conformity itself and meets its other obligations, and a well-planned audit provides it with the evidence.
Does an accessibility plugin or overlay solve the problem?
An overlay alone doesn't solve it. Judge the result on the page: bigger text after a click on an icon doesn't prove that sign-in, form labels or payment work. After adding any such tool, repeat the relevant tests.
How much does an accessibility audit cost and how long does it take?
The cost and length depend on the scope, so without one any number would be a guess. To compare offers, specify the journeys and states, number of templates, roles, languages, documents, environments and the retest you expect. Also ask whether the price includes testing with assistive technologies and whether testing with users is a separate stage.
Does testing with disabled people replace a WCAG evaluation?
No, it complements it. It shows how people actually use the product, but one person's experience covers only their needs and part of the criteria. Combine it with an expert review and properly chosen tests.
If the EAA does not apply to us, can we ignore accessibility?
An exemption from the EAA only releases you from that law's obligations. The barriers on the page are still there, and other legal or contractual obligations need a separate assessment. Keep removing the problems that block users in your product anyway.
Sources and currency
The information about EN 301 549 V4.1.1 comes from the AccessibleEU notice of 7 September 2026 and confirms that the edition was published. Check its current citation in the Official Journal of the EU separately. Source 3 is Polish and is used only as a labelled example of national implementation.
- W3C WAI: Selecting Web Accessibility Evaluation Tools: what tools can and cannot do.
- Directive (EU) 2019/882 (European Accessibility Act), full text: in particular Articles 2–4, 13–15, 31 and 32 and Annexes I and V.
- Polish Accessibility Act of 26 April 2024, Journal of Laws 2024 item 731 (in Polish): example of national transposition.
- W3C: Understanding Conformance: WCAG conformance levels and requirements.
- AccessibleEU: EN 301 549 has been updated, 7 September 2026: publication of the edition versus its citation.
- W3C: WCAG-EM 2.0, Group Note of 23 July 2026: evaluation methodology and the limits of sampling.
- W3C: Reflow, 1.4.10.
- W3C: Text Spacing, 1.4.12.
- W3C: Contrast (Minimum), 1.4.3.
- W3C: WCAG 2.2, normative text: detailed conditions and exceptions for each criterion.
- W3C: Target Size (Minimum), 2.5.8.
- ETSI: EN 301 549 V4.1.1 (2026-09): foreword on which directives editions V3.2.1 and V4.1.1 were prepared for.