How to make your Drupal government website ADA Title II compliant before the deadline

If you run a state or local government website, April 26, 2027 is now a date on your project plan. That's when the DOJ's ADA Title II Web and Mobile Accessibility Rule requires your website and mobile app to meet WCAG 2.1 Level AA.

This guide covers what the rule asks for, what's in scope, where Drupal helps, and what a realistic remediation plan looks like.

Key Takeaways

• State and local government entities serving 50,000 or more people must meet WCAG 2.1 Level AA by April 26, 2027. Smaller entities and special districts have until April 26, 2028.
• Scope covers web content, mobile apps, PDFs and documents made available online, with narrow exceptions for archived and third-party content.
• Drupal core targets WCAG 2.2 Level AA, so a Drupal site starts ahead. Themes, contributed modules, custom code, content and integrations still need testing.
• PDFs drive most of the effort. One moderately complex document takes 30 minutes to 3 hours to remediate.

Does the ADA Title II Web and Mobile Accessibility Rule apply to our government agency?

If you’re a state or local government entity/agency with populations of 50,000 or more, this rule applies to you. You have to ensure that your website and/or mobile application complies with the WCAG 2.1 Level AA standard by April 2027. Originally the deadline was April 2026 but the DOJ extended it by a year because governments needed more time to remediate their digital properties. There’s a lot of work involved around getting everything compliant - from templates, content and documents to forms, applications and third-party components.

However, if you’re a smaller public entity (under 50,000 population) or come under special district governments, there’s better news for you. You have one more year for the deadline - which will be in April 2028.

Special districts are local government entities created to provide specific public services, such as water, fire protection, public transit, libraries, parks, utilities, or healthcare, within a defined geographic area.

What does WCAG 2.1 AA compliance require?

While WCAG 2.1 Level AA does sound technical, the idea is pretty straightforward - people should be able to use your website or mobile app regardless of how they access it. Which means through screen readers, keyboard navigation, captions, magnification, voice controls, or other assistive technologies.

It's not about fixing a few issues on your home page. You need to look at the whole digital experience, including the content your team publishes and the services residents rely on.

Here are some of the areas to pay attention to:

• Navigation: Can someone move through the site using only a keyboard? Is the navigation structure clear and predictable?
• Forms: Can people understand what information is required, identify errors, and correct them without getting stuck?
• Images: Do meaningful images have useful alternative text? Are decorative images correctly treated as decorative?
• Color and contrast: Is text easy to read, including for people with low vision or color vision deficiencies?
• Headings and page structure: Is content organized in a way that makes sense to both people and assistive technologies?
• Videos and audio: Are captions, transcripts, and other necessary alternatives available?
• Links and buttons: Do they clearly communicate what they do, rather than relying on vague labels like “Click here”?
• Dynamic content: Do menus, alerts, search results, modals, and other interactive elements work properly with assistive technologies?
• Documents and PDFs: Are the documents residents need accessible? When an agency has years of forms, reports, meeting documents, and other files sitting on its website, this is easy to overlook.

Which parts of our website are in scope?

In most cases, you should think beyond just the pages that are most visible or most frequently visited. The Title II rule applies to web content, mobile apps, PDFs and any documents made available online by covered government entities, with specific exceptions and special treatment for certain types of content.

That means accessibility shouldn't stop at your homepage or main navigation. Think about the places people actually go to get something done: like applying for a permit, paying a bill, finding a public meeting, submitting a form, downloading a document, or accessing a public service.

For a government agency like yours, that can mean looking at:

• Public-facing web pages and the templates used to create them
• Online forms and applications
• PDFs and other downloadable documents
• Search and navigation
• Videos and other multimedia
• Interactive tools and calculators
• Mobile applications
• Third-party services that are part of the user journey
• Older or archived content, where applicable

There are also specific exceptions in the rule, so you don't necessarily need to treat every piece of historical or third-party content in exactly the same way. The important thing is to understand what's in scope for your agency rather than assuming that a quick scan of your current pages covers everything.

How does Drupal help with accessibility?

Drupal core targets WCAG 2.2 Level AA, which includes and builds on the WCAG 2.1 Level AA requirements specified by the DOJ's Title II rule. That gives government agencies using Drupal a strong accessibility foundation, although the finished website still needs to be tested because themes, modules, custom code, content, configuration, and integrations can introduce accessibility issues.

The core admin and front-end markup already handles a lot of the WCAG requirements.

