EAA and WCAG 2.1: how to implement digital accessibility

Since June 28, 2025, national laws transposing the European Accessibility Act (EAA), formally Directive (EU) 2019/882, apply across EU member states. The legislation does not cover every private website. It targets the consumer services listed in Article 2(2) of the directive, including e-commerce, consumer banking services, electronic communications, services providing access to audiovisual media, e-books, and the websites, apps and e-tickets of air, bus, rail and waterborne passenger transport. Microenterprises providing services (fewer than 10 employees and an annual turnover or balance sheet total not exceeding 2 million euros) are exempt under Article 4(5). The full list, the exceptions and the national fines are covered in the WordPress accessibility and WCAG 2.2 guide. This article covers something else: how an implementation runs on a WordPress site.

Directive 2019/882 does not mention WCAG by name. Annex I requires websites and mobile apps to be made perceivable, operable, understandable and robust, the same four principles that structure WCAG, and Article 15 presumes conformity for services that meet harmonised standards published in the Official Journal. In practice, audits are therefore measured against the success criteria of WCAG 2.1 or 2.2 Level AA. This guide outlines how an accessibility implementation progresses on a WordPress site: defining the audit scope, gathering a representative page sample under the W3C methodology, repairing theme templates, and publishing an accessibility statement.

#Understanding the European accessibility act (EAA) and WCAG 2.1

The European Accessibility Act establishes a common regulatory framework to remove trade barriers caused by diverging national accessibility laws. Its technical foundation rests on the four established pillars of digital accessibility: interfaces must be perceivable, operable, understandable, and robust.

WCAG 2.1 is the internationally recognised standard for digital accessibility. Penalties are not set by the directive itself: Article 30 leaves them to each member state and requires them to be effective, proportionate and dissuasive, accompanied by remedial action where an economic operator does not comply. The amounts therefore depend on the national transposing law of each country where the service is offered.

#Why digital accessibility is essential for commercial platforms

Beyond statutory compliance, building accessible digital experiences yields tangible strategic advantages:

• Expanded customer reach: According to the European Commission, roughly 90 million people live with a disability in the European Union, a large group of potential customers and users for your site.
• Universal usability improvements: Accessible design directly improves the user experience for everyone. Clear typography, high visual contrast, structured navigation menus, and readable layout sections benefit senior citizens, mobile users in bright sunlight, and visitors with temporary limitations.
• Search engine alignment: Many WCAG requirements closely align with search engine optimization principles, such as semantic document outlines, meaningful image descriptions and responsive mobile layouts.
• Conversion: Simpler checkout flows, clear error handling on checkout forms, and predictable keyboard focus make purchases easier to complete.
• Brand equity: An accessible site shows a socially responsible, modern business.
• Legal risk mitigation: Auditing and remediating digital assets reduces the probability of customer complaints, enforcement notices, or fines under national law.

#What WCAG 2.1 AA compliance requires in practice

Achieving conformance with WCAG 2.1 Level AA entails practical engineering changes across the presentation and application layers:

• Keyboard operability: Every interactive element (menus, carousels, modals, accordion tabs, and checkout buttons) must be operable using only a keyboard, displaying a distinct, visible focus indicator.
• Screen reader interoperability: Semantic HTML tags, appropriate ARIA roles, descriptive alt text for informative images, and clear form input labels ensure screen reader users receive equal contextual information.
• Color contrast ratios: Text and user interface components must meet contrast thresholds (a minimum ratio of 4.5:1 for regular text and 3:1 for large text and active interface controls).
• Synchronized media alternatives: Captions and text transcripts must accompany embedded video and audio recordings.
• Predictable heading hierarchy: Pages must organize information into a logical, unskipped hierarchy (h1 through h6).
• Accessible form validation: Checkout fields must announce validation errors clearly, identifying which field caused the issue and providing suggestions for correction.
• Document accessibility: Downloadable catalogs, invoices, and PDF manuals must feature tagged structures readable by assistive software.
• Responsiveness: The site must work on phone, tablet and desktop.

#The accessibility implementation workflow for WordPress

An accessibility project on WordPress usually runs in five steps:

1. Technical audit: Review the WordPress site, combining automated scans with manual verification using screen readers.
2. Theme and plugin remediation: Modify existing template files and components, or replace inaccessible ones with accessible alternatives.
3. Code-level remediation: Correct missing ARIA associations, remove keyboard traps, restore focus states, fix heading structures and form labels, and adjust contrast palettes.
4. Editorial training: Teach content creators to write meaningful alternative text, keep heading hierarchies intact, and tag downloadable documents.
5. Accessibility statement: Prepare the statement and set up a feedback mechanism for users.

