Spec Review/ARIA

Under review:

• WAI-ARIA

Joseph Scheuhammer

First, a general comment about section 3.2.5 "WAI-ARIA".  There should be a statement that the implicit/default WAI-ARIA roles are not added to the DOM by a user agent.  That this is the case is implied, albeit loosely, in the definition of "no role", specifically in the parenthetical:

"When [no role is] used as a default implied ARIA semantic, it means the user agent has no default mapping to ARIA roles. (However, it probably will have its own mappings to the accessibility layer.)"

Here is a concrete example:  html5 has an <input type="date"> element that represents a date editor.  There is no corresponding "date editor" ARIA role.  However, there is, in IAccessible2, an IA2_ROLE_DATE_EDITOR.  It's likely that a user agent will expose an <input type="date"> as an IA2_ROLE_DATE_EDITOR if running on an IAccessible2 platform.

The point:  user agents will expose accessibility information via an accessibility API even when there are no ARIA attributes in the source markup.  The tables show the default/implicit mapping between html5 elements and accessibility APIs.  ARIA's use here is a way of expressing that default mapping without stating it for each accessibility API*.  ARIA is being used only as a lingua franca for all such APIs, but the implicit ARIA information is not added to the DOM.

There should be a clear statement to that effect.

* for comparison, see the explicit mapping between ARIA and six accessibility APIs as documented in the ARIA User Agent Implementation Guide. 

discuss

Some more specific issues follow.

Note the following questions are good questions but have answers, have created ACTION-131 to address them.

First table -- Strong native semantics and default implied ARIA semantics

1. The <menu type="context"> element represents a context menu.  That is, a menu that is invoked typically with a right click on empty space.  Such menus are not triggered by a menu item in a menu bar, nor by pressing a button.  They are menus, nonetheless.  The table states that context menus have no implicit ARIA role.  Why isn't the implicit ARIA role "menu"?
2. The <input type="search"> element represents a search field -- a text input field that is specifically used for searching.  The table suggests the implicit ARIA role is "text".  Why not use the ARIA role "search"?
3. Conversely, <input type="time">, <input type="datetime">, <input type="datetime-local">, <input type="month"> have no implicit ARIA role.  Why isn't their implicit role "textbox"?  A possible answer is that there are appropriate roles in some accessibility APIs, and that the <input> should be exposed as the appropriate role where possible.  Is that the intent here?  If so, the implicit role mapping should be (using the time type as an example), "if the accessibility API supports a time role, expose the <input type="time"> as such; otherwise, fall back to a role of textbox."
4. The <optgroup> element is documented as having no implicit ARIA role.  Is it not semantically similar to the "group" role?

Second table  -- restrictions

1. Possible overrides for the <a> element include "checkbox", "menuitemcheckbox", and "menuitemradio".  It's not clear why "radio" is not also allowed.  An <a> element can be appear as a checkbox either inside or outside a menu; but, only as a radio button when within a menu.  Why is that a restriction?
2. Similarly, a <button> can be overridden by a "menuitemcheckbox", but not a "checkbox".  Why a checkbox only when in a menu?
3. This is more of a logical exercise: Heading elements, <hN>, can be overidden with the "link" role, but the <a> element cannot be overridden with the "heading" role.  Thus, a heading can become a link, but a link cannot be made into a heading.  Why the asymmetry?
4. It's unclear what the implied default role (2nd column) for <hN> elements that <em>are</em> within an <hgroup>.  Is it the case that the highest ranking <hN> within the <hgroup> determines the default ARIA role for the <hgroup> element, and, all the <hN> elements within the group have no role?  Is that the rationale?  And, if it is, how are the <hN> elements represented in the accessibility tree when they are within an <hgroup>? See ISSUE-164
5. Similary, for <li> elements that are not children of an <ol> or <ul>: what is their default role?  None?  How are such "isolated" <li> elements to be represented in the accessibility tree?