How to Ensure Your Contribution is Accessible

You know you want your module/initiative/theme/patch/core contribution to be accessible, but aren’t sure how to make this happen.

The BBC’s Accessibility Champions approach has been very successful, and the Drupal community can use it as a base to model our own recommended process. Accessibility isn’t easy and often requires creativity, testing and open mind. It is most efficiently and elegantly achieved when it is part of the process all the way through, starting right from the beginning.

Find an A11y Champion to be part of your team (or be your own)

• Our community is rich with experts who want to see Drupal be as accessible as it can be; you can find champions in the issue queue, talking with accessibility experts at camps and cons, or by venturing into Drupal slack and reaching out on the #accessibility channel
   
• Whether you have a dedicated champion, or you are acting as the champion yourself along with your other role(s), it is important to regularly reach out to maintainers for feedback on challenging questions and approaches, and we will be holding monthly office hours to make this easier
   
• Do your own accessibility reviews regularly
   
• Be familiar with WCAG 2.1 and ATAG 2.0 essentials

Schedule accessibility reviews at every stage

Anything that goes into Drupal core must pass the accessibility gate, which means an Accessibility Topic Maintainer has to sign off on it. Getting this sign off at the end of the project, however, as you near completion, might be very difficult if you haven’t made accessibility part of the process right from initial ideation.

Your best path toward accessibility is to schedule regular reviews with the Accessibility Topic Maintainers. At minimum, we recommend the following:

1. Design review
   1. Interaction design (including visual)
   2. Engineering design: how you choose to implement your solutions and code can have a significant impact on accessibility, and it is worth reviewing your plan with an Accessibility Topic Maintainer for gotchas before starting the actual work
2. Alpha review
   An Accessibility Topic Maintainer has seen your prototype and roadmap; the scope is clear, and accessibility challenges have been identified (but may not yet have solutions)
    
3. Beta review
   All accessibility issues have been identified, and you know how they will be fixed (though they may not yet be fixed); an Accessibility Topic Maintainer has signed off on your planned approach
    
4. Stable review
   All accessibility issues have been resolved and satisfactorily tested; the code has cleared the accessibility gate for being released into core

Our suggestion is that you aim for official sign-off from an Accessibility Topic Maintainer at each of these stages in order to smooth the stable sign-off (also known as the accessibility gate to getting something released in core).

But, what if we haven’t started the right way?

• What if our work is already underway and we didn’t start with this approach?
  Start as soon as you can. The community is here to support you.
   
• What if we don’t know enough?
  There are resources to help you along the way, and the Accessibility Topic Maintainers are here to help, not judge. We will be able to direct you towards resources, as well.
   
• What if we cannot find an accessibility champion?
  If you have to be your own accessibility champion, you’ll find the role rewarding and learn a lot. But there are a lot of community members active on the #accessibility slack channel, which is a great place to start.
   
• What if we got it wrong?
  Then someone will raise the concern in the issue queue, and you’ll work with them to figure out how to fix it and make your work even better. That’s a good thing.

Is this article targeted at me?

Are you part of any contributions to Drupal core, themes, modules, or patches? If so, then yes, this is relevant. Drupal is frequently used by universities, governments, and large institutions around the world, many of which are legally bound to provide accessible digital experiences.

Remediating inaccessible features and refactoring inaccessible code can be extremely time consuming and/or expensive. It can mean rendering a beautiful theme ugly because changes have to be forced in rather than part of the design process from the beginning.

Creating something accessible from the ground up is far more elegant, significantly easier, and less costly.