Outdated Content!

The Protocols and Formats Working Group is no longer chartered to operate. Its work will continue in two new Working Groups:

  • https://www.w3.org/WAI/APA/ Accessible Platform Architectures, to review specifications, develop technical support materials, collaborate with other Working Groups on technology accessibility, and coordinate harmonized accessibility strategies within W3C; and
  • https://www.w3.org/WAI/ARIA/ Accessible Rich Internet Applications, to continue development of the Accessible Rich Internet Applications (WAI-ARIA) suite of technologies and other technical specifications when needed to bridge known gaps.

Resources from the PFWG remain available to support long-term institutional memory, but this information is of historical value only.

This Wiki page was edited by participants of the Protocols and Formats Working Group. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.

ARIA 2 Requirements

From Protocols and Formats Working Group Wiki
Jump to: navigation, search

Note: many of these ideas are adapted from a shared doc called "ARIA 2 Proposals", started by Aaron Leventhal, with contributions from many people in the accessibility community.

Some of these are minor and straightforward enough that they should probably be ARIA 1.1 requirements.

1. Requirement: allow web developers to indicate that focus a different element than the one that appears visually to be focused.

Attribute: aria-focusproxy="IDREF"

This attribute indicates to assistive technology that when this element has focus, the element referenced by #idref should be queried for accessible state information, as if that element had focus.

There are many reasons why a web author may choose to focus an element other than the one that looks and behaves like it's focused.

One reason is for custom text editors: custom text editors commonly focus an offscreen textarea or contenteditable to capture keystrokes and pasted text, but they use a different element to render the editable text.

Another reason is that limitations of the ARIA spec make it difficult to apply roles to complex markup. As an example, an element with an ARIA role of "listbox" must be the immediate parent of a node whose ARIA role is "option", which can present a problem if the element focused is not the parent of the listbox options.

Example 1:

<textarea class="offscreen" aria-focusproxy="editor"></textarea>
<div id="editor">
  The editable text goes here.
</div>

Example 2:

<div tabindex=0 aria-focusproxy="container">
  <div id="container" role="listbox" aria-activedescendant="o1">
    <div id="o1" role="option">Option 1</div>
    <div id="o2" role="option">Option 2</div>
    <div id="o3" role="option">Option 3</div>
  </div>
</div>

Note: this is similar to aria-activedescendant. Here are the distinctions:

  • aria-activedescendant is narrowly defined for composite controls such as list boxes, grids, trees, and combo boxes. aria-focusproxy is a global attribute.
  • With aria-activedescendant, the role and state of the element that has focus still has significance. WIth aria-focusproxy, the element that has focus has no significance at all - the assistive technology is supposed to completely ignore the element that actually has focus, and defer to the proxy element as if the proxy element had focus.
Note that in Example 2, both aria-focusproxy and aria-activedescendant are used. The outer
has focus, but it delegates to the inner listbox, so assistive technology should behave as if a listbox has focus. The listbox behaves as if it is the focused element, and its active descendant is the first option.

2. Requirement: support aria-setsize on ancestors.

To make ARIA less verbose, web developers should be allowed to put aria-setsize on the parent element of a list, not on each item.

Example 1:

<div aria-setsize="1000">
  <div aria-posinset="350">Item 350</div>
  <div aria-posinset="351">Item 351</div>
  <div aria-posinset="352">Item 352</div>
</div>

3. Requirement: ARIA grids should support rowspan and colspan.

ARIA should add the following attributes, which would be exact counterparts to their html table attributes:

 aria-colspan
 aria-rowspan

Example 1:

<div role="grid">
  <div role="row">
    <div role="gridcell">1, 1</div>
    <div role="gridcell">2, 1</div>
  </div>
  <div role="row">
    <div role="gridcell" aria-colspan="2" style="width: 400px">This spans 2 columns</div>
  </div>
</div>

4. Requirement: ARIA grids should support disjoint grids, for example with fixed headers and scrolling cells.

A web developer implementing a really long scrolling table or spreadsheet may wish to place the headers in one container, and the cells in another container. It should be possible to specify these relationships using ARIA.

Proposed syntax to be determined.

5. Requirement: web authors should be able to specify a JavaScript delegate function that's called in place of checking ARIA attributes, allowing web authors to programmatically respond to accessibility queries rather than computing it dynamically.

Two new methods are added to the Element prototype:

interface Element {
  void addAriaDelegate(in DOMString attribute, 
                       in AriaDelegate delegate,
                       in boolean subtree);
  void removeAriaDelegate(in DOMString attribute, 
                          in AriaDelegate delegate,
                          in boolean subtree);
}

