Open source CMS for the EU Web Accessibility Directive

Each public sector website and mobile app needs a published accessibility statement that identifies the content that is not accessible, the reasons, and the alternatives offered. On a Drupal or WordPress estate, the statement is best treated as managed content: it lives on a stable URL in every site footer, has a named owner, and carries a review date. Keep the version history of the statement itself, because monitoring bodies compare what was published with what the site actually does. Confirm the required wording and structure with your national transposition law and your monitoring authority, since national rules add detail to the European Commission's baseline.

Assessors expect evidence that conformance to EN 301 549 v3.2.1 was tested by template, not only by page. Record the test method (automated scans, manual keyboard and screen reader checks, and a sample of authenticated flows), the tester, the date, the template or component tested, and the result against each applicable success criterion. Drupal and WordPress sites share templates across many pages, so one defect in a shared component can affect hundreds of URLs. Keep the test reports in the same repository as the theme code so each release can be traced to the report that covered it.

Keep a defect register that links each accessibility finding to a ticket, the affected template or content type, the fix, the release that shipped it, and the date of verification. On Drupal, the release pipeline and the issue tracker provide the release and verification dates; on WordPress, the deployment log and the theme version history do the same job. Assessors look for time between detection and fix, and for regression retests. Do not claim that a fix date equals conformance: record what was retested and what remains open, with an owner for each open item.

The directive requires a feedback mechanism for reporting accessibility problems. The evidence is the feedback form or contact route itself, a log of every submission with a timestamp, the category, the page or component, the response, and the closing date. On Drupal, form submissions and the audit trail of the contact module can be stored with a retention period set by your records policy. On WordPress, use a form plugin that writes entries to your own database, not to a third-party service, and confirm where the data is stored. Agree internal response targets with your legal and accessibility leads; these are your targets, not a requirement stated in the directive.

Maintain a component inventory listing every contributed module, theme, library, plugin and embedded third-party widget, with its version, licence, maintainer, and its accessibility status. Drupal contributed modules and WordPress plugins often render markup that the core team does not control, so each one needs its own test result or a documented exception. Embedded widgets such as video players, maps, chat tools and payment forms are common gaps. Record who approved each component and why. This inventory is also the document that shows monitoring bodies you know what is running on the estate.

Keep a change log that links each deployed release to the Drupal core or WordPress core version, the contributed module or plugin versions, the theme version, and the accessibility regression test that ran before release. Drupal core security releases follow a published schedule on the third Wednesday of the month, and WordPress 7.1.3 was released on October 6, 2026, with only the latest 7.1 release actively maintained. Because of this cadence, your change log will show frequent small updates; assessors look for the test evidence attached to each one, not for a quiet estate. Automatic updates may apply some patches without a human review, so record which updates were automatic and which were approved.

Monitoring bodies look for proof that content stays accessible over time, not only at launch. Provide the content review history for each section: the editor, reviewer, review date, and the next review date. Drupal revision history and content moderation logs, or WordPress revision history and editorial plugin logs, show who changed what and when. Accessibility checks should be part of the editorial workflow, such as a required alt text field, heading structure checks and a review step for new document uploads. Confirm with your own editorial governance which review cycle applies to each content type.

No. The European Commission states that overlays that do not ensure conformance are not an appropriate solution, and automated scans detect only part of the defects in EN 301 549. Automated tools are useful for regression checks and for building the evidence trail, but assessors expect manual testing with assistive technology and keyboard use. Treat the scan output as one input into the test record, and keep the manual results alongside it. DeployOpen can plan and run security and accessibility-related testing as part of an implementation or retainer, but no testing method guarantees an audit outcome.

The main drivers are the number of sites and page templates, how much of the theme must be rebuilt, the size of the existing remediation backlog, and how deep the testing goes. A single site with a few templates is a much smaller job than a multi-site estate where every department uses its own variants. Migration work matters too: a Drupal 7 or Drupal 10 site cannot simply be updated, and its themes must be rebuilt, so accessibility fixes are often bundled into that rebuild. Ask the partner to price testing, theme remediation, content remediation and documentation as separate line items so you can see what each one buys.

The first audit, template and theme remediation, and the initial accessibility statement are one-time costs. Recurring costs include re-testing after releases, updating the accessibility statement when content or conformance changes, handling feedback submitted through the reporting mechanism, and applying security updates to keep the platform supported. Accessibility is not a state a site reaches once: new content, new components and new contributed modules or plugins can introduce barriers. Ask for the recurring scope in writing, including how many release cycles are covered per year and who triages incoming feedback.

Many teams can handle content fixes and editorial checks internally, especially alt text, heading structure, link text and document accessibility. Template, theme and component fixes usually need developers who know EN 301 549 and WCAG well, and independent testing with assistive technology is harder to do in-house without a documented method. Confirm three things before deciding: whether your developers have current WCAG 2.2 experience, whether someone can run a repeatable test plan with screen readers and keyboard navigation, and whether there is a named owner for the statement and the feedback channel. A partner can cover any gap, and the split should be written into the scope.

The commitment depends on how much content exists and how many people publish to it. Editors need training on accessible authoring, and reviewers must check remediated pages before they go live. Content owners must confirm which pages carry legal or service information, because those pages are most likely to be checked. The total effort is not fixed by the platform. Ask the partner to estimate editor and reviewer hours by page type and site, and to show which tasks they will do and which you must do. Be cautious of any estimate that does not separate the two.

No. The European Commission says overlays that do not ensure conformance are not an appropriate solution for public sector websites. Overlays typically add a script that adjusts the page, but they cannot fix the underlying markup, keyboard traps, missing labels or inaccessible components that the directive requires you to address. They can also create new barriers for assistive technology users. Use the money for code and content remediation instead, and treat any overlay pitch as a red flag during procurement.

A migration usually changes the accessibility effort more than any other single factor because it forces a theme rebuild. Drupal documentation states that Drupal 6 and 7 sites cannot simply be updated to Drupal 10 or later, they are migrated into a new site and themes must be rebuilt. Drupal 7 security support ended on January 5, 2025, and Drupal 10 reaches end of life on December 9, 2026, so sites on those versions face a deadline either way. Rebuilding the theme is the moment to fix component-level barriers once rather than page by page. Confirm with the partner whether the accessibility scope covers the rebuilt theme only or the migrated content as well.

Ask for a written scope that lists the sites, templates, languages and document types covered, the conformance target (EN 301 549 v3.2.1 and the WCAG criteria it references), and the testing method, including whether assistive technology testing is included. Request separate line items for initial audit, remediation, retesting, accessibility statement drafting, feedback handling and training. Ask which recurring items are included and how changes after go-live are priced. Confirm acceptance criteria and who signs off each deliverable. Ask for a list of assumptions that would change the price, such as content volume or unknown third-party components.

The duration depends on the number of templates and sites, the size of the remediation backlog, and whether the work is combined with a migration or theme rebuild. Public sector deadlines in the EU are set by national transposition and monitoring rather than a fixed date for each site, so plan around your national authority's requirements. Ask the partner for a phased plan with milestones for audit, template fixes, content fixes and publication of the statement, and confirm which phases depend on decisions or content from your side. No duration should be accepted without the assumptions behind it.