Drupal for ADA Title II web accessibility compliance

Which ADA Title II requirements a Drupal site must meet

If your state or local government team runs a Drupal site, the core question is which web content the ADA Title II rule covers and what standard it sets. Drupal helps you reach WCAG 2.1 Level A and AA conformance, but it does not make a site compliant by itself. Conformance depends on the content editors publish, the theme your site renders, the modules you add and the testing you run against them. The Department of Justice rule sets WCAG 2.1 Level AA as the technical standard for state and local government web content and mobile apps, and it applies to content provided through contracts or licenses, so a vendor-built page or a third-party embed on your site can count toward your obligation even if you did not write it. Read the rule's text in the ADA.gov fact sheet and confirm your own compliance date with counsel, since the dates depend on your population category.

Start with an inventory. List every Drupal site, subdomain, mobile app and third-party service your entity operates or pays for, then mark which items are public-facing and which are used by the public in a way the rule reaches. Ask your team to confirm which of these pieces are your responsibility in the contract, because a licensed vendor component may still fall under your obligation. For each in-scope item, record the WCAG 2.1 success criteria it must meet and who owns the fix: a site builder for theme markup, editors for content such as alt text and table structure, and a developer for custom modules that render forms or interactive widgets.

DeployOpen prepares systems, controls and evidence for accessibility reviews, but it does not issue audit reports, attestations or certifications. An independent auditor or certification body makes that judgment, so plan your evidence trail to support one. Keep the theme and module versions under configuration control, record the results of automated and manual checks against the in-scope criteria, and track open defects with owners and dates. Ask any partner to show how each defect is traced to a fix and a retest, and to state in writing which parts of the site were excluded and why.

How WCAG 2.1 AA requirements map to Drupal core, modules and theme work

This table maps the WCAG 2.1 Level A and AA criteria named in 28 CFR 35.200 to the Drupal capability that supports each area, the configuration or build work it needs, and the evidence a reviewer will ask for. Read each row as a question to answer for your own site, since core support does not certify your content or theme. The main takeaway is that core covers much of the administrative surface, while theme markup, authored content, documents and contributed modules remain your responsibility to test.

Area	Drupal support and build work	Evidence a reviewer will ask for
Core admin and editor interfaces	Drupal core targets WCAG 2.2 AA for its own interfaces, but this does not transfer to your site. Confirm the admin theme and any custom admin forms against the 2.1 criteria the rule names.	Test results for administrative pages, with versions of core and the admin theme recorded
Theme markup and focus handling	Custom themes must provide landmarks, logical heading order, visible focus indicators, skip links and keyboard-operable menus. Component libraries and Twig templates often introduce gaps.	Automated scan output plus manual keyboard and screen reader walkthroughs of templates
Content authoring and alternative text	Editors need required alt text fields on images, clear link text guidance and heading hierarchy rules. Configure media fields and content templates so alt text cannot be skipped where it is required.	Sample of published pages showing alt text, link text and heading structure, plus editor guidance
Documents and media	PDFs, office files and video are not made accessible by Drupal itself. Plan tagged documents, captions and transcripts as content workflow steps, and decide which legacy files are archived or replaced.	Inventory of hosted files with accessibility status, captioning records and remediation tickets
Forms and Webform submissions	Use labeled form elements, error messages tied to fields and accessible validation. Webform and custom form theming need testing for focus order and error announcement.	Test scripts for form completion with keyboard and assistive technology, with defects logged
Contributed modules	Each contributed module used for menus, carousels, modals, date pickers or media embeds must be reviewed. Record the module version, check its markup and replace components that fail.	Module inventory with version, review notes and remediation or replacement decisions
Ongoing monitoring	Accessibility regresses when content, modules or the theme change. Schedule regression testing around core and module updates, and include checks in the release pipeline.	Dated test reports, change records linked to fixes and a named owner for each finding

Which compliance date applies to your entity and population

The ADA Title II web rule sets WCAG 2.1 Level AA as the technical standard for state and local government web content and mobile apps, and the date you must meet it depends on the population your entity serves. Entities serving 50,000 or more people face a compliance date of 26 April 2027. Smaller entities and special districts face 26 April 2028. An interim final rule dated April 20, 2026 extended the date for the larger group to April 26, 2027, so plan against that date rather than any earlier one. Confirm your population category against the rule text in the eCFR text of 28 CFR Part 35 Subpart H and with your legal counsel, because the category determines whether your Drupal sites are on the earlier or later timeline.