Example 1: a button that dynamically computes its aria-label

<button id="dynamicButton">
  Insert today's date
</button>
<script>
  var button = document.getElementById('dynamicButton');
  button.addAriaDelegate('aria-label', function() {
    return "Insert " + (new Date()).toLocaleDateString();
  }, false);
</script>

Example 2: a listbox that dynamically computes an item's aria-posinset and aria-setsize for each option:

<div id="listbox" role="listbox">
  <div role="option" tabindex=0>Item 201</div>
  <div role="option" tabindex=-1>Item 202</div>
  <div role="option" tabindex=-1>Item 203</div>
</div>
<script>
  var listbox = document.getElementById('listbox');
  listbox.addAriaDelegate('aria-posinset', function(element) {
    return computePosInSet(element);
  }, true);
  listbox.addAriaDelegate('aria-setsize', function(element) {
    return computeSetSize(listbox);
  }, true);
</script>

Open questions:

  • Would there be a performance hit? How can web developers avoid it?
  • What happens if you set an attribute on an element that's already covered by a Delegate?
  • How do you handle multiple delegates? Should each one get a chance to pass and allow other delegates to respond?

6. Requirement: it should be possible to make a completely accessible custom text editor.

Note that this requirement depends on the aria-focusproxy requirement.

There are many examples of sites where the web author has chosen to build a custom text editor. The text may be rendered in HTML, Canvas, SVG, or some other mechanism, but the key distinction is that the editable text component does not directly inherit from a native HTML text editing element such as <input>, <textarea>, or an element marked contentEditable.

It's beyond the scope of this requirement to describe all of the possible reasons why web authors may choose to do this. Whatever the reason, custom text editors are widespread. Making existing editors accessible is feasible in the short-term; eliminating the need for any web author to ever want to create a custom text editor is a long-term goal. Still, here are some of the reasons web authors choose to build custom editors rather than extending contentEditable.

  • Custom text editors may want to support pagination.
  • Custom text editors may render only the current page on-screen, out of a larger document.
  • Custom text editors may want finer control over rich content pasted from the clipboard or copied to the clipboard from the document.
  • Custom text editors may want to implement custom formatting or layout that isn't provided by HTML, for example text that follows a curved path, or text that wraps around an image.
  • Custom text editors may want to support discontiguous selections.

Note that *all* of the above features have been implemented in real text editors, but *none* of the above features have even been proposed as drafts for contentEditable. The gap between what contentEditable is capable of doing and what web authors want to build is vast.

The additions to ARIA needed to make a custom text editor accessible is not a lot.

The simplest case is where the formatting and layout of the text for the custom text editor is already done using HTML; the only distinction is that the editor may not be focused, and the cursor or selection are simulated.

In the case where the text editor uses another mechanism to render the text, such as Canvas or SVG, the web author should provide accessible fallback content to be used by assistive technology. This fallback content should provide the semantic information needed to make the editable text accessible. In order to provide positioning information to a screen magnifier, absolutely-positioning the invisible fallback content to its correct approximate position on-screen is suggested.

The root element of a custom text editor shall have a role of "textbox". All of the following attributes only apply only to the element with role=textbox or to its descendants.

If the custom text editor does not have focus, aria-proxyfocus should be used on the focused element to indicate that functionally, the textbox is behaving like it has focus.

To indicate the position of the cursor or selection, three possible mechanisms are supported. The reason for these three mechanisms is to support the widest possible range of implementations. These mechanisms are checked in the following priority order: if the first one is present, the others are ignored, and so on.

1. The following attributes may be on the element with role=textbox: aria-selectionstart="#idref", aria-startoffset="#", aria-selectionend="#idref", aria-endoffset="#". The selection start and end elements and offsets are interpreted exactly the same way as startContainer, startOffset, endContainer, and endOffset are in a DOM Range element. 2. The following attributes may be on elements in the subtree of the element with role=textbox: aria-startoffset="#", aria-endoffset="#". 3. Elements may be inserted into the subtree with role="selectionstart", role="selectionend", and/or role="cursor".

To indicate the cursor position when no text is selected, the start and end offsets may point to the same offset.

There is no requirement that the selection start must be before the selection end. They are typically reversed when the selection was created in the reverse direction, and when pressing shift+left or shift+right would change the left/top edge of the selection rather than the right/bottom.

It's beyond the scope of this requirement to solve the problem of assistive technology modifying text and moving the cursor. That should ideally be addressed as part of Indie UI.

Example 1:

