Performance & Accessibility: Let's Open Source That
Update, 2/3/2017: Damien McKenna started an issue on Drupal.org about adding an accessibility tag or rating to Drupal projects. Thanks, Damien!
I'm dashing this off because I just read Ethan Marcotte's post "Free, faster". In his post, he's talking about a problem that we deal with all the time in our work with nonprofit organizations. And due to the political climate, we're dealing with it even more than usual right now.
The problem is that many nonprofit organizations need a website, but many cannot afford the cost of a complete design process and ground-up custom front-end theme build. So many organizations reach for an "off-the-shelf" pre-made theme that they can customize themselves, or with limited help from a designer and/or developer. This is particularly common in WordPress, where there is a robust off-the-shelf theme marketplace. But it also happens in Drupal, too.
The trouble comes when, as a front-end expert, one starts examining these off-the-shelf themes more closely and finds they vary greatly in quality. I'll share here what Ethan found:
On one of these projects, the client had picked a dozen or so prospective themes, which I offered to audit. While most of the designs touted their responsive layouts, they often had a raft of issues on devices that were older than a year or so. ...
Equally troubling was how slow most of these themes were. ... [On] a 3G connection, the slower themes I tested took anywhere from 45-90 seconds for any content to appear. In other words, the pages took roughly a minute before they were usable. From that point, additional code would continue to download from that point, adding to the already-high cost of downloading that page over a metered data connection.
Nonprofits often want to have websites that are accessible as possible to all their users, including those who may not have desktop computers, people who may have mobile data plans with expensive caps, people who may have low vision or use screen reader software, or who may not be able to use a mouse. Quality code, including semantic HTML, progressive enhancement, and responsive layouts are all essential ingredients in keeping websites accessible.
Unfortunately, nonprofit organizations are often the least likely to be able to afford to pay specifically for accessibility. How do we usually deal with this? At DevCollaborative, we constantly work on baking best performance and accessibility practices into everything we do. We don't always get it right, or even close to AAA perfect, but we try to start from the best possible place. In our Drupal 7 work, that means we've standardized our custom builds on community-vetted and tested base themes that prioritize semantic markup and accessibility.
Now that we are starting more Drupal 8 and WordPress work, and getting more requests from organizations who really could benefit from a cheaper, quicker, pre-baked design in any platform, I'm once again researching accessible starting code, for both new custom Drupal 8 work, and off-the-shelf projects in both platforms. And it's a jungle out there. Drupal 8 is new, and the WordPress theme scape is massive. Ethan suggests this fantastic idea:
Many of these CMS themes and plugins are distributed through galleries and marketplaces. For example, WordPress has their own official Theme Directory and Plugin Directory, but there are many, many third-party clearinghouses out there. I’d love to see performance added as a ranking factor on these sites, even if it’s to flag “fast” themes/plugins against “slow” ones.
I'll take that a step further. I'd love to see both of these open source platforms, as well as their theme marketplaces, add performance and accessibility rankings as standard. This would provide an true open source opportunity for those who can afford to build for accessibility, or for those who have the time and expertise to test existing code, to share what they find back with the community. It would be incredibly valuable for me to look at Drupal and WordPress themes (and modules, and plugins, for that matter), and to filter and/or sort them on accessibility and performance so that I can better advise and build for nonprofits of all sizes.