Accessible citizen participation under the EU Web Accessibility Directive

Why a Decidim participation site must meet EN 301 549 before launch

The EU Web Accessibility Directive, (EU) 2016/2102, applies to public sector websites and mobile apps and requires them to meet the technical criteria of the harmonised standard EN 301 549 v3.2.1. It also requires each covered site or app to publish an accessibility statement that identifies inaccessible content and the alternatives offered, and to provide a feedback mechanism for reporting problems. For a public body running a participation hub, the site is the channel residents use to vote, propose and sign, so these duties apply to the whole hub, not only the home page. The directive has been in force since 22 December 2016, and the Member State transposition deadline was 23 September 2018, so a public body launching a new Decidim site has no transition period to plan around.

The directive also rules out a shortcut. The European Commission says that accessibility overlays that do not ensure conformance are not an appropriate solution, so a script that adjusts the page at runtime does not discharge the duty. The work sits in the code, templates and content of the site. Before launch, confirm which EN 301 549 clauses your national monitoring body expects you to evidence, who in your organization owns the accessibility statement, and where the feedback mechanism routes reports, since a statement that points to an unmonitored inbox is a weak position if a complaint is escalated.

If the same participation hub also serves jurisdictions in the United States, the parallel obligation is the US ADA Title II rule, which requires state and local government web content and mobile apps to meet WCAG 2.1 Level AA under a compliance date of 26 April 2027 for entities serving 50,000 or more people and 26 April 2028 for smaller entities and special districts. That timeline is a useful cross-check, not the scope of this page. The rest of this page treats the EU duty as the focus and works through what it means for a Decidim build.

Mapping the directive's obligations to Decidim configuration

This table maps each obligation under the Web Accessibility Directive to what the public body must do on a Decidim site and where that work is configured. Read it as a checklist for the build and the launch gate: each row names the evidence an assessor or monitoring body will expect to see. Custom themes, forms and integrations are where most gaps appear, so those rows deserve the most testing time.

Requirement	What the function must do	How to configure it in Decidim
EN 301 549 v3.2.1 for the site and each component	Meet the technical criteria of EN 301 549 v3.2.1 across pages, processes, assemblies, proposals, budgets and surveys, not only the home page.	Test each component and space type in the custom theme and content templates. Confirm exact conformance mapping with your accessibility auditor.
Locale-prefixed URLs	Keep language versions consistent so screen reader users and search tools land on the correct language.	Confirm how locale-prefixed URLs in v0.32 behave with your custom theme, redirects and any links stored in older content.
Accessibility statement	Publish a statement identifying inaccessible content, the reasons for it and the alternatives available to users.	Add the statement as a static page or content block in the organization's space, linked from every page footer and from the feedback form.
Feedback mechanism	Give users a working way to report accessibility problems and receive a response.	Use a contact or feedback form in the theme, and route messages through SMTP to a monitored mailbox. Test delivery from the production mail server.
Overlays and quick fixes	Do not rely on overlays to claim conformance, since the Commission says they are not an appropriate solution.	Keep remediation in the theme code and content, and record fixes in the issue tracker rather than adding third-party scripts.
Accessible proposal and voting forms	Let every user complete authorization, proposal, vote and survey forms with a keyboard and assistive technology, with clear error messages.	Test authorization handlers, census upload forms and vote confirmation screens with assistive technology before each launch.
Monitoring readiness for national reporting	Keep evidence that can support the monitoring and reporting cycle, which Member States report to the Commission every three years.	Keep dated test records, the statement version history and feedback logs for each space. Confirm the reporting requirements with your national authority.
Testing custom themes before launch	Verify that each theme change, upgrade and new component keeps conformance, since Decidim upgrades change templates.	Run automated and manual checks on a staging copy after each minor upgrade, one minor version at a time, as the Decidim update guide requires.

Which open-source options fit an accessible participation hub

Decidim is the open-source participation framework built for processes, assemblies, initiatives, proposals, surveys, meetings and participatory budgets. It is licensed under the AGPL-3.0, runs on Ruby on Rails and PostgreSQL, and is maintained by the Decidim Association together with Barcelona City Council. For a public body, the practical question is less whether the core fits the workflow and more which version line the body will run and who will apply its security updates.