• Semantic HTML out of the box - proper heading hierarchy, landmark regions, list markup, table headers with scope attributes
• Keyboard-accessible admin UI - the toolbar, contextual links, and modal dialogs all work without a mouse
• Skip links in core themes (Olivero, Claro)
• Form API output - labels programmatically tied to inputs, required fields marked, error messages associated with the field that failed
• ARIA and live regions already wired into core JavaScript components like Ajax updates and the toolbar
• Lang attribute set on the HTML element, with per-language handling if you run multilingual
• Alt text field on image fields, required by default in core media
• Olivero theme was built to WCAG AA and tested with screen readers before release
• CKEditor 5 enforces some structure - it blocks empty headings and has an accessibility checker available

What Drupal core cannot do for you are things like contrast ratios in your custom theme, alt text quality, video captions, the markup inside custom Twig templates or JS components, and anything a contributed module renders. Your theme, components, custom modules, JavaScript, content, and third-party integrations can all introduce accessibility issues.

Which Drupal accessibility modules should we install?

Along with accessibility features built into core, Drupal has several contributed modules can help teams identify and improve the user experience. Here are some of the more widely used accessibility modules worth knowing about:

1. Editoria11y Accessibility Checker

A multilingual, automatic accessibility checker that gives editors live feedback as they work, with site-wide issue reporting and dismissals. The default choice for editorial QA. Ships in the Drupal CMS Accessibility Tools recipe.

2. Text Resize

Gives visitors a block with buttons to increase and decrease text size, aimed at helping low-vision users adjust the page to suit their eyesight.

3. All in One Accessibility

Adds an accessibility widget with features such as contrast controls, text resizing and other user-facing accessibility options. It also offers automated scanning and reporting.

4. CKEditor Accessibility Checker

Bridges the CKEditor.com Accessibility Checker plugin into Drupal so editors can inspect and fix issues inside the WYSIWYG. It is minimally maintained, and the plan is to bring an accessibility tester into core.

5. AI Media Accessibility Audit (built by Specbee)

Audits your existing media library and helps site builders identify, review, and improve image alt text quality in Drupal using accessibility checks.

How do we audit a Drupal website for accessibility?

If you’re outsourcing your audit to a Drupal agency or doing it yourself, you should make sure to check these:

• Does your Drupal theme use the correct heading hierarchy, landmarks, labels, and semantic HTML?
• Do reusable components in your design system have accessible keyboard navigation and focus states?
• How Drupal forms, validation messages, autocomplete fields, and error states behave with assistive technologies
• Whether custom JavaScript components such as menus, modals, accordions, filters, and search interfaces expose the right ARIA attributes and states
• Are editors able to create accessible content through CKEditor and Drupal's content authoring tools?
• Whether contributed or custom modules introduce accessibility issues
• Are PDFs, media, embedded content, and third-party services connected to Drupal accessible?

This is particularly important for government sites because a single Drupal component can appear across hundreds or thousands of pages. The good news with Drupal is that you don't necessarily have to fix every page individually. If an accessibility issue comes from a shared template, paragraph type, component, or Drupal module, fixing the underlying implementation can address the problem across the site.

A practical approach is to start with an accessibility assessment, identify the highest-impact issues, and then work through remediation in phases. Critical public services and common components should generally be addressed before lower-priority legacy content.

Why are PDFs the hardest part?

This is what derails government projects. A typical county site holds several thousand PDFs - council minutes, permit forms, budget documents, zoning maps. Remediating one moderately complex PDF takes 30 minutes to 3 hours. Scanned documents need OCR first. Forms need proper tab order and field labels.

How long does it take to make a government Drupal website accessible?

Specbee can get you an AI powered audit in a couple of hours but this will get you a quick picture of where your website stands. Our tool can scan your site and flag common issues, helping your team identify potential problem areas quickly. It's a useful starting point for understanding your accessibility gaps and deciding where a deeper assessment is needed.

A thorough accessibility audit that involves scanning the site, reviewing Drupal templates and components, testing key user journeys, and identifying accessibility issues - will take a couple of days to a week.

But when it comes to remediation, it completely depends on the size of your website, how much of it is documents rather than pages and most importantly - how many accessibility issues show up in the audit. 

Here are some of the areas that can affect the timeline:

• Drupal theme and design system: Are templates, components, navigation, menus, forms, and interactive elements accessible?
• Custom Drupal development: Do custom modules or JavaScript introduce keyboard, focus, semantic HTML, or screen-reader issues?
• Content: Are headings, links, images, tables, videos, and other content created accessibly?
• Forms and services: Can users complete applications, registrations, payments, searches, and other important tasks using assistive technologies?
• Documents: How many PDFs, Word documents, reports, forms, and other downloadable files need to be reviewed or remediated?
• Third-party integrations: Are search tools, maps, payment systems, analytics tools, chat widgets, or other services creating accessibility barriers?
• Legacy content: How much older content needs to be reviewed, updated, archived, or brought into scope?

