When it was released in 2011, Drupal 7 was the most accessible open source content management system (CMS) available. I expect that this will be true until the release of Drupal 8. Web accessibility requires constant vigilance and will be something that will always need attention in any piece of software striving to meet the Web Content Accessibility Guidelines (WCAG) 2.0 guidelines.
This has been useful for many organizations that, for legal, economic, or ethical reasons, want to make their sites as accessible as they can be.
What makes Drupal different from most other CMSs is that the focus has been on improving Drupal Core’s accessibility on all levels (public, content editor, administrator, and developer). Fixing problems in Core allows us to fix accessibility problems at the source, and they propagate by default to themes and modules that are used.
Adding more semantics
The biggest accessibility enhancement is about additional semantics in the form of HTML5 and WAI-ARIA. Used properly, both add context that can be useful for users who use assistive technology. We have added ARIA landmarks and roles. There is also now a central means to leverage aria-live so that a screen reader can be alerted when dynamic content on a page is updated without a page reload.
One of the common problems in Drupal 7’s forms were that multi-part checkboxes and radio buttons weren’t properly wrapped in a <fieldset> element. In Drupal 8, this has been brought into the Forms API so that these elements are properly grouped together.
Drupal is known for being strong with internationalization, but creating accessible multi-lingual sites is a real challenge! Fortunately, Drupal 8 has done a lot to add semantics to its extended language support.
Little things add up
There were lots of little changes that were made to font sizes and color contrast to make sure that Drupal 8 themes meet with the WCAG 2.0 AA guidelines.
One big challenge in many user interfaces is making sure that the purpose of each link can be determined from the link text alone. When working with limited space on the page, it’s difficult to accomplish this for many CMSs. Drupal added this by default in Drupal 7 for some content but has extended this further in Drupal 8, and we are leveraging a common set of visually-hidden CSS classes.
Consolidation
There has been an initiative to seek out other open source code to adopt in Drupal. This has been called Proudly Invented Elsewhere, and it has had a big impact both on Drupal 8’s accessibility and the accessibility of other projects. The Drupal community pushed jQuery UI and CKEditor to improve their accessibility before adopting their code.
In Drupal 7, we decided to centralize functions such as how we address accessible alternatives to CSS display:none;. At about the same time the popular HTML5 boilerplate did the same. In Drupal 8, we chose to rename our CSS classes to the more commonly used "visually-hidden" so that it would be easier for themers who are already familiar with that convention.
Another big enhancement in Drupal 8 is a centralized tabbing manager. Websites are becoming increasingly complicated, and for keyboard only users, there needed to be a way to stack the tab order to manage this. We are using this on the back-end, but it will be available for all modules and themes that want to be able to ensure that the tab order is logical.
Authoring tool
It is important to remember that it’s not just our users that may have disabilities. Especially with an aging generation of boomers, accessibility is a concern for people in all levels of an organization. Drupal’s commitment to remove accessibility challenges in the admin level is huge. This also puts this CMS in a great place to address the new accessibility standard Authoring Tool Accessibility Guidelines (ATAG). ATAG is largely about helping content authors produce more accessible content.
We’ve done some simple things in Drupal 8 to help us conform to ATAG. An administrator can now force image uploads to include alternative text. We’ve also opened up the HTML headers in the default filter to encourage editors to create more structured content. Ultimately though, it is mostly because of how Drupal is structured that we are able to help authors produce more accessible content using this interface.
Views!
One of the biggest wins for Drupal 8 is that Views has been brought into Core. Views is the most popular and powerful contributed module in Drupal 7, so it was terrific to see it incorporated in Drupal 8. This is a big accessibility win for Drupal administrators as well as end users. Views UI has been cleaned up to make it much more semantic, but we’ve also added accessibility improvements for table views. Tables now support both HTML5’s caption and description elements, as well as having proper id/header semantics for each cell.
Now, there’s still more that needs to be done and will hopefully get into Core before the first release of Drupal 8, but that being said, it is now a long way ahead of the nearest competition. Because Drupal is modular, modules and themes that are built on the new API will inherit many of the best practices we’ve built into Core. Keep in mind that any of these extensions could override a best practice, so there will still be work to improve the accessibility of Drupal 8 community contributions. But the community standards are set in Core and most modules will follow them.
Start experimenting with Drupal 8
If you’re keen on accessibility and want to try out Drupal 8, an easy place to begin is http://simplytest.me/project/drupal/8.x where you can also use that to test any of the Drupal 8 contributed modules on http://drupal.org.
There are some great ways to begin experimenting with Drupal 8 and contributing to it now. What the Drupal community has done is still pretty unique, but it is certainly something that other open source projects can learn from and adopt.
3 Comments