Version line: Decidim v0.32.0 was released on July 6, 2026, followed by v0.32.1 on July 30, 2026. The 0.31 branch received v0.31.7 on September 3, 2026. Until version 1.0, only the last two minor versions receive security updates, so 0.32.x and 0.31.x are the supported branches, and 0.30.x and earlier are not.
Runtime requirements: v0.32 requires Ruby 3.4.7 and Node 22.14.x, while v0.31 uses Ruby 3.3.4 and Node 22.14.x. Confirm these with the target server image before scoping.
Upgrade path: Upgrades must go one minor version at a time, with the database backed up first, because some releases change database structures.
Patch window: Implementers get a grace period of 2 months for standard vulnerabilities and 4 months for critical ones before details are disclosed.
Accessibility scope: The core components are the body's responsibility only in combination with its configuration, theme and content, so the audit should cover the instance the public actually uses.

Confirm with the vendor which branch will receive fixes during your planned go-live window.

How the accessible voting and proposal flow is built and tested

The resident journey has to work for everyone before any legal duty can be claimed. On a Decidim site, the path runs from sign-in through the OmniAuth login buttons, into the proposal creation form, through the voting or signature step, and out to the confirmation page. Each step is a separate control set to review. Login is the first gate: the social login buttons and any custom OmniAuth provider the organization adds must be reachable by keyboard, must have visible focus, and must give a clear name to the button so a screen reader user knows which provider they are choosing. Where a provider redirects off the site and back, check that focus returns to a sensible place and that the error page after a failed login is readable and offers a way forward.

Proposal creation and voting forms carry most of the accessibility risk, because they combine text fields, rich text editors, category selectors, file attachments and submit buttons. Test each form with keyboard only, with a screen reader such as NVDA or VoiceOver, and at 200 percent and 400 percent zoom to check reflow under EN 301 549. Pay particular attention to error handling: every validation message should be tied to its field, announced when the form is submitted, and written so the user knows how to correct it. Confirm that the confirmation page announces the outcome and that the vote or signature is not lost if the page is refreshed. Authentication screens should be checked against the same criteria, and the reviewer should record which EN 301 549 clauses each finding maps to.

Custom themes are where accessibility regressions usually enter, so test them before launch rather than after. Build a short regression script covering login, proposal creation, voting, signature and confirmation, run it on every theme change, and keep the results with the accessibility statement evidence. Decide in advance who fixes defects, who signs off a release and how a resident's accessibility report reaches that team, since the directive requires a working feedback mechanism. Confirm with your Decidim partner which release line is in use, because only the 0.32.x and 0.31.x lines receive security updates, and theme changes must be retested after each upgrade. Identity verification for voting is covered in the sibling topic, so this review checks only the screens residents use to sign in and act.

Evidence the auditor or monitoring body will ask for

This table lists the evidence a monitoring body or auditor is likely to request for an accessible Decidim site, which component produces each item, and what the reader should confirm. DeployOpen prepares this evidence for your review but does not issue audit reports or attestations, so the assessment itself stays with your authority or an independent auditor.

Evidence item	Produced by	What to keep and confirm
Published accessibility statement and update history	Decidim admin (static page) and the change log kept by the site owner	Dated versions of the statement, the list of inaccessible content with alternatives, and a record of each revision after a retest
Feedback mechanism logs and response records	Ticketing or email channel linked from the statement	Time-stamped reports, triage decisions, fixes made and replies sent; confirm who owns the mailbox and retention period
EN 301 549 test results per template	Test pipeline run against each Decidim template and page type	Results mapped to the technical criteria of EN 301 549 v3.2.1, with tester, tool versions and date for each run
EN 301 549 test results per custom theme	Test pipeline run against the custom theme and component overrides	Separate results for each theme build, including forms, voting screens and proposal flows, not only the default theme
Regression results after each Decidim upgrade	Upgrade runbook and the test pipeline	Release-by-release comparison of accessibility results, with fixes for any regressions and sign-off before go-live
Change records for theme and component customizations	Version control history and the upgrade runbook	Reviewed merge records, owner per change, linked test result and rollback notes for every customization
Accessible voting and proposal form test records	Test pipeline plus manual assistive technology sessions	Scripted test cases, keyboard and screen reader results, and remediation tickets; confirm the test methods your authority accepts

