Webform module for Drupal 8: DIY Accessibility
Caring about Webform accessibility
Caring about Webform accessibility was a significant and unexpected personal milestone that happened last year while working towards a stable release of the Webform module for Drupal 8. It’s not that I didn’t care about accessibility, I just never paid attention to it.
Mike Gifford and Andrew Macpherson, Drupal's Accessibility Topic maintainers, helped me understand the importance of accessibility. They also gave me some direction for how to address webform related accessibility issues. This experience led me to do a presentation about Webform Accessibility @ Design4Drupal and to strive to fix accessibility issues in the Webform module. I learned to care about accessibility, but it’s not enough - I still have to ask the question…
Have I done enough to make the Webform module accessible to everyone?
Accessibility can't be neglected
Accessibility has become an important and persistent topic in Open Source communities. I've stated how impressed I am with WordPress's reimaging of its page building user experience, called 'Gutenberg'. At the same time, I was disappointed to see how the WordPress community, specifically how Automattic, addressed accessibility issues related to Gutenberg's user experience. My criticism is based on my sense of the responsibility associated with maintaining an Open Source product used by tens of thousands of websites, and in WordPress' case, is used by over 30% of all websites.
Open Source developers can't neglect or ignore accessibility.
Open Source is about sharing and collaborating on code and ideas with everyone; therefore the result of our collaboration needs to be accessible to everyone.
Drupal's commitment to accessibility
Dries Buytaert, Drupal project lead, recognized the quagmire that was created with WordPress's Gutenberg debacle and posted a call-to-action to the Drupal community titled "Drupal's commitment to accessibility."
Today, I've come to believe that accessibility is not something you do for a small group of people. Accessibility is about promoting inclusion. When the product you use daily is accessible, it means that we all get to work with a greater number and a greater variety of colleagues. Accessibility benefits everyone. -- https://dri.es/drupal-commitment-to-accessibility
The Drupal community has defined an accessibility gate with Web Content Accessibility Guidelines (WCAG) guidelines for releasing new Drupal core features. It’s inspiring to see the Drupal community's commitment to addressing accessibility. Whenever I peek at the Drupal's Accessibility Slack channel, I continually see pings to Andrew Macpherson asking him to review new core features for accessibility issues. Asking one person or even a group of people to review new features for accessibility issues does not scale very well. I’m hesitant to distract Andrew from his Drupal core accessibility responsibilities to help me with evaluating the Webform module for accessibility issues and yet I know it needs to be addressed.
Before the New Year, I was able to chat with Andrew about Drupal's and Webform's accessibility, and I suggested that accessibility should be treated like Drupal's commitment to security. Drupal has a dedicated security team, which displays badges next to stable releases that are covered by Drupal's security advisory policy. Maybe this approach is too extreme, but we need to improve how we make accessibility part of our process when building and maintaining core and contributed projects.
It’s impossible to build a team that can monitor all of Drupal for accessibility issues. My conversation with Andrew led me to suggest that I should try to 'self-certify' and assess the Webform module's accessibility. At the very least I should review, document, and quantify the Webform module's commitment to accessibility. The challenge I faced was…
How to self assess the Webform module's accessibility?
Initially, I found this task to feel daunting until I googled "Accessibility checklists" and found Berkeley's Web Access team's accessibility self-assessment documentation.
Berkeley's Web Access accessibility self-assessment
Accessibility is Usability!!! -- https://webaccess.berkeley.edu/home
This statement from Berkeley's Web Access homepage is brilliant because it transitions everyone's acknowledgment that usability is a key part of a website's user experience and makes us realize that accessibility is just as important. The Berkeley Web Access team has put a significant amount of thought and passion into these resources.
Berkeley's Web Access site is a comprehensive, up-to-date resource for beginners and experts. There are resources discussing what is a screenreader, what does "keyboard-only" mean? and tips and how tos. They even link to Drupal's accessibility statement. What spoke to me directly was their self-assessment section with a DIY accessibility checklist.
Berkley's DIY Accessibility for Developers Google Sheet is precisely the tool I was looking for to help me take a crack at self-assessing the Webform module's accessibility.
Performing the Webform module's DIY Accessibility Audit
To properly self-assess the Webform module's accessibility, it helps to establish some goals. My accessibility self-audit goals are to…
- Develop a process for auditing the Webform module's accessibility
- Document and remediate any Webform or Drupal accessibility issues
- Define a benchmark for the Webform module's accessibility
My process is to fill out the DIY Accessibility Audit spreadsheet's action items AS-IS and avoid making any changes to overall spreadsheet architecture or recommendations. I decided to use WebAIM's WCAG 2 Checklist with my favorite accessibility evaluation tool, the WAVE extension for Chrome. I also wanted to leverage Pa11y, an automated and command-line testing tools. All new accessibility issues would be documented on Drupal.org via Issue #3026393: [meta] Self-assess the Webform module for Drupal 8's accessibility. The completed spreadsheet will define a benchmark for the Webform module's accessibility.
I also think it’s important to note that all aspects of the Webform module's accessibility are being reviewed and assessed, not just the generated public-facing forms. The form builder and administrative user interfaces must also be accessible to everyone. Since the Webform module is built on top of Drupal's Form API, some accessibility issues may be coming from Drupal core. Therefore, I’m also going to track and document related Drupal core accessibility issues.
Here are results from the Webform module's DIY Accessibility Audit
When I began reviewing and filling in the DIY Accessibility for Developers spreadsheet, I had a misconception that I’d be able to share some statistical results that quantify the Webform module's accessibility. The first page of the spreadsheet does include the number of issues and their statuses. I don't feel saying X issues exist with X fixed and X remaining portrays a complete picture. The experience of filling out this spreadsheet did give me an understanding of what is required to make a user experience like the Webform module accessible.
Developers need to start reviewing their project's user experience through different perspectives. To understand accessibility, developers need to navigate the project's UX using just the keyboard and recognize that every piece of content and the visible widget will be read aloud by a screen reader.
I found that the combination of reviewing the WCAG guidelines and comparing the results from two automated tools, WAVE and Pa11y, helped me to see any immediate problems. Listing out individual WCAG guidelines with Webform and Drupal specific notes helped me apprehend the Webform module's accessibility. I did find and remedy a few accessibility issues, which were all related to the proper labeling of form inputs with appropriate contextual information, which would be read aloud via a screen reader.
The Web Content Accessibility Guidelines (WCAG) can feel overwhelming but when I approached them using WebAIM's WCAG 2 Checklist, it was easy to just read through them and determine which guidelines apply to the Webform module. Collaborating and iteratively defining an accessibility checklist with recommended accessibility testing tools for Drupal core and contribute projects would help ensure the accessibility is part of our Drupal communities process. Some of this discussion is already happening via Issue #2857808: Automating accessibility checks.
Self-assessment can improve Drupal's accessibility
Self-assessment is one of many tools and approaches to improving Drupal's accessibility. We recognize security and automated testing as part of our process and visibly on every project page. Shouldn't accessibility be treated the same way?
Personally, I take a lot of pride in knowing the Webform module is one the most accessible form builders on the market. This is something I want to promote to anyone evaluating the Webform module and Drupal.
Promoting the Webform module's accessibility
To truly and publically define the Webform's accessibility benchmark, I decided to add the below callout to the Webform module's project which links to the completed spreadsheet and this blog post.
Contributing and funding Webform accessibility
Improving the Webform module's and Drupal's accessibility requires an ongoing effort. Every minor release of Webform and Drupal should include accessibility improvements. If you have the time and resources, please get involved in the Drupal and the Webform module's issue queue. Organizations that rely on the Webform module should consider backing or donating the Webform module's Open Collective. Backing the Webform module's Open Collective will help us improve accessibility and encourage the overall growth and support of the Webform module.
Final thoughts
I like Berkeley's Web Access statement that "Accessibility is Usability!!!" so much, I decided to play with these words and came up with…
Open Source is Accessibility!!!
This statement plays with multiple meaning of accessibility because Open Source is built on the idea that the software's source code should be accessible to everyone. It’s now time for our software to be accessible to everyone.
Everyone needs to care accessibility and your opinion matters. Asking people to self-access their code might be asking too much. At the same time, I'm proud of the accessibility bullet point I have added to my resume skills. Striving to include everyone and anyone is never a bad idea. For me, being an Open Source developer is more than just writing code, it’s about working with a diverse and inclusive community of people, and doing my level best to make sure everyone is acknowledged, heard, seen and considered. We’re all individuals but we’re also all part of the big picture.
What do you think about encouraging Drupal core and contrib developers to self-assess their code and projects?
Please post your thought on my blog and consider backing or donating to the Webform module's Open Collective.