Drupal ADA Compliance: How to Build a More Accessible Website

ADA compliance for Drupal websites starts with the right standards, the right theme, and a repeatable process. This guide shows what to test, the Drupal features that matter, and a step-by-step checklist you can use on any site.

How ADA, WCAG and Drupal relate

ADA is a US civil-rights law that courts often evaluate against the Web Content Accessibility Guidelines, or WCAG. For practical work, aim for WCAG 2.1 AA or WCAG 2.2 AA as your acceptance target. Drupal does not make a site compliant on its own. Drupal gives tools and patterns that let you build sites that meet WCAG.

UK and public-sector context

In the UK, accessibility obligations map to national law and public-sector rules. Use WCAG as the technical benchmark and confirm which WCAG level your organisation must meet.

Quick audit: what to test first

Start with a short manual pass and a couple of automated scans. That will tell you how deep the project must go.

• Automated scan with a tool such as axe DevTools or Lighthouse. These catch many failures but not everything.
• Keyboard-only navigation. Try every interactive UI element with Tab, Shift+Tab, Enter and Space.
• Screen reader check. Test a few representative pages with NVDA or VoiceOver.
• Colour contrast check against WCAG ratios.
• Forms review for labels, legends, and error handling.

Key Drupal features to use

Use these Drupal-specific items on every site as a baseline. They remove common accessibility barriers without heavy development.

• Accessible core themes. Olivero for front end and Claro for the admin interface are accessibility-focused themes available in recent Drupal core releases.
• Semantic HTML from templates. Ensure Twig templates output proper headings, list markup and landmark elements such as <header>, <nav>, <main> and <footer>.
• Accessible rich text. Use CKEditor with an accessibility checker plugin and limit style-only span tags that break semantic structure.
• Accessible forms. Use the Webform module or core forms with explicit <label> elements and <fieldset>/<legend> where fields are grouped.
• Skip links and focus styles. Provide a visible skip-to-content link and ensure focus rings are not removed by CSS.

Step-by-step Drupal accessibility checklist

1. Pick accessible themes

   Install and enable Olivero for the public site and Claro for content authors. Confirm the theme versions you use are the core-provided releases or come from trusted maintainers.

2. Audit templates

   Check all page templates for proper landmark elements and one <h1> per page. Fix heading order so it follows a strict nesting sequence (h1 then h2 etc.).

3. Set up editor rules

   Configure CKEditor to provide semantic block formats only. Add an accessibility checker plugin so authors see issues before publishing.

4. Make images accessible

   Require descriptive alt text on image fields. For decorative images, use empty alt attributes. Add guidance text to image upload widgets so authors know what to enter.

5. Fix forms

   Use <label> elements linked by for/id attributes. Group related controls inside <fieldset> with a <legend>. Ensure form error messages are announced and visible to keyboard users.

6. Keyboard and focus

   Test every interactive widget with keyboard only. Do not remove default focus outlines. Where custom focus styles are used, ensure they meet contrast requirements.

7. ARIA only when needed

   Use WAI-ARIA roles and attributes to supplement semantics, not replace native HTML elements. Avoid duplicating semantics that native elements already provide.

8. Provide accessible media

   Caption video and provide transcripts. For audio, provide text alternatives. If you use third-party players, confirm they support keyboard controls and captions.

9. Review PDFs and documents

   When you must publish PDFs, make them tagged and test them in a screen reader. Prefer HTML pages over PDFs for public information.

10. Run automated and manual tests

    Combine axe or WAVE automated checks with keyboard and screen reader testing on representative pages. Fix high-impact issues first: missing labels, broken headings, incorrect focus order and colour contrast failures.

11. Train content authors

    Create short guidance and content templates that force authors to add alt text, use headings properly and write meaningful link text. Put checks into the editorial workflow.

12. Document and repeat

    Keep an accessibility log with issues found, fixes applied, and verification notes. Re-run tests on every release and when new features are added.

Configuration and module suggestions

Instead of listing every contrib module, focus on patterns. Use modules that enforce semantic markup, improve editor feedback and make admin pages usable.

• Enable modules that add aria attributes where templates are missing them. Test each module for output quality before enabling site-wide.
• Add an accessibility checker to CKEditor so authors catch problems in the editor. Configure it to report WCAG-level issues only as warnings, not blockers.
• Use Webform for complex forms and ensure server-side validation yields clear, accessible error messages.

Common mistakes and how to avoid them

• Relying only on automated tools

  Automated scans find 20 to 50 percent of issues depending on the page. They miss meaning, reading order and many ARIA problems. Always do manual testing with keyboard and a screen reader.

• Fixing one page only

  Applying fixes to a single page or component without updating templates or the editor workflow creates technical debt. Apply changes at the template or pattern level.

• Invalid ARIA usage

  ARIA can make things worse if used incorrectly. Prefer native HTML elements and only add ARIA when there is no native alternative.

• Not training content authors

  Most accessibility failures are content problems. Provide short, repeatable rules for authors and add checks into the CMS publishing process.

Testing matrix: tools and who should use them

Test	Who	Why
Automated scan (axe, Lighthouse)	Developer or tester	Quick detection of missing alt text, ARIA issues and contrast failures
Keyboard-only navigation	Developer, QA, content editor	Finds focus order problems and inaccessible widgets
Screen reader test (NVDA, VoiceOver)	Accessibility tester or developer	Verifies reading order, labels and live region announcements
Colour contrast check	Designer or developer	Ensures text meets WCAG contrast ratios

WCAG contrast quick reference

Requirement	Minimum ratio
Normal text	4.5:1
Large text (18pt or 14pt bold)	3:1

Integration and maintenance plan

Treat accessibility like security. Make it part of your sprint definition, not a one-off task.

• Include accessibility tickets in every sprint backlog.
• Run automated checks in CI for build breaks.
• Review new contrib modules for accessible output before enabling them.
• Keep a short author checklist visible in the editor interface.

When to bring in specialists

Bring in an accessibility specialist for complex interactive features, large document conversions, or when you need a formal audit for procurement or legal reasons. Use specialists to write acceptance criteria tied to WCAG success criteria.

Final checklist before launch

• Representative pages pass automated scans with no critical failures.
• Keyboard navigation works across the site and admin pages.
• Screen reader spot checks succeed on pages with rich content.
• Content authors have guidance and tools in the editor.
• Accessibility fixes are documented and in the release notes.

Accessibility is a continuous effort. With the right Drupal themes, disciplined templates and author training, you can reach WCAG targets and make your site usable for more people.