What Decidim configuration and tooling alone do not settle

Decidim gives a public body a strong starting point, but conformance with EN 301 549 depends on what the body builds, writes and links to around the platform. The cards below cover the gaps that remain after configuration, and each one is a check the team owns before launch and after every change.

Manual testing with assistive technology

Automated checks catch only part of what fails in a custom theme. Keyboard-only navigation, focus order in dialogs and proposal wizards, and screen reader announcements for form errors and vote confirmations need a human tester running real assistive technology. Test each custom template, not just the stock components it replaces, and record which combinations of browser and reader were used so the results can support the accessibility statement.

Staff-authored content and uploaded documents

Decidim pages, process descriptions, meeting notes and proposal attachments are written by staff and residents, and the platform cannot judge whether they are accessible. Scanned PDFs without tags, images without alternative text and headings used for styling will fail the standard even on a conformant site. Set a publishing checklist for staff, decide whether uploaded residents' files are accepted at all, and assign an owner for removing or replacing documents that the feedback mechanism flags.

Third-party maps, geocoding and login pages

Maps, geocoding lookups and social login buttons often load content from providers the body does not control. Their embedded widgets, consent screens and error pages may not meet the standard, and the body still carries responsibility for what citizens see on its site. List every external service in the site map, test the flow from start to finish, and where an embedded element cannot be made accessible, provide an alternative route and say so in the statement.

Statement accuracy depends on real test results

The accessibility statement must identify inaccessible content and the alternatives offered, so its wording is only as reliable as the testing behind it. A statement that claims full conformance after a single automated scan invites challenge from users and monitoring bodies. Keep a dated test log linked to each release, name the known gaps with a remediation plan, and update the statement whenever a custom theme, module or external service changes.

Overlays do not replace conformance

Accessibility overlays add a widget that alters the page at runtime and promise to fix issues automatically. The Commission's position is that overlays that do not ensure conformance are not an appropriate solution for public sector sites. Remove any overlay from consideration when procuring a theme or hosting package, and ask the implementation partner to confirm in writing that every fix is made in the source code, templates and content.

Questions buyers ask before hiring help for accessible participation

What drives the cost of a conformance review for a custom Decidim theme?

The size and novelty of the theme drive most of the effort: how many templates, components and custom widgets it changes, and how far it departs from Decidim's standard markup. Reviewers test against EN 301 549 v3.2.1, so each custom page, form and interactive control adds test cases, and each defect found adds retest cycles. Ask any provider for a written scope listing the pages, user journeys, assistive technologies and browsers covered, and whether the quote includes fix work or only findings. Assessment is usually one-time, but it recurs after each significant theme change or platform upgrade. DeployOpen does not publish a price list; a quote follows from the written scope.

How long does an accessibility launch review take?

No fixed duration is supplied for this work, so the timeline must come from the written scope. It depends on the number of templates and user journeys to test, the volume of defects, how quickly the body's staff can review fixes, and whether the review runs before or after content is loaded. Ask the provider to split the schedule into test, fix and retest phases, and to name the dependencies that could move each date. Build the review into the launch plan early, because a theme that fails late usually delays go-live.

What does the public body need to provide for an accessibility engagement?

The body typically supplies four things: content owners who can write or approve accessible text, alt text and document versions; test accounts with each participant role, such as citizen, moderator and administrator; access to the staging and production environments and hosting logs needed to reproduce defects; and a named decision-maker who accepts fixes and signs off the accessibility statement. Ask the provider to list these inputs in the written scope with the people responsible for each. Delays in any of them move the launch date, not the testing effort.

Can our own staff run accessibility testing on a Decidim site?

Yes, many teams can cover routine checks in-house, but a sound programme needs more than a browser plug-in. Staff need working knowledge of WCAG 2.1 success criteria, keyboard and screen reader testing, reading HTML and CSS, and enough Ruby or template skills to fix defects in a Decidim theme. They also need a repeatable record of findings and retests. Common splits are internal checks during content updates and an external review before launch. Confirm with any partner which parts they would hand back to your team and which skills the handover assumes.

