This is the abstract for your specification.

Custom status paragraph

Abstract

This specification, in conjunction with the User Context Module, is intended address the problem of device-, OS-, and localization-independent control of web content.

placeholder for remaining intro

UI Change Request Events

The core principle behind UI Change Request Events is that they operate on a completely backwards-compatible, opt-in basis. In other words, the web application author has to be aware of these events and register event listeners, or the user agent and assistive technology behave as they normally would.

Change request events do not cause any direct manipulation or mutation of the DOM. Instead, the event object conveys the user's intent to the web application, and allows the web application to make the appropriate changes to the DOM, on behalf of the user agent or assistive technology. If a web application is authored to understand the change request event, it can cancel the event using preventDefault(), which informs the user agent or assistive technology that the event has been captured and understood. If a web application does not cancel any change request event, the user agent or assistive technology can then attempt fallback behavior or communicate to the user that the input has not been recognized.

Note: The UIRequestEvent interface does not inherit from AccessibilityEvent (proposed in the following section), because we believe it will ultimately be useful outside the context of assistive technology. This may prove to be a lightweight, performant alternative to mutation events. For example, DOMAttrChangeRequest instead of DOMAttrModified.

Event fires on document.activeElement (or AT equivalent) if applicable, or otherwise document.body.

These events should be asynchronous, but when used in conjunction with keyboard events, should fire after keydown, but before both keyup and keypress.

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    DISMISS  =  3;
  const unsigned short    DELETE   =  4;
  const unsigned short    EXPAND   =  5;
  const unsigned short    COLLAPSE =  6;
  // 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
DismissRequest

Initiated when the user agent or assistive technology sends a 'dismiss' 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
ExpandRequest

Initiated when the user agent or assistive technology conveys intent to reveal information in a collapsed section (e.g. a disclosure widget) or branch node in a hierarchy (e.g., a tree view).

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

Initiated when the user agent or assistive technology conveys intent to hide or collapse information in an expanded section (e.g. a disclosure widget) or branch node in a hierarchy (e.g., a tree view).

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

Examples

  1. Users, wanting to 'undo' a discrete action in a web application, can indicate their intent a number of ways, including pressing Control+Z on Windows or Linux, Command+Z on Mac OS X, and even by shaking some accelerometer- or gyroscope-enabled mobile devices. User agents understanding this intent should initiate an UndoRequest event. Web authors who have registered for this event should process the event to determine whether to cancel the event. If the 'undo' action is understood in the context of the web application, web authors should undo the user's change, and cancel the event using the event object's preventDefault() method.
  2. Users, wanting to 'escape from' or 'dismiss' a web application state (for example, closing a modal dialog), can indicate their intent a number of ways, including pressing Escape on most keyboard-controlled operating systems, or by using a two-finger scrub gesture in VoiceOver on iOS or Mac OS X. User agents understanding this intent should initiate an DismissRequest event. Web authors who have registered for this event should process the event to determine whether to cancel the event. If the 'dismiss' action is understood in the context of the web application, web authors should perform the appropriate action (such as closing the dialog), and cancel the event using the event object's preventDefault() method.

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 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

Example

Users, wanting to change the value of a custom range widget (slider, media progressbar, etc.) in a web application, can indicate their intent a number of ways, including pressing various keys (Up, Down, Left, Right, PageUp, PageDown, Home, End) on most keyboard-controlled interfaces, and through gestures on many touch-enabled interfaces. User agents understanding this intent should initiate a ValueChangeRequest event. Web authors who have registered for this event, should process the event to determine whether to cancel the event. If the value change action is understood in the context of the web application, web authors should change the value of the associated widget by an amount determined via the changeType argument, and cancel the event using the event object's preventDefault() method. If the event is not cancelled by the web author, user agents may pass the literal interaction event to the web application; in this case, in the form of a keypress or touch event.

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

Examples

  1. If a user wanted to expand or collapse the current node of an ARIA tree, the assistive technology would initiate a DOMAttrChangeRequest event on the tree item element, with the attrName equal to aria-expanded, and the newValue equal to true or false.
  2. If a user wanted to sort an ARIA grid on a particular column, the assistive technology would initiate a DOMAttrChangeRequest event on the column header element, with the attrName equal to aria-sort, and the newValue equal to ascending or descending.

Accessibility Events

The following events are only initiated by assistive technologies, as opposed to mainstream user agents.

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:

ATFocusIn

Initiated when the assistive technology cursor or point of regard moves to a particular DOM node.

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

Initiated when the assistive technology cursor or point of regard 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 DismissRequest 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