Population category is not the only question. Ask counsel whether content supplied through contracts or licenses, such as a vendor-hosted event calendar embedded in your Drupal theme, falls within the rule, since the rule covers that content too. Also list every site, subdomain and mobile app your entity operates, because each one carries the same obligation and needs its own remediation record.

The dates also set your Drupal sequence. A site still on Drupal 7 cannot be updated in place; it must be migrated into a new site and its theme rebuilt, so accessibility remediation on that site will happen in the new build, not the old one. Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule, which is before the April 2027 date for larger entities. A Drupal 10 site therefore needs an upgrade to a supported major version inside the same window as remediation, and running both in parallel avoids remediating a theme you will have to rebuild. Ask your team to map each site to its version and its owner, then schedule migration or upgrade work and accessibility fixes as one plan.

What Drupal core provides for accessibility and what it leaves to you

Drupal core publishes an accessibility target and maintains its own administrative and default interfaces, but a public site is more than those parts. Each card below separates what core or a documented module supplies from what your theme, content and editors must still deliver, and what your team should test before relying on it.

Core administrative interfaces

Drupal core targets WCAG 2.2 level AA for administrative interfaces, which is the target stated on the Drupal accessibility page. That target does not certify your site, and it does not cover custom admin forms, contributed admin pages or content-type configuration your team builds. Test the content editing screens your staff use with a keyboard and a screen reader, and record any gaps against the WCAG 2.1 AA criteria that apply to your own pages.

Default front-end theme

The default theme is a starting point, not a conformance claim. Colors, focus styles, heading structure, menus and component variants change once your brand theme is applied, and those changes are where most contrast and focus failures appear. Plan a theme audit covering color contrast, visible focus, skip links and responsive navigation, and retest after every design change.

Content editor and text formats

The editor controls which headings, lists, links and embedded media a content author can create, so it decides whether editors can produce accessible structure. Restrict text formats to elements your templates handle correctly, and document rules for heading levels and link text. Test by having editors build representative pages and checking the rendered output with an automated checker and a keyboard pass.

Media and file handling

Core stores images and documents, but it does not write alternative text, captions or transcripts for you. Make alt text a required editorial step for images that carry meaning, and define how decorative images are marked. PDFs and other uploaded files need their own accessibility review, because a file served from your site is part of the web content covered by the rule.

Forms and Webform submissions

Forms built with core or the Webform module need labels, error messages that identify the field and the problem, and logical focus order. Confirm that error summaries are announced to assistive technology and that time-limited steps offer enough time to complete. Test each form type your citizens use, including confirmation pages and file upload fields, with a screen reader before launch.

Contributed modules and third-party embeds

Contributed modules and embedded widgets, such as maps, chat tools and video players, are not covered by core's accessibility work. Inventory every module and embed that outputs markup on public pages, check its release notes for accessibility fixes, and record who owns each gap. Content delivered through contracts or licenses is still your responsibility, so include vendor accessibility commitments in procurement.

How to configure a Drupal site for WCAG 2.1 AA work

This sequence moves a Drupal site from an unmeasured state to one where accessibility is tested against WCAG 2.1 AA on every release, with each stage leaving a record the team can reuse and audit.

