An accessibility review examines whether people with disabilities can complete the affected tasks and whether the interface satisfies the applicable accessibility requirements. Use this process for Drupal core, contributed projects, themes, and sites.

A contribution review is not automatically a conformance audit. A conformance claim requires a defined scope, complete processes, representative pages and states, and an appropriate evaluation method. This guide helps contributors find barriers, prevent regressions, and record evidence that another reviewer can reproduce.

1. Define the review scope

Start with the user task, not a testing tool. Identify what changed, who may be affected, and what a person must be able to perceive, understand, and operate.

Record the relevant:

• Pages, components, routes, and complete workflows.
• Drupal version, project version, patch, or merge request.
• Enabled modules, themes, text formats, permissions, and other configuration.
• User roles, content, languages, and validation states.
• Viewport sizes, zoom levels, color modes, and user preferences.
• Browsers and assistive technologies required by the project or affected behavior.

Select the checks that apply to the affected task and surfaces. Record what is included, what is excluded, and why. Do not exclude a task, surface, or state known to be affected by the change. For Drupal core, state whether the accessibility gate applies to all or part of the change, or is not applicable. Resolve a disputed applicability decision before passing the gate. For a contributed project, follow any project-specific review and release requirements and use this guide to select relevant evidence.

For a proposed change, record the behavior before and after applying it. If no comparable baseline exists, record why and define the expected result. Test every state introduced or changed, including loading, empty, error, expanded, selected, disabled, and completed states where relevant.

A stable preview makes a review easier to repeat. Drupal core, Drupal CMS, and many contributed projects provide Tugboat previews for merge requests. A local environment is also acceptable when the configuration and steps are documented.

2. Distinguish barriers, requirements, and rules

Use four levels of evidence:

1. Accessibility barriers affect people and tasks. Describe who is affected and what becomes difficult or impossible.
2. Accessibility requirements include Web Content Accessibility Guidelines (WCAG), Authoring Tool Accessibility Guidelines (ATAG), and Drupal policies.
3. Test rules evaluate particular conditions. A rule may test part of a requirement, contribute evidence about several requirements, or cover an optional best practice.
4. Automated gates use the smaller subset of rules that are deterministic in the project environment and do not routinely produce false positives.

A barrier may exist without a direct WCAG mapping. A WCAG failure may exist even when one user does not encounter it. Passing an automated rule does not establish that a success criterion is satisfied, and passing every available rule does not establish conformance.

Use the Accessibility Coding Standards as the reference for required implementation behavior.

3. Run relevant automated checks

Automated tools can identify some deterministic failures and flag other conditions for review. Run them after the affected content and interaction state are available, not only on the initial page load.

• Test the pages, components, themes, viewports, and states included in the review scope.
• Record the tool and version, rule identifier, tested element, and result.
• Separate WCAG 2.2 Level A and AA rules from Level AAA and best-practice rules.
• Review incomplete, needs-review, and context-dependent results manually.
• Compare results before and after a proposed change to identify regressions.
• Verify that the reported element and state can be reproduced before filing an issue.

Drupal core uses axe-core with Nightwatch on representative public and administration pages. New or substantially changed interactive behavior should receive automated regression coverage where practical.

A failed automated rule may block a build only when the result is deterministic and consistently represents a defect in the tested environment. Keep rule exceptions narrow, explain why each rule is disabled, link to an issue that tracks the underlying problem, and state when the exception should be rechecked. Do not suppress an entire rule set to remove inconvenient results.

4. Perform manual checks

Automated testing does not replace manual evaluation. Perform the checks that apply to the affected task and record the result of each check.

Keyboard and focus

• Complete every action using the keyboard alone. Test forward and backward navigation.
• Confirm that focus order follows the reading and interaction order.
• Check that focus is always visible and is not obscured by sticky content, dialogs, or overlays.
• Confirm that there are no keyboard traps. A modal dialog may contain focus while open, but it must provide a predictable way to close.
• Check initial focus and focus restoration when a dialog, menu, overlay, or other temporary context opens and closes.
• Confirm that custom widgets support the expected keys and that static content is not placed in the tab order without a reason.
• Verify that content shown on hover is also available on focus and remains dismissible, hoverable, and persistent when required.

Pointer, touch, and alternative input

• Provide a single-pointer alternative for multipoint or path-based gestures unless the path is essential.
• Provide a non-dragging alternative for drag interactions.
• Confirm that pointer actions can be cancelled or undone where WCAG requires it.
• Check that visible labels match accessible names so speech-input users can identify controls.
• Test targets against the WCAG 2.2 minimum size and spacing requirement, including its exceptions.

Zoom, reflow, and personalization

• Resize text to 200 percent without losing content or functionality.
• Test reflow at 400 percent browser zoom on a 1280 CSS-pixel-wide viewport, or the equivalent 320 CSS-pixel viewport, where the criterion applies.
• Repeat keyboard checks in responsive layouts and when navigation or controls change form.
• Apply WCAG text-spacing overrides and confirm that content remains readable and operable.
• Test forced-colors mode, increased contrast settings, and reduced motion when the change affects them.
• Check that content and functionality do not require one display orientation unless that orientation is essential.

Structure, names, and visual information

• Confirm that the page title and headings describe the content and that heading levels reflect the structure. WCAG does not require exactly one h1.
• Check landmarks, lists, tables, reading order, page language, and changes in language.
• Inspect the final rendered document object model and accessibility tree when the result depends on generated semantics, names, states, properties, or relationships.
• Confirm that every control has an accessible name and that it includes the visible label.
• Review link and button text in context.
• Check meaningful images, icons, charts, and other non-text content for an appropriate text alternative. Confirm that decorative images are ignored.
• Verify text contrast, including the large-text exception, and non-text contrast for controls, focus indicators, states, and essential graphics.
• Confirm that color, position, shape, sound, or an icon is not the only way information is conveyed.

