Drupal Speaks

Aural user interfaces and how we're making Drupal 8 the most accessible CMS in the world

Jesse Beach
Senior Front End Developer
@jessebeach

Wim Leers
Senior Software Engineer
@wimleers

[Wim] Hi I'm Wim Leers.

[Jesse] And I'm Jesse Beach. I work at Acquia on the Spark team as a front end developer.

This is a session about making data and interactions accessible everyone.

[Wim] So we're talking about accessibility, right?

[Jesse] Yes, but first I must admit that I am not an accessibility expert.

[Wim] And neither am I.

[Jesse] What we are, are two front end developers with a passion for beautiful, usable and delightful UIs. And given that all of you out there — front-end developers, usability experts, UX designers, back-end developers, doc writers, community organizers — of course feel the same way, then we are all, therefore, concerned with accessibility. Because accessibility is about creating rich experiences for everyone.

[Wim] A rich experience is one that anyone, regardless of the range of their abilities, finds satisfying. That means, given a task, they can understand what actions they need to undertake, how to undertake them, what the results of those actions are and that the task completed successfully or not.

[Jesse] A rich experience is also one that provides awareness of possibilities and constraints, because as humans, we don't always know what we want to do until we've explored a bit.

[Wim] We find inspiration through interaction and that is what a rich UI does, it inspires and encourages.

Isn't Drupal accessible already?

As an inclusive community, we are committed to making sure that Drupal is an accessible tool for building websites that can also be accessed by people with disabilities.

We have an accessibility checklist

http://drupal.org/node/465106

All non-text content has alternative text
All data tables have headings
Users can complete and submit all forms
Links make sense out of context
Media has captions and/or transcripts
Non-HTML content is accessible
Users can skip repetitive elements on the page
Meaning is not conveyed through color alone
Content is clearly written and easy to read
JavaScript is accessible
The site complies to standards

We have accessibility tags for issues

+needs accessibility review

+needs color accessibility review

+a11y

Accessibility pledge

#D7AX

#D8AX

I pledge to make this [module or theme] as accessible as it can be. If you find any flaws, please submit an issue [link to issue queue]. Help me fix them if you can.

Accessibility tools and best practices

Accessibility pledge wiki

Interfaces give us access to information

Interfaces are sensual

Visual
Aural
Tactile
Every sense but taste and smell (so far)

Interface !== Visual

Oh crap! Screen readers! Put in alt attributes!

Visual is not primary

What is accessibility?

Accessibility is the foundation of usability

Three levels of doing accessibility

The markup - automated testing
The ux - behavioral testing
The content - real-time feedback

QUAIL

Accessibility Information Library

Unleash the robots

Automated testing

Codify best practice

Accessibility module

Behavioral testing

...or, check your ego.

DrupalCamp Twin Cities testing sessions

Study findings

“Fairly accessible for speech/ keyboard for content consumption.”
“I was able to complete tasks using only my keyboard”
“That was truly a pain free testing experience.” using Dragon NaturallySpeaking11 Professional

Session recording highlights

Testing content creation in Drupal

01.00.00
01.01.00

Issues about form validation that we discovered during the testing

Aural user interfaces

Drupal Speaks?

You betcha!

Let’s have a listen

Why consider speech output?

Isn't semantic HTML enough?

Tour module tooltip markup


<div data-index="0">
  <div role="dialog" aria-labelledby="tour-tip-views-ui-displays-label" aria-describedby="tour-tip-views-ui-displays-contents">
    <h2 id="tour-tip-views-ui-displays-label">Displays</h2>
    <p id="tour-tip-views-ui-displays-contents">A view can consist of multiple displays.</p>
    <div class="tour-progress">1 of 10</div>
    <a href="#" class="joyride-next-tip">Next</a>
    <a href="#close" class="joyride-close-tip">X</a>
  </div>
</div>

The accessible-to-usable scale

In trying to determine the scale of the effort to bring the aural experience of Drupal's interface up to the same level of polish of the visual UI, we wanted to understand just how far apart they might be.

So we put together this chart that plots the visual and aural UI experiences from a lower bound of inaccessible (a value of 0) to an upper bound of delightful interaction (a value of 4).

We might say that the visual content consumption experience of Drupal ranges from 2.5 to 3.5.

The visual site administration experience ranges from a 2 to 3.5

The aural content consumption experience ranges from 1.5 to 3