Freeze the site inventory
Record every public page, template, content type, block view, menu, form, and enabled module before any remediation begins. The site owner and lead developer sign off on the list, and each item is tagged by owner, whether editors or citizens use it, and whether it is generated by core, a contributed module, the theme, or custom code. The output is a versioned inventory the team keeps in the project repository, so later test results can be traced to a specific page or component rather than to the whole site.
Set the WCAG 2.1 AA test baseline
Agree the success criteria in scope for WCAG 2.1 Level AA, the automated tools that will run in continuous integration, and the manual test procedure a tester follows with keyboard and screen reader checks. Run the first baseline against a representative sample from each template in the inventory. The output is a baseline report that lists each failing criterion, the affected template, and the severity, which becomes the starting point for tracking progress. Confirm the reference documents with your accessibility lead, since the regulation points to WCAG 2.1 while Drupal core targets WCAG 2.2 AA.
Remediate the theme and components
Fix the base theme first, because most failures repeat across templates. Check landmark regions, a single logical heading structure, focus order and visible focus styles, color contrast for text and interface states, and labels and error messages on every form element. Build these as components so a fix applies everywhere the component appears. The output is a theme branch where each fix maps to a baseline finding, and a rerun of the baseline shows those findings closed without new regressions in the sample.
Set editor guidance and required alt text
Configure the content types and media fields so that images cannot be published without alternative text, and so that decorative images have a documented way to be marked. Write short editor guidance covering headings, link text, table use, and captions, and place it where editors work. Ask editors to complete a sample task on a staging site and record where they struggled. The output is a field configuration export, a guidance page, and a short record of the editor test, which together show how content will stay compliant after launch.
Configure document and media handling
Decide how PDFs, office documents, video, and audio are published, since these are often where accessibility gaps remain after the pages are fixed. Set rules for when a file is hosted on the site, when it is linked to an external system, and what alternative text, transcript, or accessible version must accompany it. Where files come from an upload field, confirm that the metadata fields capture the information the rules require. The output is a documented publishing rule for each file type, plus test files that the team has checked against the same baseline.
Test contributed modules and embeds
Review each contributed module that renders user-facing output, along with third-party embeds such as video players, maps, chat widgets, and survey tools. Test them against the same procedure used for the theme, and record which issues belong to the module maintainer, which to the theme, and which need a workaround or replacement. Confirm the module versions in use, since accessibility fixes arrive through normal updates. The output is a register of modules and embeds with their test results and a decision for each, which the team checks again at every update.
Lock accessibility checks into the release pipeline
Add the automated accessibility checks and the baseline sample to the continuous integration pipeline so that every change to the theme, configuration export, or module set runs against them before deployment. Require a manual check for any change to forms, navigation, or new templates. Document who approves an exception and how it is tracked. The output is a pipeline that blocks deployment on new failures and a written procedure that the platform team follows, so that accessibility is retested whenever configuration or theme code changes.

How the work differs for Drupal 7, Drupal 10 and Drupal 11 sites

Drupal 7 sites carry the heaviest load because they cannot be moved forward in place. Drupal 7 security support ended on January 5, 2025, and Drupal.org documentation explains that Drupal 6 and 7 sites cannot simply be updated to Drupal 10 or later. The site is migrated into a new Drupal site using the core Migrate, Migrate Drupal and Migrate Drupal UI modules or Drush, and the theme has to be rebuilt because themes cannot be migrated. Accessibility work and migration therefore overlap, and the rebuilt theme is the natural place to fix markup, navigation and forms.

No in-place path: Plan a new Drupal site and a content migration rather than an update of the existing installation.
Theme rebuild: Every template, menu, form and component is rewritten, so WCAG 2.1 AA checks belong in the new build, not after launch.
Unsupported interim period: Sites that cannot migrate yet can use an Extended Security Support Provider, listed by the Drupal Association, including HeroDevs and Tag1 Consulting. This covers security patches only.
Extended support does not fix accessibility: Provider coverage does not make legacy templates conform, so remediation still has to be scheduled.
Content and module audit: Identify contributed modules that have no Drupal 10 or 11 equivalent, since their features and their accessible output must be rebuilt or replaced.

Confirm with your web team which contributed modules and custom code the legacy site depends on before estimating the rebuild.

What evidence a Drupal accessibility program produces and how to keep it

An accessibility program on a Drupal site is only as defensible as its records. The cards below cover the evidence an entity should expect to hold, who relies on each record, and how to store it so it stays current after launch. DeployOpen prepares this evidence, but independent reviewers decide conformance.

Page and template inventory

A register of every public page, template, component and document the entity publishes, with a named owner for each item. Drupal content types, views, and theme templates are the natural units, so the inventory should map to them. Store it as a spreadsheet or content register exported on each release, and check that new content types added by editors appear in it. Auditors and the Department of Justice start from this list when judging scope.

WCAG 2.1 AA test results

Records of automated and manual checks against WCAG 2.1 Level AA, listing each success criterion tested, the page or template, the result and the tools and versions used. Record tool versions with every run, because results from different tool versions are hard to compare. Keep the raw reports alongside a short summary so a reviewer can trace each finding. Automated scans alone do not cover keyboard and screen reader behavior, so note manual testers and their assistive technology.

Remediation tickets tied to releases

