Click here to watch Drupal without barriers -- accessibility is about access and enabling.

I've always been interested in topics of accessibility, but frankly, I always felt too overwhelmed by technical specifications, over-complicated examples and dogmatic specialists who demand nothing less than development purity.

At the end of 2012, while working on Drupal 8 core issues, faced with the Accessibility Gate, I decided to get over my fear. I installed ChromeVox and for the first time listened to Drupal. After a few days of tinkering with Toolbar I realized that accessibility is fundamentally just holistic interface design and development. We wouldn't build a form without a submit button, but render that submit button as a span tag with a JavaScript submit behavior and it is invisible to a screen reader.

Drupal 7 is quite impressive in its support of accessibility. It is easier to use than Drupal 6 and under the hood, the theme-layer markup is largely semantic and well qualified with ARIA properties. For content-driven, mostly static pages this level of support is adequate.

The direction of the web has been and continues to be towards dynamic pages and single-page applications. Describing the state of the page on delivery is no longer sufficient. We need to update our UIs structurally to represent the state of our pages. I will venture a guess that many of us mentally conflate the representation of application state (the model) with the visual UI (one of the views).

In order to really address accessibility, one of the things we need to do as designers and developers is tease the representation of state out of the visual UI and render it through markup. In this way, both our visual and aural UIs (and perhaps other modalities) will be driven from this common model -- the markup.

We have pieces of this already: an abstract theming layer for markup; a presentation layer for CSS; a JavaScript layer for behavior. Drupal module and theme developers have robust tools to build strong visual UIs. We lack common tools to express page state through non-visual modes.

What we've begun to build in Drupal 8 are the tools to build robust aural UIs. These include using Backbone models to drive visual and aural views and a method 'Drupal.announce' that will read aloud strings passed to it. We're working on a tabbing management utility that will better express salient elements of a page when a user begins a task flow.

My goal is to build a transparent, easy-to-implement and perhaps somewhat automatic aural presentation layer, like the visual presentation layer, that core and contrib can leverage.

To do this, we need to be diligent about separating state from presentation. We need to understand that accessibility is a synonym for universal access. We need to design UIs that express our content and applications through multiple modalities. We need to become comfortable with testing our pages with screen readers.

Most of all, we need to relax and let go of the fear of getting it right on the first try. I want Drupal 8 to have the tools to let contrib experiment so that when the Drupal 9 release cycle spins up, we will build aural and visual UIs along side each other.

In this session, we will spend some time brainstorming what additional tools we might need. Ideas will be recorded and translated into issues.

Slides

A persistent link to the slides for this presentation.

Notes

A persistent link to the notes that will be developed during this conversation.