How to make sure your contribution is available

You know you want your module/initiative/theme/patch/core contribution to be accessible, but you're not sure how to achieve that.

The BBC Accessibility Champions approach has been very successful, and the Drupal community can use it as a foundation to model our own recommended process. Accessibility is not easy and often requires creativity, testing, and open-mindedness. It's most effective and elegantly achieved when it's part of the entire process from the very beginning.

Find an A11y Champion for Your Team (or Be One Yourself)

• Our community is rich with experts who want Drupal to be as accessible as possible. You can find champions in issue queues, speak with accessibility experts at camps and cons, or join the #accessibility channel in Drupal Slack.
• Whether you're a dedicated champion or stepping into that role alongside your other responsibilities, it's important to regularly reach out to maintainers for feedback on tricky issues and approaches. We also host monthly office hours to make this easier.
• Routinely conduct your own accessibility reviews.
• Familiarize yourself with the basics of WCAG 2.1 and ATAG 2.0.

Accessibility Review Schedule at Every Stage

Everything that goes into Drupal core must pass through the accessibility gate, which means a theme accessibility maintainer must sign off on it. However, getting that sign-off at the end of the project can be difficult if accessibility wasn’t part of the process from the start.

Your best path to accessibility is to schedule regular reviews with accessibility maintainers. At a minimum, we recommend the following:

1. Design Review

• Interaction and visual design review.
• Engineering design: The way you plan to implement your solutions and code can significantly impact accessibility. It’s worth reviewing your approach with an accessibility specialist before starting work.

2. Alpha Review

The theme accessibility maintainer has seen your prototype and roadmap; the scope is clear, and accessibility issues have been identified (even if not yet resolved).

3. Beta Review

All accessibility issues have been identified, and you have a plan to resolve them (even if they aren't fixed yet). The theme accessibility maintainer has approved your proposed approach.

4. Stable Review

All accessibility issues have been resolved and thoroughly tested. The code passes the accessibility gate for inclusion in core.

We recommend seeking official sign-off from the theme accessibility maintainer at each stage to ease the path to stable release (a.k.a., the accessibility gate for getting something into core).

But What If We Didn't Start the Right Way?

• What if the work is already in progress and we didn’t start with this approach?

Start as soon as possible. The community is here to support you.

• What if we don’t know enough?

There are resources to guide you, and theme accessibility maintainers are here to help, not to judge. We’ll also direct you to helpful materials.

• What if we can’t find an accessibility champion?

If you want to become your own accessibility champion, the role is rewarding and educational. But the #accessibility Slack channel has many active community members you can reach out to.

• What if we got it wrong?

Then someone will raise the issue in the issue queue, and you'll work with them to fix it and improve your work. That’s a good thing.

Is This Article for Me?

Are you contributing to Drupal core, themes, modules, or patches? If yes, then this is relevant. Drupal is widely used by universities, governments, and institutions around the world, many of which are legally required to provide accessible digital technology.

Fixing inaccessible features and refactoring inaccessible code can be extremely time-consuming and/or expensive.

Creating something accessible from the beginning is far more elegant, significantly easier, and cheaper.