Each accessibility defect should have a ticket that records the failing criterion, the affected template, the fix, and the release version where the fix shipped. Linking tickets to release tags lets the entity show when a barrier was closed and which build carried the fix. Keep tickets in the same tracker as normal development so that accessibility work is not stored in a separate spreadsheet that drifts. Confirm that the tracker retains closed tickets for the full period the entity expects to be asked about.

Retest records

Proof that a fixed defect was retested on the released build, not only on a developer's branch. A retest record names the tester, the environment, the date and the outcome, and it refers back to the original ticket. Retests are what show a barrier stayed closed after later module or theme updates. Schedule retests after each Drupal core and contributed module update, since security releases can change markup and focus behavior.

Published accessibility statement

A public statement describing the conformance target, the pages or services covered, known gaps, the date of the last review, and a contact for reporting barriers. The statement should match the inventory and test results, so reviewers can check each claim against the records. Drupal can publish it as a managed page with a fixed URL and a revision date. Assign an owner who reviews it on the same cycle as the test results.

Editor training and configuration history

Training records show which editors completed accessibility instruction, when, and on which version of the guidance. Pair them with the configuration export history for theme and module changes, which shows when text formats, editor settings and templates were altered and who approved each change. Store exported configuration in version control, with commit messages that name the ticket. Together these records show whether accessibility was maintained through staff changes and routine updates.

What Drupal and a partner cannot close for you

Drupal cannot make content accessible on its own, and no implementation partner can do it for your staff after launch. Core provides accessible markup, keyboard-operable templates and form components, but the people who write pages, upload files and insert media decide whether a page passes. Missing alt text on images, PDFs scanned from paper without tags or reading order, spreadsheets with merged header cells, and videos published without captions all sit in content, not in the theme or the codebase. The practical work is to define authoring rules in the editorial workflow, add accessibility checks to the review step before publication, and train editors on the Drupal content forms they use every day. Ask your partner which checks can be enforced in the content model, such as required alt text fields on image media, and which must rely on reviewers.

Third-party components are the second gap. Maps, payment forms, chat widgets and video players are usually embedded from vendors, and their markup is outside your theme and outside Drupal's control. Each one needs an inventory entry, a test with a screen reader and keyboard, and either a replacement or a written commitment from the vendor about its conformance. Contributed modules carry the same risk: a module that renders inaccessible output will stay that way until a maintainer or your team fixes it. Confirm with each vendor which WCAG version they test against and how they handle reported barriers, and record the answer in your procurement file. The rule also reaches content provided through contracts or licenses, so these commitments belong in contracts, not only in the site audit. Mobile apps fall under the same rule as a separate deliverable. Drupal does not build them, and a responsive website does not satisfy the app requirement. If your organization publishes a mobile app, plan its accessibility work with the team that owns it. Finally, your organization still owns the policy decisions: which population category applies to you, how you read the compliance date for that category, which pages count as in scope, and whether the site meets the standard. An independent assessment and your legal counsel make those calls. A partner can prepare the evidence, test the templates and document the gaps, but the final conformance judgment belongs to your organization.

What do buyers ask about Drupal ADA Title II work before hiring help?

What drives the cost of making a Drupal site meet WCAG 2.1 AA?

The main drivers are the number of templates, the volume of content that needs review, the number of contributed modules that render output, the age of the theme, and the third-party embeds on each page. A site with a few well-built templates and a clean theme usually costs far less to bring into conformance than one with dozens of hand-built page layouts, years of inconsistent markup and video or map widgets from outside vendors. Ask for a written scope that lists each template, each contributed module that affects output, each embed and the approximate number of content items per content type. Remediation is usually a one-time project, while accessibility testing, new content checks and module updates recur. Ask any partner to separate those two costs in the quote.

How long does ADA Title II remediation take on a Drupal site?

The timeline depends on the scope of the site and on the compliance date that applies to your entity. The Department of Justice rule requires WCAG 2.1 Level A and AA from April 26, 2027 for entities serving 50,000 or more people, and from April 26, 2028 for smaller entities and special districts (28 CFR 35.200). The April 20, 2026 interim final rule extended the date for the larger group to April 26, 2027. Work the schedule backward from that date: theme and template fixes first, then content remediation, then testing and sign-off. Ask for milestones in the written scope rather than a single end date, so you can see where the work stands before the deadline.

What does the client team need to provide for accessibility work?

