Independent User Interface for Rich Internet Applications

1.1. Problem Description

At the time of this writing, WAI-ARIA states that:

Accessibility of web content requires semantic information about widgets, structures, and behaviors, in order to allow assistive technologies to convey appropriate information to persons with disabilities. [The WAI-ARIA] specification provides an ontology of roles, states, and properties that define accessible user interface elements and can be used to improve the accessibility and interoperability of web content and applications. These semantics are designed to allow an author to properly convey user interface behaviors and structural information to assistive technologies in document-level markup.

WAI-ARIA 1.0 specifies a standardized means for web applications to convey accessibility semantics through declarative markup in the DOM. This document, the Independent User Interface specification, standardizes a method for assistive technology to assume control of customized user interface widgets, or convey the user's intent for control of the web application. Simple control over web applications can be achieved by using standard activation events, like click or DOMActivate, but full control over secondary actions (tree expansion, grid sorting, scrolling) requires additional events and interfaces, that allows for more robust (link @@ WCAG Robust) control over web applications.

Benefits include low barrier of entry for end users, and ease of development for web application authors. The Independent User Interface specification allows users of assistive technology to control web applications using the same commands they are accustomed to with native regardless of rendering engine, platform, operating system, or localization.

The specification is organized into three parts: UI Change Request Events for all user agents, Accessibility Events for assistive technology, and additions to the Navigator interface for Assistive Technology Identification and Notification.

Interface UIRequestEvent

interface UIRequestEvent : UIEvent {
  
  // UA or AT notifies web app of a change request
  const unsigned short    UNDO    =  1;
  const unsigned short    REDO    =  2;
  const unsigned short    ESCAPE  =  3;
  const unsigned short    DELETE  =  4;
  // expect more type constants will be added for other event types…
  // ZOOM_IN / ZOOM_OUT ? perhaps that should just be slider widget, covered under ValueChangeRequest
  
  readonly attribute unsigned short    eventType;
  
  void initUIRequestEvent(
         in DOMString typeArg,
         in boolean canBubbleArg,
         in boolean cancelableArg,
         in views::AbstractView viewArg,
         in long detailArg,
         in unsigned short eventTypeArg
       );
};

The different types of UIRequestEvents that can occur are:

UndoRequest

Initiated when the user agent or assistive technology sends an 'undo' request to the web application.

• Bubbles: Yes
• Cancelable: Yes
• Context Info: eventType

RedoRequest

Initiated when the user agent or assistive technology sends a 'redo' request to the web application.

• Bubbles: Yes
• Cancelable: Yes
• Context Info: eventType

EscapeRequest

Initiated when the user agent or assistive technology sends a 'escape' request to the web application.

• Bubbles: Yes
• Cancelable: Yes
• Context Info: eventType

DeleteRequest

Initiated when the user agent or assistive technology sends a 'delete' request to the web application.

• Bubbles: Yes
• Cancelable: Yes
• Context Info: eventType

Interface UIScrollRequestEvent

interface UIScrollRequestEvent : UIRequestEvent {
  
  // for custom scroll views or widgets (e.g. carousels, lists, grids)
  const unsigned short    LEFT          =  1;
  const unsigned short    UP            =  2;
  const unsigned short    RIGHT         =  3;
  const unsigned short    DOWN          =  4;
  const unsigned short    LEFT_LIMIT    =  5;
  const unsigned short    TOP_LIMIT     =  6;
  const unsigned short    RIGHT_LIMIT   =  7;
  const unsigned short    BOTTOM_LIMIT  =  8;
  
  readonly attribute unsigned short   scrollType;
  
  void initUIScrollRequestEvent(
         in DOMString typeArg,
         in boolean canBubbleArg,
         in boolean cancelableArg,
         in views::AbstractView viewArg,
         in long detailArg,
         in unsigned short eventTypeArg
         in unsigned short scrollTypeArg
       );
};

The single type of UIScrollRequestEvent that can occur is:

ScrollRequest

Initiated when the user agent or assistive technology sends a scroll request to the web application. Scroll events need only be used on custom scroll views (lists and grids showing data subsets, carousels, etc.), as user agents and assistive technologies already manage scrolling of native scroll views.

Note: The scroll type constants are more or less equivalent to user-expected behavior for PageUp/PageDown and Home/End keys on native scroll views, but also allow horizontal scrolling.

• Bubbles: Yes
• Cancelable: Yes
• Context Info: scrollType

Interface UIValueChangeRequestEvent

interface UIValueChangeRequestEvent : UIRequestEvent {
  
  // value changes (e.g. ranges)
  const unsigned short    INCREMENT        =  1;
  const unsigned short    INCREMENT_SMALL  =  2;
  const unsigned short    INCREMENT_LARGE  =  3;
  const unsigned short    INCREMENT_MAX    =  4;
  const unsigned short    DECREMENT        =  5;
  const unsigned short    DECREMENT_SMALL  =  6;
  const unsigned short    DECREMENT_LARGE  =  7;
  const unsigned short    DECREMENT_MIN    =  8;
  
  readonly attribute unsigned short   changeType;
  
  void initUIValueChangeRequestEvent(
         in DOMString typeArg,
         in boolean canBubbleArg,
         in boolean cancelableArg,
         in views::AbstractView viewArg,
         in long detailArg,
         in unsigned short eventTypeArg,
         in unsigned short changeTypeArg
       );
};

The single type of UIValueChangeRequestEvent that can occur is:

ValueChangeRequest

Initiated when the user agent or assistive technology sends a value change request to the web application.

Web authors should code applications to accept all values of the changeType argument. For example, if there is no special behavior for INCREMENT_SMALL or INCREMENT_LARGE, web applications would behave as if they had received a basic INCREMENT change type.

