Introduction

When Focus on Custom JavaScript/ARIA Widgets?

This module covers a wide range of topics related to creating custom widgets with ARIA (accessible rich internet applications) methods. In order to create a custom widget successfully, you have to know techniques related to ARIA itself (such as name, role, value, description, and live regions), and keyboard accessibility (all the basic concepts, plus an understanding of the ARIA keyboard model).

"First Rule of ARIA Use: Don't use ARIA unless you have to."

The section entitled "ARIA Widget Examples" shows live examples of these principles in action. The accessibility features of the widgets are explained in detail. You may copy and use the code in your own web development, or just learn from the accessibility patterns in the widgets.

Summary

Creating accessible custom JavaScript widgets can be tricky. There are lots of little things to pay attention to, including keyboard interaction, touch interaction, ARIA authoring practices, and even the question of whether a custom JavaScript widget is the right approach in the first place. It's always best to start with the assumption that native HTML widgets are the best approach. They are natively accessible, and people are more used to them. They don't have to learn how to use them in the same way they have to learn how to use a custom control they've never encountered before.

Study the WAI-ARIA Authoring Practices. Whenever you start on the path of creating a custom widget, find an ARIA widget that already accomplishes your goals. If there isn't one quite like what you want, first ask if what you want is really necessary, because it will be unfamiliar to users. If you decide it is necessary, identify the closest ARIA widget match, and use those ARIA roles and design patterns as the basis for your design. It's okay to make compound widgets consisting of design patterns from 2 or more ARIA widgets, as long as the end result is intuitive to use and all of the names, roles, and properties are communicated properly to screen reader users.

ARIA Concepts

Checklist - Deque

ARIA Concepts category

None documented

Download Summary & Checklist

None documented

Tips & Tricks

  • The Roles Model
    • Abstract Roles
    • Widget Roles
    • Document Structure
    • Landmark Roles
  • Supported States and Properties
  • Managing Focus
  • Conformance

What Is ARIA?

  • Accessible Rich Internet Applications
  • Without ARIA it's impossible for AT to fully understand all components
  • ARIA is to provide information for the A11Y APIs
  • ARIA changes everything
  • For interactive widgets, and applications
  • The work of web accessibility advocates
  • For names, roles, states and properties
  • ARIA Allows Real-Time Live Announcements

ARIA Concepts

  • ARIA allows you to communicate the following information to screen readers:
    • Labels
    • Roles
    • States
    • Properties
    • Relationships
  • ARIA is Useful Only to Assistive Technologies
  • ARIA is Not a Programming Language

Jump to:

Guidelines

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented

Name Vs. Label

Checklist - Deque

Label Examples category

None documented

Download Summary & Checklist

None documented

Tips & Tricks

Non-ARIA Names and Labels

  • The <label> tag designates the label for a form <input> element.
  • The <legend> labels <fieldset> elements (groups of form elements).
  • The <th> tag designates a table header cell (as opposed to <td> for table data cells).
  • The text inside the opening and closing <button> elements is the label for that button.
  • The value attribute on a submit button serves as the label for that button.
  • The alt attribute serves as the name, or text replacement, for an image.
  • The <title> tag designates the name of a web page.
  • The title attribute designates the name of an <iframe> element.
  • A visible label for a component not programmatically related like adjecent button for an input or an icon with screen reader only text

Descriptions - Aria-describedby

  • The Purpose is to provide extra information
  • Works in the same way as aria-labelledby
  • Refers to the id of another object
  • More verbose, can contain entire paragraphs, best to keep text brief
  • Support in Jaws very good
  • Long delay VoiceOver OSX, but can be shortened
  • Short delay VoiceOver iOS
  • Isn't read on most types of elements (div, paragraph, list item, etc.) by either NVDA or VoiceOver
  • Placing same elements inside an application region, NVDA and VoiceOver on Mac OSX (not iOS) will read them

Roles

Checklist - Deque

Roles category

None documented

Download Summary & Checklist

None documented

Tips & Tricks

