Six failures account for 96% of all automatically detected accessibility errors across the web: low contrast text, missing image alt text, missing form labels, empty links, empty buttons, and missing document language. On government Drupal sites, four platform-specific failures compound these further: keyboard traps in contrib module widgets, inaccessible PDF documents, improper heading structure, and focus indicators removed by CSS. These 10 represent the failures found consistently across government Drupal environments during formal WCAG 2.1 Level AA audits.
Table of Contents
- Why These 10 Keep Appearing
- The 6 Universal Failures
- The 4 Drupal-Specific Failures
- Which Failures Invite Complaints First
- What Automated Scans Tell You and What They Do Not
- Frequently Asked Questions
- Your Next Move
After auditing government Drupal sites across sectors, the same failures keep surfacing in the same places for the same reasons. Some are universal and appear on any site, regardless of the CMS. Others are specific to how Drupal generates HTML, how its contrib modules handle form output, and how content teams work inside the platform day to day.
This blog covers all 10. Six that every site carries. Four that are unique to Drupal environments and that automated scanning tools will not reliably catch.
1. Why These 10 Keep Appearing
Government Drupal sites fail WCAG audits for predictable reasons. Understanding those reasons matters because fixing a violation without addressing its root cause means it comes back.
The theme was not built for accessibility. Most government Drupal themes were designed to meet brand guidelines, not WCAG criteria. A theme built in Drupal 7 and migrated forward carries its original accessibility assumptions through every version upgrade. A migration is not an audit.
Contrib modules generate their own HTML. Drupal's module ecosystem is its strength, but contrib modules output their own markup. That output does not always follow your theme's accessibility decisions. A form module, a calendar widget, a media carousel: each generates HTML that may bypass every accessibility improvement made to the base theme.
Content editors introduce new failures continuously. WCAG compliance is not a state you reach and maintain automatically. Every time an editor uploads an image without alt text, links to an untagged PDF, or uses heading tags for visual styling instead of document structure, a new violation is introduced. On a large government site with many editors, this happens every day.
Third-party tools are in scope but not under your control. Online payment systems, permit applications, interactive maps, chatbots: if they are embedded on your site and serve the public, they are in scope for WCAG compliance. You are responsible for their accessibility even when you did not build them and cannot modify their code directly.
2. The 6 Universal Failures
These appear on virtually every site audited, government or otherwise. Research consistently identifies the same six categories as accounting for 96% of all automatically detected accessibility errors across the web. They have remained unchanged for seven consecutive years of large-scale accessibility analysis.
What we find on Drupal sites:
Government brand palettes are chosen for aesthetics, not readability. When applied in Drupal themes, they produce light gray text on white backgrounds, pale link text on light surfaces, and body text overlaid on hero images without sufficient contrast layering beneath. System-generated content compounds this. Status messages, error notices, and inline help text rendered by Drupal modules often inherit theme colors without individual contrast testing.
Who it affects:
Users with low vision, color blindness, and older adults with reduced contrast sensitivity.
Why it recurs:
Brand palettes are treated as fixed and enforced organization-wide. Contrast ratios are rarely checked when color values are adjusted or a new content type is introduced.
What we find on Drupal sites:
Drupal's Media Library does not require alt text by default. The field exists but is optional unless explicitly configured as mandatory. Editors working quickly skip it. Decorative images are uploaded with no alt attribute at all rather than an empty alt="", which is the correct markup to signal to screen readers that the image should be ignored. An image with no alt attribute causes a screen reader to announce the filename, often a UUID string or something like IMG_4523.jpg. A blind user navigating a government services page encounters that announcement with no useful information.
Who it affects:
Blind users, users with low vision using screen readers, users on slow connections when images fail to load.
Why it recurs:
The CMS does not enforce it. Editors are not trained on what alt text is or why it exists. Automated scans flag missing alt attributes but cannot assess the quality of alt text that is present.
What we find on Drupal sites:
This is the most complaint-generating failure in this list. Government sites depend heavily on forms: permit applications, service requests, contact forms, registration portals. When a form field has a visible label that is not programmatically associated with its input element, a screen reader user has no reliable way to know what the field expects.
Drupal's Forms API generates labels by default, but contrib modules frequently override this. A date picker module may output a visible label with no corresponding for attribute. A multi-step form may lose label associations between steps. A custom content type built as a form interface may never have been tested with assistive technology.
Who it affects:
Blind users, screen reader users, users with cognitive disabilities who depend on clear field identification.
Why it recurs:
Developers test forms visually. If the label appears near the input, it looks correct. The programmatic association is invisible on screen and only apparent using a screen reader or accessibility inspection tool.
What we find on Drupal sites:
Icon-only navigation links, social media icons without text alternatives, 'Read more' links with no destination context, and linked images without descriptive alt text. When a link has no discernible text content, a screen reader announces it only as 'link' with no indication of where it leads.
Government Drupal sites frequently use icon-based navigation for social sharing, document downloads, and external service links. A page may contain dozens of these. A blind user navigating by the link list, which is a common screen reader behavior, encounters a list of unlabeled items with no usable information.
Who it affects:
Blind users, screen reader users who navigate pages by jumping between links.
Why it recurs:
Icon links are visually polished and the design intent is obvious to a sighted user. The accessibility failure is invisible without a screen reader and does not trigger visual QA processes.
What we find on Drupal sites:
Search buttons using only a magnifying glass icon. Accordion controls using only a chevron. Mobile navigation toggles with no visible or hidden label. Carousel controls have no accessible name. When a button carries no discernible label, a screen reader announces it as 'button' with no indication of what it does.
This is common on Drupal sites that use front-end component libraries or JavaScript-enhanced UI patterns for interactive elements. The visual design is clear. The underlying HTML carries no accessible name.
Who it affects:
Blind users, screen reader users, and voice control software users who try to activate elements by spoken name.
Why it recurs:
Developers and QA reviewers click the button, it functions correctly, and the test passes. Screen reader testing of button labels is rarely included in standard development or QA processes.
What we find on Drupal sites:
The lang attribute on the root HTML element tells screen readers and browser translation tools which language to use when rendering and pronouncing the page. On government Drupal sites, this attribute is frequently absent or incorrectly set, particularly on older installations, post-migration sites, or implementations using custom base themes that did not include it.
This is a theme-level configuration issue, not a content issue. It is set once and affects every page on the site simultaneously.
Who it affects:
Screen reader users who rely on correct pronunciation, users of browser translation tools, and users with cognitive disabilities using reading assistance software.
Why it recurs:
It is invisible in the browser and easy to overlook in development. If the base theme does not include it, no subsequent content or configuration change will add it.
3. The 4 Drupal-Specific Failures
These four are specific to Drupal's architecture. They are produced by how Drupal generates HTML through its module system, how its front-end layer manages keyboard focus, and how content management workflows introduce compliance debt. Automated scanning tools miss them or underreport them significantly. Manual review with assistive technology is required.
What we find on Drupal sites:
A keyboard trap is a condition in which a user navigating only with a keyboard cannot move focus away from an element using standard key commands. This occurs most frequently in Drupal environments on date picker widgets, modal dialogs, autocomplete fields, and embedded map interfaces generated by contrib modules.
The user tabs into the widget and cannot exit it. They cannot reach the submit button. They cannot close the modal. For a government service form, this is a complete denial of access to that service.
Why Drupal is specifically affected:
Many contrib modules include complex interactive widgets that were not tested comprehensively with the keyboard. When modules are updated, keyboard behavior can change without accessibility regression testing. A widget that functioned correctly in a previous module version may introduce a trap after an update.
Who it affects:
Users with motor disabilities who rely entirely on keyboard navigation, and users who cannot use a pointing device.
Why automated tools miss it:
Keyboard trap detection requires a tester to navigate to the widget using only a keyboard and attempt to exit it. Automated tools can check for the presence of focus management code, but cannot determine whether a user is actually trapped in the rendered interface.
What we find on Drupal sites:
Government Drupal sites link to PDFs extensively: meeting agendas, permit applications, service forms, public notices, and budget documents. A large proportion of those PDFs are untagged. An untagged PDF provides no document structure, no defined reading order, and no navigable headings or form fields to a screen reader. The content may technically exist as text in the file, but it is inaccessible to assistive technology without a proper tag structure.
Why Drupal is specifically affected:
Drupal's Media Library lacks a built-in mechanism to flag or reject inaccessible PDFs during upload. Any PDF can be linked from any content node. The file will appear with a working link and no accessibility warning to the editor.
Who it affects:
Blind users, screen reader users, and users who rely on text-to-speech for reading extended documents.
Why it recurs:
Content teams do not consider linked PDFs to be web content subject to the same accessibility standards as HTML pages. The WCAG obligation for PDFs linked from government sites is identical to that for HTML content, yet this is rarely addressed in content team training.
What we find on Drupal sites:
Heading structure is how screen reader users navigate a page. They skip between headings using keyboard shortcuts to find sections, the same way a sighted user scans a page visually. When headings are missing, skipped, or used for visual styling rather than document structure, screen reader users cannot navigate the page efficiently.
On government Drupal sites, heading problems appear from multiple directions simultaneously. Blocks output their own headings independently. Views generate heading tags without awareness of the broader page context. Content editors use H3 or H4 for visual styling when no parent H2 exists. A sidebar block may output an H2 that competes with the page's primary H1. The result is a heading hierarchy that has no logical structure when read by a screen reader.
Why Drupal is specifically affected:
Drupal pages are assembled from multiple independent blocks, each of which may include heading markup. No single component has visibility into the heading level choices made by every other component on the same page. The resulting heading hierarchy is often a collision of independent decisions rather than a coherent document structure.
Who it affects:
Blind users and screen reader users who rely on heading navigation to orient themselves and move through page sections efficiently.
Why automated tools partially miss it:
Automated tools detect skipped heading levels, such as an H4 following an H2. They do not detect semantically incorrect headings: an H2 used purely for visual styling that carries no structural meaning, or multiple H1 elements that each represent a different block's title. Those require human judgment.
What we find on Drupal sites:
The focus indicator is the visible outline that appears around an interactive element when a keyboard user navigates to it. It is the keyboard user's equivalent of a mouse cursor. Without it, a keyboard-only user has no way to know where they are on the page.
On government Drupal sites, this is found on almost every audited environment. Government brand guidelines typically require a clean visual appearance. Developers add outline: none or outline: 0 to all interactive elements in the CSS to remove the browser default focus ring. No accessible replacement is provided. The site looks polished on screen. Keyboard users navigating the page have no visible indication of focus position.
Why is Drupal specifically affected?
Drupal's Claro and Olivero core themes include visible focus indicators. But government sites typically use custom themes built on agency brand guidelines where visual polish overrides accessibility. The override is often added once to a global stylesheet and applies to every interactive element across the entire site.
Who it affects:
Keyboard-only users, screen reader users, users with motor disabilities who cannot use a mouse, and users with attention or cognitive disabilities who rely on visible focus to track their position.
Why automated tools miss it:
Automated tools can detect the absence of a focus style declaration in CSS. They cannot always determine whether a custom focus indicator meets the visibility threshold required by WCAG 2.4.7 in the rendered page across all interactive elements. Manual keyboard testing on the live site is required.
4. Which Failures Invite Complaints First
Not all 10 failures carry the same complaint risk. The violations most likely to generate a formal ADA complaint are those that prevent a user from completing a task entirely, not those that create friction or reduce quality.
The critical and high failures are the ones most consistently cited in advocacy organization complaint filings, because they represent complete barriers to service access, not just degraded usability.
5. What Automated Scans Tell You and What They Do Not
Automated accessibility scanning tools can quickly identify a portion of these failures. They reliably detect low contrast ratios, missing alt attributes, empty links, missing document language, and some form labeling issues when the label association is completely absent from the markup.
They will not detect keyboard traps. They will not determine whether a focus indicator actually meets the visibility threshold in the rendered page. They will not assess whether alt text is meaningful, but rather just present. They will not identify an inaccessible PDF by scanning a link to it. They will partially detect heading structure issues, but cannot evaluate whether headings carry genuine structural meaning.
An automated scan is a starting point, not a compliance posture. The four Drupal-specific failures in this blog require manual testing with actual assistive technology: a screen reader, keyboard-only navigation, and a tester with experience evaluating government Drupal environments specifically.
6. Frequently Asked Questions
Q: Are these 10 failures specific to government sites or do they appear on all Drupal sites?
The 6 universal failures appear across all websites regardless of the CMS. Government sites tend to accumulate them because they run longer between full accessibility reviews, use a wider range of contrib modules accumulated over the years, and have larger content teams introducing new violations continuously. The 4 Drupal-specific failures stem from how Drupal generates HTML through its module system, how its front-end layer manages focus, and how content management workflows create ongoing compliance debt. Government Drupal sites experience all 4 Drupal-specific failures at high frequency due to long deployment cycles, accumulated contrib modules, and large editorial teams.
Q: Will fixing these 10 failures make our Drupal site fully WCAG 2.1 Level AA compliant?
Not necessarily. WCAG 2.1 Level AA has 50 success criteria. These 10 represent the most prevalent failures found in government Drupal environments and addressing them significantly reduces complaint exposure. But a formal audit against all 50 criteria is required to establish a documented compliance posture. Treat these 10 as your highest-priority starting point, not the complete scope of remediation work needed.
Q: How do we stop content editors from continuously introducing new alt text and heading failures?
It operates at two levels. First, configure Drupal's Media Library to make the alt text field required on image upload. This prevents the most common source of new alt text failures at the point of entry. Second, train your content team on what accessible alt text looks like for different image types, and on using heading levels for document structure rather than visual styling. The Editoria11y module for Drupal provides in-context accessibility checking at the point of publishing and surfaces both alt text and heading structure issues before content goes live.
Q: Our site passed an automated accessibility scan last year. Do we still have these failures?
Almost certainly yes on some of them. Automated tools reliably detect a subset of WCAG failures. The four Drupal-specific failures in this blog require manual testing and are not reliably detected by automated tools. Additionally, government Drupal sites continuously add new content. A clean scan result from last year reflects the site at that specific moment. Content published since, module updates since, and theme changes since may have introduced new failures. A clean automated scan result is not a compliance posture. It is a point-in-time snapshot of automatically detectable issues.
7. Your Next Move
These 10 failures do not appear to be due to government teams being negligent. They appear because Drupal is a complex platform, content publishing is continuous, and accessibility testing has not historically been built into the development and maintenance workflow.
The good news is that they are predictable. Predictable failures can be triaged, prioritized, and systematically fixed, starting with those that pose the greatest risk.
At BinaryWorks, our Drupal team delivers a free 48-hour emergency audit that identifies these failures across your site and ranks them by complaint risk. P1 critical, P2 important, P3 backlog. A 30-minute debrief call to walk through findings. A remediation roadmap your team can act on immediately.
Claim Your Free ADA Accessibility Audit
First 25 organizations. No commitment. Just a clear, complete picture of where your site stands.