Does upgrading Decidim affect accessibility conformance?

It can. Decidim's update guide asks implementers to move one minor version at a time, follow each release's upgrade instructions, and back up the database first, because some releases change database structures. Upgrades can also alter markup and styling that a custom theme depends on, so a conformance check that passed on one version is not automatically valid on the next. Decidim supports only the last two minor versions with security updates, currently 0.32.x and 0.31.x, so plan upgrades inside that window. Ask whether a retainer covers upgrade testing, regression checks on custom templates and accessibility re-verification, and what it excludes.

What does the national monitoring cycle mean for the records we keep?

Member States monitor public sector websites and apps and, since 2021, report results to the Commission every three years, so a body may be asked to show its statement, feedback records and remediation history for that period. Keep dated versions of the accessibility statement, the audit reports and the defect and fix log, plus records of feedback received and how each report was handled. Retention periods are set by national law and your records policy, so confirm them with your legal team. Records of personal data in feedback messages also fall under data protection rules.

Keeping conformance through Decidim upgrades

Conformance is not a property you certify once at launch. Every Decidim upgrade can change markup, focus handling, form labels and the templates your custom theme overrides, so the accessibility position you documented in your statement can quietly drift. Plan each upgrade as a change to your accessibility evidence, not only to the software. Decidim's update guide asks implementers to move one minor version at a time, for example 0.29 to 0.30 before 0.31, and to follow each release's upgrade instructions because some releases change database structures. Take a full database backup before every step, and confirm the upgrade path in the release notes for your exact starting version.

Support windows also set your calendar. Until version 1.0, Decidim supports only the last two minor versions with security updates, which are 0.32.x and 0.31.x at the time of writing, so a site still on 0.30 or earlier is outside security support and should be scheduled for a move before anything else. Decidim's security policy gives implementers a grace period of 2 months to apply patches for standard vulnerabilities and 4 months for critical ones before details are disclosed. Those windows are short enough that a patch may arrive during a live consultation or a voting period. Agree in advance which upgrades can be applied mid-process, who signs off on a security patch outside the normal cycle, and how much regression testing you can compress without dropping the audit trail.

After each upgrade, re-run the accessibility regression set against the production-like staging copy, not against the default theme alone. Cover the pages your statement describes as in scope: the proposal creation and edit forms, the vote and sign flows, the authorization steps, the process and assembly pages, and any custom theme components. Check keyboard paths, focus order after form errors, label and error association, and contrast on the custom palette. Record the results, the version tested and the defects found, and retain them with your conformance evidence. Confirm with your implementation partner who owns the regression scripts, how they are updated when Decidim changes its templates, and whether a failed check blocks the release or opens a ticket.

How a fixed-scope accessibility launch review runs

The sequence turns an existing or planned Decidim site into one whose conformance to EN 301 549 is tested, documented and handed over with the accessibility statement and feedback channel in place. Each step closes with a written output that the organization can check before the next one starts.

