Accessibility/ARIAConflictsWithNativeMarkup: Difference between revisions

The page is designed to extend section 3.2 "Conflicts between native markup semantics and ARIA" of the [http://www.w3.org/TR/wai-aria-implementation/#mapping_conflicts ARIA implementation guide] to get rid possible multiple treatments of the specification.

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

ARIA usage within native markup can be result of two conflict types. This is either ARIA overwhelms 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 upon native markup. Otherwise ARIA suppress any rules coming from native markup excepting some general native markup rules.

In the case of compatible roles or if ARIA role is not presented then user agent creates accessible for native markup element as usually 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 a place. For example,

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.

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

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

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