Changes to the Drupal Accessibility Page
This document explains the redraft of Accessibility on Drupal.org. The revision follows the Drupal.org content style guide. It also applies lessons from the WP Accessibility Knowledge Base and the ACCESSIBILITY.md approach to scope, evidence, and testing.
Summary
The redraft retains the original page’s purpose, structure, history, and community voice. It makes the claims more precise and gives readers clearer routes to documentation, issue queues, testing guidance, and contribution.
The most important change is a clear separation among:
- Accessibility targets and practices for Drupal core
- Accessibility of a completed site built with Drupal
- Accessibility of contributed modules and themes
- Accessibility of Drupal.org and related community sites
The original page blurred these scopes. That made some statements sound like product-wide conformance claims.
Editorial Approach
- Used clear, direct, and approachable language.
- Shortened sentences and paragraphs where practical.
- Used active voice and descriptive link text.
- Expanded abbreviations on first use.
- Used American English and Drupal.org terminology.
- Kept the existing second-level heading structure, with limited renaming.
- Retained a community-oriented invitation to contribute.
- Avoided promotional language and unsupported claims.
Detailed Changes
| Area | Change | Reason |
|---|---|---|
| Introduction | Retained the inclusive community framing. Added a statement that Drupal core provides foundations and defaults, while a completed site is not automatically accessible. | This prevents readers from treating use of Drupal as evidence of site conformance. Content, configuration, contributed projects, and custom code all affect the result. |
| Goals | Changed “all features align” to a WCAG 2.2 AA target. Described ATAG 2.0 as guidance for the authoring experience. | “All features align” is an unqualified conformance claim. The available documentation does not provide the scope and evidence needed to support it. Drupal should still state its standards clearly. |
| History | Kept the Drupal 7, Drupal 8, and GAAD Pledge history. Reduced repetition and linked the pledge to the current Accessibility Coding Standards URL. | The history explains how accessibility became part of Drupal governance. The old coding standards URL redirects and should be replaced. |
| Development process | Stated that Drupal treats accessibility barriers as bugs. Clarified what the accessibility quality gate does and does not establish. | The gate can stop a change, but passing it is not equivalent to testing all interfaces against every WCAG success criterion. |
| Stable-release fixes | Retained the explanation that critical barriers may be fixed after release. Added backward-compatibility and site-risk considerations. | This explains why a known problem may not always receive an immediate stable-release change without implying that accessibility is being deprioritized. |
| Testing | Renamed “Automated Testing” to “Testing.” Retained WAVE, axe DevTools, and Accessibility Insights. Added rendered-state, keyboard, reflow, semantics, and assistive-technology testing. | Automated testing is only one part of the process. The former heading placed too much emphasis on tools. |
| Automated results | Added that automated results are evidence, not proof of WCAG conformance. | Automated tools detect only a subset of barriers. This aligns the page with established accessibility-testing practice and avoids overstating tool coverage. |
| Conformance reports | Added a short section linking to Drupal’s Accessibility Conformance Report process. Defined the minimum scope information a useful assessment should provide. | The former page moved directly from testing tools to assistive technology. It did not explain how a general commitment differs from a scoped conformance assessment. |
| Disabled people | Strengthened the role of people with disabilities in testing and contribution. Replaced the narrower reference to blind developers with a wider range of roles and disabilities. | Screen-reader experience is important but does not represent all disability-related access needs. |
| Assistive technology | Retained NVDA and VoiceOver as common testing tools, but removed the implication that they form a defined or comprehensive test matrix. | Coverage varies by issue and contributor. The page does not provide evidence for a formally supported browser and assistive-technology matrix. |
| HTML and ARIA | Made the native-HTML-first rule explicit. Clarified that ARIA does not add keyboard behavior or correct invalid HTML. | This gives implementers a concise and technically accurate rule instead of only saying that Drupal tries to limit ARIA. |
| Core modules | Renamed the section “Core Modules and Configuration.” Retained Inline Form Errors and language-of-parts configuration. Added a reminder to test the actual Drupal version and configuration. | The original section suggested that core defaults alone determine accessibility. Configuration and release differences matter. |
| Contributed modules | Removed the claim that most contributed developers follow accessibility practices. Explained that contributed projects do not pass through the core accessibility gate. Retained Webform as a positive example. | The removed claim was not supported by evidence. Project accessibility varies by release, configuration, and use. |
| Module lists | Added that inclusion in the accessibility-related module list is not certification. | A recommendation or category listing should not be confused with an accessibility audit. |
| Core themes | Updated Olivero and Claro from historical Drupal 9 additions to their current public-facing and administration roles. | The former wording had aged and did not explain what each theme is for. Rachel Olivero’s contribution and the origin of the Olivero name remain. |
| Contributed themes | Removed the description of Olivero as a “base theme.” Explained that tested core patterns may reduce risk, but custom work can change the result. Added that Drupal.org does not certify contributed themes. | Olivero is a core theme, but “base theme” has a specific technical meaning in Drupal. The new wording also defines the boundary of Drupal’s current review process. |
| Legacy theming guide | Removed the Drupal 7 accessible theming guide. Linked the current coding standards and accessibility review guide instead. | The legacy guide may contain useful principles, but it is not a reliable primary guide for current Drupal theming. |
| Community sites | Explicitly separated Drupal.org and related services from Drupal core. Added the information needed for a useful barrier report. | A Drupal.org defect is not automatically a Drupal core defect. Reports need the affected task, observed result, expected result, reproduction steps, and relevant environment. |
| Accessibility team | Focused the section on the work contributors perform. Updated issue-search URLs and the office-hours link. | The original searches were tied to old Drupal version filters. The revised links are not limited to Drupal 8. |
| Contribution | Renamed “Our Community of Developers and Designers” to “Contribute.” Added lived-experience reporting and manual testing. Made every list item an action. | Accessibility work also needs writers, content specialists, site builders, and disabled users. The old heading excluded several of these groups. |
Content Removed or Altered
- “All features of Drupal core align”: Replaced with a target because no complete, versioned conformance assessment is linked.
- “Major releases have been delayed several times”: Removed because it is a historical assertion without a supporting source and does not help readers act.
- “Most developers follow community best practices”: Removed because it cannot be verified across contributed projects.
- “Most Drupal events include accessibility”: Removed because it is broad, time-sensitive, and not necessary to find the accessibility community.
- Drupal Groups as one of three primary community sites: Replaced with the broader phrase “related community properties.” This avoids freezing a changing service inventory into the page.
- The Drupal 7 theming guide: Removed as a primary resource because the page is for current Drupal users.
- Repeated requests to join Slack: Consolidated into one direct route to the relevant channel.
- Repeated statements about ongoing work: Consolidated so the page remains close to its original size.
Claims Not Added
The revision does not add:
- A claim that Drupal core fully conforms to WCAG 2.2 AA
- A claim that Drupal conforms to ATAG 2.0
- A legal-compliance claim for sites built with Drupal
- An accessibility certification for contributed modules or themes
- A formal browser and assistive-technology support matrix
- Audit results, response times, or release guarantees that are not documented
Adding any of these claims would require defined scope, dated evidence, ownership, and a maintenance process.
What Remains Consistent
The redraft preserves the page’s central message: accessibility is part of Drupal’s values and development process, barriers are bugs, open standards guide the work, and community participation is necessary. It also preserves the original coverage of standards, testing, assistive technology, HTML and ARIA, modules, themes, community sites, and contribution.