Web Accessibility
Techniques for Designers
and Developers

North West Drupal User Group
10th May 2016

Hi.

Andrew Macpherson

Senior developer at Annertech

Accessibility contributor at Drupal project

@MartianWebDev on Twitter.
Fuzzbomb on GitHub, and most other places.
We don't get to use cool handles on LinkedIn.

I love Drupal this much.

Photo of Andrew wearing a cheesy 1960s sci-fi space suit, made of neon pink and gold. His helmet is styled like the Drupal logo. The background is a photo-shopped outer-space landscape of mountains, planets and galaxies. One of the planets is the Drupal logo, a smiley face with an infinity symbol for eyes.

What is web accessibility?

UK government statistics estimate 11.6 million people
are living with some kind of disability in the UK.

  • Works for everyone, regardless of disability.
  • Works with varied devices, including assistive technology.
  • Remove barriers to participation.
  • Increase social mobility (c.f. the digital divide).
  • Related terms: universal design, inclusive design.

Who benefits? We all do!

Broad categories of impairments...

  • Cognitive impairments
    learning differences, distractability, dyslexia, ...
  • Hearing impairments
    deafness, hard-of-hearing, tinnitus
  • Motor impairments
    limited fine motor control, slow response time
  • Visual impairments
    blindness, low-vision, colour-blindness

Disability in Context

Disability isn't always clear-cut. It depends...

  • Mild to severe.
  • Permanent or temporary - broken wrist in plaster cast.
  • When acquired? During childhood, or later in life.
  • Environment - noisy places, bright sunlight, darkness.
  • Situation - driving a car, both hands-full.
  • "Visibility" - a wheel chair is apparent, dyslexia isn't.

Why am I telling you this?

More than two-thirds of screen reader users surveyed said a lack of awareness (43%) or skills (26.6%) were the primary reason that developers do not create accessible web sites.

Source: WebAIM Screen reader User Survey #6 Results

Who's responsible?

Web technologists

  • Designers - colours, page layout, interactive styles
  • Front-end developers - custom component behaviour,
    e.g. date-pickers, notifications, FancyMegaDropSearchBox
  • Information Architects - navigation, page outline, data models
  • UX designers - can everyone take the same "journey"?
  • Back-end developers - your web service provide images, but does it also provide text alternatives?
  • Testers - defining expected behaviour for custom UI components.

Content Authors

  • Document outline: headings, sections, etc.
  • Organising content, writing styles, use of diagrams, plain English, etc.
  • Context - choice of text alternatives for images, summaries for tables.
  • Audio/Video content, captioning, etc.

Who else is responsible?

Not just "web" professionals...

  • Product-owners - commissioning a web-site.
  • Customer service professionals - a website is just one part of the customer's experience.
  • PR - outreach, tell people your website is easy to use.
  • Others...?

Topics I'm NOT covering today

... but feel free to ask about them later!

  • Developer tools
    So many to choose from. We'll see a few during demos.
  • Automated testing
    Many problems can't be caught this way.
  • User testing for accessibility.
    Awesome if you can manage this!
  • Compliance, procurement, legal aspects.
    Yawn.

Accessibility Principles

"POUR"

  • Perceivable
  • Operable
  • Understandable
  • Robust

W3C Web Acessibility Initiative (WAI)

Web Content Accessibility Guidelines 2.0 (WCAG)

WCAG Success Criteria

WCAG is organized as a set of success criteria, each
describing an accessibility practice in terms of:

  • Intent & Benefits
  • Priority level (A, AA, AAA)
  • Examples
  • Sufficient techniques
  • Common failures

Example: SC 1.3.1 Info and Relationships describes the use of headings and labels to indicate the structure of a page.

Colour Contrast

Grey text, on a grey background, is hard to read.

Who benefits? Users who...

  • have low vision, e.g. cateracts
  • are over the age of, say, 40
  • have low-quality screens (LCD with poor viewing angle)
  • are using their devices outdoors
  • are indoors, but near a window (or, on a train)
  • ... pretty much everyone

