Changes to the Drupal Core Accessibility Gate
This document explains the proposed redraft of the Drupal core accessibility gate. The current page mixes policy requirements, historical notes, examples, and tool recommendations. The replacement defines five issue-scoped checks and links to the detailed review procedure.
Summary
The revision proposes updating the target from Web Content Accessibility Guidelines (WCAG) 2.1 to WCAG 2.2, clarifies when Authoring Tool Accessibility Guidelines (ATAG) 2.0 applies, and distinguishes a gate decision from a product conformance claim. A proposal-status notice makes clear that the current published gate remains authoritative until Drupal approves and publishes the replacement.
The original body contained approximately 919 words. The revised body contains 791 words, a decrease of 13.9 percent. The revised structure removes historical examples and detailed testing instructions from the gate while adding scope triage, reproducible evidence, and a decision rule.
The revision:
- Organizes the gate as five outcome-based checks, consistent with the parent core gates policy.
- Defines when the gate applies to all or part of a change and when an issue can mark it not applicable.
- Proposes WCAG 2.2 Level AA as the updated core target.
- Applies ATAG 2.0 separately to author access and support for accessible generated content.
- Requires issue-scoped, reproducible, and accessible evidence, including a baseline and unperformed checks.
- Links the detailed review guide instead of duplicating its testing matrix.
- Defines a pass, an acceptable follow-up, reasons to postpone, and risk-based use of the review tag.
Detailed changes
| Original area | Change | Reason |
|---|---|---|
| Page status and purpose | Added a proposal-status notice and an introduction that identifies the gate’s scope and limits. | The preview must not imply that the proposed WCAG 2.2 policy has already replaced the current gate. |
| Gate structure | Replaced many topic-specific checks with five outcomes: scope, requirements, testing, evidence, and resolution. | The parent policy says each gate should focus on five or fewer important items and should not add unnecessary burden. |
| “Conforms to WCAG 2.1 and ATAG 2.0” | Replaced the combined conformance statement with proposed WCAG 2.2 Level AA and ATAG 2.0 Level AA targets, including an explanation of ATAG Parts A and B. | WCAG 2.2 is the current W3C Recommendation. Passing one issue gate is not a full conformance evaluation of Drupal, a feature, or a completed site. |
| When the gate is needed | Added a recorded decision that the gate applies to all or part of a change, or is not applicable, with an explicit boundary against excluding known affected tasks, surfaces, or states. | Scope should keep evaluation proportionate without allowing affected behavior to be removed from the pass decision. |
| Detailed interface checks | Replaced gate-level lists for markup, contrast, forms, keyboard behavior, and JavaScript with an outcome to test the affected task and final output, plus a link to the review guide. | The review guide is the maintainable home for procedures and test matrices. The gate should define the decision, not duplicate the manual. |
| Authoring tools | Added separate outcomes for author access, support for producing accessible content, and the published or otherwise consumed output. | ATAG Part A, ATAG Part B, and WCAG address distinct parts of an authoring workflow. |
| Automated checks and exceptions | Removed the fixed tool list. Automation is one evidence source, and exceptions must be narrow, explained, linked to a follow-up, and assigned a recheck condition. | Tool lists become stale, automation cannot determine conformance, and indefinite suppression can hide regressions. |
| Issue evidence | Added a compact evidence outcome covering the task, states, baseline, expected and actual results, environment, performed and unperformed checks, limitations, follow-ups, and accessible artifacts. | A reviewer needs enough context to reproduce and evaluate the result without relying on visual-only evidence. |
| Existing patterns | Retained the preference for established patterns, with the qualification that the pattern must fit the task and have no relevant known accessibility problem. | Reusing a pattern reduces unnecessary variation, but precedent does not prove accessibility. |
Needs accessibility review |
Kept the canonical issue tag and its Topic Maintainer signoff meaning, added a significant-impact threshold, and retained severe task impact for one access need as an indicator. | Routine changes should not automatically require the tag, but a severe barrier for one group warrants review without a cross-disability threshold. |
| Gate decision | Added issue-scoped pass, follow-up, and postpone conditions, including a recorded rationale and task-blocking barriers without a direct WCAG mapping. | A gate that lists practices without a scoped decision rule cannot be applied consistently and may be mistaken for a product-wide conformance claim. |
Content removed or consolidated
- Drupal 8 gate discussion: Removed because it is historical context rather than a current requirement.
- Repeated “When needed,” “Details,” and “Resources” blocks: Consolidated into the five gate outcomes.
- Fixed checker and browser-extension lists: Removed because evidence requirements are more stable than product recommendations.
- Old contrast, Drupal 6 form-label, jQuery, and JavaScript examples: Replaced by outcome-based guidance and the maintained review procedure.
- Detailed testing matrix: Kept in the accessibility review guide instead of duplicating it in policy.
Claims not added
The revision does not claim that:
- The proposed WCAG 2.2 target is approved before Drupal publishes the replacement gate.
- Passing the issue gate establishes WCAG or ATAG conformance for Drupal core, a feature, or a completed site.
- An automated checker can find every accessibility barrier.
- Every change needs testing with every browser and assistive-technology combination.
- Every user-interface change requires Accessibility Topic Maintainer signoff.
- Level AAA success criteria are blockers under a Level AA policy.
- A legal accessibility obligation can be determined from this engineering gate.
Sources checked
- Current Drupal core accessibility gate
- Drupal core gates policy
- Drupal Accessibility Coding Standards
- Drupal issue tags: special tags
- How to ensure your contribution is accessible
- How to perform an accessibility review
- Web Content Accessibility Guidelines (WCAG) 2.2
- Authoring Tool Accessibility Guidelines (ATAG) 2.0