<div contentEditable id="hiddenContentEditable" tabIndex=0 aria-focusproxy="customtext"></div>
<div id="customtext" role="textbox" aria-selectionstart="line2" aria-startoffset="6" aria-selectionend="line2" aria-endoffset="11">
  <line id="line1">A B C</line>
  <line id="line2">Alpha Bravo Charlie</line>
</div>

Example 2:

<div contentEditable id="hiddenContentEditable" tabIndex=0 aria-focusproxy="customtext"></div>
<div id="customtext" role="textbox">
  <line id="line1">A B C</line>
  <line id="line2" aria-startoffset="6" aria-endoffset="11">Alpha Bravo Charlie</line>
</div>

Example 3:

<div contentEditable id="hiddenContentEditable" tabIndex=0 aria-focusproxy="customtext"></div>
<div id="customtext" role="textbox">
  <line id="line1">A B C</line>
  <line id="line2">Alpha <span role="selectionstart">Bravo<span role="selectionend"> Charlie</line>
</div>

7. Requirement: web authors should be able to reuse existing attributes rather than adding ids to elements they need to reference for accessibility.

Any place in the ARIA spec where an IDREF is allowed, a element-scoped query selector will be allowed instead. For backwards compatibility, a string is first interpreted as an IDREF. If that fails to exactly match an ID in the DOM, it's interpreted as an element-scoped query selector.

Note that user agents already have lots of code to efficiently track elements that might be affected by CSS rules whenever element attributes change. There's no reason these mechanisms couldn't be extended to make ARIA attributes containing query selectors efficient, too.

Example 1:

<div role="listbox" aria-activedescendant="div[tabindex=0]>
  <div role="option" tabindex=0>Alpha</div>
  <div role="option" tabindex=-1>Bravo</div>
  <div role="option" tabindex=-1>Charlie</div>
</div>

8. Web authors should be able to hint to assistive technology whether an element is interactive or not, meaning whether or not it responds to key events or any events other than a simple click/activate.

Background: many screen readers have a "focus mode", where keystrokes get passed through to the web application, and a "browse mode" or "virtual cursor mode" where many keystrokes directly control the screen reader rather than the web app. These screen readers often have an "auto focus mode" feature, where certain elements such as text boxes and combo boxes automatically enter focus mode, and other elements do not. Even without auto focus mode, the user can enter focus mode on one of these elements usually simply by pressing Enter, rather than by pressing some more obscure keystroke.

The problem is that sometimes a web author wants to add interactive semantics to an element that doesn't normally cause the screen reader to enter focus mode. When this happens, a web app that's nominally keyboard-accessible becomes cumbersome to use with this type of screen reader.

This requirement aims to address the problem in a generic way without being tied to specific screen reader implementation details.

If an element is not focusable, this attribute does not apply.

A focusable element that's "interactive" is simply one that listens for any events other than a simple "click" or "activate".

By default, any kind of text box, combo box, list box, grid, or tree control is interactive. Other focusable elements like links and buttons are not.

A web author can use this feature, for example, to build an accessible presentation editor. Every element in the presentation might be focusable, but some of them would have roles like heading, link, button, or even just static text. Interacting with one of these elements might allow you to move them around the page by pressing the arrow keys.

Example 1:

<button>Simple button</button>
<button aria-interactive="true">Button that responds to additional keys</button>

9. Requirement: add an attribute to specify if dialogs are modal or not.

Note that HTML5 now includes a dialog element. The ARIA roles of dialog and alertdialog are superfluous when used with an HTML5 dialog, but they're still useful for improving accessibility of sites that don't want to or can't take advantage of the HTML5 element.

Any element with role=dialog or role=alertdialog should have another optional attribute aria-modal. If true, this should be a strong signal to assistive technology that the scope should be limited to the contents of the dialog unless the user explicitly overrides this mode and escapes the dialog context.

As an example, a screen reader user who presses a key to jump to the top of the page should be sent to the top of the modal dialog. Reaching the end of the dialog should be similar to reaching the end fo the page.

Example 1:

<div role="dialog" aria-modal="true">
  Are you sure you want to delete this file?
  <div>
    <button>Delete</button>
    <button>Cancel</button>
</div>

10. Requirement: Support grouped text fields.

It's common for web forms to use multiple adjacent text fields to represent separate components of a larger whole. Examples include telephone numbers (in the U.S., a 3-digit area code, 3-digit prefix, and 4-digit suffix), times, dates, IP addresses, and other composite control.

The HTML fieldset element can sometimes be used to group related fields. However, it may not make sense for the web author to use a fieldset. In fact, the relation between the fields may be obvious to a sighted user. What's needed is to convey that relationship to assistive technology.

