Last week, I attended a meetup that was about the accessibility of not just one CMS, but two: WordPress and Drupal. It brought together people from both communities to talk about their accessibility efforts. Because CMS accessibility can make a huge difference. It was kindly organised by Level Level, a WordPress consultancy in Rotterdam.

Disclaimer: I work on authoring tool accessibility at the W3C/WAI, this write-up is in my personal capacity, views are, as always, my own.

Short introductory talks were given by Rian Rietveld, former WordPress accessibility lead, and Mike Gifford, “godfather of Drupal accessibility”, who visited from Canada. They talked about how they moved their respective communities towards doing (a lot) more work on accessibility.

Rian and Mike

WordPress and catching up (Rian)

Rian explained that back in 2011 a lot of accessibility discussions in WordPress were still of the “why is it important” and “raising awareness” kind. Rian wanted it all to be more practical and focused on getting things done. The time seemed right, because more people got interested in the subject, partly because accessibility legislation was about to get stricter. Something else that helped was that the WordPress Slack community just started and turned out to be great for facilitating conversations. In 2016, WordPress announced:

All new or updated code released into WordPress core and bundled themes must conform with the WCAG 2.0 guidelines at level AA.

(see: WordPress goes WCAG)

Things got complicated around the release of Project Gutenberg, a new block based content editor. It was pushed by Automattic, the company of WordPress’ inventor Matt Mullenweg that also dedicates a lot of its developers to WordPress core, as it would strategically bring WordPress in line with other modernised forms of content editing. This type of content editing is hard to get right.

For the accessibility team, Gutenberg was extremely tricky, Rian explained, because of the process: first features were developed, then designed, then accessibility checked. This order of things made that the accessibility team would always have to play catch up, in a fast moving project. The accessibility team warned about issues in the editor from the very start, but it was hard to catch up with the speed of development and convince people of the need for accessibility. Rian left the team when it became clear that Gutenberg would be included into WordPress without the accessibility issues addressed.

An accessibility audit of the Gutenberg editor was then crowdsourced, hundreds of issues were found and filed in GitHub. They are being addressed, but there are still many issues, and the catch up problem seems to have remained unsolved. Monique, who is in the core design team now, mentioned that she notices more designers and developers ask accessibility questions earlier on in the process, which is hopeful.

Others mentioned the active accessibility community on WordPress Slack, that makes a difference by checking core code as well as plug-ins and themes. This is something WordPress has had for a while, but it is still “catching up” rather than “considered from the start”, which one would hope WordPress would do more, as it often ends up being cheaper and easier. The WordPress governance project, that includes accessibility, may help with this, and improve how the efforts of the accessibility team are supported.

Drupal and ATAG (Mike)

Mike talked about how, in 2008/2009, he started looking into Drupal accessibility, because he had known people in the disability rights scene for years and wanted to apply what he knew to Drupal. He filed accessibility issues, and found it oddly addictive to tag them and get them in the issue queue.

Mike explained that, some years ago, Drupal’s founder Dries Buytaert had identified a number of “gates” for Drupal quality control:

Core changes must pass through a series of “gates” to ensure their quality is up to standards. Gates are essentially “checklists” that can be used to evaluate a patch’s readiness, by both developers and patch reviewers/core committers.

(see: Drupal core gates)

Accessibility is one of those gates, others include performance and usability. Needless to say, being one of the gates helped ensure accessibility throughout the ecosystem.

Drupal publicly committed to being WCAG AA, see Drupal’s commitment to accessibility on Dries Buytaert’s blog. Mike said accessibility work in Drupal was focused on not just the front-end, but also the back-end (just like in WordPress): they want to make Drupal itself accessible. The standard to follow for that kind of accessibility is ATAG, which Mike put a lot of effort in promoting within the Drupal community.

For those who are unfamiliar, ATAG has two parts: part A is about accessibility of the CMS so that content editors with disabilities can use it, part B is about improving the accessibility of output, so that web users with disabilities can use the resulting website. In Drupal 7, Mike said, they more or less met part A of ATAG, in Drupal 8, they tried to incorporate as much as possible of part B.

A major driver for improving accessibility in Drupal, Mike explained, was the idea of scale: rather than do work to fix one website, they did work to fix a platform that is used on 3% of the web. Yes, this is awesome about making CMSes more accessible: you’re potentially improving a lot of sites at once. This also gives the team some leverage when, say, talking to a browser vendor about a specific bug, then you would normally have as the owner of just one site.

Challenges and solutions

After hearing Rian and Mike talk about their experiences in their respective community, we talked about various interesting subjects:

• is it possible to educate all developers in the world about basic accessibility, or should we ensure that’s built into libraries and CMSes? The latter could be super effective and help teach people where they are
• adding to the previous question, Mike said governments could take this up: as they use a lot of open source software and are paid with tax money, why not spend some of their resources on contributing accessibility improvements (as in: code) back to the open source projects they use?
• in procuring websites and CMSes, is it sufficient to ask for WCAG compliance? Mike suggests to ask more questions than that, see his Accessibility Contracting Best Practices
• what’s the role of ATAG in this? Mike said we give content editors a lot of power, but not enough guidance. Implementing the B part of ATAG in CMSes can help here. It does seem harder to do than WCAG, he said, because the effects of (and investment in) ATAG improvements are much earlier in the process, they are about what it’s like for the content editor and how they are encouraged.
• Mallory, in the audience, mentioned the work that Greg Whitworth is doing on standardising form controls, people were excited for the potential of this project to make one common accessibility issue go away
• we talked briefly about Dragon Naturallyspeaking, an assistive technology that is often forgotten about when testing the accessibility of user interfaces

It was an interesting and constructive evening, with many experiences shared and plenty to think about. It’s clear that CMSes can play a huge role in making the web more accessible. One the one hand, for end users of the web: by encouraging and explaining content editors, implementing automated checks and high quality HTML output (this depends on many things, like templates used and also the very nature of WYSIWYG). On the other hand for content editors, by being usable for content editors with disabilities.

---

Originally posted as Managing accessibility in open source CMSes: a write-up on Hidde's blog.

Reply via email