Colour Contrast Thresholds

Beware: large text is described in points, not pixels.
Text size varies with screen size!

Colour contrast tips

  • Establish accessible colours before your client signs-off the design.
  • Aim for colour contrast which is comfortably over the threshold.
  • Avoid the borderline contrast level permitted for large text (3:1)
    - not robust enough for small devices.
  • Palest grey text which passes (AA) on white is #767676
  • color: red; /* #f00 */ on white does not pass (AA).

Colour contrast tools

Many to choose from.

Colour contrast inspiration

Contrast Rebellion

Colour Blindness

"Please correct the errors shown in red."

  • Reduced ability to perceive one or more pigments.
  • Affects ~8% of men (~4% of whole population)
  • Don't rely on colour alone to convey meaning.
  • WCAG SC 1.4.1 - Use of Color

Monochrome photo of a snooker table, cue ball in the foreground, other balls near a corner pocket in the background.

"Steve is going for the pink ball - and for those of you who are
watching in black and white, the pink is next to the green."
Ted Lowe (1920-2011)

Demo:
Protanopia Simulation

A person with protanopia has difficulty
perceiving the red component of colours.

Let's look at some text where some links
inside a paragraph are styled red...

screenshot of article with red links in paragraphs, not underlined.
Simulation of protanopia. Red links in paragraphs are not easy to distinguish.

Solution? Underline the links!

This allows links to stand out, without relying on colour alone.

Most web browsers do this by default.

But your stylesheet killed it.

Screenshot of article where red links are also underlined.
Protanopia simulation of previous screenshot. Underlined links are easily to see.

Accessible pass/fail Colour Coding

The Keyboard-only Experience

Everything that can be controlled with a mouse,
must also be operable with a keyboard.

Just a few standard controls.

Not necessarily using assistive-technology.
Might be a plain-old QWERTY keyboard.

Basic keyboard controls

keyboard diagram, basic control keys highlighted

The highlighted keys are used to interact with a web page.

Interacting with the page

  • TAB moves between interactive elements.
    (SHIFT + TAB moves backwards among them.)
  • ENTER operates links and buttons.
  • SPACE operates buttons and checkboxes
  • Arrow keys control various things (radios, select, slider)
  • ESCAPE cancels things (e.g. dialogs).

More ways to use the keyboard

  • Navigate viewport with SPACE, PgUp, PgDn, Home, End
  • Browser Menu Bar + Context menus
  • Caret browsing, spatial navigation - some browsers only.

Keyboard-only Demo

Focus styles

Sighted keyboard users really need to be sure what
element has focus, before they press enter.

Subtle focus styles don't work - they need to be clear.
Beware of re-using mouse hover styles.

This doesn't limit your creativity - take
inspiration from games consoles and Smart TV.

a { outline: none; }

DON'T DO IT!

(Unless you replace it with something even clearer)

Example: Virgin Media TV menus.
Focus indicated by colour, border, width, and arrow.

Screenshot of Virgin Media TV interface, showing a very clear focus style

Source: Virgin Media TiVo teases new design ahead of rollout

Bypass Blocks - part 1
"skip to main content" links

Allows quick access to interact with the page's main content,
without traversing lots of sidebar links, or a header menu.

Who benefits? Primarily sighted keyboard users.
(Screen readers offer other ways to get around a page.)

WCAG Success Criterion 2.4.1 - Bypass Blocks

Semantic HTML

HTML is a great language for marking up documents.

  • Document outline: headings, lists.
  • Regions: navigation, article, footer, etc.
  • Hyperlinks
  • Forms: fieldsets, labels, etc.
  • Tables, figures.
  • Embedded content: images, video, etc.

Interactive Elements

HTML is not a general-purpose user-interface language, so developers often customize behaviour with javascript.
Be careful what elements you use!

  • <div> means nothing
  • <span> means nothing
  • <button> - pressing it makes something happen.
  • <a href> - hyperlinks direct you somewhere else.

