Accessibility/WebAccessibilityAPI: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 171: Line 171:


<pre>
<pre>
jump
activate
   exposed on links, base action: activate
   exposed on accessible elements that may be activated
</pre>
 


<pre>
subactions
press
  jump on links, press on buttons, check/uncheck on checkboxes
  exposed on buttons, activate
</pre>
 
 
<pre>
activate
  exposed on accessible elements that might be activate
</pre>
</pre>


Line 192: Line 183:
</pre>
</pre>


<pre>
scroll
scroll
   scrolls the accessible element into view, optionally takes coordinates relative the element to scroll the view to
   scrolls the accessible element into view, may take coordinates relative the element to scroll the view to
  parameter: pos of Position
optional argument: Position
  directory Position {
directory Position {
    int x;
  int x;
    int y;
  int y;
  };
};
</pre>


===Parent-child relations===
===Parent-child relations===

Revision as of 20:57, 15 January 2015

Introduction

There's number of objectives on the web to improve accessibility and usability support. The web applications want to provide special support for their users, helping them navigate and perceive the content. The browser has number of add-ons that serve to improve accessibility support, for example, landmarks navigation. These tasks requires accessibility API similar to what desktop assistive technologies have.

Also web accessibility API allows in-browser automated accessibility testing of web content, i.e. helpful to check HTML and other standards in the browser is accessible to all users.

Web accessibility API

The API provides a generic accessibility interface that allows you to receive accessible object properties, traverse accessible hierarchy and interact with the accessible object. This interface can be requested from DOM node.

Node interface extension

DOM Node interface should be extended by

interface Node {
  AccessibleElement? accessibleElement;
};

AccessibleElement

This is basic interface implement by all accessible objects.

interface AccessibleElement {
  readonly attribute DOMString role;
  readonly attribute sequence<DOMString> states;

  readonly attribute DOMString name;
  readonly attribute DOMString description;
  readonly attribute DOMString value;
  readonly attribute Rect bounds; 

  readonly attribute any getAttribute(in DOMString name);
  readonly attribute sequence<AccessibleElement>? getRelations(in DOMString type);

  readonly attribute sequence<DOMString> actions;
  void activate(in unsigned int actionIndex);

  readonly attribute AccesibleElement? parent;
  readonly attribute AccesibleElement? firstChild;
  readonly attribute AccesibleElement? lastChild;
  readonly attribute AccesibleElement? nextSibling;
  readonly attribute AccesibleElement? lastSibling;
  // do we need getChildAt and indexInParent?

  readony attribute Node? DOMNode;
};

Basic getters

AccessibleElement .role
    Returns accessible role.

Returns string representation for the accessible role of the accessible element. Examples: "button", "menu", "textfield".

AccessibleElement .states
    Returns accessible states.

Returns string list of states applied to the accessible element. Examples: "focusable", "focused", "selectable".

AccessibleElement .name
    Returns accessible name.

Returns accessible name of the accessible element.

AccessibleElement .description
    Returns accessible description.

Returns accessible description of the accessible element.

AccessibleElement .value
    Returns accessible value.

Returns accessible value of the accessible element if applicable.

AccessibleElement .bounds
    Returns boundaries of the accessible element.

Returns boundaries for the accessible element in client coordinates.

Attributes

The accessible element may support any of attributes outlined below. Also it may expose its custom attributes.

AccessibleElement .getAttribute(in DOMString name)
    Returns the attribute.

Return the attribute by name.

Attribute list

A typical accessible element may support the following attributes:

DOMString accessKey;
    Returns access key associated with the accessible element like "alt+letter".

DOMString keyboardShortcut;
    Returns keyboard shortcut used to activate the accessible element, like "ctrl+letter".
int groupSize;
    Returns a number of items withing the group this accessible element belongs to. If no group then -1.

int indexInGroup;
    Returns an index in the group this accessible element belongs to. If no group then -1.

int level;
    Returns level in hierarchy the accessible element belongs to. -1 if doesn't belong to any hierarchy.
int minvalue;
   Returns minimum possible value.

int maxvalue;
    Returns maximum possible value;

int step;
    Returns step value (iteration between next values).

Relations

sequence<AccessibleElement> .getRelations(in DOMString type)
    Returns related accessible elements.

Return sequence of related accessible elements for given relation type.

Relation types

name_for/named_by
description_for/described_by
?do we need it

Actions

The accessible element may allow set of actions that can be invoked on it. These can be "activate" having accessible element specific semantic like "jump" or "press", or it can be generic actions like "scrollto" or "focus". Certain accessilbe actions may take extra parameters.

AccessibleElement .activate(in DOMString name, in optional any argument)
    Invokes the accessible action.

Performs the given accessible action on the accessible element.

Action list

activate
  exposed on accessible elements that may be activated

subactions
  jump on links, press on buttons, check/uncheck on checkboxes
focus
  focus the accessible element
