Use the ARIA
role attribute to provide more information about the structure of a
document for users of assistive technologies.
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).
A limitation of the core HTML markup grammar is that it is not well-suited for identifying common
publishing structures because of its small set of elements. There may be hundreds of
elements in a publication, for example, but reliably distinguishing 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.
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 publications.
Refer to the EPUB Type to ARIA Role
Authoring Guide for a list of bad practices to avoid when switching from the
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.