Button vs. Link. We'll run into that a lot.

Human-readable semantics

Some attributes often contain rich semantics, but are
really only useful to a human audience: developers!

  • class attribute
  • data-* attributes
  • ng-* attributes
  • Others?

None are understood by screen readers.

<div class="button"> is not a button.
Use <button> instead.

Machine-Readable Semantics

Assistive technology can understand these.

  • HTML Elements: headings, tables, forms, ...
  • HTML attributes: disabled, required, checked, ...
  • aria-* attributes
  • SVG, MathML.

Buttons in Drupal Forms

Watch out! In Drupal Form API the following code:

'#type' => 'button'

... actually produces...

<input type="submit">

If you want a <button> use

'#type' => 'markup'

The Screen Reader Experience

Whoah. Learning curve.

Some Useful Tools

  1. Headphones! Be kind to your colleagues :-)
  2. A cheat-sheet with keyboard controls.
  3. Learn the stop-talking key command (usually Control).

Slice & Dice

Many ways to navigate or inspect a page...

  • Focus via TAB key, just like a sighted keyboard user.
  • Document outline: sensible heading levels!
  • Landmark Roles: header, footer, navigation, sidebar, search box.
  • Forms mode (some screen readers offer extra tools for forms).
  • Browse a list of links.
  • Table navigation tools (e.g. read headers, skip to end of row, etc.)

NVDA screen reader provides a tool for landmarks and headings.

Screenshot of NVDA screen reader's landmarks dialog

Screen Reader User habits

See the WebAIM Screenreader user survey

  • What technology do you use?
  • Preferred navigation methods?
  • Dealing with images, frames, PDF, multimedia, ...

So, What Does a Screen Reader
Actually Read?

It reads the accessibility tree - huh?

  • Accessibility APIs are part of the overall operating system.
  • Web browsers and assistive technology talk through these APIs.
  • The accessibility tree is a bit like a sub-set of the DOM, after taking into account HTML, CSS, ARIA, JS, and user actions. It's dynamic.
  • Developer tools to inspect the accessibility tree are becoming more widely available.
  • Beware of tools which only test the HTML source code, instead of the DOM or accessibility tree.

Screenreader Demo

Let's look at a Drupal 8 website!

  • Landmark roles
  • Forms have aria-describedby
  • Fancy drop-buttons!
  • Collapsible summary/details elements!
  • ARIA-live announcements (e.g. module search filter)

Note: Drupal 8 is a nice screen reader experience ;-)

What about CSS?

Myth: Good HTML is all that matters.

CSS affects accessibility in many ways.

  • Colours live there! We've already looked at this.
  • Link styles (underline).
  • Focus styles (outline).
  • How easy is it to distinguish heading styles visually?
  • Make regions clearer - navigation and footer styling.

Critical CSS Considerations

CSS can hide content from assistive tech:

  • label { display: none; }
  • label { visibility: hidden; }

Both of these will hide content from screen readers, and
interactive elements will not be focusable by keyboard users.

Many frameworks provide a .visually-hidden class to hide labels and headings from the visual design, while making them available to screen readers. A useful way to maintain a good document outline.

More CSS considerations

Conversely, some methods of hiding content
visually do not hide it from screen readers.

form .error-message { opacity: 0; }

An error message concealed in this way would be announced
by a screen reader, whether there is an error or not!

The "Off-Canvas" Myth

Content rendered outside the viewport is still there!
This can be a help or a hindrance...

Good:
"Invisible" labels are still accessible to screen readers.

Bad:
Focusable elements are still in the tabbing order. Sighted keyboard users can traverse them, but can't tell what's in focus! Operable, but not perceivable. Example: a menu which slides on/off the page.

What about Javascript?

Myth: Accessible sites can't use Javascript.

It's a similar story: JS can help or hinder accessibility.

Javascript can change CSS properties and HTML attributes,
or even replace whole chunks of HTML in the DOM...
and a screen reader user might be none the wiser.