The aural site administration experience ranges from 0 to 3

We propose that the aural site administration experience -- managing content, managing views, configuring a site -- has the most variability in experience within Drupal.

As developers, we have tended to focus our accessibility improvements on static markup which is important, but it's only half the story.

We want to pull the lower bound of the aural UI experience at least up to accessible for all administrative pages and push the upper bound closer to delightful.

Accessibility for everyone

dynamic applications undergo state and property changes.

those changes must be expressed

we build interfaces

for everyone

so how do we do it?

show and announce the changes

Rich experience for everyone

ARIA

Accessible Rich Internet Applications

So let's move from our brief introduction to accessibility in Drupal to the work currently underway to make it even better.

[Wim] Modern UIs are complex. As we introduce just-in-time information and dynamically updating pages, we also introduce new design patterns to express to the user that their page contents have changed: spinner icons, quick flashes of color, shifting boxes, fade in effects. Almost exclusively, these indicators are visual. While we were helping to improve authoring experience tools for Drupal 8, we realized that Drupal is, too, evolving into a complex and dynamic front end application. That we need to express to the user when and how their interface has updated. And that we need to do this within Drupal's guidelines. We can't only express updates visually because for users who are blind, our UIs are frustratingly silent about what's going on.

We use ARIA attributes to represent through markup what you are accustomed to representing through visual language.

States like

active
disabled
pressed

Properties like

label
form
dialog

In this video we show the following snippet of code change when the user clicks the Menu button in the Drupal 8 toolbar.


<a href="/admin" title="Admin menu" class="icon icon-menu toolbar-tab" id="toolbar-item--2" data-toolbar-tray="toolbar-item--2-tray" aria-owns="toolbar-item--2" role="button" aria-pressed="false">Menu</a>

The aria-pressed attribute toggles between false and true as the button is toggled off and on.

ARIA-Live

Describes an HTML element that reads its contents when those contents are altered.

<div aria-live="polite" class="element-hidden">
  some text to speak
</div>

Express changes aurally

Drupal.announce


  // Pass a string.
  Drupal.announce('The application has been updated.');

  // Make sure the string is translatable.
  Drupal.announce(
    Drupal.t('The application has been updated.')
  );


<body>
  ...
  <div id="drupal-live-announce" class="element-invisible" aria-live="polite" aria-busy="false">The application has been updated.</div>
</body>

Quick successive calls

<script>
// Quick successive calls will concatenate.
Drupal.announce(Drupal.t('Freegan before they sold out polaroid.'));
Drupal.announce(Drupal.t('Pitchfork letterpress polaroid four.'));
Drupal.announce(Drupal.t('Cardigan cosby sweater fanny pack.'));
</script>

<div id="drupal-live-announce" class="element-invisible" aria-live="polite" aria-busy="false">
Freegan before they sold out polaroid.
Pitchfork letterpress polaroid four.
Cardigan cosby sweater fanny pack.
</div>

Wait, doesn't this accessibility feature depend on JavaScript?

JavaScript enabled	Respondents
Yes	98.6%
No	1.4%

Source

WebAIM 2012 Survery

Guide the flow

Drupal.TabbingManager

Why Drupal.TabbingManager?

Depending upon the action to be performed by the dialog, the object with focus before the dialog box is opened should be saved. This will allow restoring focus to this element when the dialog box is closed.

http://www.w3.org/TR/wai-aria-practices/#modal_dialog

Managing tabbing is difficult

What?

Constrain tabbable elements to just those necessary to complete a task.

Overlay module

How-to: tabbing management

Using Drupal.TabbingManager.

Apply tabbing constraint

Using a core API rather than reinventing.

manageTabbing: function () {
  var tabbingContext = this.model.get('tabbingContext');

  // Always release an existing tabbing context.
  if (tabbingContext) {
    tabbingContext.release();
  }

  // Create a new tabbing context when edit mode is enabled.
  if (!this.model.get('isViewing')) {
    tabbingContext = Drupal.tabbingManager.constrain($('.contextual-toolbar-tab, .contextual'));
    this.model.set('tabbingContext', tabbingContext);
  }
}

Example from contextual.module.

[Wim] Let's first look at the code within the if-test at the bottom. That's where a tabbing constraint gets applied. We call Drupal dot tabbingManager dot constrain, with a selector for the elements that should be tabbable.
The constrain method returns a "tabbing context". Tabbing contexts are the building blocks that the tabbing manager uses to keep track of things. We store a reference to it.

