Spinning ARIA Around

Spinning ARIA Around

Eric Eggert, Knowbility · AccessU · May 2019

Eric Eggert

Eric Eggert is a Web Developer and Teacher who works with Knowbility and the W3C on improving the Web for People with Disabilities, and everyone else.

My name is Eric Eggert and I work with Knowbility and the W3C to improve the Web for People with Disabilities. I work with Knowbility and they donate 50% of my work time to W3C as a fellowship.

Important Note:

This presentation contains ARIA examples that are preventing websites and applications from being accessible.

Don’t copy & paste mindlessly.

WAI-ARIA: Accessible Rich Internet Applications

Internet Applications

Internet Applications

ARIA ≠ 🧙‍♀️|| 🧙‍♂️

ARIA is not witchcraft or sorcery.

No aria-make-accessible=”true”

5 Rules of ARIA

Using ARIA

Rule 1

If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of repurposing an element and adding an ARIA role, state or property to make it accessible, then do so.

Rule 2

Do not change native semantics, unless you really have to.

Bad Example:

<h1 role="button">heading button</h1>

Good Example:

<h1><button>heading button</button></h1>

Nicolas Steenhout @vavroom:

Here’s an accessibility gem: <h2 class="h3" role="heading" aria-level="1">Some heading</h2> #a11y

on Twitter

Rule 3

All interactive ARIA controls must be usable with the keyboard.

Rule 3

If you create a widget that a user can click or tap or drag or drop or slide or scroll, a user must also be able to navigate to the widget and perform an equivalent action using the keyboard. All interactive widgets must be scripted to respond to standard keystrokes or keystroke combinations where applicable.

Example

If using role=button the element must be able to receive focus and a user must be able to activate the action associated with the element using both the enter (on WIN OS) or return (MAC OS) and the space key. — ARIA Practices Guide

DEMO

Rule 4

Do not use role="presentation" or aria-hidden="true" on a focusable element. Using either of these on a focusable element will result in some users focusing on ‘nothing’.

Rule 5

All interactive elements must have an accessible name.

Some Roles

<div role="main"> <!-- better: <main> -->

<form role="search">

<div role="tooltip">

<output role="alert">

Some Properties and States

<input aria-required="true">

<input aria-labelledby="label" aria-describedby="errormsg">

<button aria-expanded="false">

<div aria-hidden="true">

<div aria-live="assertive">

Live Regions

<div aria-live="off">

<div aria-live="polite">

<div aria-live="assertive">

ARIA Support

Heydon Pickering: aria-controls is 💩

The many roles and properties of ARIA.

RDF Model of WAI-ARIA

WAI-ARIA is really Complicated!

Makes it also complicated for Web Developers!

Exhibit 1 – Bad!

<a id="airline-logo" href="…"
   class="logo"
   aria-label="Airline Name">
   &nbsp;
</a>

Exhibit 1 – Better!

<a id="logo" href="…">
   <img src="…" alt="Airline Name">
</a>

or:

<a id="logo" href="…">
   <svg>
     <title>Airline Name</title>
     …
   </svg>
</a>

Exhibit 2 – Bad!

<div class="nav">
  <a href="javascript:void(0);" class="navInactive" role="button">
    <span class="hiddenText">Slide 1</span>
  </a>
  <a href="javascript:void(0);" class="navActive" role="button">
    <span class="hiddenText">Slide 2</span>
  </a>
  <a href="javascript:void(0);" class="navInactive" role="button">
    <span class="hiddenText">Slide 3</span>
  </a>
</div>

Exhibit 2 – **Better!**

<nav>
  <button aria-pressed="false" aria-label="Slide 1">
     &nbsp;
  </button>
  <button aria-pressed="true" aria-label="Slide 2">
     &nbsp;         
  </button>
  <button aria-pressed="false" aria-label="Slide 3">
     &nbsp;
  </button>
</nav>

Exhibit 2 – **Even Better!**

<nav>
  <button aria-pressed="false">
   <img src="…" alt="Slide 1">
  </button>
  <button aria-pressed="true">
   <img src="…" alt="Slide 2">
  </button>
  <button aria-pressed="false">
   <img src="…" alt="Slide 3">
  </button>
</nav>

Exhibit 3 – Bad!

<th 
 tabindex="0" 
 role="button" 
 aria-label="Sort column"
>Name</th>

Exhibit 3a – Bad!

<button type="button" role="button" aria-required="false" tabindex="0">2</button> WHAT THE HECK? #facepalm #a11y

— Paul J. Adam on Twitter

Exhibit 4 – Bad!*

<span aria-hidden="true" role="img" class="icon"> </span>

*Actually not harmful, but really, what is the point?!

Exhibit 5 – Really Bad!

<body aria-hidden="true">

Exhibit 6 – Bad!

<a 
  href="…" 
  target="_blank" 
  title="Click here to 
         view the video." 
  tabindex="-1" 
  role="button" 
  aria-label="External link"
></a>

Things you should not do: use an aria-live region on a carousel. Screen readers get constantly disrupted because the content changes. Makes your website impossible to use.

#ariaserious

Eric Eggert on Twitter

<label for="ID">Label Text</label><input type="text" id="id" />

Is not accessible. IDs are case sensitive in HTML/the DOM.

#ariaserious #htmlserious

Eric Eggert on Twitter

WAI-ARIA Authoring Practices 1.1

https://www.w3.org/TR/wai-aria-practices-1.1/

Using ARIA

https://www.w3.org/TR/using-aria/

Conclusion

• ✅ Landmarks
• ✅ States & Properties (Widget)
• ⚠️ Roles — Mind the Keyboard