Use the ARIA
role attribute to provide more information about the structure of a
document for users of assistive technologies.
A limitation of the core HTML markup grammar is that it is not well-suited for differentiating common
publishing structures. There may be hundreds of
aside elements in a publication, for
example, but reliably identifying which ones represent notes from sidebars from warnings and alerts
has not been possible.
For sighted users, the deficiency this causes has been masked by the enhanced visual rendering that CSS style sheets afford (backgrounds, borders and shading are used to convey roles visually). For users of assistive technologies — which rely on an understanding of the underlying markup in order to facilitate navigation — Web-based technologies have only had limited accessibility because primary and secondary material was often indistinguishable below the visual surface.
To make publications more accessible, you need to consider that many users will be interacting with
the content in non-visual ways, and for that reason the logical reading
order must be defined at the markup level. To facilitate this discovery, the ARIA
role attribute allows more precise meanings to be applied to the generic tags.
The ARIA specification defines many roles, but the majority are intended to aid in making scripted HTML interfaces more accessible (see ARIA in the scripting section The core specification does contain a number of document structure roles and landmark roles, but these are focused primarily on the layout of web pages. It is more common in publishing to use the roles defined in the Digital Publishing WAI-ARIA modules.
epub:type attribute was intended to serve a similar
function to the ARIA
role attribute in EPUB 3, but accessibility support never
materialized. The attribute is useful for enabling certain user agent behaviors, such as pop-up
footnotes, but should not be used with expectations of enhancing the accessibility of
Refer to the EPUB Type to ARIA
Role Authoring Guide for a list of bad practices to avoid when switching from the
epub:type to the ARIA
As XHTML 1.0 was released before ARIA 1.0, EPUB 2 does not support the use of ARIA attributes. Inclusion of the attributes will result in validation errors.
Frequently Asked Questions
- Should I add a landmark role to every section?
No, landmarks are designed to allow the reader to quickly move to the primary sections of a publication, not stand in as an alternative to the table of contents.
If the DPUB-ARIA vocabulary does not include a role for a section, consider the impact on navigation before defining a new landmark with a
regionrole. Landmarks are a flat list list of destinations so overloading the list with subsections will only cause confusion.
- Does adding
titleto an untitled section create a landmark?
Yes, so care needs to be taken not to overload the landmarks list in this way. When a
sectionelement has a label, it is handled as though the
regionrole has been applied to it, which makes the section a landmark.
If an untitled section does not map to an existing landmark role, such as
doc-chapter, consider the impact on navigation before labelling it.
- Do I have to label every role?
No, whether a label is required depends on whether the role requires an accessible name. To determine if an accessible name is required, see the role's definition in the DPUB-ARIA or ARIA specification. If the role does not have an "Accessible name required" field in its list of properties, check the role's superclass (the value is inherited).
- Should I always label landmarks?
Best practice is to provide a label for landmarks using the
aria-labelledby(when a heading is present in the text) or
aria-labelattributes (when a section does not have an explicit heading).
Although labels are not required for DPUB-ARIA landmarks, support for the vocabulary is also not yet widespread. Adding a label ensures that default processing rules for HTML will create a landmark even if the vocabulary is not recognized (i.e., adding a label to a
sectionelement indicates to browsers to treat the section as an implied
regionwhen creating the accessibility tree).