Widgets and Simulated Controls

  • The Basics of Accessible Simulated Controls
    • All controls must be keyboard accessible and keyboard operable
    • Focus must be managed when using non-standard controls
    • Ensure that important information and relationships are explicitly defined
  • The Basics of Accessible Simulated Controls
    • Programmatic focus
    • Keyboard tab order
    • Visual focus indicator
    • Keyboard trap
  • Ensure that Users Can Navigate To, Through, and Past All Simulated Controls
  • Avoid Applying Events to Elements which are Typically not Able to Receive Focus

HTML5 and ARIA Landmarks

5.3 Categorization of Roles

User Agent Implementation Guide

  • 5.4. Role mapping
  • The following rules describe how to expose WAI-ARIA roles using the accessibility API:
      • User agent MUST use the first token in the sequence
      • WAI-ARIA over HTML
      • WAI-ARIA roles override host language semantics, no changes in the DOM, only in accessibility tree
      • User agents MUST map WAI-ARIA roles even in the absence of author-supplied scripts!!!
    1. If no role attribute present, or contains no matching non-abstract WAI-ARIA role, the user agent MUST fall back on base markup
    2. When explicit or inherited role of presentation is applied, user agent MUST implement the rules for presentation role
    3. User agents MUST expose the WAI-ARIA role string if the API supports a mechanism
      • Platform A11Y APIs typically don't provide a way to notify a role has changed
      • So assistive technologies are unlikely to process a change in role
      • When changing a rol, delete associated element and its children and replace with new element having new role

The Document Role

  • document (role) - ARIA
    • In a document region, keyboard shortcuts to navigate headings, landmarks, tables, lists, etc.
    • Access all aspects text, including spelling of words
    • Default role for body element is "document"
    • body - HTML AAM
    • Only reason using role="document" is inside other region such as application

The Application Role

  • application (role) - ARIA
    • Nearly all keyboard shortcuts are turned off in application regions
    • Need to be able to control the logic of keyboard interactions within web applications
    • Only focusable elements will be possible to read
    • tabindex="1" for focus possible BUT use sparingly as functionality lacks!
    • Never wrap entire web page in application region, only around widgets
  • Keyboard features NOT disabled e.g.
    • Tab key
    • Enter or Return key
    • space bar key
    • arrow keys
  • Roles who trigger application mode automatically
    • role="dialog"
    • role="alertdialog"
    • role="tablist"
    • role="tree"
    • role="slider"
    • role="toolbar"
    • role="grid"
    • role="menu"

The Presentation Role

  • presentation (role) - ARIA
  • none (role) - ARIA = NEW synonym!
    • Essentially cancels the native role and turns it into the equivalent of a span or div
    • Technically the object is removed from the accessibility tree / API
    • It's the opposite of adding a specific role to an element
    • Adding role="presentation" does NOT hide the element of textual content from anyone

Other Semantic Roles

  • The Math Role
    • Screen reader support is still not robust
    • Use aria-labe as a back-up
  • The Definition Role
    • Use role="definition" and aria-labelledby="example" with id="example"
    • Support for definition lists (dl) is not good so add the ARIA example
  • The Note Role
    • Similar in concept to HTML 5 <aside> or the ARIA role="complementary"
    • But role="note" is not a landmark region like the other two
  • The Directory Role
    • For designating a table of contents (TOC) or other similar directory structures
    • Whether the items are links or not

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented

ARIA Widget Examples

Checklist - Deque

ARIA Widget Examples category

None documented

Download Summary & Checklist

None documented

Tips & Tricks

Widgets and Simulated Controls

  • The Basics of Accessible Simulated Controls
    • All controls must be keyboard accessible and keyboard operable
    • Focus must be managed when using non-standard controls
    • Ensure that important information and relationships are explicitly defined
  • The Basics of Accessible Simulated Controls
    • Programmatic focus
    • Keyboard tab order
    • Visual focus indicator
    • Keyboard trap
  • Ensure that Users Can Navigate To, Through, and Past All Simulated Controls
  • Avoid Applying Events to Elements which are Typically not Able to Receive Focus

Resources

Specifications

None documented

Examples

None documented

Miscellaneous

None documented

Practice

WCAG Annotations

None documented

Design Annotations

None documented