• Bubbles: Yes
• Cancelable: Yes
• Context Info: eventType

Interface DOMAttributeChangeRequestEvent

interface DOMAttributeChangeRequestEvent : UIRequestEvent {
  
  readonly attribute DOMString    attrName;
  readonly attribute DOMString    newValue;
  
  void initDOMAttributeChangeRequestEvent(
         in DOMString typeArg,
         in boolean canBubbleArg,
         in boolean cancelableArg,
         in views::AbstractView viewArg,
         in long detailArg,
         in unsigned short eventTypeArg,
         in DOMString attrNameArg,
         in DOMString newValueArg
       );
};

The single type of DOMAttributeChangeRequestEvent that can occur is:

DOMAttrChangeRequest

Initiated when the user agent or assistive technology sends an attribute change request to the web application. In order for web applications to understand the intent of change request events from the user agent or assistive technology, these change requests should be limited to attributes for which a change in value indicates a discrete, defined action for known types of widgets and UI elements.

Note: Currently, this limitation indicates that DOMAttrChangeRequest only applies to WAI-ARIA widgets, but it has the potential to be used with future iterations of HTML5 or SVG.

• Bubbles: Yes
• Cancelable: Yes
• Context Info: attrName, newValue

Interface AccessibilityEvent

interface AccessibilityEvent : UIEvent {
  void initAccessibilityEvent(
         in DOMString typeArg,
         in boolean canBubbleArg,
         in boolean cancelableArg,
         in views::AbstractView viewArg,
         in long detailArg
       );
};

The different types of AccessibilityEvents that can occur are:

AXFocusIn

Initiated when the assistive technology cursor moves to a particular DOM node.

• Bubbles: Yes
• Cancelable: No
• Context Info: None

AXFocusOut

Initiated when the assistive technology cursor leaves a particular DOM node.

• Bubbles: Yes
• Cancelable: No
• Context Info: None

AXDragSelect

Initiated by the assistive technology in order to inform the web application than a draggable element (e.g. an element with an explicit aria-grabbed value) should be marked for dragging.

• Bubbles: Yes
• Cancelable: Yes
• Context Info: None

AXDragCancel

Editorial Note: This event may not be necessary; could use general EscapeRequest instead.

Initiated by the assistive technology in order to inform the web application than the current drag operation should be cancelled.

• Bubbles: Yes
• Cancelable: No … Editorial Note: Does this need to be cancelable?
• Context Info: None

AXDragDrop

Initiated by the assistive technology in order to inform the web application than a specific drop target (e.g. an element with an explicit aria-dropeffect value) should receive the drop event of the current drag operation.

• Bubbles: Yes
• Cancelable: Yes
• Context Info: None

Interface Accessibility

interface Accessibility {
  readonly attribute InterfaceObject accessibility; // Editorial Note: Is it necessary to define this attribute in the IDL?
  // objects implementing the Accessibility interface also implement the ScreenReader and AccessibilityNotifications interfaces
};
Accessibility implements AccessibilityNotifications;
Accessibility implements ScreenReader;
Accessibility implements Magnifier;
Accessibility implements Speech;

[Supplemental, NoInterfaceObject]
interface AccessibilityNotifications {
  void elementsChanged();
  void screenChanged();
};

Methods for Interface Accessibility

Interface ScreenReader

The screenreader attribute of the Accessibility interface must return an instance of the ScreenReader interface:

interface ScreenReader {
  readonly attribute InterfaceObject screenreader; // Editorial Note: Is it necessary to define this attribute in the IDL?
  // objects implementing the ScreenReader interface also implement the interfaces given below
};
ScreenReader implements ScreenReaderID;
ScreenReader implements ScreenReaderStatus;

[Supplemental, NoInterfaceObject]
interface ScreenReaderID {
  readonly attribute DOMString name;
  readonly attribute DOMString version;
};

[Supplemental, NoInterfaceObject]
interface ScreenReaderStatus {
  readonly attribute boolean active;
};

Properties for Interface ScreenReader

Note: The authors recommend that user agents adopt a domain-level security policy for the ScreenReader interface that is similar to the security policy for location data or cookies. A user should be able to explicitly disallow sharing of this information altogether, or on a per-domain basis.

Methods for Interface ScreenReader

Interface Magnifier

The magnifier attribute of the Accessibility interface must return an instance of the Magnifier interface:

interface Magnifier {
  readonly attribute InterfaceObject magnifier; // Editorial Note: Is it necessary to define this attribute in the IDL?
  // objects implementing the Magnifier interface also implement the interfaces given below
};
Magnifier implements MagnifierID;
Magnifier implements MagnifierStatus;
Magnifier implements MagnifierNotifications;

[Supplemental, NoInterfaceObject]
interface MagnifierID {
  readonly attribute DOMString name;
  readonly attribute DOMString version;
};

[Supplemental, NoInterfaceObject]
interface MagnifierStatus {
  readonly attribute boolean active;
};

[Supplemental, NoInterfaceObject]
interface MagnifierNotifications {
  void focusPosition(
         in DOMElement element,
         in optional array cursorRect,
         in optional array selectionPolygon
       );
};

Properties for Interface Magnifier

Methods for Interface Magnifier

Interface Speech

The speech attribute of the Accessibility interface must return an instance of the Speech interface:

interface Speech {
  // TBD, placeholder for speech-controlled user agents or assistive technology
  // may need speech.synthesis and speech.recognition; each could have name/version/engine, etc. 
  // potential method: speech.synthesis.speak() to trigger TTS from web app
  // potential method: speech.recognition.updateDictionary() to capture correct pronunciation of uncommon or app-specific words
};