You Won't Believe These 6 Drupal 8 Accessibility Improvements!

OMG Is this the most accessible CMS ever? These are some notes from a lightning talk I gave at NWDUG. You can find my slides here.

1 Simple Trick For A Javascript-free Accordion (jQuery Developers Will Hate You!)

Phil Wolstenholme / Via codepen.io

* The < fieldset> element is no longer being abused for JS-reliant accordion style expanding widgets on the node add/edit page. For expanding widgets, the HTML5 < details> tag is now being used.

* Details tag is very cool - an HTML5 accordion/ ’disclosure widget’, with no JS required. It’s keyboard accessible and is only 4 lines of HTML5. Avoids custom JS that can bring a11y problems with things like keyboard focus if not done properly.

* The element is currently only available in Chrome or Safari, but will be available in Firefox 49. there is no IE/Edge support at the moment. That said, polyfills are available for unsupported browsers and one is included in Drupal core.

* There’s more information on developer.mozilla.org and a CodePen demo here showing the default and custom styling that is possible.

Meet Single Labels In Your (text)Area

* Forms a big deal for making using your site accessible, especially aspects of labelling inputs and handling errors. D8 has improvements in both these areas.

* Orphaned elements have been removed. These were labels that were only included for visual reasons and were not linked to an associated input element.

* Orphaned labels can confuse AT as they read the label but do not have an input field to associate it with. Now there is a one to one (single…) relationship between labels and form elements.

* As well as improvements to label elements, errors are better labelled. Form validation errors can now be shown inline, underneath the invalid input element.

* Previously discussed in an issue queue from 2009 that had 265 comments but no resolution

* A second comment thread ended up at 600 comments . The feature was briefly included in D8 but caused regressions so was eventually included in D8 but as an experimental module.

* Moves away from using colour to communicate errors, which was a major failure and ACAG 2.0 violation of D7 forms.

* Also good for small screens, necessary info is inline rather than hidden at the top in the messages region.

The Headings And Field Labels They Don't Want You To See

* D8 has a new form label option for when you want to label an input element for the sake of AT users, but you (or your designer) think sighted users wouldn’t need the label, for example in a search form in the header with an obvious icon.

* There is a new ‘visually hidden’ field label formatter. This way, field labels can be included in a way accessible to AT, but invisible to sighted users. This saves us excluding labels from markup or using display:none; which makes the content unavailable to AT.

* This way, the form is announced to screenreader users with additional context, and the design is not affected for sighted users.

* The same CSS class is used for invisible headings to give AT users a bit more context, for example an invisible ‘Breadcrumbs’ heading before breadcrumbs, and ‘Navigation’ before menus.

Edit: see this caveat - Stable theme does not respect "visually hidden" field label display option

Can You Identify These Four WAI-ARIA Landmarks? [QUIZ]

* WAI-ARIA stands for 'Web Accessibility Initiative for Accessible Rich Internet Applications'.

* Not settled enough for D7 but was mature enough to be included in D8. ARIA attributes weren't valid XHTML, but they are valid HTML5.

* For containing elements without implied roles (nav, sidebar/aside, etc), default themes now use WAI-ARIA landmarks. These set points that AT users can jump to in order to navigate pages more easily. E.g. jumping to messages reason to find out why a form did not submit, or jumping to content regions while avoiding tabbing through navigation links.

5 Changes To Views UI That Will Give Assistive Tech Users The Feels

* Now part of D8 core, Views has come with big a11y improvements

* Now supplies caption and summary element for tables, headers now included, good for AT as some users can't scan a data table as quickly as others so summaries and additional context text is useful

* Mini pager is more semantic, current position is shown and the '1', '2' etc links are given more context for screenreader users.

* Other improvements like removing duplicate IDs, fixing contrast

* These changes have a large impact on CMS users as core admin listing pages are being migrated to Views, so are benefiting from the a11y improvements without additional work being required.

First You'll be Shocked, Then You'll Be Inspired: D8's Javascript Improvements For A11y

* jQuery UI is being used more in core than it was in D7. A11y work has been done on this project before it was added to Drupal, often by Drupal contributors.

* D8's Autocomplete feature is is now using jQuery UI rather than D7's homemade implementation. The new feature is vastly improved.

* The main improvement is for screen reader users. As they enter characters into the field the number of returned results is read out to them, and they can use the arrow keys to select a suggestion. There is a video demo including audio of this feature here.

* New Modal content API using jQuery UI is an a11y win as previously Drupal used a mix of modal approaches, Views own, CTools own, contrib modules own, etc. Now we use one standardised, proudly-invented-elsewhere option, which has strong a11y credentials and which will be maintained more widely than a homegrown solution would be.

* Drupal.announce() - API for text to speech, used for password strength indicator which is pretty cool, the user's password strength is read out to them as they type. This provides an audio equivalent of the red/amber/green meter for non sighted or color blind users.

* The function can be used to announce dynamic changes, for example additional content loading on scroll.

* Drupal.tabingManager - The tabbing manager tells keyboard navigation tools where to skip to next on the page. This is useful for when a user has started a task and you know that they will only need to focus on particular elements.

* In D8, this can be seen in the inline editing mode. When this is enabled, tabbing skips to the contextual edit links for each block/content item, bypassing other focusable elements on the page.

Thanks

Thanks to Andrew Macpherson for supplying some corrections to these notes and my lightning talk.