This spec has been deprecated, please see the Accessibility Object Model Explainer and index to specs for up to date information.

Introduction

This document is the spec for Phase 2 of the Accessibility Object Model spec. For background, please refer to the Accessibility Object Model Explainer for the background and motivation, and then Phase 1.

Phase 2: Accessible Actions

In this phase, we extend AccessibleNode so that it's also an EventTarget. AccessibleNodes receive special accessibility input events or accessible actions that represent explicit intents to control the user agent via an accessibility API

          interface AccessibleNode : EventTarget {
            ...
          };
        

Accessibility input events are needed for two reasons.

• First, because it's possible to create AccessibleNodes that don't correspond to a DOM node and authors need to be able to listen to events on these nodes.
• Second, because there are many types of specific user intents that can be communicated to the user agent via accessibility APIs that don't correspond to existing keyboard and mouse events - for example some assistive technology has keystrokes or gestures to increment a slider, or dismiss a pop-up.

          interface AccessibleSetValueEvent : Event {
            attribute DOMString value;
          };
        

Accessibility input events go through capture and bubble phases, just like DOM events. The only difference is that the capture and bubble phases happen entirely in the accessibility tree. If the event is not canceled (by calling preventDefault()) after completely going through the capture and bubble phases in the accessibility tree, the event executes its fallback behavior, as defined in the accessibility attribute table.

When an event's fallback behavior involves firing a DOM event, the event's target will be the associated DOM node of the target AccessibleNode, or the associated DOM node of the nearest ancestor of the target AccessibleNode that has one. Fallback DOM events will go through capture and bubble phases just like any other DOM events.

As an example, suppose an accessible click event is received on a button. Here's the sequence of what will occur:

1. Capturing event listeners are called, starting with the root of the accessibility tree, and continuing along the ancestor chain until reaching the target AccessibleNode in the accessibility tree.
2. If none of the capturing event listeners stop propagation, normal (non-capturing) event listeners on the target AccessibleNode are called, and if stopPropagation() is not called, the event bubbles up to all event listeners on ancestors of the target.
3. After capture and bubble phases in the accessibility tree, if preventDefault() was not called, the event's fallback behavior is triggered. In this case it fires a DOM "click" event on the targer AccessibleNode's associated DOM node, going through capture and bubble phases in the DOM tree.

The following were considered as possible accessibility input events but were deferred for a future version of the spec. Please file a bug if you have a compelling use case for one of these.

• "addtoselection"
• "collapse"
• "delete"
• "expand"
• "medianext"
• "mediapause"
• "mediaprevious"
• "mediastart"
• "mediastop"
• "removefromselection"
• "scroll"
• "zoom"

Platform compatibility table

The following table shows proposed accessible actions and the native actions or methods they correspond to on each platform with an accessibility API.

When an action maps cleanly to a method or action on all or nearly all platforms, that's good evidence that it's a good candidate for an accessible action in the Accessibility Object Model. When an action doesn't map cleanly, that means it's potentially more risky for compatibility.

In the table below, Tier 1 actions appear to have broad support across almost all platforms. Tier 2 actions are supported on at least 2 unrelated platforms. The remaining native actions are shown below.

Actions unique to macOS:

• AXConfirmAction
• AXDeleteAction
• AXRaiseAction
• AXShowAlternateUIAction
• AXShowDefaultUIAction
• set AXCaretBrowsingEnabled
• set AXDisclosing
• set AXGrabbed
• set AXPreventKeyboardDOMEventDispatch

Actions unique to UIA

• IDockProvider::SetDockPosition
• IMultipleViewProvider::SetCurrentView
• ITransformProvider::Move
• ITransformProvider::Resize
• ITransformProvider::Rotate
• IWindowProvider::SetVisualState (minimized, maximized, normal)

Actions unique to Android:

• ACTION_ACCESSIBILITY_FOCUS
• ACTION_CLEAR_ACCESSIBILITY_FOCUS
• ACTION_NEXT_AT_MOVEMENT_GRANULARITY
• ACTION_NEXT_HTML_ELEMENT
• ACTION_PREVIOUS_AT_MOVEMENT_GRANULARITY
• ACTION_PREVIOUS_HTML_ELEMENT

Privacy concerns

This phase raises some potential privacy concerns. If a web app receives an accessibility input event, it now knows for a fact that assistive technology or some other client of a native accessibility API is running. There is potential that this could be used to track or discriminate against some users.

To address these concerns, a web site should not be able to receive these events until the user has explicitly opted in to allow those events to be received by that web site.

A new web permission should be added, "accessibility-events", with a default value of "ask".

A website can add event listeners to AOM nodes without triggering any permission checks. However, as soon as an accessibility event would trigger an AOM event listener, at that point the user is prompted to see if they want to enable the site to be able to listen for accessibility events.

Example permission dialog text: "The site www.example.com would like to respond to accessibility events." [Allow] [Block]

Because of the potential privacy concerns, maybe this permission should only be available on secure sites? Many other permissions have gone that route.

Phase 3: Virtual Accessibility Nodes

See Phase 3

Phase 4: Computed Accessibility Tree

See Phase 4