What should our remediation plan look like?

For a government Drupal website accessibility remediation should start by understanding where the issues come from, which affects users most, and which fixes can solve problems across the site.

1. Audit your Drupal site

Assess templates, components, content types, forms, navigation, documents, and critical user journeys. Automated scanning can identify common issues, while manual and assistive technology testing catches what tools miss.

2. Prioritize the biggest issues

Focus first on barriers that prevent people from accessing essential information or completing important services. Look for systemic issues too. Fixing an accessibility problem in a shared Drupal component can resolve it across hundreds of pages.

3. Fix the Drupal implementation

Review your theme, Twig templates, custom modules, JavaScript, and components for issues with semantic HTML, keyboard navigation, focus states, forms, ARIA, contrast, and dynamic content.

Drupal core currently targets WCAG 2.2 Level AA, providing a strong accessibility foundation. But themes, modules, custom code, configuration, and content can still introduce accessibility issues.

4. Fix content and documents

Review headings, alt text, links, tables, captions, and especially PDFs and downloadable documents. Accessibility isn't just a development task; your content workflow matters too.

5. Test and keep testing

Validate fixes with automated tools, manual checks, keyboard navigation, screen readers, and critical user journeys. Then build these checks into your Drupal development and content workflows.

How do we keep our Drupal website compliant after April 2027?

A technically accessible Drupal site can become inaccessible again if your content editors continue publishing content with poor heading structure, missing alternative text, inaccessible tables, or untagged PDFs. That is why accessibility needs to become part of the Drupal content, design, and development workflow and not just a one-time remediation project. A few pointers to help you stay compliant:

1. Run a short training for everyone with publishing rights. Cover heading structure, alt text, link text, tables and captions.
2. Install Editoria11y (the Drupal module we spoke about previously) so it can flag issues while the author is still working.
3. Add accessibility acceptance criteria to every front-end ticket. Keyboard operable, visible focus state, correct semantic markup, contrast ratio verified, tested with a screen reader.
4. Add automated checks to your pipeline to catch a portion of WCAG issues. Treat this as a floor for quality rather than evidence of compliance.
5. Fix accessibility issues at component level. When an issue turns up in a shared paragraph type, Twig template or JS component, fix it there once.
6. Publish content as a web page by default, and reserve PDFs for documents that genuinely need to be printed or signed. When a PDF is unavoidable, require tags, correct reading order and alt text before upload. This stops the backlog from rebuilding.

Can we run an automated accessibility scanner?

Yes, you can. But think of it as an assistant, not the whole solution. Automated tools can catch many common accessibility issues quickly, but they can't reliably assess everything required for WCAG 2.1 AA compliance. Keyboard testing, manual review, and testing with assistive technologies are still important parts of the process.

That said, an automated scan is a useful place to start, especially if you're trying to understand the current state of a large government website.

Specbee offers a quick accessibility scan powered by our AI-assisted accessibility tool to help identify common accessibility issues across your website. It can quickly flag areas that may need attention, giving your team an initial view of where the biggest gaps could be.

The results can help you prioritize what to investigate further and determine where a more comprehensive accessibility audit may be needed.

Want to know where your website stands? Get a quick accessibility scan from Specbee and see what needs attention.

Can I use an AI tool to fix all my accessibility issues?

As tempting as it may sound, there's no AI tool that can automatically fix every accessibility issue on your website. Some accessibility products, including tools that inject JavaScript into a site to automatically adjust or remediate certain issues, have faced criticism (and heavy fines) from accessibility advocates over whether these approaches can deliver genuine WCAG compliance.

AI-powered tools can be useful for finding issues, suggesting fixes, and speeding up parts of the remediation process. But accessibility is more than a technical checklist. Most of the issues often require human review and testing.

For a government website, the safer approach is to use AI as part of a broader accessibility process: which is to scan, identify, fix, manually test, and validate. Don't treat an automated or AI-powered tool as a substitute for actual accessibility testing.

Final thoughts

April 26, 2027 is the deadline. But the real test is simpler: can someone using a screen reader find a meeting agenda, pay a bill, or submit a permit application without getting stuck?

A clean scan won't tell you that. You need to audit your site, fix the underlying issues, and test the journeys that matter.

Drupal gives you a strong accessibility foundation, with core targeting WCAG 2.2 Level AA. But your theme, custom modules, content, and integrations still need to be tested and fixed.

Specbee’s AI-assisted tool scans your site and flags issues across templates, components and content. We also fix accessibility issues in Drupal themes, custom modules, forms, JavaScript and documents too. Find out more about our web governance services.