Now let's look at the rest of the function. Let's start at the top. First, a reference to the existing tabbing context (if any) is retrieved. Then, if there indeed is a tabbing context, we release it. Finally, if the "is viewing" variable equals false, we apply a new tabbing constraint.

Looking at the whole, this method gets called whenever the "is viewing" variable's value changes (from true to false or vice versa). The existing tabbing constraint is always released. A new tabbing constraint is applied if the value for "is viewing" equals false, which means that the pencil icon (also known as "edit mode") is toggled in the toolbar.

Announce the details of the constraint

Using Drupal.announce.

announceTabbingConstraint: function () {
  var args =  {
    '@contextualsCount': Drupal.formatPlural(Drupal.contextual.collection.length, '@count contextual link', '@count contextual links')
  };

  Drupal.announce(Drupal.t('Tabbing is constrained to a set of @contextualsCount and the edit mode toggle.', args));
  Drupal.announce(Drupal.t('Press the esc key to exit.'));
},

Example from contextual.module.

Complex tabbing flows

Tabbing contexts can be stacked and popped as a user moves between task flows, even between modules.

[Wim] Something that Jesse and I found very important, is to ensure that multiple modules can each have tabbing constraints simultaneously, without running into problems. Otherwise, Drupal contrib would not be able to use the tabbing manager in practice.

For example: the user can navigate to the edit mode toggle in the toolbar, toggle it and then tabbing is constrained to contextual links. The user can then tab from one contextual link to the next, and open them. If the user were to start in-place editing from one of those contextual links, then the in-place editing functionality would apply a new tabbing constraint (that gets stacked on top of the previous one). When stopping in-place editing, the contextual links tabbing constraint will be applied again. (The in-place editing tabbing constraint was popped.)

Embrace modalities

Backbone.js

The essential premise at the heart of Backbone has always been to try and discover the minimal set of data-structuring (Models and Collections) and user interface (Views and URLs) primitives that are useful when building web applications with JavaScript.

Jeremy Ashkenas — http://ashkenas.com/backbonejs-1.0/

Framework doesn't matter

Separation of concerns matters

Before Drupal 8

event handlers ⟶ rendering ⟶ debug hell

Now in Drupal 8

events ⟶ state

state ⟶ rendering

developer ⟶ happy

A schema explaining the different components of Backbone. Relevant parts to us: data & state are modeled in Backbone Models. Backbone Models of the same type may be grouped in Backbone Collections if that is useful for the use case. Backbone Models are connected to Backbone Views via model event bindings, so that Backbone Views are able to update themselves whenever the data/state changes. A View is typically bound to a DOM element, within which it renders itself.

Source: http://kiranb.scripts.mit.edu/backbone-slides/

Example

function toggleEditMode (event, data) {
  for (var i = contextuals.length - 1; i >= 0; i--) {
    contextuals[i][(data.status) ? 'detachHighlightBehaviors' : 'attachHighlightBehaviors']();
    contextuals[i].$region.toggleClass('contextual-region-active', data.status);
  }
  }

versus

_toggleEditMode: function (event, data) {
  Drupal.contextual.collection.each(function (model) {
    model.set('isLocked', data.status);
  });
  }

How-to: Backbone.js for better accessibility

one model,
many views

Step 1: create a model

Contains state, is stupid. Views update it.

Drupal.contextualToolbar.Model = Backbone.Model.extend({
  defaults: {
    // Whether the toggle is currently in "view" or "edit" mode.
    isViewing: true,
    // Whether the toggle should be visible or hidden.
    isVisible: false,
    // A TabbingContext object as returned by Drupal.TabbingManager:
    // the set of tabbable elements when edit mode is enabled.
    tabbingContext: null
  }
});

Example from contextual.module.

Step 2: create a visual view

99.9% of sites need visual output & mouse + touch input.

Drupal.contextualToolbar.VisualView = Backbone.View.extend({
  events: {
    'click': function () {
      this.model.set('isViewing', !this.model.get('isViewing')),
    }
  },
  initialize: function () {
    this.model.on('change', this.render, this);
  },
  render: function () {
    var $el = this.el;
    var m = this.model;
    $el.toggleClass('element-hidden', !m.get('isVisible'));
    $el.find('button').toggleClass('active', !m.get('isViewing'));
    return this;
  }
});