Agree scope and templates in writing
The organization and DeployOpen agree in writing which sites, spaces, components and custom themes fall within scope, which page templates represent them, and which forms count as in scope for testing, such as proposal, vote and signature forms. Your accessibility lead confirms the list of pages and user journeys, and the organization's legal or compliance contact confirms which public sector body the statement will name. The step closes when the signed scope document lists every template and journey to be tested, so that no later question about coverage has to be settled from memory.
Run the baseline accessibility test
DeployOpen tests each agreed template and journey against the technical criteria of EN 301 549 v3.2.1, combining automated checks with manual testing using keyboard navigation and screen readers. Findings are logged with the affected template, the criterion, the user impact and a reproduction step, so the baseline reflects the site as built rather than as designed. The step closes when a baseline report exists for every agreed template and your team has reviewed it for missing items.
Remediate theme and component defects
Defects that originate in the custom theme, shared templates or Decidim components are fixed at source, so the same problem does not return on the next page or in the next participatory space. DeployOpen records each change against the finding it resolves and retests the affected template after each fix. Your team checks the changes in a staging environment, and the step closes when every finding is either fixed and retested or recorded as an open item with an agreed owner.
Draft the statement from test results
The accessibility statement is written from the baseline and retest results, not from a template. It identifies which content is not accessible, explains the reasons, and describes the alternatives available to people who cannot use the affected content, as the directive requires. The organization's legal reviewer confirms the wording, including the date of the last review. The step closes when the draft statement matches the test record item for item and the open items are named in it.
Set up and test the feedback channel
DeployOpen configures the feedback mechanism that the directive requires, so visitors can report accessibility problems and receive a response, and links it from the statement and the site footer. The channel is tested end to end with a sample report, including confirmation that the message reaches a named mailbox or ticket queue that someone monitors. The step closes when a test report has been sent, received and logged, and the organization has named the person responsible for responding.
Compile the sign-off evidence pack
DeployOpen assembles the evidence pack: the agreed scope, baseline and retest reports, the change log, the published statement, the feedback channel test record and the list of open items with owners. The pack shows what was tested and what was changed, but it is not an audit report or a certification, and the organization should ask its own assessors what they will accept. The step closes when the organization's sign-off contact has reviewed the pack and approved it in writing.
Hand over and confirm ongoing ownership
The handover covers the test scripts, the theme change documentation, the statement maintenance steps and the process for handling feedback reports, so the organization's staff can repeat checks after a Decidim upgrade or a new template. Ownership of the open items and the statement review date is assigned to named people. The step closes when the organization's team has run a short walkthrough and confirmed in writing that it can maintain the statement and respond to reports without DeployOpen. Ongoing retesting is a separate arrangement that can be agreed as a retainer.

Where to read the directive and the Decidim documentation

Start with the European Commission's web accessibility policy page, which summarizes the Web Accessibility Directive (EU) 2016/2102 and the harmonised standard EN 301 549 v3.2.1 that the technical criteria point to. The directive itself is the baseline, but the text your body must follow is the national transposition in your Member State, which sets the enforcement authority, the statement format and any local deadlines. Pull that national law in writing before you scope the work, and ask your legal or accessibility office to confirm which public bodies and sites it covers, including whether a municipal or regional subsidiary counts as a separate site.

Then read the Decidim documentation alongside the release you plan to deploy. The installation and update guides describe how the application is configured, and the security policy explains which minor versions still receive fixes. Check the upgrade notes for each release, because changes to templates, components or themes can alter the markup that your accessibility testing covers. Confirm with your implementation partner which Decidim version the accessibility test results apply to, and record that version in the accessibility statement so the statement and the running site stay in step.

Treat the sources as a checklist rather than a one-time reading. Assign one owner to track national guidance, Decidim release notes and any change to a custom theme or plugin, and agree how often the accessibility statement is reviewed. Ask the partner to show how each custom template, form and proposal flow was tested against EN 301 549, and where the results are stored. That evidence is what your monitoring authority is likely to ask for first.

How DeployOpen scopes, tests and supports accessible Decidim sites

DeployOpen plans, implements, customizes, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including Decidim. For accessible citizen participation, we treat conformance with EN 301 549 as a delivery requirement that is checked at each stage, from the first theme decision to the statement published at launch.

How we scope

Written scope lists every Decidim space, component and custom theme in the launch, agreed before work starts.
Scope names the accessibility statement, feedback mechanism and accessible form flows the public site must provide.
Engagements are fixed-scope, and ongoing support after launch can be added as a retainer.

How we build

Custom themes and components are reviewed against EN 301 549 criteria during development, not only at the end.
Proposal, vote and sign-up forms are tested with keyboard-only navigation, screen readers and zoomed layouts.
Customizations are kept within the Decidim extension approach so that upstream security updates can still be applied.

How we hand over

Handover includes the accessibility test records, known issues list and the reasoning behind each custom theme decision.
The published accessibility statement and feedback channel are configured, tested and documented with the client's owners.
Operating documentation covers Decidim update steps, database backups and the minor-version upgrade order.

How we support

Support covers Decidim security patch application within the grace periods the project publishes for each severity.
Retests run after each theme change, Decidim upgrade or new component so conformance does not silently regress.
Ask us to confirm the support hours, response terms and retest frequency in your written scope before signing.