scroll
 scrolls the accessible element into view, optionally takes coordinates relative the element to scroll the view to
 parameter: pos of Position
 directory Position {
   int x;
   int y;
 };

Parent-child relations

The interface provides a bunch of methods to provide access to parent/child relations between accessible elements.

AccessibleElement .parent
  Returns parent.

Returns the parent accessible element if any.

AccessibleElement .firstChild
  Returns first child.

Returns the first child accessible element if any.

AccessibleElement .lastChild
  Returns last child.

Returns the last child accessible element if any.

AccessibleElement .nextSibling
  Returns next sibling.

Returns the next sibling accessible element if any.

AccessibleElement .previousSibling
  Returns previous sibling.

Returns the previous sibling accessible element if any.

Other

AccessibleElement .DOMNode
  Returns DOM node.

Returns the DOM node associated with the accessible element if any. The accessible element does not have a DOM node, either when it has been unattached from the DOM node or it's not DOM node based. The first case happens when the javascript holds reference to the object longer than the object life cycle requires. The second case may happen because of browser-specific implementation or in javascript created trees.

Tree traversal

Traversal/search stuff:

Text navigation, move by chars, words, lines. Structure navigation: move by paragraphs, sections, headers, main, side. Landmarks navigation Search/Filters

Action stuff: select, caret

Obtaining: from point, from accessible, from selection

Description:

Position/Range

VirtualCursor interface? AccessibleText interface?

interface AccessibleTextRange {
  //start/end points
};

Accessible Document

interface AccessibleDocument {
  sequence<DOMString> getTaxonomy(in DOMString type, in DOMString value);
  void buildTaxonomy(in DOMString type, in DOMString newbie, in sequence<DOMString> base)
    raises(DOMException);
};

Taxonomies

You can get hierarchical relations between roles, states or actions. For example, if the web author introduces a role 'x-checklistitem' that is compounded from two roles 'checkbox' and 'listitem' and supposed to inherit properties of both then the web author should integrate the new role into existing hierarchy.

AccessibleDocument .getTaxonomy
    Returns a sequence of base items
    Parameters
      type
          a taxonomy type, supported values are 'role' or 'action'
      value
          a value the taxonomy is requested for

Returns a sequence of base item the given item is inherited from. For example, for 'checkmenuitem' role it will return 'checkbox' and 'menuitem' roles.

AccessibleDocument .buildTaxonomy
    Adds the item into hierarchy
    Parameters
      type
          a taxonomy type, like 'role' or 'action'
      newbie
          a new item put in hierarchy
      base
          a list of base items the new item is inherited from

Adds a new value into hierarchy. Example,

a11ydoc.buildTaxonomy('role', 'x-checklistitem', [ 'checkbox', 'menuitem' ]);

JavaScript trees

The web developer can create accessible element tree right in JavaScript and attach it to existing accessible element. For example, if the author wants to make accessible charts drawn in canvas then javascript accessible tree is a right thing for this.

callback interface JSAccessilbeElement {
  readonly attribute any getAttribute(in DOMString name);
  readonly attribute sequence<AccessibleElement>? getRelations(in DOMString type);
};

Attributes

JSAccessibleElement .getAttribute

The javascript accessible element may answer to all attributes listed by AccessibleElement. Also it may expose custom attributes. Examples of plausible attribute the js object will return: "role", "states", "bounds".

Relations

JSAccessibleElement .getRelations

The object may support number of relations type listed by AccessibleElement. It may also expose custom relation type as long as target AT is fine with that.

Extensibility

The web application might need to extend default taxonomies to express the new semantics. For example, the web service publishing music sheets can introduce new characteristics like role, states, etc to describe music sheet content. However the web application should take care to explain new characteristic by extending default taxonomies, i.e. by describing the connection between old and new characteristics. That will resolve any backward compatibility issue, so if the consumer doesn't know about new roles then he can still figure out a closest match it's aware about. For example, if the web app author introduces "x-redbutton' and provides a role taxonomy for it saying this is an extension of 'button' role, then the consumer unfamiliar with 'x-redbutton' role will treat it as a button.

The author should follow name convention to avoid potential collisions with future additions into the spec predefined lists. Thus all names should be prefixed by 'x-' like 'x-redbutton' from example above.

Music sheet example

To make a music sheet accessible the web app may introduce bunch of new roles, attributes and relations:

roles:
  'sheet' - inherited from 'section'
  'note' - inherited from 'image', describes the note
role 'sheet' attributes:
  instrument: DOMString,
  tempo: number/DOMString
  clef: DOMString
role 'note' attributes:
  key: enum { C, D, E, F, G, A, H },
  alteration: enum { none, flat, sharp },
  octave: enum { ... },
  duration: number,
  effects: sequence<DOMString>, // tremolo, bend
role 'note' relations:
  crescendo: [note, ...] a list a notes the crescendo is applied to
  diminuendo: [note, ...] a list a notes the diminuendo is applied to