Read This First
No ARIA is better than Bad ARIA. Before using any ARIA, read this to understand why.
How to build accessibility semantics into web patterns and widgets
No ARIA is better than Bad ARIA. Before using any ARIA, read this to understand why.
Like an HTML table
element, a WAI-ARIA table is a static tabular structure containing one or more rows that each contain one or more cells; it is not an interactive widget.
Thus, its cells are not focusable or selectable.
The grid pattern is used to make an interactive widget that has a tabular structure.
However, tables are often used to present a combination of information and interactive widgets. Since a table is not a widget, each widget contained in a table is a separate stop in the page tab sequence. If the number of widgets is large, replacing the table with a grid can dramatically reduce the length of the page tab sequence because a grid is a composite widget that can contain other widgets.
As with other WAI-ARIA roles that have a native host language equivalent, authors are strongly encouraged to use a native HTML table
element whenever possible.
This is especially important with role table
because it is a new feature of WAI-ARIA 1.1.
It is thus advisable to test implementations thoroughly with each browser and assistive technology combination that could be used by the target audience.
div
and span
elements.aria-sort
in the headers of sortable columns.Not applicable.
table
element or an element with role rowgroup.row
element and has one of the following roles:
If rows or cells are included in a table via aria-owns, they will be presented to assistive technologies after the DOM descendants of the table
element unless the DOM descendants are also included in the aria-owns
attribute.
This is an unpublished draft preview that might include content that is not yet approved. The published website is at w3.org/WAI/.