What Drupal accessibility to WCAG 2.2 AA covers in your project
Meeting WCAG 2.2 AA on a Drupal site is not a setting you switch on. It is the combined output of four layers: Drupal core, the theme and components, the content authors publish, and the testing that checks the result. Core's accessibility work targets the standard, so it gives the project a sound starting point. The project still owns what core does not cover, including theme templates, custom components, custom module output, forms, interactive widgets and any custom JavaScript. Before scoping, confirm with your compliance owner which WCAG version and conformance level your regulator or contract names, and which pages count as in scope. Then map each page template and component to the success criteria it must meet.
Treat accessibility as a separate piece of work when the site is public-facing under a regulation or contract, when the theme or front-end components are custom, or when the site carries a large inherited content base with PDFs, images and embedded media. Public sector bodies and regulated customer portals often fall into this group. The work covers page templates, navigation, focus handling, color contrast, form labels and error messages, and the keyboard paths through interactive features. Authoring checks belong in the same plan. Editoria11y can flag common problems to editors while they write, so issues are fixed before publication, but an automated checker finds only part of what a person using assistive technology would encounter.
Accessibility work does not replace an independent audit. Outside assessors test the live site against the criteria you agreed and issue their own findings, and DeployOpen does not issue audit reports, attestations or certifications. What the project can provide is the preparation: a documented scope, test evidence from the build, a remediation log and the authoring rules that keep content compliant after launch. Ask any partner to state in writing which deliverables are scoped, who runs the final assessment, and who fixes findings raised after go-live. Those three answers decide whether the work still holds once the site has been live for a year.
Which accessibility layer fits each kind of work
This table compares the layers of an accessibility program on a Drupal site: core behavior, theme and component markup, contributed modules, authoring checks and testing. Read each row as a question of who controls the behavior, who usually owns the fix and when that layer is the right place to spend effort. The main takeaway is that core covers only part of WCAG 2.2 AA, and the remaining gaps sit in your theme, components and content practices.
| Layer | What it controls and who usually owns it | When it fits a project |
|---|---|---|
| Drupal core behavior | Base markup, form labels, admin interface and core text formats; owned by the Drupal core maintainers, configured by your team | Start here for every project, then confirm which core behaviors your chosen version and configuration actually preserve |
| Theme and component markup | Heading order, landmarks, focus styles, color contrast, target sizes and custom widgets; owned by your front-end team or agency | Any site with a custom or heavily branded design, where most WCAG 2.2 AA gaps usually appear |
| Contributed modules | Features such as menus, carousels, modals, date pickers and media embeds; owned by your team through module selection and review | When a module adds interactive components, so each one needs its own keyboard and screen reader check before launch |
| Authoring checks (Editoria11y) | Editor-facing warnings on alt text, link text, headings and contrast while content is written; owned by content leads, with setup by your developers | When editors publish frequently and need prompts before content goes live, rather than fixing errors after publication |
| Automated scanning | Rule-based detection of many machine-testable failures across rendered pages; owned by QA or the development team | As a regression check in the build or release pipeline, recognizing it cannot confirm every success criterion |
| Manual and assistive technology testing | Keyboard operation, screen reader output, focus order and task completion; owned by a specialist or trained internal testers | Before launch and after changes to templates, navigation or interactive components, since many WCAG 2.2 criteria need human judgment |
What Drupal core already targets and what the project still owns
Core accessibility work on Drupal is tracked through its own issue process, so the first task is to confirm, from the core accessibility documentation on Drupal.org, which WCAG version and conformance level each core release you run is designed to meet. Do not assume that a core upgrade carries a newer target with it. Write the target you confirmed into the project's accessibility statement and into the acceptance criteria for the build, so that the claim matches what the code was tested against. If the documentation does not state the target for a given release, ask the Drupal community or your vendor to name it in writing before you rely on it.
What the project inherits is mostly the Claro administration theme, core form and table markup, and the base output of the Olivero front-end theme, but only in the state each release leaves them. Inheritance stops at the edges of your build. The project still owns the verification of custom forms built with the Form API, any third-party embeds such as video players, maps, chat widgets and payment frames, the output of your own theme's Twig templates and CSS, and the content patterns editors create with Paragraphs, Layout Builder or text formats. A core heading structure is correct only if editors use heading levels in order and the theme does not override them with styled divs. Plan for these owned areas as separate work items with named owners. Ask any implementation partner to show which tests cover each area, whether they run keyboard-only and screen reader checks on the custom parts, and how they record results against each success criterion. An accessibility claim without that record is a statement of intent, not evidence.
Theme and component work that still falls to the project
Drupal core and contributed modules give a site accessible building blocks, but the theme, custom components and the content that editors publish remain the project's responsibility. The cards below cover the areas where a WCAG 2.2 AA audit most often finds gaps, and each names who builds the fix and who verifies it. No module should be treated as fixing these areas automatically.
Semantic templates and heading structure
Twig templates and the theme decide which elements carry the page structure: landmarks such as header, main and nav, one h1 per page, and heading levels that follow the content rather than the visual size. Custom node, block and View templates often introduce extra div wrappers or heading levels chosen for styling. Theme developers should review each template against a heading outline, and an accessibility tester should check the rendered page with a screen reader, since automated tools miss most structure problems.
Color contrast and focus styles
Brand palettes are set in the theme's CSS and design tokens, so contrast problems usually start there and then spread into components, states and disabled controls. Text, icons that carry meaning and focus indicators all need enough contrast against their backgrounds under WCAG 2.2. The designer and front-end lead should agree the palette before build, and a tester should check hover, error, selected and focus states, because a default outline removed for aesthetic reasons is a common failure.
Keyboard operation of custom components
Carousels, accordions, custom menus, modals, tabs and search overlays built in the theme or in a custom module need keyboard support written by hand. Each control must be reachable in a logical order, operable with standard keys, and must not trap focus unless it is a modal that returns focus when closed. Frontend developers should test every custom component with keyboard only, and the tester should confirm that focus remains visible and that dismissing an overlay does not lose the user's place.
Accessible forms and error messages
Forms built with the Form API, Webform or custom render arrays need visible labels, programmatic association between labels and inputs, and error messages that identify the field and explain the fix in text. Required fields, help text and inline validation should be announced to assistive technology. Developers should review each custom form in the theme, and the content team should test the forms editors and public users actually submit, because default markup can change with contributed modules and theme overrides.
Media and iframe handling
Embedded videos, maps, social posts and third-party widgets often arrive through media embeds, WYSIWYG content or custom Twig, and they bring their own titles, captions and controls. Each iframe needs a meaningful title, captions or transcripts for video where the content requires them, and player controls that work by keyboard. The project should set rules for editors on which embed types are allowed and check the rendered output, since an iframe with no title fails regardless of how the page looks.
Motion and timing
Animated sliders, auto-advancing banners, parallax effects, and timed session or notification messages can distract users or make content unavailable. Designers should decide which motion is essential, and developers should respect the operating system's reduced-motion setting, provide pause or stop controls for moving content, and avoid time limits that cannot be extended. A review of animations and timeouts in the theme and in the login and session code should be part of the acceptance checklist before launch.
How to set up an accessibility program on a Drupal build
This sequence turns WCAG 2.2 AA from a goal into a repeatable practice: a confirmed scope, a tested baseline, agreed component patterns, authoring guardrails and checks that run on every change after launch.
Confirm scope and WCAG 2.2 AA criteria
Start by agreeing with legal, compliance and the business owner which sites, templates, user journeys and content types must meet WCAG 2.2 AA, and which conformance claim you will make. Record the applicable success criteria in a short written scope document so every later test is measured against the same list. Ask your auditor or regulator which level and which criteria they will examine, because the answer determines how deep the baseline must go. The step is complete when the scope document is signed off and lists the templates, flows and third-party embeds in scope.
Baseline core and theme with automated and manual tests
Run automated scanners against representative pages from core, the contributed modules and your theme, then complete manual testing with keyboard-only navigation, screen readers and zoomed layouts. Include forms, navigation menus, search, media, modal dialogs and error messages, since these are where Drupal projects most often diverge from core behavior. Record each issue against the success criterion it breaks, the component that causes it and whether the fix belongs to core, a contributed module or your own theme. The step is complete when you have a dated baseline report that separates inherited issues from issues your project introduced.
Define component patterns and acceptance criteria
For each reusable component in your theme, such as accordions, carousels, cards, tabs, forms and media blocks, write a pattern that states the expected markup, focus order, keyboard behavior, labeling and color contrast. Attach an acceptance checklist to each pattern that developers and reviewers can apply without interpretation. Agree with content and design owners which patterns editors may combine and which they may not alter. The step is complete when every component in the baseline has an approved pattern and the checklist is linked from the project's contribution guidelines.
Install and configure Editoria11y for authors
Install the Editoria11y accessibility checker on the authoring environment and configure it for your editorial workflow, so that editors see flagged issues such as missing alternative text, empty links, heading order problems and low contrast before they publish. Decide which checks run for each content type and how editors record a reason when they dismiss a warning. Train a small group of editors on the tool and on the patterns from the previous step. The step is complete when test pages with deliberate errors are flagged in the editing interface and the training notes are documented for the content team.
Add accessibility checks to the build and release process
Add automated accessibility tests to the continuous integration pipeline so that pull requests touching theme code or components are scanned before merge, and add a manual checklist to the release gate for changes to templates, navigation and forms. Define which failures block a release and which create tracked tickets, and agree who can override a block. Keep the scanner configuration in version control with the rest of the build. The step is complete when a deliberately broken test change fails the pipeline and the release checklist has been used at least once for a real release.
Schedule re-testing after content and theme changes
Set a recurring re-test schedule for the site and trigger an extra test whenever the theme, a contributed module, a template or a major content area changes. Include spot checks of new content types and third-party embeds, because content changes can break accessibility without any code change. Track the open issues from each cycle in the same backlog as other defects, and review trends with the accessibility owner. The step is complete when the schedule, triggers and owner are written down, and the first re-test cycle has closed or assigned every baseline issue.
How accessibility holds after launch
A site that meets WCAG 2.2 AA at launch can drift within a few update cycles. The concerns below are where that drift usually starts, and each one needs an owner, a check and a planned place in the project budget before the build closes.
Regressions from core and module updates
Drupal core and contributed modules ship security and bugfix releases on a fixed schedule, and the Drupal Security Team handles vulnerabilities on its own track. Security releases do not test for accessibility, so a new version of a menu, form, media or dialog module can change focus handling or label output without anyone noticing. Plan a scripted accessibility check on staging for every update, and confirm with the platform team who signs off before production deploys.
New content types and layouts
Content types, paragraph types and layout options added after launch often bypass the accessibility review that covered the original templates. A new card layout or a heading field that editors can set to any level can break the page outline that the theme assumes. Require that every new content type or layout passes a heading, landmark and keyboard review before it is made available to editors, and record that review in the change ticket.
Third-party embeds and consent banners
Videos, maps, chat widgets and consent banners frequently inject markup the project does not control. Iframes without titles, carousels without pause controls and banners that trap focus are common failures. Inventory every embed type that editors can add, decide which ones need a wrapper or a documented alternative, and confirm with the consent tool owner that its banner remains operable by keyboard and screen reader.
Editor turnover and training
Most accessibility defects after launch come from content entered by editors, not from code. Turnover means new editors arrive without the reasoning behind alt text rules, link text conventions or heading order. Build a short onboarding path that covers the authoring checks in Editoria11y, assign a named accessibility contact for content questions, and ask the client who owns editor training and how often it runs.
Testing cadence and evidence retention
Automated scans catch only part of WCAG 2.2 AA, so a cadence needs both automated runs and periodic manual testing with assistive technology. Decide how often each runs, which pages and templates are in scope, and how long results are kept. Ask the client whether their compliance or procurement process expects dated evidence, and agree on the format and storage location before the first run.
Theme documentation kept with code
Accessibility decisions in the theme, such as focus styles, color tokens, skip links and component ARIA patterns, lose value when only the developers who built them remember why. Store component documentation, known limitations and test results in the repository next to the theme code, and review them whenever a component changes. Confirm with the platform team that documentation is part of the definition of done for theme work.
What buyers ask before hiring help for Drupal accessibility
What drives the cost of Drupal accessibility work?
The main driver is how much of the site runs on custom theme code, custom components and contributed modules that need changes, because those are where most WCAG 2.2 AA failures originate. Core already targets accessibility, so the remaining work usually sits in the theme, component library, custom forms, custom blocks and the editor setup. Other drivers include the number of distinct page templates, the number of content types editors use, how many languages the site runs, and whether the site has documents, video or embedded third-party widgets. Ask any partner for a written scope that lists each template or component in scope, the testing method for each, and whether retesting after fixes is included. Confirm with your own team which pages carry the most traffic or legal exposure, since that often sets priority.
Is an automated accessibility scan enough to meet WCAG 2.2 AA?
No. Automated tools reliably catch some categories of problems, such as missing alternative text attributes, some color contrast failures and missing form labels, but they cannot judge whether alternative text is meaningful, whether focus order makes sense, or whether a custom widget works with a keyboard and a screen reader. A credible program combines automated scans with manual review using keyboard-only navigation, screen readers and zoomed layouts on representative templates. Ask for both the automated and manual results, a list of success criteria tested, and a record of which findings were fixed and retested.
How long does a Drupal accessibility remediation program take?
Duration depends on the number of templates, components and content patterns in scope, the amount of custom code, and how quickly your team can review and approve changes. A site with a small number of templates and a mostly standard theme will move much faster than an estate with many custom components and multiple languages. Ask for a timeline in the written scope that is tied to named deliverables, and ask what your team must provide and when. Any timeline should be confirmed against your own environment and release process rather than taken from a general figure.
What does the work need from our team?
Expect to supply access to a staging environment that matches production, the theme and component source, a named decision-maker who can accept or reject design changes, and content owners who can confirm that alternative text and headings are accurate. Your team also needs to agree on the browsers, assistive technologies and devices that count as in scope. If your organization has its own accessibility policy or a statement that describes conformance, your legal or accessibility lead should review the scope before work starts. Confirm which of these responsibilities sit with you before the engagement begins.
Can our editors run the authoring checks themselves?
Yes, for many common issues. Editoria11y is an open-source accessibility checker that runs in the editing interface and flags issues such as missing alternative text, heading structure problems and link text that does not describe its destination, so editors can correct content before publishing. It does not replace testing of the front end, templates or custom components, and it cannot confirm that a published page meets WCAG 2.2 AA on its own. Plan a short editor training session, document the checks you expect editors to perform, and confirm with your partner how Editoria11y is configured for your content types.
Does DeployOpen issue an accessibility certification?
No. DeployOpen does not issue accessibility audit reports, attestations or certifications. Our work can include testing, remediation, documentation and preparing evidence that an independent auditor or assessor can review. If your organization needs a formal conformance assessment or a certification from an external body, ask that body which methods and evidence it accepts before work starts, and plan for an independent review after remediation is complete.
Will remediation work need to be repeated after Drupal upgrades?
Often some of it will. Core accessibility improvements arrive through Drupal releases, but custom theme code, custom components and contributed modules can regress when they are updated or replaced. Ask for the accessibility test cases to be kept in your repository, a record of which components were tested, and a retest step in your upgrade routine. This keeps later upgrades from quietly reintroducing failures, and it makes the cost of each future change easier to estimate.
Limits to confirm before you commit to a WCAG 2.2 AA target
A WCAG 2.2 AA target only means something once the scope, the software versions, the third-party tools and the sign-off rules are fixed in writing. The six items below are the points where Drupal projects most often discover gaps late, after the target has already been promised.
Exact success criteria in scope
WCAG 2.2 AA contains many success criteria, and some apply differently to templates, authored content, forms and media. Agree the list in writing before the audit starts, and state which pages and content types it covers. A target that says only "WCAG 2.2 AA" leaves the team arguing later about what was promised. Ask whether PDFs, downloads and embedded media fall inside the boundary.
Core and contributed module versions
Accessibility behavior in Drupal comes from core, the theme and contributed modules, and each can change between releases. Record the exact Drupal core version and every contributed module that renders output, forms or menus. Confirm the site will remain on a supported release during the work, since Drupal 10 reaches end of life on December 9, 2026 according to the core release schedule. A fix made in one version can disappear after an unpatched upgrade.
Accessibility of third-party tools
Chat widgets, consent banners, payment forms, embedded video players and booking tools often sit outside the Drupal codebase but inside the user journey. Ask each vendor for its current accessibility statement or conformance report, and test the widget with a keyboard and a screen reader in the live page. Where a vendor cannot show conformance, decide whether the component is replaced, isolated or documented as an exception.
Legal or procurement standard to cite
The conformance claim should name the regulation, contract or procurement rule the organization must meet, because that text can require a specific standard, version and scope. Ask legal or procurement which rule applies, which WCAG version it references and whether it requires a published accessibility statement. Do not assume that a WCAG target satisfies a national or sector rule until counsel confirms it.
Who signs off on conformance
Name one accountable owner who accepts the conformance position, usually a product owner or accessibility lead with authority over content and design. Define who can accept a known exception, who approves a published statement and who reviews fixes after each release. Without this, the team may ship new pages that break criteria the project already closed. Write the sign-off steps into the statement process.
Independent assessment of the result
DeployOpen prepares the test plan, fixes, evidence and documentation, but independent auditors and accessibility assessors give the opinion on conformance, and DeployOpen does not issue audit reports or certifications. Confirm early whether your organization requires a third-party assessment, who selects the assessor and what evidence the assessor will need. Plan time for their questions and retests, since their findings may change the scope.
How DeployOpen scopes and delivers accessibility work on Drupal
DeployOpen plans, builds, documents and supports Drupal accessibility work inside your own infrastructure, with the scope agreed in writing before any build starts. We treat WCAG 2.2 AA as a set of checks across core, theme, components and authoring, and we prepare the evidence your internal reviewers and independent auditors need. DeployOpen does not issue audit reports or certifications.
How we scope
- We confirm which pages, templates, content types and user journeys fall inside the written scope.
- We separate what Drupal core already targets from theme, component and contributed module work the project still owns.
- We agree which WCAG 2.2 AA success criteria the testing will cover and which need manual review by your team.
How we build
- We build theme and component fixes with semantic markup, focus handling and color contrast checked during development.
- We configure Editoria11y so editors see accessibility prompts while they write, and we document what it does not catch.
- We test with automated checks, keyboard navigation and screen readers, and record each finding against its success criterion.
How we hand over
- We deliver an accessibility conformance record that maps each finding and fix to the agreed success criteria.
- We document component patterns, authoring guidelines and known gaps so your team can maintain them after launch.
- We confirm with your team which evidence goes to independent auditors, since DeployOpen prepares evidence but does not certify.
How we support
- Ongoing accessibility checks and fixes after each Drupal core or contributed module update are available as a retainer.
- Retainer scope, response expectations and reporting are agreed in writing, and we confirm them with your team before work begins.
- Quotes follow from the written scope, so we ask you to list pages, templates, languages and audit requirements up front.