Example from contextual.module.

Step 3: create a keyboard view

For screen reader users & power users: keyboard input.

Drupal.contextualToolbar.KeyboardView = Backbone.View.extend({
  // …
});

Unnecessary here: the click event in the VisualView already works with keyboard input. We don't need focus or blur.

Step 4: create an aural view

For screen reader users: aural output.

Drupal.contextualToolbar.AuralView = Backbone.View.extend({
  initialize: function () {
    this.model.on('change', this.render, this);
    this.model.on('change:isViewing', this.manageTabbing, this);
  },
  render: function () {
    var $el = this.el;
    var m = this.model;
    $el.find('button').attr('aria-pressed', !m.get('isViewing'));
    return this;
  },
  manageTabbing: function () {
    // See TabbingManager example.
    Drupal.announce('<a relevant, explanatory message>');
  }
});

Example from contextual.module.

All done!

Everything remains in sync!

Just like that.

Proposed best practice

Evolving as we develop more complex interactions

Devel accessibility

Not familiar with using a screen reader?

`console.log` announcements

Screenshot of devel_a11y's ability to log announcements via Drupal.announce to the browser's console.

Visualize tabbing constraints

http://drupal.org/project/devel_a11y

a UI is sight, and sound and touch

Drupal 8 will communicate with each sense

using shared tools and a structured framework

and your module?

References

Screen Reader User Survey #4. 2013. http://webaim.org/projects/screenreadersurvey4/
http://kiranb.scripts.mit.edu/backbone-slides/#compenents-diagram

Resources

http://previousnext.com.au/blog/so-you-want-be-accessible
http://squizlabs.github.io/HTML_CodeSniffer/
http://webaim.org/projects/screenreadersurvey4/
Pillow fight

How do we make aural UIs informative without being annoying?

Listening to long instruction sentences gets annoying if they don't introduce more info and just repeat the same thing on every page. Eventually, one might want to turn off these audio announcements.

HELP US IMPROVE

Help us improve Acquia products by taking part in UX research. Get a sneak peak at new Acquia offerings, try things out and give us your feedback.

And, we compensate our participants!

Studies are conducted remotely; no travel required.

Interested? Sign up at usability.acquia.com, contact us at uxresearch@acquia.com or find speak to Lisa Rex.

Drupal Speaks

Aural user interfaces and how we're making Drupal 8 the most accessible CMS in the world

Isn't Drupal accessible already?

We have an accessibility checklist

We have accessibility tags for issues

Accessibility pledge

Interfaces give us access to information

Interfaces are sensual

Interface !== Visual

Oh crap! Screen readers! Put in alt attributes!

Visual is not primary

What is accessibility?

Accessibility is the foundation of usability

Three levels of doing accessibility

QUAIL

Accessibility Information Library

Unleash the robots

Codify best practice

Behavioral testing

...or, check your ego.

DrupalCamp Twin Cities testing sessions

Session recording highlights

Issues about form validation that we discovered during the testing

Aural user interfaces

Drupal Speaks?

You betcha!

Let’s have a listen

Why consider speech output?

Isn't semantic HTML enough?

Tour module tooltip markup

The accessible-to-usable scale

Accessibility for everyone

dynamic applications undergo state and property changes.

those changes must be expressed

we build interfaces

for everyone

so how do we do it?

show and announce the changes

Rich experience for everyone

ARIA

Accessible Rich Internet Applications

States like

Properties like

ARIA-Live

Express changes aurally

Drupal.announce

Quick successive calls

Wait, doesn't this accessibility feature depend on JavaScript?

Source

Guide the flow

Drupal.TabbingManager

Why Drupal.TabbingManager?

Managing tabbing is difficult

What?

Overlay module

How-to: tabbing management

Apply tabbing constraint

Announce the details of the constraint

Complex tabbing flows

Embrace modalities

Backbone.js

Framework doesn't matter

Separation of concerns matters

Before Drupal 8

Now in Drupal 8

Example

How-to: Backbone.js for better accessibility

one model,many views

Step 1: create a model

Step 2: create a visual view

Step 3: create a keyboard view

Step 4: create an aural view

All done!

Proposed best practice

Devel accessibility

Not familiar with using a screen reader?

console.log announcements

Visualize tabbing constraints

a UI is sight, and sound and touch

Drupal 8 will communicate with each sense

one model,
many views

`console.log` announcements