Drupal 7 still remains the most accessible open source CMS available. The changes that the community began implementing in 2008 to improve accessibility for the entire user interface (public, content editor, administrator and developer) has still not been matched by any other piece of web software (open source or proprietary). By focusing accessibility efforts on improving Core, we are able to fix accessibility problems by default regardless of what themes, or extensions are used in any given implementation.

That being said, Drupal 8 is already considerably better, and not just because we removed Overlay.

ARIA and HTM5

One of the big enhancements that will be evident is a broad adoption of HTML5 and Web Accessibility Initiative's Accessible Rich Internet Applications Suite (WAI ARIA). Neither standard was mature enough to bring into Drupal 7, but we are happy to see their adoption in Drupal 8.

With the adoption of TWIG, pretty much all of Drupal’s HTML has been reviewed and brought up to current HTML5 standards. We’ve added DETAILS and replaced many places where FIELDSETS were used inappropriately to expand/collapse form elements. We’ve also added the phone number field type so that tel: links are now properly supported. HTML5 also provided a required element which is adopted in Core. There are other HTML5 attributes which have been added, but these provide the greatest benefits to users of Assistive Technologies.

It was also clear that when we added elements like DETAILS we needed to re-purpose FIELDSETS so that they could be used semantically without adjusting the design of a web form. One of the biggest accessibility problems in Drupal 7 was that we couldn’t effectively manage multi-part forms (radios and checkboxes).

WAI-ARIA provides an opportunity to add a wealth of semantic information to a web page. The simplest addition we made was to adding ARIA Landmarks to Bartik and Seven. We also added ARIA roles to Core blocks,status messages. We added the ARIA attribute aria-invalid to proactively alert screen reader users when there is a problem. We used the ARIA attribute aria-sort for tables to add additional context. We are also automatically adding aria-describedby links to form elements when they have related descriptions.

One of the biggest steps for ARIA though is the addition of an ARIA Live Announcements API. Simply by centralizing functions like this it will make it so much easier for a consistent, predictable aural experience.

Continuing Improvements

Simply by using Drupal 8 you will get so much useful HTML5 and WAI-ARIA from Core. Because these best practices are built into Core, new Drupal 8 themes are going to look at the best practices adopted here and emulate them. Some things, like the font size of PRE is in many ways pretty trivial, but how many times have we found font sizes of particular elements too small to be easily readable.

There has been a whole set of changes to increase the semantics of Core. Everything from using buttons rather than themed links where appropriate to ensuring that we are continuing to use headings properly for list elements and blocks. We’ve also pushed our breadcrumbs to be even more accessible, knowing that they are a critical piece of site navigation. We’ve also seen big improvements in Comments and Book pages.

We didn’t really get an opportunity to look at color contrast in Drupal 7, but are happy to say that we’ve found a number of places where we can enhance Core. From the Toolbar, to the * required red. We’ve added colouring a better description to passwords and also tightened up the consistency in the use of colors especially on the admin side.

I do find it really amazing how much work has gone into properly removing the CSS display: none; properly in Drupal. This isn’t a poorly spent effort, and in fact I’m surprised that other CMS’s still haven’t picked up on this. Fortunately the HTML 5 Boilerplate’s CSS did, and even expanded on it to include a fourth class, “invisible”. In an effort to build to broader standards, Drupal has adopted these names: hidden, visually-hidden, visually-hidden.focusable and invisible. But browsers are always changing, so we’ve addressed problems with Firefox, Safari and on the iPhone.

A few other pieces which I expect users will notice, but that they may never know about. We are now using fieldsets on the advanced search form, which is commonly enabled in most Drupal sites. You could always override the output of the aggregator module, but now by default links are presented in context much like other elements which were brought in for Drupal 7. Also, main content links are now underlined by default.

Going Big

The adoption of the HTML5 Boilerplate is one example of Proudly Invented Elsewhere, another is doing more to leverage jQuery UI. Although there were big reasons to proceed this, it allowed us to implement an accessible and reusable modal dialog infrastructure for Drupal 8 Core. Having Drupal leverage jQuery UI provided an extra push for the jQuery UI team and also additional resources to help with testing and development. The jQuery team was also able to repurpose our approach to autocomplete, so we could just stop supporting a Drupal specific approach.

Internationalization is really important both for WCAG 2.0 AA as well as for the Drupal Community. As with Drupal 6 and 7, Drupal 8 is making multi-lingual websites even easier. This is very important for most institutions around the world. Making multi-lingual sites accessible is a bit more complicated as you need to embody languages in content and links. We fixed the complication where you could be browsing a node in one language (English) that is embedded in a site which is expressed in another language (French).

Users may see fewer images without alt text because administrators now have the ability to force alt text for uploaded images. This is one step in making Drupal also Authoring Tool Accessibility Guidelines (ATAG) 2.0 compliant. Another big one is Drupal’s new TabbingManager which automatically handles simultaneous tabbing constraints: it stacks them. Drupal 8 needed a way to manage complex tabbing constraints due to advanced features like in-place editing which will provide a big usability advantage.

The next issue will comment specifically on accessibility features which are improving the admin side of Drupal. Given the range of disabilities and the vast number of people using Drupal, it seemed simply ridiculous to exclude people with disabilities from editing, administering and developing with Drupal.