Used with care, Javascript can greatly enhance accessibility.

It's time to learn about ARIA.

Introducing WAI-ARIA

HTML is NOT a general-purpose user interface language!

ARIA (accessible rich internet applications) provides
a vocabulary of UI roles, states, and properties.

They express the range of interaction found in native desktop and mobile UI widget APIs, using formal, machine-readable semantics.

It's a game changer.

An ARIA buffet

  • Roles
    navigation, menubar, spinbutton, tablist, ...
  • States
    expanded, pressed, invalid, grabbed, ...
  • Relationships
    labelled-by, described-by, controls, ...
  • Properties
    haspopup, dropeffect, readonly, ...

Example: button states

A "burger" style menu button. The aria-expanded property is toggled by Javascript during toggleMenuList().


  <nav role="navigation" aria-labelledby="menuButton">
    <h3>
      <button id="menuButton" 
              onclick="toggleMenuList()"
              aria-controls="menuList"
              aria-expanded="true" >Menu</button>
    </h3>
    <ul id="menuList">
      <li>Link 1</li>
      <li>Link 2</li>
      <li>Link 3</li>
    </ul>
  </nav>

For more detail, see my other slideshow from LeedsJS.

Example: rich form descriptions

aria-describedby can associate help and/or error messages with a particular form input. Note that it can take multiple element IDs.


  <label for="length">How long is a piece of string?</label>
  <input id="length" type="number"
         value="-10"
         aria-describedby="length-help length-error"
         aria-invalid="true" />
  <div id="length-error">Error - length cannot be negative.</div>
  <div id="length-help">Measured in inches.</div>

A screenreader can announce
"How long is a piece of string? Minus 10, number input, invalid. Measured in inches. Error - length cannot be negative."

The Golden Rules of ARIA

Use it sparingly!

Do NOT use an aria-* role or property,
if an equivalent one already exists in HTML.
Host-language semantics are preferred.

Avoid initialising dynamic properties in HTML source.
Handle these with non-intrusive JavaScript.

How Do ARIA and HTML
Semantics Relate?

ARIA is best used to supplement HTML semantics, but beware:
ARIA will also override HTML semantics.

Example: this is a BUTTON, not a heading...

<h3 role="button">Options</h3>

For a collapsible section, where both heading and button
semantics are desired, use a button inside a heading. 

<h3><button>Options</button></h3>

Other Uses of ARIA

  • Use in other languages: SVG, MathML, ...
  • Sometimes safer to over-ride a HTML native role.
    Avoids breaking CSS or JS which deals with elements by tag names.
  • Complex relationships: text inputs in a table can be labelled by both column and row headers.
  • ASCII art! <pre role="image" aria-label="ASCII art fish">
    is equivalent to <img alt="ASCII art fish"/>

Bypass Blocks - Part 2
ARIA Landmark Roles

These help assistive tech users get to the right part of the page quickly, e.g. <div role=navigation>

ARIA roles: main, banner, contentinfo, navigation,
complementary, search, ...

New HTML5 elements offer equivalents:
main, header, footer, nav, aside.

Caution: Internet Explorer still needs roles, because the HTML semantics are not passed up through accessibility API.
i.e. <nav role="navigation">

Reading List

  • TL;DR... a11yproject.com - A community-reviewed set of tutorials, recipes, and tips, aimed at those learning web accessibility.
  • WebAIM.org - a great set of articles, screenreader tutorials, and the Screen Reader User Survey.

In fact, you might do better perusing their resource lists ;-)

Using Personas

Dive Into Accessibility

A short open-source book which gives a great introduction to thinking about accessibility, along with techiniques.

Particularly useful for introducing personas when considering accessibility. For every technique, it has a discussion of who benefits, and how.

It's starting to look a little dated (19-inch is a large monitor!), and a few techniques have changed, but few books match this one as an introduction to the topic.

ARIA

Blogs

Misc. Reading List

Any Questions?

The End

Image Credits