Web AccessibilityTechniques for Designersand Developers

North West Drupal User Group10th 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 peopleare 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 impairmentslearning differences, distractability, dyslexia, ...
• Hearing impairmentsdeafness, hard-of-hearing, tinnitus
• Motor impairmentslimited fine motor control, slow response time
• Visual impairmentsblindness, 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.

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 toolsSo many to choose from. We'll see a few during demos.
• Automated testingMany 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, eachdescribing 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

• Level AA - Contrast (Minimum)
  • 4.5 : 1 for normal text
  • 3 : 1 for large text (above 18pt)
• Level AAA - Contrast (Enhanced)
  • 7 : 1 for normal text
  • 4.5 : 1 for large text (above 18pt)

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.

• Online tools, e.g.
  • Lea Verou's Contrast Ratio
  • NCSU Color Pallette Accessibility Evaluator
• Web browser add-ons
• Tools inside graphic suites
• Stand-alone applications

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.

Demo:Protanopia Simulation

A person with protanopia has difficultyperceiving the red component of colours.

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

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.

Accessible pass/fail Colour Coding

• Don't rely on green vs red
• Use shapes too - ticks and crosses
• Demo: Colour coding article at Penn State Uni.
• WebAIM article on Link colours

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

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

• BBC NewsClear focus styles
• Channel 4 newsPoor/absent focus styles.
• WebAIM: Intro to Web AccessibilityAnimated focus styles!

Focus styles

Sighted keyboard users really need to be sure whatelement 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.

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 arereally 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:

... actually produces...

<input type="submit">

If you want a <button> use

The Screen Reader Experience

Whoah. Learning curve.

Some Useful Tools

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.

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 ReaderActually 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, andinteractive 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 contentvisually do not hide it from screen readers.

form .error-message { opacity: 0; }

An error message concealed in this way would be announcedby 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) providesa 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

• Rolesnavigation, menubar, spinbutton, tablist, ...
• Statesexpanded, pressed, invalid, grabbed, ...
• Relationshipslabelled-by, described-by, controls, ...
• Propertieshaspopup, 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!

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

How Do ARIA and HTMLSemantics 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 buttonsemantics 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

• HeydonWorks' intro - a good starting point
• Marco Zehe's Aria Tips
• WAI-ARIA Authoring Practices - describesthe expected behaviour of UI widgets.
• Paul J Adam's Demos - worked examples
• OpenAjax Alliance demos - worked examples

Blogs

• Paciello Group
• Léonie Watson
• SSB Bart Group
• Simply Accessible

Misc. Reading List

• Twitter hashtag - #a11y
• How to use NVDA and Firefox to test your web pages for accessibility - A great screen reader tutorial.
• Twitter Bootstrap Components - Well documented, provides detail about steps you need to take to make best use of Bootstrap's accessibility.

Any Questions?

The End

Image Credits

• Screenshots from the Electronic Frontier Foundation.
• Screenshots from Age Action Ireland.
• Tango icons from Wikimedia Commons.
• Snooker photo from Wikimedia Commons.
• Keyboard diagram created with keyboard-layout-editor.com
• I made the silly space suit myself. @wodgeyboy added the planets and stuff.