Motivating Use Cases

Today, a library author creating a custom element is forced to "sprout" ARIA attributes to express semantics which are implicit
for native elements.

Unlike a native element, a custom element's semantics may be completely overwritten or removed by the author using the custom
element, and it is impossible to distinguish between the semantics provided by the custom element and semantics set
by the page author.

This capability
need not, but
may be limited to Web Components.

Use Case 2: Setting relationships without IDREFs

To express an accessible relationship between two elements in the DOM, ARIA attributes let one element refer to the ID of
another element.

aria-labelledby indicates one element labels another:

First name:

aria-activedescendant indicates a descendant that's focused in a composite control like a list box.

Item 1

Item 2

Item 3

Use Case 2: Setting relationships without IDREFs (2)

It can be
cumbersome and
error-prone to maintain unique IDs on all elements that have a relationship with some other element.

But if you're using Shadow DOM, it's
impossible to establish a relationship between two elements that aren't part of the same
tree scope.

For example, it's
impossible to make an accessible combobox using
aria-activedescendant if the the text field is in a different tree scope from the listbox options:

#shadow-root (open)
|
|
| Option 1Option 2Option 3

Use Case 3: Capturing input events from AT

ARIA only helps the web author communicate in one direction: from the web app to the assistive technology.

However, AT can also command and control applications, for example issuing commands to activate, focus, or scroll. While
native HTML elements already support these commands, web authors can't override this behavior for custom elements.

Examples: AT wants to
select an item in a list box,
increment a slider, or
dismiss a dialog.

Another example: AT user performs a gesture to explicitly
scroll to the left on a map widget.

Use Case 4: Making custom-drawn UI accessible.

To make a canvas-based UI (for example, a UI drawn using WebGL) accessible requires hacks like non-rendered fallback DOM
content doing double duty as the accessible version of the painted UI.

More generally, any UI which has a visual semantic structure (such as an image with complex content) which doesn't match
up to its DOM structure is difficult to make accessible.

Use Case 5: Introspection

There's no way to programmatically detect if an accessibility feature is supported by the browser or if you're using it correctly.

Accessibility Object Model

AOM: Brief History

Microsoft and Mozilla independently proposed a JavaScript accessibility API. Apple and Google had similar ideas.

AOM is a collaboration between Apple, Google, and Mozilla, part of the Web Incubator Community Group. It takes the best ideas
from previous proposals and organizes them into four
phases, each with smaller scope, each solving an increasing number of real-world use-cases.

Both Safari and Google Chrome have implemented some of the spec experimentally.

Warning!

All syntax shown on these slides is subject to change.

We are committed to
solving these problems, but the solution may not be exactly what you see here.

Phases 1-3 overview

Phases 1 through three, taken together, should bring the capabilities of accessibility on the web closer to what is possible
on native platorms.

Programmatic API

Virtual tree for custom UI

Listen to events from assistive technology

Phase 1: Accessible Properties

Basically, reflect ARIA into JavaScript.

Every ARIA attribute, such as
role and
aria-checked here:

Receive promotional offers

...can be set directly from JavaScript:

el.role = "checkbox";
el.ariaChecked = true;

Phase 1: Accessible Properties (2)

These properties will also be available on the ShadowRoot interface.
This will allow Custom Elements to express their intrinsic semantics:

Phase 2 Use cases include...

Focus events in composite controls, e.g. when the AT wants to focus an option or cell, but the web app wants to focus
the listbox or grid and use aria-activedescendant.

Events that don't have any equivalent on the web now, like
"increment",
"decrement", or
"dismiss".

Capturing events on virtual nodes intended entirely for AT (more in Phase 3).

Phase 2 and privacy

If an AOM event listener is ever called, the web page *definitively knows* that the user is running AT.

Some users may not be comfortable revealing this, due to concerns of discrimination, or of being offered an undesired alternate
interface.

So triggering an AOM event listener brings up a new
user permission dialog before the web page can capture the event.

Phase 2 and feature detection

If the user
does grant permission, this is great because the app can now enable any extra features needed by AT.

If the user does not grant permission, they can have more confidence they're getting the same experience as everyone else
and that they haven't revealed to the site that they're an AT user.

We would suggest that authors use progressive enhancement techniques to ensure that users have as acceptable experience as
possible regardless of whether they gave permission to use AOM, or indeed whether the browser supports AOM.

Phase 2 demo: Canvas slider

Using VoiceOver, try
Interacting with this slider and using VoiceOver commands to increment and decrement it.