A lot has been made and said about the accessibility orientated improvements being delivered in Drupal 8, so much so in fact I got quite excited about having a look for myself and exploring some of these areas of enhancement. Admittedly I approached it with some scepticism, having seen the state of Drupal 7 and the need to constantly add a re-work module I wrote (Accessibilty_remedy) to correct form markup as its major focus amongst other fixes. Plus I am quite picky with regards to what some developers consider as to be acceptable approaches to accessibility, namely that doing enough to hit a series of automated checks to meet a named standard. To add a little context I am an avid endorser of good accessibility practices, for reference read my post on 'Accessibility in the Real World: Top 6 Automation Misses'.
The initative for Drupal 8 has been promoted as adding advancements in Drupal core to follow World Wide Web Consortium (W3C) guidelines: WCAG 2.0 (Web Content Accessibility Guidelines) and ATAG 2.0 (Authoring Tool Accessibility Guidelines). Lets take a quick look at some of the most signicant improvements in Drupal 8, and what they may actual mean to your project.
Contrast Improvement
The first touchpoint we will look at is the improved contrast ratios in core themes so people that suffer with difficulties with colour are able to view content more clearly. Whilst there is no argument that this is a worthy step forward, I would suggest for your project this has little relevance, as I am sure you will have you own custom themes and colour palette, the key factor here is ensuring that your own work follows the same minimum standard. For more information See the related WCAG 2.0 section about contrasts.
'ALT' text form image fields, (But no Captioning for video media)
The next touch point to look at is alternative text for images. This is really useful for people who use screen readers or other assistive technologies to understand the context of any images presented. They can understand the meaning of an image through short descriptive phrases. The good news is this alternative text is now by default a required field in Drupal 8 for any image field. Personally I think this is a great step forward, but bear in mind that whilst making the alt text field mandatory will force content authors into adding alt text, it doesn’t necessarily mean that this text will add anything of benefit, I really do suggest a little education to these authors as to what compiles good use of alt text. For more information See the related WCAG 2.0 section about alternative texts.
Whilst we are working with assistive technology alternatives for media, maybe we should also go the extra step and enforce captioning and transcripts on video media usage too? Just a thought.
Improved and more Semenatics
Many accessibility improvements are hard to see as it involves semantics. Drupal 8 uses HTML5 elements in its templates which add more meaning into the code. For instance, assistive technology such as screen readers can now interpret elements like <header>,<footer> or <form>. Additionally, WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) extending markup really improves semantics using:
- landmarks to identify regions in a page, for example: role="banner" ;
- live regions to indicate that an element will be updated, for example: aria-live="polite";
- roles to describe the type of widgets presented, for example: role="alert";
- properties: attributes that represent a data value associated with the element.
See the related WCAG 2.0 sections about semantics. As with colour contrast improvement, this improvement is only as good as your own custom theme or modules, ensure that these additions don’t get lost, or worse still used incorrectly in your own theme. This correct usage is vital for the WAI-ARIA semantics, as some mis-use here would actually be a negative influence on your actual end user interacting with your site.
Tabbing Order
Drupal 8 introduces a TabbingManager javascript feature. It enables to constrain tabbing order on the page and facilitates navigation with keyboards. It is really helpful to guide a non-visual user to the most important elements on the page and minimize confusion with screen readers. For project usage this is great, but doesn’t get the past that tabbing order should be natural and not forced, thinking about the logical sequence of content of the page and how a user would expect a tabbing sequence to work should make this a little redundant, or if used to bring more salient objects of the page into focus, then perhaps considering what information are captured in these, and is the usages of such components the best solution, more times than not the capability that TabbingManager brings are a 1p fix for £1 problem. See the related WCAG 2.0 section about keyboard operations.
Forms
This is the big topic from my interests point of view, knowing that Drupal 7 really struggled making accessible forms. Drupal 8 accessibility involves many improvements regarding forms in Drupal 8.
Starting with error handling, in Drupal 7, all errors were displayed by default on top of the form and fields were highlighted in red, this made it difficult for people with colour awareness issues to understand where the errors were. In Drupal 8, there is an experimental module option to enable form inline errors and an error icon is displayed next to the field. Nevertheless, note that this feature is not enabled by default as there are still some pending issues. The error message is displayed below the field when the Form Inline Error module is enabled. See the related WCAG 2.0 sections about error identification.
Whilst the positioning of inline errors is a great step forward it only really serves half the problem when handling form errors with assistive technologies, in an ideal world we also need to consider that unless you have used some fancy JS to submit the form, the entire webpage has re-loaded, how does a user of assistive technology know the form submission has an error, we should be looking at pre-pending a statement to the page title (browser title), to say an error has occurred as this is usually the very first thing assistive technologies present to their users. Next, without the user knowing what fields have an error without navigating through each one, having inline form errors is ok, it would be better if the placement of the message is not after after the label and input serving the error, but we still need an identifier at the start of the form declaring which elements require further attention, ideally these indetntifiers would be linked directly to the input in question. Whilst this is being disucssed as a super accessibility improvement, it is also great for mobile users where the form may not be immediately in the view portion of the screen.
Regarding the form API changes, radios and checkboxes are now embedded in fieldsets to meet WCAG compliance. HOORAY!!! Indeed, grouping related elements will help screen readers to navigate in complex forms. Plus, all fields have a label associated with the right element using the “for” attribute. Now all thats left is to stop people using fieldsets for presentation purposes grouping fields togeher, but that cant be a coded solution, back to Accessbility Education 101. 
See the related WCAG technical section about fieldsets. I have to say this is the biggest bug bearer I have with my fellow developers, if I had a £1 for every time I have seen a fieldset mis-used id be able to buy an island, well maybe not an entire island, or even a car, more likely a really fancy ice-cream.
Tables and Views
As Views UI module is in core now, it had to become more accessible, thats a cold harsh statement thats needed including. The views tables markup is more semantic. Data cells are associated with header cells through “id” and “headers” attributes. It is also possible to add a <caption> element to explain the purpose of the table and a <summary> element to give an overview on how the data is organized and how to navigate the table. Plus, the “scope” attribute enables to explicitly mark row and column headings. See the related WCAG section about tabular information.
I would really class this improvement as significant, tables are notoriously hard for screen readers to interpt the data within the tables to the user, a factor made more complex if the structure of the table becomes more involved. This is a 10/10 improvement that you will inherit for free.
Hidden Elements
Drupal 8 has standardised CSS classes in the naming convention of HTML5 Boilerplate using different classes to hide elements:
- “hidden“: hide an element visually and from screen readers;
- “visually-hidden“: hide an element only visually but available for screen readers;
- “invisible“: hide an element visually and from screen readers without affecting the layout.
It is vital that the usage of these is correct and consider when this class is being applied, for example a span with 'visually-hidden' within a label will still be read by a screen reader, and is really useful for adding some context to your label. For your project you now have a 3 classes available to standardise your output with, I would hazard a guess that the more accessibility conscious developers already use these or something very similar that deliver the same result, great work getting this cinluded in core though.
Aural Alerts
Users with visual impairment that use assitive technologies will not be able to see all visual updates of the page such as colour changes, animations or texts appended to the content. In order to make these changes apparent in a non-visual way, Drupal provides the Drupal.announce() JavaScript method which creates an “aria-live” element on the page. This way, text appended to the node can then be read by am assitive technology user agent. See the related WCAG technical section about how to use live regions to identify errors.
This is a great addition in Drupal 8, I wonder how long it will take developers to pick up on it as the front end gets ever more interactive.
To summerise
Drupal core maintainers have accomplished great enhancements regarding accessibility in Drupal 8. These accessibility features will definitively be beneficial to keyboard-only users, low-vision users and colorblind people and will also be good for the usability and the SEO of your website.
That said a lot of the things they have done could be extended more (especailly form error handling and media related supporting fields), the quick wins seem to have been captured and delivered well, others are very precise improvements, some of which will be lost once you have deployed your own theme and/or custom modules that generate their own markup.
For the record I am yet to release a Drupal 8 site to the masses, my work in this new version is either for training and business development reasons, or my own personal intrugue. Things may and hopefully will continue toi evole in the right way.
Share this Blog with colleagues