Assistive technology could use this information to provide feedback about the current position relative to the total number of fields, or even to logically group the text from all of the fields into one virtual buffer.

Specifically, there should be a new role "fieldset" that inherits from group. For backwards compatibility, authors can specify "group fieldset".

Example 1:

<div role="group fieldset" aria-label="Telephone number">
  <input type="text" maxlength=3>
  <input type="text" maxlength=3>
  <input type="text" maxlength=4>
</div>

11. Requirement: Support time and date pickers.

There are two components to date and time pickers - a particular implementation may use either one or both:

1. A composite input field - for example, a fieldset of three text fields representing the year, month, and day, or hours, minutes, and seconds.

2. A graphical picker, especially a calendar grid for a date.

When both are present - for example a date picker where a 2-dimensional graphical picker appears when you focus the date picker - aria-activedescendant should be used to indicate the cell in the graphical picker that corresponds to the current date.

Specifically, new roles "datepicker", "timepicker", and "datetimepicker" are all subroles of "fieldset". They're used on container elements for date or time pickers that contain other elements; they specify that all of the fields collectively convey a date and/or time.

When both a composite input field and graphical picker are present, *both* should have a role of, e.g. datepicker.

Example 1:

<div role="group datepicker" aria-label="Check-in date" aria-activedescendant="cal_selected">
  <input type="text" aria-label="Year" placeholder="yyyy" maxlength=4>
  <input type="text" aria-label="Month" placeholder="mm" maxlength=2>
  <input type="text" aria-label="Day" placeholder="dd" maxlength=2>
</div>
<div id="calendar" role="group datepicker">
  <div>
    <button>Previous month</button>
    <button>Previous month</button>
  </div>
  <table role="grid">
    <tr>
      <th>Sun</th><th>Mon</th><th>Tue</th><th>Wed</th><th>Thu</th><th>Fri</th><th>Sat</th>
    </tr>
    <tr>
      <td>1</td><td>2</td><td>3</td><td>4</td><td>5</td><td>6</td><td id="cal_selected">7</td>
    </tr>
     ...
   </table>
</div>

12: Requirement: Make it easier for web authors to mark an element as a leaf node.

DEPRECATED - this would be solved by role='text' in the latest ARIA 1.1 spec

It's like aria-hidden but doesn't exclude the node itself, just its descendants. As an example, suppose I have a div with 100 image elements as children. I want the outer div to have role=img and aria-label=collage, but I don't want the descendant images to be exposed to assistive technology. Adding aria-hidden to all of them would be cumbersome, and adding an intermediate node in-between could mess up existing CSS.

Specifically, aria-leaf="true" means that this object has no children in the accessibility tree.

Example 1:

<div role="img" aria-label="3 stars" aria-leaf="true">
  <img src="star.png">
  <img src="star.png">
  <img src="star.png">
  <img src="empty.png">
  <img src="empty.png">
</div>

13: Requirement: Make it possible to apply ARIA using (CSS-style) selectors.

DEPRECATED - this would be solved by Cascading Attribute Sheets: http://www.xanthir.com/blog/b4K_0

Note that it isn't a requirement that ARIA be specified in stylesheets. ARIA isn't really style. Rather, the goal is that ARIA attributes could be specified using rules that apply to many elements. This would greatly simplify the task of applying ARIA properly to complicated web apps that already have a lot of structure but don't have the right accessible markup.

Example 1:

ARIA style section:
.mylist {
  role: listbox;
}
.myitem {
  role: option;
  aria-setsize: 25;
}
.myitem.selected {
  aria-selected: true;
}

HTML:
<div class="mylist" tabindex=0>
  <div class="myitem">Item 1</div>
  <div class="myitem" selected>Item 2</div>
  <div class="myitem">Item 3</div>
</div>

14. Requirement: Allow specifying step size for range controls.

An ARIA slider exposes its min, max, and current value, but no step size. Indie UI provides a way to change the value, but even absent that it might be valuable for assistive technology to know the plausible step size that's allowed when changing a range value.

Note that <input type=range> already supports a step attribute.

Example 1:

<div role="slider" aria-valuemin=0 aria-valuemax=100 aria-valuestep=10 aria-value=70>70%</div>

15. Requirement: Add an ARIA attribute to allow elements to specify their keyboard shortcut.

The keyboard shortcut is not functional, it's informational. It informs the assistive technology that a shortcut exists to perform the default action for the given element. It's still up to the app to implement the keyboard event handler.

This allows AT to announce the keyboard shortcut along with a control when it's focused, or even query the page for a list of all keyboard shortcuts to present them to the user.

Example 1:

<button aria-keyboardshortcut="Ctrl+N">Create new document</button>