The following sections break these steps into concrete decisions. The reference is WCAG-EM 2.0, the WCAG conformance evaluation methodology the W3C published as a Group Note on 23 July 2026. It divides an evaluation into five steps: defining the scope, exploring the website, selecting a representative sample, evaluating the sample, and reporting the findings.

#How to define the scope for a website accessibility audit

The first step of WCAG-EM has four elements: the scope of the website, the target conformance level, the accessibility support baseline, and optional additional requirements. On a WordPress site, each one maps to a concrete decision.

Scope of the website: State what the evaluation covers. Only the main domain, or also a subdomain with the shop, the customer account area, language versions and campaign pages? On a WordPress multisite network, each site can run its own theme and plugins, so any excluded network site must be documented explicitly.

Target conformance level: For services covered by the EAA, the practical target is Level AA. The choice between WCAG 2.1 and 2.2 belongs in the scope, because it defines which success criteria the auditor checks. WordPress itself has adopted WCAG 2.2 AA for its own code, as the accessibility coding standards state.

Accessibility support baseline: WCAG-EM requires defining which combinations of browsers and assistive technologies the evaluation relies on. For example: NVDA with Firefox or Chrome on Windows, VoiceOver with Safari on macOS and iOS, TalkBack with Chrome on Android. Without this list, two audits of the same site can produce different results and neither can be repeated.

Additional requirements: This covers anything beyond conformance, such as selected Level AAA criteria or a usability test with people with disabilities.

#How to select page samples following the WCAG-EM methodology

The second step of WCAG-EM is exploring the website: common views, essential functionality, page types, and the technologies the content relies on. The methodology defines common views as those relevant to the entire site, usually linked directly from the entry point: the home page, help, legal information and contact.

In WordPress it pays to explore along the template hierarchy, because one template generates hundreds of URLs:

The third step selects the sample. WCAG-EM combines three components:

• Structured sample: Covers the common views, the essential functionality and one example of every page type.
• Random sample: According to the methodology, the random sample is 10 percent of the structured sample and is added on top of it. With 30 pages in the structured sample, the evaluation adds 3 random ones.
• Complete processes: If a page belongs to a process, every step of that process enters the sample, including the starting point, the default sequence and the important branches.

On a WooCommerce store, the complete purchase process is the cart, customer details, choice of shipping and payment, the order confirmation, and the path with a validation error. On a contact form, it is the empty form, the form with errors and the message after submission. An audit that skips the error state skips the place where a screen reader user most often gets stuck.

#What random sampling reveals in website audits

The fourth step of WCAG-EM evaluates the selected pages and processes and then compares the results of the structured sample with those of the random sample. If the random pages reveal problems that did not appear in the structured sample, the sample was not representative and has to be extended. In WordPress this mostly happens when exploration missed a content type: an old post from the classic editor, a page built with a different page builder, or a plugin that injects its own widget on only some pages.

The methodology also assumes that the evaluator knows WCAG 2 well, understands assistive technologies and knows how people with disabilities use websites. Running an automated tool does not meet that assumption, because the tool cannot judge whether alt text describes the image or whether the focus order makes sense.

#How to prioritize accessibility fixes efficiently

An audit report usually lists dozens of errors. In WordPress, the fix order is better set by where an error originates than by the order of the list:

1. Complete processes that block the goal: An error that prevents completing an order or submitting a form shuts the service to a whole group of users, so it comes first.
2. Shared template parts: Header, menu, footer, consent banner and search appear on every page. One fix in a template part or theme file removes the error from the whole site.
3. Reusable components: Custom blocks, patterns, shortcodes and plugin widgets. The question here is whether to fix, replace with an accessible alternative, or remove.
4. Editorial content: Alternative text, headings inside posts, link text and PDF files. The editorial team fixes this part, so fixes should come with rules and examples.

This split also affects the budget: fixes in points 2 and 3 are done once and apply to thousands of URLs, while point 4 grows with the volume of content.

#Testing with assistive technology users

