Does the European Accessibility Act apply to your Drupal site?
The European Accessibility Act (EAA) reaches products and services that matter most to persons with disabilities, including banking services, e-books, e-commerce and passenger transport services, as the European Commission describes the directive. Drupal can support WCAG-based conformance for a website or web application, but the platform does not make any service conformant on its own. Whether your Drupal site falls inside the EAA is a legal scoping decision that your organization or counsel must make, starting from the Commission's product and service scope and then checking how your specific offer, customers and member states apply it. A bank running a Drupal site for account opening, a retailer selling online, a publisher distributing e-books and a transport operator selling tickets online should each ask that question about the exact services the site delivers, not only about the brand's website.
Once the scope is clear, the work divides between the platform and the people who own the content. Drupal's accessibility work is documented on the Drupal.org accessibility page, which describes an accessibility focus across core and the contributed ecosystem. That gives you a sound starting point, but it does not cover the decisions that remain with your team: the theme's color contrast, focus order and component markup, the alternative text and heading structure editors add to pages, the accessibility of forms and checkout flows built from contributed modules, and the testing and remediation routine after launch. Ask your theme developer and content owners to name who approves each of these, and confirm with your legal or compliance team which services the EAA covers in each market where you operate.
Before you commit budget, confirm three things in writing: which services are in scope, which conformance target your counsel and accessibility lead have agreed for those services, and who keeps the evidence current. A partner can plan the Drupal side of that work, including theme audits, editor guidance and checks in the build pipeline, but the scope and the accessibility statement belong to your organization. Treat the scope decision as the first deliverable of the project, because it determines which pages, flows and modules receive remediation and which do not.
Mapping EAA service scope to Drupal capabilities and configuration
This table maps each service category named in the Commission's description of the European Accessibility Act to the Drupal site area it usually involves, the platform capability that helps, the configuration the team must own, and the work that remains after launch. Use it to scope the accessibility work per site area, and treat every capability claim as something to confirm against the Drupal.org accessibility documentation or an accessibility auditor before you rely on it.
| Service category | Drupal site area | Platform help and team configuration | Remaining content and process work |
|---|---|---|---|
| E-commerce | Product catalog, cart, checkout and account pages (for example, a Drupal Commerce store) | Core provides a base of accessibility features, but checkout forms, error messages and payment steps depend on theme markup and contributed form modules. Confirm current support on the Drupal.org accessibility page. | Product image alt text, accessible product descriptions, checkout flow testing with assistive technology, and an accessibility auditor review of key journeys. |
| Banking services | Account login, transaction views, forms for applications and secure messaging areas | Authentication flows and session timeouts must be designed so they can be operated with a keyboard and read by screen readers. Configure SSO and two-factor steps with the team's identity provider in mind. | Plain-language instructions, accessible error recovery, and documented testing of authenticated screens, which automated checks often miss. |
| E-books | Digital reading content, if published from Drupal (for example, as a content type with files or embedded readers) | Drupal can store and display structured content, but accessible e-book files are produced by the publishing process, not the CMS alone. Confirm with the publisher how files are created and checked. | Content structure (headings, lists, tables), alt text for images, and decisions about whether the team or a separate publishing tool owns the e-book format. |
| Passenger transport services | Timetable, booking, ticket purchase and real-time status pages | Booking widgets and third-party embeds frequently sit outside the theme. Map which parts Drupal renders and which the transport operator's vendor controls, then confirm responsibility in writing. | Vendor accessibility statements for embedded tools, accessible alternatives for live status updates, and regular editor checks of timetable content. |
How WCAG-based conformance is reached on Drupal
The European Accessibility Act sets accessibility requirements for products and services, but it does not give teams a technical checklist, so most teams use the Web Content Accessibility Guidelines (WCAG) as the reference and map their Drupal build to specific success criteria. Confirm with your legal or accessibility lead which WCAG version and which conformance level apply to each service in scope, and record that decision before the build starts, because every later test depends on it. Drupal core provides an accessibility baseline that the Drupal project documents on its accessibility features page, but core alone does not make a site conformant. Contributed modules used for forms, carts, search, media and third-party widgets each need their own review, and a module that is accessible in one release can regress after an update.
Most of the conformance work sits in the theme and in content authoring. The theme controls markup structure, focus order, color contrast, visible focus indicators and keyboard operation for menus, dialogs, carousels and accordions, so custom components should be tested with a keyboard and a screen reader before they are reused across templates. Editors control headings, alternative text, link text, media captions and table structure, and no template can compensate for a page with skipped heading levels or vague link text. Build these rules into content types and the editorial workflow: required fields for alternative text on images, a review step before publishing, and a short editor checklist tied to the content model rather than a separate policy document nobody opens.
Conformance is tested per page template and per content type, not for the site as a whole. A product page, a checkout step, a login screen and an article can each fail for different reasons, so sample each template and each content type that editors can create, including states such as error messages and empty search results. Third-party embeds such as payment widgets, chat tools and video players, and any PDFs the site publishes, need separate checks because the Drupal team does not control their markup. Plan these as their own work items with named owners, and record which findings are fixed in the theme, which are fixed in content and which are passed to the vendor.
Accessibility evidence a Drupal team can produce and keep
An accessibility claim on a Drupal site is only as credible as the records behind it. The items below are the working files a team can produce and keep current, and they feed an independent auditor or the organization's own assessment. None of them is a certificate or a conformance statement on its own.
Dated audit report per template
Record a WCAG-based audit for each page template (listing, product or service detail, checkout or application forms, account pages, and login) with the date, the Drupal core and theme versions tested, and the assistive technologies used. Store the report in the project repository next to the release it describes. Check that each finding names the template and component, so a fix to a shared component can be traced to every page that inherits it. Ask the auditor to state the scope and sample in writing.
Theme and component test record
Keep automated and manual test results for each component in the theme library, such as navigation, modals, form fields, tables and media players. Automated checks catch some issues, but keyboard, focus order and screen reader behavior need manual sign-off. Tag each record with the component version so a regression after a contributed module update can be found quickly. Link the record to the Drupal security and minor release cycle so retesting follows each update.
Configuration export under version control
Commit the exported site configuration, including theme settings, text formats, WYSIWYG options, module settings and image style definitions, to Git. Each release then shows what changed in accessibility-relevant settings, such as alternative text requirements or allowed HTML tags. Review changes through merge requests so a configuration change that removes a control is visible before deployment. Confirm with your hosting team that production never receives unreviewed configuration changes.
Editor guidance and training record
Maintain a dated record of the guidance given to content editors on headings, link text, alternative text, table markup, document uploads and color contrast, together with attendance or completion. Editors produce much of the content that an auditor samples, so this record is often the difference between a template that passes and one that drifts. Update the guidance when the editorial workflow or theme changes, and record who signed off each version.
Content review log for transactional pages
Log periodic reviews of high-traffic pages and transactional flows such as forms, payments, bookings and account screens. Record the page, reviewer, date, defects found and the ticket that fixed each one. For services covered by the European Accessibility Act, such as banking and e-commerce, these flows matter most because users must complete them. Sample a fixed set of pages each cycle so the log shows coverage over time, not only a single launch review.
Issue tracker history with fixes
Keep accessibility defects in the same tracker as other development work, with labels for WCAG criterion, template, severity and release. The history shows how quickly defects are found, fixed and verified, which an assessor will ask about. Confirm who owns triage, whether accessibility bugs can be deferred, and how deferrals are approved. Export the tracker history at each release so the record survives changes to the hosting tool.
Accessibility statements and editor checks
What should an accessibility statement on a Drupal site contain?
An accessibility statement should say which parts of the site it covers, what conformance level the organization is working toward, which parts do not yet fully conform, how users can report a barrier, and how and when the statement was last reviewed. Keep the structure plain and factual. No law fixes a single statement format that every organization must use, so confirm the required content with your legal or compliance team and with the national authority in each market you serve before publishing. Avoid claiming full conformance unless an independent test supports it.
Who owns the accessibility statement and who keeps it current?
Ownership sits with a named role on the organization side, usually the accountable executive or the compliance lead, who signs off the content. The content owner for the site drafts it, and the Drupal team maintains the page, its location and its template. Agree in writing who approves changes, who receives user reports and how quickly those reports are answered. Without a named owner, the statement tends to drift out of date after the first release.
How do we publish an accessibility statement on a Drupal site?
Create it as a standard content type or a basic page with a fixed URL, linked from the footer on every page and from the main navigation of the site. Store the known-issues list as a structured field or a view rather than free text, so the table can be updated without editing the whole page. Set the page's language and add a last-reviewed date field. Changes should go through the same workflow as other content, with a revision record kept for each published version.
Which accessibility checks should editors run before publishing a page?
Editors should run a short, repeatable checklist before every publish:
- Give every meaningful image alternative text, and mark decorative images as decorative.
- Use headings in order and do not use them for visual styling.
- Write descriptive link text and check that links open where users expect.
- Confirm that form fields have visible labels and that error messages are clear.
- Check color contrast and that the page works with a keyboard only.
Run an automated checker on the rendered page as a second step, then review the result manually, since automated tools miss many issues.
How do we handle user-generated and imported content for accessibility?
Treat user-generated and imported content as part of the site, because the organization is still responsible for what it publishes. Set rules for submitters, such as required alternative text fields in forms and content guidelines for comments or uploads. For imported content, review a sample after each migration or batch import, and fix systematic problems in the template or the importer rather than page by page. Decide who moderates content that fails the rules and how quickly it is corrected or removed.
How do we record known accessibility issues and workarounds?
Record each known issue in a register with the page or component affected, the criterion it fails, a severity rating, the workaround if one exists, the owner and a target date set by the owner. Link the register from the accessibility statement so readers can see what is known. Review the register at each release and close items only after retesting. Be careful about promising fix dates in public text, because a stated date becomes a commitment that the organization must then meet.
How often should the accessibility statement be reviewed after a release?
Review the statement after every release that changes templates, navigation, forms, media handling or third-party embeds, and on a fixed calendar cycle for the rest. Drupal core and contributed modules publish updates on a regular schedule, so check the release notes for accessibility-related changes and retest the affected pages. Update the last-reviewed date only when the review was actually carried out. Ask your implementation partner or internal team to confirm the review steps and the retest scope in writing when the project starts.
What Drupal and DeployOpen do not cover
Drupal gives you a capable base for accessible pages, but conformance depends on decisions and content that sit outside the framework and outside any implementation partner's scope. The cards below name the gaps, who should own each one, and what to confirm in writing before the build starts.
Legal scope determination
Whether a given service, product or site falls under the European Accessibility Act depends on your sector, your service categories and how your national authority reads the directive. DeployOpen can build to the requirements you choose, but it cannot decide what the law covers for your organization. Your legal or compliance function should own the scope decision and record it in a memo that the project team signs against. Confirm which services and sites are in scope before estimating any work.
Editor-authored and vendor content
Most accessibility failures on a live site come from content, such as alt text, heading order, link labels and color contrast in body copy, rather than from templates. Editors and third-party agencies write that content after launch, so the Drupal build can only provide the checks and guidance. Your content owner should own editorial standards and training. In the contract with any content vendor, confirm they must follow your accessibility guidelines and fix defects they introduce.
Embedded widgets and partner front ends
Chat tools, maps, video players, cookie banners and payment or banking partner iframes often load from outside your Drupal codebase. Their accessibility is controlled by the third party, and an embedded element can fail even when your theme passes. Your digital product owner should own the inventory of embedded services and their conformance evidence. Ask each vendor, in writing, for its accessibility statement and conformance level, and confirm who fixes a defect reported in their widget.
PDFs and external documents
Downloadable PDFs, Word files and spreadsheets linked from Drupal pages are separate documents that Drupal does not author or remediate. Many are scanned or exported without tags, so screen reader users cannot navigate them. Your document owners should own remediation, either at source or through a publishing rule. Confirm whether legacy documents are in scope, who approves exceptions, and whether a document repository will be restricted to tagged files.
Testing with people with disabilities
Automated checks and expert reviews catch many issues, but they cannot show how people with disabilities experience a journey such as account opening or checkout. DeployOpen can plan and run technical testing, yet user testing needs participants recruited and paid by you, with their consent and feedback handled by your team. Your accessibility or service design lead should own this program. Confirm the testing cadence, the participant recruitment method and how findings feed the backlog.
Conformance claims and certification
An accessibility statement is a public claim about your conformance, and the claim must match what you have tested. DeployOpen prepares test evidence and a conformance review, but it does not issue audit reports, attestations or certifications, and no implementation partner can certify conformance on your behalf. Your legal and accessibility owners should own the statement and any independent assessment. Confirm which body, if any, will assess conformance and what evidence it will require before publication.
Configuration sequence for an EAA-ready Drupal site
This sequence moves an EAA-ready Drupal site from legal scope to measured conformance, with each step producing an artifact the next step depends on. It keeps the accessibility work tied to the templates, components and editorial habits that determine whether the site stays conformant after launch.
Confirm service scope with counsel
Your legal or compliance team, with counsel, decides which of your services fall under the European Accessibility Act. The EU Commission lists banking services, e-books, e-commerce and passenger transport services among the covered categories, so a site that sells or provides these services needs an explicit scope decision. DeployOpen can document the sites and services in front of counsel, but the classification is a legal decision. Done means a written scope note naming each in-scope site, service and member state, signed off by the owner.
List in-scope templates and user journeys
Using the scope note, the product owner and a Drupal developer inventory every page template, content type view, form, checkout or account step, and any journey a customer must complete to use the service. Include content generated by Views, Webform, Commerce and any embedded third-party widgets, since these are often where conformance breaks. Done means a spreadsheet of templates and journeys with an owner and a priority for each, reviewed by the business owner.
Select the WCAG target and test method
The team chooses the WCAG version and conformance level it will test against, and records the testing methods it will use: automated scanning, manual keyboard and screen reader testing, and review with assistive technology users where practical. Confirm the target with counsel and any sector regulator, because the EAA refers to accessibility requirements that your compliance adviser should map to the chosen standard. Done means a written test plan that names the standard, level, tools and the people who test.
Audit core and theme output
A developer or accessibility specialist audits the rendered output of Drupal core, the active theme and each contributed module on the in-scope templates, against the chosen target. Drupal core publishes its own accessibility commitments on Drupal.org, which helps you separate core behavior from theme and content defects, but core output still needs testing in your configuration. Record each finding with the template, the success criterion affected and a reproduction step. Done means a defect log that separates core, contributed module, theme and content issues.
Fix templates and reusable components
Developers correct the theme templates, Twig output, form markup, focus styles and color tokens at the component level, so one fix applies to every page that uses the component. Contributed module issues are either configured around, patched in a custom module, or raised upstream with the maintainer, and the choice is recorded for future upgrades. Done means each high-priority defect has a fix merged, retested on the affected template, and an upgrade note for any patch that will need reapplying.
Configure editorial tools and content guidance
Editors create content through WYSIWYG settings, media fields, and block layouts that can still produce inaccessible content, such as missing alternative text, skipped heading levels or vague link text. The team restricts formats, adds required fields or validation where Drupal allows it, and writes short guidance on headings, images and link text for each content type. Editor training is delivered against that guidance. Done means editors can complete a sample page per content type that passes the same checks as the templates.
Publish the accessibility statement and feedback route
The organization writes an accessibility statement covering the scope, the target standard, known limitations with planned fixes, and a contact route for reporting barriers. Counsel reviews the statement, and the feedback form or address is tested so that a report reaches a named owner. DeployOpen can prepare the draft and the operational routing, but the statement is the organization's own published commitment. Done means a live statement linked from the footer and a tested route that logs and assigns each report.
Add regression checks to the build pipeline
The team adds automated accessibility checks to the Composer-based build or CI pipeline so that changes to templates, components and configuration are scanned before release. Automated checks catch only part of WCAG, so the pipeline should run them on the in-scope templates and keep manual test scripts for each release. Failures block the merge when they breach the agreed threshold. Done means a pipeline run that fails on a seeded defect, plus a documented manual test checklist for each release.
Schedule re-review at each Drupal release
Drupal publishes bugfix releases on the first Wednesday of each month and security releases on the third Wednesday, so the team plans a standing review after those dates to check that updates have not changed markup, focus behavior or contributed module output. Major version changes, such as the move to Drupal 12 scheduled for the week of December 7, 2026, trigger a full re-audit of the in-scope templates. Done means a recurring review calendar with an owner, a checklist, and a record of each re-test.
Questions buyers ask about EAA work on Drupal
What drives the cost of European Accessibility Act work on a Drupal site?
The cost follows the size and state of the site: how many page templates and content types need remediation, how many custom components and interactive widgets exist, how many third-party embeds (payment forms, booking widgets, chat tools, video players) appear on key journeys, how much legacy content must be corrected, and how good the current theme's markup is. Each of these is a separate line in a written scope. Sites with a well-built theme and few custom interactions usually need less work than sites with many bespoke components. Ask any partner, including DeployOpen, for a quote that lists templates, components, embeds and content areas separately, so you can see which items are one-time work and which recur with each new release or content campaign.
How long does accessibility remediation take on a Drupal site?
The duration depends on the same inputs as cost: the number of templates and components, the number of third-party embeds that the organization does not control, the volume of legacy content, and how quickly decisions are made on design and content changes. No general duration applies to every site, so treat any timeline without a stated scope as an estimate to challenge. A useful plan separates template and theme fixes, which often cover many pages at once, from content corrections and embed decisions, which depend on people outside the project team. Ask for milestones tied to the agreed deliverables.
Can our internal team handle EAA accessibility work on Drupal alone?
Many teams can handle parts of the work internally, especially content corrections, alt text, heading structure and editor training, provided they have someone who understands WCAG-based testing. Theme markup, custom modules, keyboard behavior in interactive components and integration with third-party embeds need developers who know both Drupal and accessibility testing. Consider a short internal audit first: if the defects cluster in a few templates, an internal team may manage them. If they are spread across custom code and embeds, a partner with Drupal development and testing experience can shorten the work. DeployOpen plans, implements and documents Drupal work inside your own infrastructure, so you keep ownership of the code and the evidence.
What do editors and product owners need to contribute to accessibility work?
Editors and product owners make decisions that code cannot make alone. Editors need to write meaningful link text, supply alternative text for images, keep heading levels in order, and use the content model rather than manual formatting. Product owners need to approve design changes such as color contrast, focus styles and form layouts, and to decide what happens to embedded third-party tools that fail testing. Plan review time for both groups. Editor training and a short internal style guide for accessible content are usually part of the scope, and they recur whenever new staff join.
Is a fixed-scope engagement possible for Drupal accessibility work?
Yes. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. For accessibility work, the written scope should name the templates and user journeys in scope, the WCAG-based criteria the team will test against, the components and embeds covered, the content areas to correct, and the evidence delivered at the end. Work the organization does not control, such as a third-party booking provider's markup, should be listed as an dependency with a clear owner. Ongoing checks after launch can be arranged as a separate retainer.
Do Drupal upgrades affect accessibility conformance?
They can. Drupal core and contributed modules change markup, scripts and admin interfaces across releases, so a site that conformed at one version may regress after an upgrade. Drupal 11 is the current major version, and Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule. Drupal 12 is scheduled for the week of December 7, 2026. Plan regression testing for key templates and journeys as part of each upgrade, and keep the accessibility test suite in your delivery pipeline so that theme and module changes are checked before release. Confirm with your upgrade partner how accessibility regression testing is included in the scope.
Can DeployOpen issue an accessibility conformance certificate for our site?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform conformance assessments and issue any formal findings. What DeployOpen can provide is remediation work, documented test results, an accessibility statement draft for your review, and editor guidance, so that an independent assessor has clear evidence to review. Ask any partner to state in writing which parts of the work are their deliverables and which belong to an external assessor.
Which Drupal sites does the European Accessibility Act affect?
The European Accessibility Act is an EU directive covering products and services most important for persons with disabilities, including banking services, e-books, e-commerce and passenger transport services, according to the European Commission. Drupal sites that sell products, run online banking or account services, or deliver covered e-commerce journeys are the most likely to fall within scope. Whether a particular site is in scope depends on the service it provides and on national transposition, so confirm the position with your legal or compliance team before scoping work. Once scope is clear, the technical plan follows from the templates and journeys involved.
How DeployOpen scopes and delivers accessibility work on Drupal
DeployOpen plans, builds, documents and supports self-hosted Drupal inside your own infrastructure, so accessibility work sits alongside content, theme and integration work in one written scope. We prepare the site, theme, content practices and evidence for the EAA, and we do not issue audit reports or certifications.
How we scope
- We list which sites, services and user journeys fall under the European Accessibility Act before any build starts.
- The written scope names the WCAG-based conformance target, the templates, content types and forms included.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- We build or adjust themes, components and custom modules so semantic markup, focus order and labels are correct by design.
- Editors receive content guidance and form patterns that keep alternative text, headings and link text consistent.
- We test with automated checks and manual keyboard and screen reader passes against the agreed success criteria.
How we hand over
- Handover includes configuration exports, theme documentation and a record of test results and open issues.
- We write an accessibility statement draft and a checklist that your team can maintain as content changes.
- Your team receives a runbook covering how to re-test after module and core updates.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after launch.
- Retainers can cover re-testing after Drupal core and contributed module updates on the release schedule.
- Confirm with your legal and compliance leads which parts of the statement and evidence your organization owns.
