Changes to “How to Ensure Your Contribution Is Accessible”

This document explains the redraft of How to Ensure Your Contribution Is Accessible. The original page was last updated on September 22, 2023. It described an accessibility-champion model and a four-stage sign-off process. The revision makes the guidance applicable to ordinary contributions as well as large initiatives and aligns it with the proposed revision of the Drupal core accessibility gate.

Summary

The revised page treats accessibility as a shared contribution responsibility. It retains the option of naming an accessibility lead or champion, but makes that a coordination role rather than the person responsible for accessibility. It adds scope triage, testable outcomes, concise evidence, and risk-based review while linking the detailed review procedure instead of duplicating it.

The original body contained approximately 711 words. The revised body contains 957 words, an increase of 34.6 percent. The additional detail defines practical work products, including scope, user impact, acceptance criteria, testing, issue evidence, and review decisions.

The revision:

Detailed changes

Changes grouped by original section or claim
Original area Change Reason
Introduction Replaced the conversational opening with a direct statement that accessibility is part of contribution quality throughout planning, design, implementation, review, and testing. The original opening described good intentions but did not say what contributors need to do.
Contribution scope Added triage for direct and indirect effects on interfaces, rendered content, documentation or examples, and authoring workflows. Changes with no such effect normally need no separate accessibility testing. Ordinary contributors need a proportionate way to decide whether accessibility work is relevant without turning every non-interface change into a testing exercise.
BBC Accessibility Champions Removed the external case study as the basis for Drupal’s process. A single organization’s model does not define current Drupal governance. The useful part of the model, naming someone to coordinate accessibility, is retained without making it mandatory.
“Find an A11y Champion” Replaced the section with “Make accessibility a shared responsibility.” An accessibility lead or champion remains optional, and one person may perform several roles on a small contribution. Assigning accessibility to one person creates a predictable ownership gap, while requiring separate people for every role would burden ordinary contributions.
WCAG 2.1 and ATAG 2.0 essentials Replaced the outdated WCAG 2.1 reference with a goal to meet WCAG 2.2 Level AA, explained the distinct purpose of ATAG Parts A and B, and added Drupal’s coding standards as the implementation reference. This states the broad project goal without presenting the proposed core gate update as already-approved policy.
Level AAA Added a short statement that Level AAA and advisory techniques are useful goals but are not Level AA requirements. This keeps aspirational improvements visible without misclassifying them as mandatory failures under an AA target.
Accessibility planning Added affected tasks, surfaces, states, relevant checks, standards, and testable accessibility acceptance criteria. The original page recommended early involvement but did not define a proportionate scope or what planning should produce.
Existing patterns Added guidance to reuse an established Drupal pattern only when it fits the task and has no relevant known accessibility defect. Consistency helps, but existing code is not proof that a pattern is accessible.
Authoring workflows Added separate recorded outcomes for the interface used by disabled authors, support for accessible authoring, and the final rendered output. This turns ATAG Parts A and B into concrete design and review decisions and connects generated output to WCAG.
Design, alpha, beta, and stable reviews Removed the four-stage minimum review schedule and replaced it with continuous testing plus risk-based review triggers. The staged model may fit a large initiative, but it adds unnecessary process to small changes and does not match the core-gates principle that gates should not add work for the responsible team.
Accessibility Topic Maintainer sign-off Removed the claim that every core contribution needs Topic Maintainer sign-off at every stage. Risk-triggered issues use the canonical review tag, whose current definition signals that signoff is needed. This distinguishes universal staged approval from the maintained issue-tag process for new, complex, high-impact, or unresolved work.
Testing Added final-rendered-output testing and risk-based selection of checks, then links the detailed review guide for the full procedure. The contribution page should orient ordinary contributors without becoming a second testing manual.
Disabled-user testing Links to the review guide for voluntary participation, privacy, diagnosis, approval-role, and generalization boundaries. The procedural safeguards belong in one canonical review guide rather than being repeated in the overview.
Issue evidence Added a concise evidence record covering scope, tasks and states, baseline, expected and actual results, relevant tests, unperformed checks, limitations, follow-ups, and accessible artifacts. Reviewers need evidence they can understand and repeat, while the detailed environment matrix remains in the review guide.
Needs accessibility review Added the canonical core issue tag and its Topic Maintainer signoff meaning, and links the core gate for the maintained risk indicators. The overview explains the escalation path without duplicating policy text that could drift.
Core and contributed projects Clarified that core issues record gate applicability and a decision, while contributed projects follow their own policies and use this guide to select appropriate evidence. The original page grouped core, modules, themes, initiatives, and patches together, then described a core-only approval process as if it applied to all of them.
Work already underway Replaced the question-and-answer section with direct steps for assessing and correcting work in progress. The revised wording tells contributors what to do without reassurance, repetition, or dependence on finding a champion.
Getting help Retained the issue queue, Drupal Slack channel, and accessibility office hours, and requires decisions reached elsewhere to be summarized in the issue with their evidence. Community channels remain useful for broader questions and early advice, while decisions and rationale must remain with the contribution.

Content removed or altered

Claims not added

The revision does not claim that:

Sources checked