Confirmed users
1,396
edits
Accessibility/ARIAConflictsWithNativeMarkup: Difference between revisions
Jump to navigation
Jump to search
Accessibility/ARIAConflictsWithNativeMarkup (view source)
Revision as of 08:33, 1 September 2009
, 1 September 2009→Proposal
(Created page with '=Summary= The page is designed to extend 3.2 "Conflicts between native markup semantics and ARIA" of the [http://www.w3.org/TR/wai-aria-implementation/#mapping_conflicts ARIA imp…') |
|||
| Line 3: | Line 3: | ||
=Proposal= | =Proposal= | ||
ARIA markup wins native markup if any conflict is occurred, i.e. mapping native markup to accessibility API is overridden by mapping ARIA markup because ARIA is essentially an override. | |||
ARIA usage within native markup can be result of two types of conflicts. This is either ARIA overwhelms mapping rules of native markup at all or ARIA is mapped upon native markup. It depends on if ARIA role and role of native content are consistent or no ARIA role was used. | |||
==Consistent roles== | |||
Con | |||
==Inconsistent roles== | |||
Let's consider an example: | |||
<code> | |||
<table role="label"> | |||
<tr> | |||
<td>cell</td> | |||
</tr> | |||
</table> | |||
</code> | |||
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, i.e. these objects shouldn't have role table or role cell and etc and shouldn't implement any interfaces specific for tables (like IAccessibleTable2 or IAccessibleTableCell in the case of IAccessible2 API). | |||
When ARIA role is inconsistent with role coming from native markup then user agent should create generic accessible objects. | |||