A WCAG audit tells you whether the site meets the criteria. It does not tell you whether the site is comfortable to use. In “Involving Users in Evaluating Web Accessibility”, the W3C WAI recommends involving people with disabilities throughout the work rather than only at the end, and notes that conducting informal evaluations throughout development is more effective than only formal usability testing at the end of a project.

That material gives concrete rules for organising a test:

• Expert review first: Remove obvious barriers before inviting users, so their time is not spent on problems the audit already found.
• A few people, different needs: The WAI recommends including a few people with disabilities and, depending on the audience, older users. The experience level should match the audience: on a public service, novice screen reader users matter too.
• Think aloud: Participants say what they are doing and what they expect, and the facilitator notes where a barrier causes an error.
• Careful conclusions: The WAI warns: “Avoid assuming that input from one person with a disability applies to all people with disabilities” (W3C WAI). The problem may lie in the content, the browser, the assistive technology, or how familiar the participant is with it.

User testing does not replace the audit. The WAI writes that involving users alone cannot determine if a website is accessible, so it is combined with WCAG conformance evaluation. In a WordPress project, a good moment for the test is when the template fixes are already on staging and the content is real, not placeholder.

#What an accessibility statement must contain

The W3C WAI guidance on accessibility statements sets a minimum: a commitment to accessibility, the standard applied (for example WCAG 2.2) and contact details in case users encounter problems. It also recommends including known limitations, measures taken by the organisation, technical specifications, the environments in which the content was tested, and references to applicable legislation.

The free W3C accessibility statement generator walks through these fields. The limitations section takes the most work, because for each known issue the generator asks for five things: which content part it affects, a description of the issue, why the issue occurs, what the organisation is doing about it, and what users can do in the meantime. Filling it in honestly requires the audit results, so the statement is written after the evaluation, not before. The generator also has fields for the conformance status (fully conformant, partially conformant, non conformant, not assessed) and for the assessment approach: self-evaluation or external evaluation.

For services covered by the EAA, the directive adds its own obligation. Article 13(2) of Directive (EU) 2019/882 requires the service provider to prepare the information in accordance with Annex V and explain how the service meets the accessibility requirements. The information must be made available to the public in written and oral format, including in a manner accessible to persons with disabilities, and kept for as long as the service is in operation. Annex V says the information goes into the general terms and conditions or an equivalent document and, where applicable, contains:

• a general description of the service in accessible formats,
• descriptions and explanations necessary for understanding the operation of the service,
• a description of how the service meets the accessibility requirements of Annex I.

For a WordPress store this usually means two documents: a page with the accessibility statement for users, and a section in the terms and conditions with the information Annex V requires. Both should be linked from the footer so they are reachable from every page.

#How to maintain accessibility standards long term

The accessibility of a WordPress site changes with every theme and plugin update and with every new post. The directive anticipates this in Article 13(3): the service provider must have procedures in place so the service remains in conformity, and must take into account changes in the service, in the requirements and in the standards it refers to. Article 13(4) adds that in case of non-conformity the provider takes corrective measures and immediately informs the competent national authorities.

In practice, this procedure on a WordPress site has a few fixed elements:

• Re-evaluating the sample after changes: The audit sample (common views, page types, complete processes) becomes a checklist after updating the theme, the form or shop plugins, and after changing a template part.
• Recording results: In its fifth step, WCAG-EM recommends documenting the outcome of each step and, optionally, a machine-readable report. The free WCAG-EM Report Tool walks through the steps of the methodology and produces a report that can be compared with the next audit.
• Rules for the editorial team: Most new errors after implementation come from content: missing alternative text, a skipped heading level, a PDF scanned as an image.
• Handling requests: The contact channel in the statement needs an owner and a response time, because the W3C generator asks for exactly that: the typical duration for a response.

If a business relies on the disproportionate burden clause in Article 14, it has to document the assessment and keep the relevant results for five years after the service was last provided. One more reason to keep audit results and fix decisions in one place.

#Who should implement accessibility on your WordPress site

Building accessible WordPress sites requires familiarity with the template hierarchy, the block editor, and how assistive technologies behave:

• WordPress engineering expertise: We work on accessibility across custom themes, WooCommerce stores, and larger portals.
• Structured methodology: Our audits follow the W3C WCAG-EM methodology and end with actionable technical documentation.
• Long-term governance: We train editorial teams and help draft accessibility statements.

The deadline has already passed. Contact our team to discuss your accessibility roadmap. Explore our WordPress developer services or learn how our WooCommerce developer solutions make shopping work for all users.