Drupal ADA Compliance Guide 2026

Drupal's admin toolbar, content editing interface, and administrative forms are regularly tested for accessibility. Screen reader users and keyboard-only users should be able to administer a Drupal site without assistive technology barriers in the core interface.

Drupal 10's default front-end theme, Olivero, was specifically developed with accessibility as a primary requirement. It provides a strong WCAG 2.1 AA baseline for new Drupal installations. Stable heading hierarchy, sufficient contrast, proper landmark regions, and keyboard-navigable menus are all included.

Core content type output (articles, basic pages) follows semantic HTML conventions. Core block types output standard accessible markup. However, content-level accessibility (alt text, heading structure) depends on content editor behavior, not the platform.

This is where Drupal accessibility breaks down. Contributed modules — the ecosystem of add-ons that extend Drupal — have wildly varying accessibility quality. Some popular modules have well-known WCAG failures that have been open in the issue queue for years.

Most contributed Drupal themes prioritize visual design over accessibility. Many themes in the Drupal.org theme directory have not been tested for WCAG conformance and have documented failures including insufficient contrast, missing focus indicators, and inaccessible navigation patterns.

Questions to ask before choosing any Drupal theme

• Does the theme have accessibility documentation on Drupal.org?
• Does the theme's issue queue have unresolved accessibility bug reports?
• Has the theme been tested with VoiceOver/NVDA screen readers?
• Does the theme meet WCAG 1.4.3 contrast ratios for all text?
• Are keyboard focus indicators visible on all links, buttons, and form fields?
• Does the theme use proper landmark HTML elements (nav, main, header, footer)?

CKEditor 5 is included in Drupal 10 core and is far more accessible than older WYSIWYG editors. However, content editors can still create inaccessible output: using font-size changes to simulate headings instead of H2/H3 tags, creating data tables without proper table headers, or copying and pasting content from Word that carries over inaccessible formatting. Editor training is essential.

The Webform module is the standard form-building solution for Drupal and is widely used for contact forms, applications, surveys, and registrations. Webform is accessibility-aware, but the output is only as accessible as how you configure it — form fields need labels, required fields need proper indicators, and error messages need to be programmatically associated with the fields they describe.

Views generates most of the dynamic content listings on Drupal sites (news lists, staff directories, events calendars). Views output is generally accessible if configured correctly, but complex exposed filter forms and pagination widgets can have accessibility issues.

Paragraphs is the dominant layout/component system for Drupal content. Accessibility depends entirely on how individual paragraph types are templated. Custom paragraph types with media, accordions, tabs, sliders, or modals need individual accessibility review. Accordion and tab patterns are common ARIA implementation failures.

Drupal's Media module (core since Drupal 8.7) handles image, video, and document management. The module supports alt text fields, but they're not required by default — content editors can save images without completing the alt text field. Videos uploaded through Media need captions.

Drupal's Layout Builder allows site builders to construct page layouts visually. The Layout Builder interface itself has improved accessibility, but layouts created with Layout Builder can have heading hierarchy problems when content editors use the visual arrangement instead of semantic structure as a guide.

Fix: Make the alt text field required for image content types (with an 'is decorative' checkbox for purely decorative images). Train content editors on the difference between meaningful and decorative images. Run regular automated scans to catch missing alt text before it accumulates.

Fix: Establish a policy that all PDFs uploaded to the site must pass the Adobe Acrobat accessibility check before being attached to content. Better: where possible, convert PDF content to accessible HTML pages instead of file attachments. Use Drupal's Media module to maintain a PDF library and run accessibility checks when new PDFs are uploaded.

Fix: Configure CKEditor to require proper heading tags (H2, H3) instead of allowing font-size changes. Document the site's heading hierarchy for content editors (H1 is the page title, content sections use H2, sub-sections use H3). Run heading structure audits with automated tools as part of your content QA process.

Fix: Train content editors to use CKEditor's table properties to designate header rows. Avoid using tables for visual layout (use CSS layout instead). If you maintain a large content library, audit existing tables for header row markup.

Fix: For YouTube embeds, enable captions in the embed settings. For videos hosted in Drupal's Media module, require a captions/transcript field. Auto-generated YouTube captions are acceptable as a starting point but require review for accuracy before publishing.

Fix: Train editors to avoid 'click here,' 'read more,' and 'learn more' link text. These links are meaningless to screen reader users navigating a list of links. Link text should describe the destination or action: 'Download the 2026 Annual Report (PDF)' instead of 'click here.'

Theme & Visual Layer

• ☐Use Olivero (Drupal core) or a vetted, accessibility-tested theme
• ☐Verify all text meets WCAG 1.4.3 contrast ratios (4.5:1 normal, 3:1 large)
• ☐Confirm keyboard focus indicators are visible on all interactive elements
• ☐Test navigation menus for keyboard and screen reader accessibility
• ☐Verify skip navigation link is present and functional
• ☐Check that no content relies solely on color to convey meaning

Forms

• ☐All form fields have visible, programmatic labels (not just placeholder text)
• ☐Required fields are clearly indicated (asterisk + accessible text)
• ☐Error messages are specific and programmatically associated with their fields
• ☐Multi-step forms have progress indication
• ☐CAPTCHA (if used) has an accessible alternative
• ☐Form submission confirmation messages are accessible and screen-reader-announced