Forms, errors, and authentication

• Check labels, instructions, descriptions, required states, input purposes, and related control groups.
• Submit valid and invalid data. Confirm that errors are identified in text, associated with the affected controls, and explain how to correct the input.
• Verify that an error summary or notification is easy to find and that entered values are preserved when appropriate.
• Check that users are not required to enter the same information twice in one process unless an exception applies.
• Test password managers and copying and pasting. Confirm that authentication does not depend on a cognitive-function test when an accessible alternative is required.
• Review important submissions for appropriate confirmation, correction, and error-prevention steps.

Dynamic content

• Confirm that visible names, roles, states, and properties remain correct after each update.
• Check whether focus should remain in place or move to the updated content. The result should be predictable and easy to find.
• Verify that meaningful status changes are announced when they are not otherwise apparent.
• Check that announcements are concise and do not duplicate information already communicated through focus.
• Confirm loading, progress, completion, empty, and error states where they affect the task.

Media, timing, and motion

• Apply the relevant WCAG requirements for prerecorded and live audio and video. Captions, transcripts, audio descriptions, and media alternatives are not interchangeable in every case.
• Check controls for autoplaying audio and for moving, blinking, scrolling, or auto-updating content.
• Confirm that time limits can be adjusted, extended, or disabled when required.
• Check flashing content against the applicable threshold.
• Respect reduced-motion preferences and provide a reduced or static alternative when motion is not essential.

Authoring workflows and generated content

For editors, layout tools, media tools, and other authoring features, review both the interface used by authors and the content it produces.

Record separate outcomes for whether disabled authors can complete the task and whether the feature preserves accessibility information and helps authors produce accessible output. Assess the rendered output against the relevant WCAG target.

• Complete the authoring task by keyboard and with the relevant assistive technology.
• Check whether disabled authors receive the same instructions, validation, previews, and repair options.
• Review generated markup and content in its published context, not only inside the editor.
• Confirm that accessible information, including headings, language, alternative text, table structure, and media alternatives, is preserved when content is edited, transformed, saved, and reused.
• Check that defaults and templates generate accessible output and that authors are prompted for information Drupal cannot supply automatically.
• Confirm that accessibility options are as easy to find and use as comparable authoring options.

5. Test with assistive technology

Select browser and assistive-technology combinations based on the project’s support policy, the affected users, and the behavior being reviewed. Record the exact browser, operating system, and assistive-technology versions, the task and state tested, and the test date. Testing every available combination is neither possible nor necessary.

Complete the defined tasks rather than exploring the page without a goal. Check:

• Page title, landmarks, headings, lists, tables, and reading order.
• Control names, roles, states, values, descriptions, and keyboard behavior.
• Forms, validation, errors, instructions, and completion messages.
• Dynamic updates, status announcements, focus placement, and focus restoration.
• Alternative text and the order and clarity of meaningful content.

A contributor who does not regularly use a screen reader can identify implementation defects, but that test does not reproduce the experience of a person who relies on it. Do not turn off the monitor as a substitute for testing with blind users. Do not infer that one assistive-technology result applies to every product, browser, disability, or user.

6. Test with disabled users

Include disabled users when reviewing new, complex, high-impact, or unfamiliar patterns where possible. Participation should be voluntary and informed. Ask participants to complete defined tasks using their usual technologies and strategies. Fix obvious standards failures before user testing so the session can focus on problems that technical review is less likely to find.

Record the test scope, access method and environment relevant to the finding, observed barriers, and limitations. Default to an anonymized, task-based summary. Do not require a diagnosis, treat participants as approvers or representatives of a group, or generalize one person’s result to an entire disability group. Do not attach recordings, names, contact details, or uniquely identifying participant details to a public issue without explicit permission.

User testing can identify barriers that WCAG evaluation misses. It does not establish WCAG conformance and does not replace standards-based review.

7. Record reproducible evidence

A review is useful only when another contributor can understand and repeat it. Record:

• The affected people and task.
• The page, component, configuration, role, content, viewport, and interface state.
• Exact steps and the expected and actual results.
• The applicable WCAG, ATAG, or project requirement.
• Tool rules and versions, when a tool contributed evidence.
• Browsers, assistive technologies, and user preferences used.
• Whether the result is new, pre-existing, intermittent, or dependent on a particular condition.
• Relevant screenshots, recordings, markup, or console output. Describe information in images in text, and provide captions or a transcript for recordings needed to understand the result.
• Relevant checks not performed and why, and any limits on what the evaluation can establish.

Raw tool output is not a complete bug report. Explain the user impact and the evidence needed to reproduce the result.

After a fix, repeat the failed task and the relevant automated and manual checks. Also test adjacent states and components that use the same pattern. Record the successful retest rather than closing the issue from code inspection alone.

Record the review disposition and rationale, including whether a result blocks approval, needs manual review, belongs in a follow-up issue, or is an accepted narrow exception. For a follow-up or exception, record the condition for rechecking it.

8. Determine the review outcome

For Drupal core, apply the accessibility gate. The gate defines the indicators for adding the Needs accessibility review issue tag and records its Topic Maintainer signoff requirement. Routine changes using established patterns still need applicable evidence, but do not automatically require the tag.

See also the guidance on ensuring a contribution is accessible.