Three things are needed from your side. First, content owners who can review and correct pages, alt text, headings, link text and tables, since many accessibility failures live in content rather than code. Second, a named sign-off authority who can accept the scope, approve design changes and decide on trade-offs such as which third-party embed to replace. Third, access to a staging environment that mirrors production, with accounts for testers and a way to deploy fixes without waiting for a production window. Agree on these before the build starts, and confirm who owns the accessibility statement and public-facing commitments.

Can an internal team fix ADA Title II issues on Drupal without a partner?

An internal team can do it if it has the skills and time for the work. The team needs front-end developers who understand semantic HTML and ARIA, a Drupal developer who can change templates and the theme, someone who can run automated and manual accessibility testing against WCAG 2.1 AA, and editors trained to write accessible content. Drupal core targets WCAG 2.2 level AA for its public and administrative interfaces, so much of the core output is a good starting point, but contributed modules, custom code and the theme still need checking. Ask yourself whether those skills are available before the compliance date, and whether the same people can keep up with routine updates.

Does migrating from Drupal 7 change the accessibility plan?

Yes, it changes the plan substantially. Drupal 7 security support ended on January 5, 2025, and Drupal 6 and 7 sites cannot be updated in place to Drupal 10 or later. They are migrated into a new site with the core Migrate, Migrate Drupal and Migrate Drupal UI modules or with Drush, and themes must be rebuilt because they cannot be migrated. That means the theme and templates are rebuilt to meet WCAG 2.1 AA as part of the migration rather than patched afterward. If you cannot migrate yet, the Drupal Association lists certified Extended Security Support Provider vendors, but that support does not change the accessibility obligations. Ask for the accessibility checks to be part of the migration acceptance criteria.

What should a fixed-scope quote for accessibility work include?

A fixed-scope quote should follow from a written scope, and you should ask for that scope before accepting any estimate. It should list the templates, content types and page groups in scope, the contributed modules and custom code that affect output, the third-party embeds to be fixed or replaced, and the WCAG 2.1 AA success criteria used for testing. It should name the testing methods, the deliverables such as an issue log and a remediation report, the client responsibilities and the milestones tied to the compliance date. Also ask what is excluded, how changes to scope are priced and what ongoing testing and content checks cost after launch. DeployOpen does not publish a price list, and a quote follows from the written scope.

Which parts of Drupal accessibility are handled by core, and which remain our work?

Drupal core provides a base of accessible markup and targets WCAG 2.2 level AA for public-facing and administrative interfaces, which is a useful starting point for ADA Title II work. Your work remains in the theme, custom modules, contributed modules you have installed, editorial content and third-party embeds. Core cannot fix a video without captions, a chart without a text alternative or a heading structure that editors have misused. Ask your partner to map each finding to its owner (core, contributed module, theme, custom code or content) so the fixes and the sign-off are clear.

How DeployOpen scopes, delivers and supports Drupal accessibility compliance work

DeployOpen plans, builds, documents and supports self-hosted Drupal sites inside the client's own infrastructure. For ADA Title II work, we start from a written scope that separates what Drupal core provides from the content, theme and testing work that remains with your team and ours.

How we scope

Inventory public-facing pages, administrative interfaces, forms, documents and mobile apps that fall under the rule for your entity
Confirm your population band and compliance date with counsel before setting the delivery plan
Agree in writing which Drupal modules, themes and content areas are in scope, with deliverables and timelines
Record which WCAG 2.1 Level A and AA success criteria each deliverable will be tested against

How we build

Review theme markup, components and forms against WCAG 2.1 Level AA, using the core accessibility features as the baseline
Rebuild or remediate custom themes and modules where core output or contributed code falls short
Test with automated checks, keyboard navigation and assistive technologies, and log each finding with its status
Build editor guidance and accessibility checks into content workflows so new pages keep meeting the standard

How we hand over

Deliver a written accessibility test report that lists tested pages, templates and the criteria each one met or failed
Provide a remediation log with owners, priorities and open items your team can track after launch
Document configuration in exported code so changes go through version control and review
Train content editors and site owners on accessibility practices for their daily work

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope engagement ends
Retest after Drupal core and contributed module updates, including the monthly bugfix and third-Wednesday security release cycle
Ask your team to confirm the Drupal version and PHP runtime in your environment before any support plan starts
Keep a record of compliance evidence your auditors or counsel may request, while noting that DeployOpen does not issue certifications