Accessibility/ARIAConflictsWithNativeMarkup

Summary

The page is designed to extend section 3.2 "Conflicts between native markup semantics and ARIA" of the ARIA implementation guide to get rid of possible multiple treatments of the specification.

Proposal

When the page is mapped to accessibility API then ARIA wins over native markup if any conflict occurs, i.e. the rules of native markup mapping are overridden by rules of ARIA markup mapping because ARIA is essentially an override.

Conflicts settlement

ARIA usage within native markup can be the result of two conflict types. This is either ARIA overrules mapping rules of native markup or ARIA is mapped upon native markup. It depends on compatibility of ARIA role and role from native markup. Thus if roles are consistent or no ARIA role was used then ARIA is mapped on top of native markup. Otherwise ARIA suppresses any rules coming from native markup excepting some general native markup rules.

ARIA applied on top of native markup

In the case of compatible roles or if ARIA role is not present, then user agent creates accessible for native markup element as usual with one exception. If ARIA markup and native markup are mapped to the same accessibility API properties then ARIA wins. Otherwise implementation coming from native markup accessible takes place. For example,

  <ul role="list">
    <li role="listitem" aria-selected="true">item</li>
  </ul>

Here, there is no conflict between ARIA and native markup roles. User agent should create accessible objects based on original accessibles for HTML ul and HTML li elements. ARIA role and aria-selected should be mapped to accessibility API before methods of original accessible will be called. In that way, for example, accessible object created for HTML li should have selected state.

Let's consider another example.

 <input aria-disabled="true"/>

Here there is conflict since input isn't disabled and therefore its native accessible object shouldn't have disabled state. But since aria-disabled is used then result accessible object should expose disabled state.

ARIA suppresses native markup

When ARIA role is incompatible with role coming from native markup then user agent should create generic accessible object. However the accessible object should reflect any general rules peculiar to all elements from native markup. For example,

  <a role="button" title="it's a button">button</a>

Here @title attribute is peculiar to all elements of HTML document and it should be mapped to accessibility name since ARIA doesn't override it. On the other hand, user agent shouldn't create specific accessible for HTML a. In that way, for example, traversed and etc states specific for link accessibles shouldn't be exposed.

Let's consider an example:

  <table role="label">
     <tr>
       <td>cell</td>
     </tr>
  </table>

In this case ARIA role="label" placed on HTML table should force user agent to not create specific accessible objects for neither HTML table nor its descendants, for example, these objects shouldn't have table, row or cell roles and shouldn't implement any interfaces specific for tables (like IAccessibleTable2 or IAccessibleTableCell in the case of IAccessible2 API).

Compatible and incompatible roles

Any weak ARIA role (i.e. ARIA role not mapping to accessibility API role) is not in conflict with native markup roles, for example, "banner", "search" and other ARIA landmark roles.

Strong (not weak) ARIA roles are compatible with predefined set of HTML elements only. Strong ARIA roles override conflicting native semantics.

HTML elements having no conflict with ARIA roles

HTML element	ARIA roles
a	link
div	section
#document	document, dialog
button	button
img	image
input	textbox
input@type="checkbox"	checkbox
input@type="radio"	radio
input@type="button"	button
li	listitem? menuitem? treeitem?
option	listitem
select	combobox
select@size>"1"	listbox
table	grid, treegrid
td	gridcell
th	columnheader, rowheader
tr	row
ul	list?