In Part 1, I mentioned Authoring Tool Accessibility Guidelines (ATAG) although most of the analysis here will be geared to achieving Web Content Accessibility Guidelines (WCAG) 2.0 AA. Drupal is both about web content and the process of authoring that content and ATAG 2.0 is about both. For the most part we’ve looked at seeing that the admin side of Drupal is as accessible as the public facing components. The interface also has a strong role in producing better, more accessible content. Being able to force alt text for images is a part of this, but it is just the beginning.

Many of the elements mentioned in Part 1 will also be present on the admin side. For instance, we’ve adopted similar approaches to both Bartik & the default admin theme Seven when it comes to ARIA & HTML5.

Administering any CMS, you are ultimately navigating web forms to manage the content. We’ve done lots of little things to clean up the accessibility of the admin side from silencing the “*” for screen readers to adding missing titles. There are lots of places where LABELS were used for markup rather than as a semantic relationship, and we’ve fixed most of those now (see 1811216, 2044521, 1932068 & 882666). We’ve also enlarged the font size for things like the table sorting link so it is easier for people who have mobility challenges to find and use.

We also cleaned up the accessibility contextual links (849926 & 1905340). Removed blank table headers, fixed up file uploads so that screen readers get some notifications and made sure that parents didn't show up if there were no child elements present. dealing with parents. Lots of little items like this have been cleaned up throughout the interface, but since the understanding about web accessibility has grown so much Drupal 8 contributors it is a lot less than it used to be. Accessibility is talked about by much more than the accessibility team.

These forms ultimately encourage content authors to follow best practice in the creation of their content, including web forms. By using Drupal properly and following the examples in Core it will be much easier for everyone to create accessible content by default, an important part of ATAG 2.0 AA compliance. A simple example of this is that we expanded the allowed filters in Drupal 8 to encourage users to use HTML headings in the default Filtered HTML text format.

On the admin side we made internationalization more accessible by improving the String Translation UI and ensuring that the original language is set semantically. We have also allowed the ability to synchronize alt and titles text for multi-lingual images. Most of the other accessibility challenges with multi-lingual sites are then just taken care of when the content is presented to the users. A great illustration of ATAG 2.0.

As with the public facing links, we have continued to ensure that the “purpose of each link can be determined from the link text alone” and have done so both in the Forums as well as with the main Add content links.

We increased the maximum allowed text size for alt and title strings to be 1024 characters allowing for more complex descriptions of images. Although not in Core yet, through CKEditor it is possible to add longdesc links for other images.

jQuery UI’s modal dialogs are used all over in the admin side and are a great example of the Proudly Invented Elsewhere concept, as is the adoption of CKEditor. Serious work went into choosing which WYSIWYG editor went into Drupal 8 and accessibility was a big component of the decision. With that we get a lot of accessibility gains as IBM and others have worked to improve CKEditor’s accessibility over the years. With Drupal we have improved our own configuration pages so that it can be administered with people using assistive technologies. We will also get benefits from accessibility enhancements made to CKEditor, like the Language of Parts improvements which are scheduled for a 4.3 release.

Views. The most powerful module in Drupal 6 and 7 got brought into Core. With that it got cleaned up a great deal, particularly for it’s accessibility. Now it is even easier for administrators with disabilities to use this incredibly powerful query engine. There were a bunch of basic improvements like:

• moving to jQuery UI’s modal dialogs,
• clean up of empty headers and adding missing ones
• Removing duplicate ID’s
• Fixing color contrast
• Cleaning up sort order semantics

None of these will affect the output of Views, but there were also improvements to the output as well. The mini-pagers in views needed a header and additional context to understand the purpose of the previous/next links. This brings it up with the accessibility levels for pagers in the rest of Drupal Core.

The tables are also significantly improved as there is now proper id/header semantics included by default. This makes it easier for users to know where they are on large data tables. To keep up with data tables in HTML5 we have had to add captions and descriptions and removed the summary element for tables. Having this ability to control the captions and descriptions of tables is a really strong advantage for Drupal.

Another nice element is that many core admin listing pages are being migrated over to Views, so that this semantic presentation is available for many of the lists that are required critical for Drupal 8.

Plug: I will be presenting about the Drupal Accessibility Advantage at 7am ET (May 15th) as part of Inclusive Design 24. There will be 24 such videos, one for every hour of Global Accessibility Awareness Day. These videos should be available in the future for those who miss tomorrow's presentation.