Summary

Use the ARIA role attribute to provide more information about the structure of a document for users of assistive technologies.

Techniques

Examples

Example 1 — Chapters
<section role="doc-chapter" aria-labelledby="hd03">
   <h2 id="hd03">1 - It begins</h2>
   …
</section>
Example 2 — Footnote and reference
<p>lorum ipsum.<a role="doc-noteref" href="#fn01">1</a></p>
<aside role="doc-footnote">
   …
</aside>
Example 3 — Endnotes
<section role="doc-endnotes" aria-labelledby="hd-notes">
   <h1 id="hd-notes">Endnotes</h1>
   
   <section>
     <h2>Chapter 1</h2>
     <ol>
      <li role="doc-endnote">…</li>
      …
     </ol>
   </section>
   …
</section>

Explanation

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 3

The 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 epub:type to the ARIA role attribute.

EPUB 2

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 region role. Landmarks are a flat list list of destinations so overloading the list with subsections will only cause confusion.

Does adding aria-label or title to an untitled section create a landmark?

Yes, so care needs to be taken not to overload the landmarks list in this way. When a section element has a label, it is handled as though the region role 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-label attributes (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 section element indicates to browsers to treat the section as an implied region when creating the accessibility tree).

Related Links