Images and Media

• ☐All meaningful images have descriptive alt text (required field in Media module)
• ☐Decorative images have empty alt text (alt='')
• ☐All videos have closed captions or transcripts
• ☐Audio content has transcripts
• ☐Auto-playing media can be paused/stopped (WCAG 2.2.2)
• ☐Complex images (charts, infographics) have detailed text descriptions

Content Structure

• ☐Pages have a single H1 heading (the page title)
• ☐Content sections use H2 headings; sub-sections use H3
• ☐Heading hierarchy is logical and doesn't skip levels
• ☐Lists use proper UL/OL/LI markup (not fake lists with dashes)
• ☐Data tables have proper header rows/columns with TH elements
• ☐Links have descriptive text (not 'click here' or 'read more')

Documents

• ☐All PDF attachments pass Adobe Acrobat accessibility check
• ☐PDFs have document title, language, and logical reading order
• ☐PDFs with tables have tagged table headers
• ☐HTML alternatives are available for complex PDFs where possible

Keyboard Navigation

• ☐All page functionality is operable with a keyboard alone
• ☐Tab order is logical and follows visual reading order
• ☐No keyboard traps (focus does not get stuck in any element)
• ☐Dropdown menus are keyboard-navigable with Escape key to close
• ☐Modal dialogs return focus to trigger element on close
• ☐Custom JavaScript widgets implement correct ARIA keyboard patterns

Run an automated WCAG scan on your Drupal site to catch the most common violations — missing alt text, contrast failures, missing form labels, and landmark structure issues. Automated tools catch approximately 30–40% of all WCAG failures and are the fastest way to identify the most critical issues.

The free axe DevTools browser extension (Chrome/Firefox) by Deque runs axe-core accessibility checks on individual pages. Essential for developers testing Drupal templates and custom paragraph types. The paid axe DevTools Pro adds workflow integration and more detailed reporting.

Screen reader testing is the only way to catch ARIA implementation failures, reading order issues, and focus management problems that automated tools miss. Test your Drupal site's navigation, forms, and custom components with NVDA + Chrome (Windows) and VoiceOver + Safari (Mac).

Unplug your mouse and try to use your Drupal site using only Tab, Shift+Tab, Enter, Space, and arrow keys. Can you reach and activate every interactive element? Is focus always visible? Can you navigate dropdown menus and close modals? This identifies keyboard accessibility failures that automated tools often miss.

For testing text contrast in Drupal theme designs, the free Colour Contrast Analyser desktop app provides immediate contrast ratio results. Particularly useful for testing text overlaid on images or dynamic theme color combinations.

Which Drupal version should we use for the best accessibility foundation?

Drupal 10 (and later) provides the strongest accessibility foundation. Drupal 10's core includes the Olivero theme (WCAG 2.1 AA), CKEditor 5 (more accessible editor than CKEditor 4), and ongoing Accessibility Team maintenance. If you're still on Drupal 7, upgrading to Drupal 10 is a compliance requirement — Drupal 7 reached end-of-life in January 2025 and receives no more security or accessibility patches. Drupal 9 also reached end-of-life in November 2023.

Can we use a contributed theme and still be WCAG compliant?

Yes, but you need to verify the theme's accessibility before using it. Check the theme's Drupal.org page for accessibility documentation and open issue queue bugs. Run automated scans on a staging site with the theme installed. Look for themes explicitly marketed as accessibility-focused or WCAG-compliant. If you're using a custom or commercial theme, accessibility remediation of the theme is likely needed before launch.

How does Drupal handle Section 508 compliance?

Section 508 (the US federal accessibility standard for federal agencies and their contractors) was updated in 2017 to incorporate WCAG 2.0 Level AA. Since WCAG 2.1 AA is a superset of WCAG 2.0 AA, achieving WCAG 2.1 AA compliance on a Drupal site effectively meets Section 508 requirements. The GSA maintains a VPAT (Voluntary Product Accessibility Template) for Drupal core, and accessibility has been a factor in Drupal's strong adoption by US federal agencies.

Our Drupal site has thousands of legacy content pages. Do they all need to be accessible?

Under ADA Title II, archived content has a limited exception: content that was created before the Title II rule's compliance date and is no longer used or updated can qualify as archived. However, this exception is narrow. If legacy content pages are still linked, indexed, or in active use, they are not exempt. For organizations with large legacy content libraries, a phased remediation approach — starting with the highest-traffic pages — combined with an accessibility statement acknowledging ongoing remediation is the practical approach.

Should we install an accessibility overlay widget on our Drupal site?

No. Accessibility overlays (accessiBe, UserWay, AudioEye, etc.) do not solve Drupal accessibility problems at the source code level and do not protect against ADA Title II enforcement or lawsuits. The FTC fined accessiBe $1 million in 2025 for falsely claiming its AI could make websites fully compliant. For government and university Drupal sites with formal Title II compliance obligations, an overlay is not an acceptable compliance solution — regulators and plaintiffs will look for WCAG conformance in your actual source code, not a JavaScript overlay patching it.