Digital Publishing WAI-ARIA Module 1.1

W3C Candidate Recommendation Snapshot

More details about this document
This version:
https://www.w3.org/TR/2024/CR-dpub-aria-1.1-20240227/
Latest published version:
https://www.w3.org/TR/dpub-aria-1.1/
Latest editor's draft:
https://w3c.github.io/dpub-aria/
History:
https://www.w3.org/standards/history/dpub-aria-1.1/
Commit history
Implementation report:
https://www.w3.org/2024/02/27-dpub-aam-1.1-implementation-report.html
Editors:
Matt Garrish (DAISY Consortium)
Tzviya Siegman (Wiley)
Former editors:
Shane McCarron (Spec-Ops)
Markus Gylling (DAISY Consortium)
Feedback:
GitHub w3c/dpub-aria (pull requests, new issue, open issues)

Abstract

Enabling users of assistive technologies to find their way through web content requires embedding semantic metadata about web document structural divisions. This is particularly important for structural divisions of long-form documents and goes along with embedding semantic metadata about web-application widgets and behaviors for assistive technologies. This specification defines a set of WAI-ARIA roles specific to helping users of assistive technologies navigate through such long-form documents.

This document is part of the WAI-ARIA suite described in the WAI-ARIA Overview.

Status of This Document

This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

Feature development for this version is complete. This is a Candidate Recommendation published to obtain implementation feedback before finalization of the specification.

While feedback on any aspect of the specification is encouraged, we would particularly like feedback on the addition of the doc-pageheader and doc-pagefooter roles.

Comments are welcome at any time but most especially before 27 April 2024.

There have been only minor clarifications since the First Public Working Draft.

This document was published by the Accessible Rich Internet Applications Working Group as a Candidate Recommendation Snapshot using the Recommendation track.

Publication as a Candidate Recommendation does not imply endorsement by W3C and its Members. A Candidate Recommendation Snapshot has received wide review, is intended to gather implementation experience, and has commitments from Working Group members to royalty-free licensing for implementations.

This Candidate Recommendation is not expected to advance to Proposed Recommendation any earlier than 27 April 2024.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 03 November 2023 W3C Process Document.

1. Introduction

This section is non-normative.

WAI-ARIA is a technical specification that defines a common host language semantic accessibility API and framework that enables web browsers to map the accessibility semantics in web content to platform-specific accessibility APIs. This enables web content to be interoperable with platform assistive technologies similar to native platform applications without platform dependencies.

This specification is a modular extension of WAI-ARIA designed for the digital publishing industry. The goals of this specification include:

The roles defined in this specification are derived from the EPUB Structural Semantics Vocabulary.

For a more detailed explanation of WAI-ARIA please refer to the WAI-ARIA Introduction and how it applies to Rich Internet Application Accessibility.

1.1 Target Audience

This specification defines a module of WAI-ARIA for digital publishing, including roles, states, properties and values. It impacts several audiences:

Each conformance requirement indicates the audience to which it applies.

Although this specification is applicable to the above audiences, it is not specifically targeted to, nor is it intended to be the sole source of information for, any of these audiences. In the future, additional documents will be created to assist authors in applying these WAI-ARIA semantics for the publishing industry and to define how the information in this document is mapped to platform accessibility APIs.

1.2 User Agent Support

This module builds on the general User Agent support principles defined in [WAI-ARIA] by also providing the ability for user agents to enhance the general user interface presented to readers.

1.3 Co-Evolution of WAI-ARIA and Host Languages

The Digital Publishing WAI-ARIA module follows the model for co-evolution of WAI-ARIA and host languages defined in [WAI-ARIA]. It is intended to augment semantics in supporting languages like [HTML], [SVG2] and EPUB, or to be used as an accessibility enhancement technology in other markup-based languages that do not explicitly include support for ARIA. It clarifies semantics to assistive technologies when authors create new types of objects, via style and script, that are not yet directly supported by the language of the page, because the invention of new types of objects is faster than standardized support for them appears in web languages.

It is not appropriate to create objects with style and script when the host language provides a semantic element for that type of objects. While WAI-ARIA can improve the accessibility of these objects, accessibility is best provided by allowing the user agent to handle the object natively. For example, it is not better to use a heading role on a div element than it is to use a native heading element, such as an h1.

It is expected that, over time, host languages will evolve to provide semantics for objects that currently can only be declared with this specification. This is natural and desirable, as one goal of WAI-ARIA is to help stimulate the emergence of more semantic and accessible markup. When native semantics for a given feature become available, it is appropriate for authors to use the native feature and stop using this module for that feature. Legacy content may continue to use the Digital Publishing WAI-ARIA module, however, so the need for user agents to support it remains.

While specific features of this module may lose importance over time, the general possibility of the Digital Publishing WAI-ARIA module to add semantics to web pages or open web-based standards, such as EPUB, is expected to be a persistent need. Host languages may not implement all the semantics this module provides, and various host languages may implement different subsets of the features. New types of objects are continually being developed, and one goal of this specification is to provide a way to make such objects accessible, because authoring practices often advance faster than host language standards. In this way, this module and host languages both evolve together but at different rates.

Some host languages exist to create semantics for features other than the user interface. For example, SVG expresses the semantics behind production of graphical objects, not of user interface components that those objects may represent. Host languages such as these might, by design, not provide native semantics that map to this specification's features. In these cases, the Digital Publishing WAI-ARIA module could be adopted as a long-term approach to add semantic information to these host languages.

1.4 Authoring Practices

1.4.1 Authoring Tools

Many of the requirements in the definitions of the WAI-ARIA and Digital Publishing WAI-ARIA roles, states and properties can be checked automatically during the development process, similar to other quality control processes used for validating code. To assist authors who are creating digital publications, such as EPUB, can compare the semantic structure of Digital Publishing WAI-ARIA roles from the DOM to that defined in this specification and notify the author of errors or simply create templates that enforce that structure.

1.4.2 Testing Practices and Tools

The accessibility of interactive content cannot be confirmed by static checks alone. Developers of interactive content should test for device-independent access to widgets and applications, and should verify accessibility API access to all content and changes during user interaction.

1.5 Assistive Technologies

Programmatic access to accessibility semantics is essential for assistive technologies. For more information, refer to the Assistive Technologies section in [WAI-ARIA].

2. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, and SHOULD in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Normative sections provide requirements that authors, user agents and assistive technologies MUST follow for an implementation to conform to this specification.

Non-normative sections provide information useful to understanding the specification. Such sections may contain examples of recommended practice, but it is not required to follow such recommendations to conform to this specification.

3. Digital Publishing Roles

This section defines additions to the WAI-ARIA roles model and describes the characteristics and properties of all roles. See ARIA Roles for descriptions of the fields provided by this module.

3.1 Definition of Roles

Below is an alphabetical list of WAI-ARIA roles to be used by rich internet application authors.

doc-abstract
A short summary of the principal ideas, concepts, and conclusions of the work, or of a section or excerpt within it.
doc-acknowledgments
A section or statement that acknowledges significant contributions by persons, organizations, governments, and other entities to the realization of the work.
doc-afterword
A closing statement from the author or a person of importance, typically providing insight into how the content came to be written, its significance, or related events that have transpired since its timeline.
doc-appendix
A section of supplemental information located after the primary content that informs the content but is not central to it.
doc-backlink
A link that allows the user to return to a related location in the content (e.g., from a footnote to its reference or from a glossary definition to where a term is used).
doc-biblioentry
[Deprecated in DPUB-ARIA 1.1] A single reference to an external source in a bibliography. A biblioentry typically provides more detailed information than its reference(s) in the content (e.g., full title, author(s), publisher, publication date, etc.).
doc-bibliography
A list of external references cited in the work, which may be to print or digital sources.
doc-biblioref
A reference to a bibliography entry.
doc-chapter
A major thematic section of content in a work.
doc-colophon
A short section of production notes particular to the edition (e.g., describing the typeface used), often located at the end of a work.
doc-conclusion
A concluding section or statement that summarizes the work or wraps up the narrative.
doc-cover
An image that sets the mood or tone for the work and typically includes the title and author.
doc-credit
An acknowledgment of the source of integrated content from third-party sources, such as photos. Typically identifies the creator, copyright, and any restrictions on reuse.
doc-credits
A collection of credits.
doc-dedication
An inscription at the front of the work, typically addressed in tribute to one or more persons close to the author.
doc-endnote
[Deprecated in DPUB-ARIA 1.1] One of a collection of notes that occur at the end of a work, or a section within it, that provides additional context to a referenced passage of text.
doc-endnotes
A collection of notes at the end of a work or a section within it.
doc-epigraph
A quotation set at the start of the work or a section that establishes the theme or sets the mood.
doc-epilogue
A concluding section of narrative that wraps up or comments on the actions and events of the work, typically from a future perspective.
doc-errata
A set of corrections discovered after initial publication of the work, sometimes referred to as corrigenda.
doc-example
An illustration of a key concept of the work, such as a code listing, case study or problem.
doc-footnote
Ancillary information, such as a citation or commentary, that provides additional context to a referenced passage of text.
doc-foreword
An introductory section that precedes the work, typically not written by the author of the work.
doc-glossary
A brief dictionary of new, uncommon, or specialized terms used in the content.
doc-glossref
A reference to a glossary definition.
doc-index
A navigational aid that provides a detailed list of links to key subjects, names and other important topics covered in the work.
doc-introduction
A preliminary section that typically introduces the scope or nature of the work.
doc-noteref
A reference to a footnote or endnote, typically appearing as a superscripted number or symbol in the main body of text.
doc-notice
Notifies the user of consequences that might arise from an action or event. Examples include warnings, cautions and dangers.
doc-pagebreak
A separator denoting the position before which a break occurs between two contiguous pages in a statically paginated version of the content.
doc-pagelist
A navigational aid that provides a list of links to the page breaks in the content.
doc-pagefooter
A section of text appearing at the bottom of a page that provides context about the current work and location within it. The page footer is distinct from the body text and normally follows a repeating template that contains (possibly truncated) items such as the document title, current section, author name(s), and page number.
doc-pageheader
A section of text appearing at the top of a page that provides context about the current work and location within it. The page header is distinct from the body text and normally follows a repeating template that contains (possibly truncated) items such as the document title, current section, author name(s), and page number.
doc-part
A major structural division in a work that contains a set of related sections dealing with a particular subject, narrative arc, or similar encapsulated theme.
doc-preface
An introductory section that precedes the work, typically written by the author of the work.
doc-prologue
An introductory section that sets the background to a work, typically part of the narrative.
doc-pullquote
A distinctively placed or highlighted quotation from the current content designed to draw attention to a topic or highlight a key point.
doc-qna
A section of content structured as a series of questions and answers, such as an interview or list of frequently asked questions.
doc-subtitle
An explanatory or alternate title for the work, or a section or component within it.
doc-tip
Helpful information that clarifies some aspect of the content or assists in its comprehension.
doc-toc
A navigational aid that provides an ordered list of links to the major sectional headings in the content. A table of contents may cover an entire work, or only a smaller section of it.

doc-abstract (role)

A short summary of the principal ideas, concepts, and conclusions of the work, or of a section or excerpt within it.

<section role="doc-abstract" aria-label="Abstract">
   <p>Accessibility of web content requires semantic information about widgets, structures,
      and behaviors …</p>
</section>
Characteristics of doc-abstract:
Characteristic Value
Superclass Role: section
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-acknowledgments (role)

A section or statement that acknowledges significant contributions by persons, organizations, governments, and other entities to the realization of the work.

<section role="doc-acknowledgments">
   <p>I would like to extend my sincere gratitude to … </p>
</section>
Characteristics of doc-acknowledgments:
Characteristic Value
Superclass Role: landmark
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-afterword (role)

A closing statement from the author or a person of importance, typically providing insight into how the content came to be written, its significance, or related events that have transpired since its timeline.

<section role="doc-afterword">
   <h2>Afterword: Why I Wrote This Book</h2></section>
Characteristics of doc-afterword:
Characteristic Value
Superclass Role: landmark
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-appendix (role)

A section of supplemental information located after the primary content that informs the content but is not central to it.

<section role="doc-appendix">
   <h2>Appendix A. Historical Timeline</h2></section>
Characteristics of doc-appendix:
Characteristic Value
Superclass Role: landmark
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-biblioentry (role)

[Deprecated in DPUB-ARIA 1.1] A single reference to an external source in a bibliography. A biblioentry typically provides more detailed information than its reference(s) in the content (e.g., full title, author(s), publisher, publication date, etc.).

Note

The doc-biblioentry role was designed for use as a list item, but due to clarifications in the WAI-ARIA specification, it is not valid as a child of the list role. As the doc-bibliography role already identifies a section of bibliography entries, authors are instead advised to use the list and listitem roles when native HTML elements cannot be used to structure the entries.

Characteristics of doc-biblioentry:
Characteristic Value
Related Concepts:
Name From: author
Accessible Name Required: True

doc-bibliography (role)

A list of external references cited in the work, which may be to print or digital sources.

The element carrying the doc-bibliography role MUST contain at least one descendant list containing the bibliography entries (if the entries are subdivided, for example alphabetically, the element would contain more than one list).

Authors MUST NOT apply the doc-bibliography role directly to the list containing the entries.

<section role="doc-bibliography">
   <h2>Select Bibliography</h2>
   <ul></ul>
</section>
Characteristics of doc-bibliography:
Characteristic Value
Superclass Role: landmark
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-biblioref (role)

A reference to a bibliography entry.

<p>
   As <a role="doc-biblioref"
      href="#b8cab5dd-bc24-459c-9858-7afa9da69b64">Steinbeck</a>
   says in his great novel …
</p>
Characteristics of doc-biblioref:
Characteristic Value
Superclass Role: link
Related Concepts:
Inherited States and Properties:
Name From:
  • contents
  • author
Accessible Name Required: True

doc-chapter (role)

A major thematic section of content in a work.

<section role="doc-chapter">
   <h2>Chapter 1. Loomings.</h2></section>
Characteristics of doc-chapter:
Characteristic Value
Superclass Role: landmark
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-colophon (role)

A short section of production notes particular to the edition (e.g., describing the typeface used), often located at the end of a work.

<section role="doc-colophon" aria-label="About the type">
   <p>This publication was set using … </p>
</section>
Characteristics of doc-colophon:
Characteristic Value
Superclass Role: section
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-conclusion (role)

A concluding section or statement that summarizes the work or wraps up the narrative.

<section role="doc-conclusion">
   <h2>Summary</h2>
   <p>A central task in feminist scholarship is to expose and dismantle the stereotypes … </p>
</section>
Characteristics of doc-conclusion:
Characteristic Value
Superclass Role: landmark
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-cover (role)

An image that sets the mood or tone for the work and typically includes the title and author.

<img role="doc-cover" src="coverimage.jpg" alt="A Room of One's Own by Virginia Woolf"/>
Characteristics of doc-cover:
Characteristic Value
Superclass Role: img
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-credit (role)

An acknowledgment of the source of integrated content from third-party sources, such as photos. Typically identifies the creator, copyright, and any restrictions on reuse.

<p role="doc-credit">
   Page 62, Table 3.1 from <cite>“Economic Foundations of Cost-Effectiveness Analysis”</cite>
   by A. M. Garber and C. E. Phelps …
</p>
Characteristics of doc-credit:
Characteristic Value
Superclass Role: section
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-credits (role)

A collection of credits.

<section role="doc-credits">
   <h2>Photo Credits</h2></section>
Characteristics of doc-credits:
Characteristic Value
Superclass Role: landmark
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-dedication (role)

An inscription at the front of the work, typically addressed in tribute to one or more persons close to the author.

<p role="doc-dedication">To my family, without whom this would have never been possible.</p>
Characteristics of doc-dedication:
Characteristic Value
Superclass Role: section
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-endnote (role)

[Deprecated in DPUB-ARIA 1.1] One of a collection of notes that occur at the end of a work, or a section within it, that provides additional context to a referenced passage of text.

Note

The doc-endnote role was designed for use as a list item, but due to clarifications in the WAI-ARIA specification, it is not valid as a child of the list role. As the doc-endnotes role already identifies a section of endnotes, authors are instead advised to use the list and listitem roles when native HTML elements cannot be used to structure the entries.

Characteristics of doc-endnote:
Characteristic Value
Superclass Role: listitem
Related Concepts:
Inherited States and Properties:
Name From: author

doc-endnotes (role)

A collection of notes at the end of a work or a section within it.

The element carrying the doc-endnotes role MUST contain at least one descendant list containing the endnotes (if the notes are subdivided, for example by chapter, the element would contain more than one list).

Authors MUST NOT declare elements with the role doc-footnote within the endnotes as it is redundant with the implied role.

Authors MUST NOT apply the doc-endnotes role directly to the list containing the endnotes.

<section role="doc-endnotes">
   <h2>Notes</h2>
   <ol>
      <li id="6baa07af">
         <p>Additional results of this study can be found at … </p>
      </li>
      <li id="7b2c0555">
         <p></p>
      </li></ol>
</section>
<section role="doc-endnotes">
   <h2>Notes</h2>
   <section>
      <h3>Canto I</h3>
      <div role="list>
         <div role="listitem">
            <p>1. The use of alliteration here … </p>
         </div></div>
   </section></section>
Characteristics of doc-endnotes:
Characteristic Value
Superclass Role: landmark
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-epigraph (role)

A quotation set at the start of the work or a section that establishes the theme or sets the mood.

<blockquote role="doc-epigraph">
   <p>“Would you tell me please, which way I ought to go from here?”</p>
   <p>“That depends a good deal on where you want to get to,” said the cat.</p>
</blockquote>
Characteristics of doc-epigraph:
Characteristic Value
Superclass Role: section
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-epilogue (role)

A concluding section of narrative that wraps up or comments on the actions and events of the work, typically from a future perspective.

<section role="doc-epilogue">
   <header>
      <h2>Epilogue</h2>
      <p>SPOKEN BY PROSPERO</p>
   </header>
   <p>Now my charms are all o'erthrown, …</p></section>
Characteristics of doc-epilogue:
Characteristic Value
Superclass Role: landmark
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-errata (role)

A set of corrections discovered after initial publication of the work, sometimes referred to as corrigenda.

<section role="doc-errata">
   <h2>Corrections</h2></section>
Characteristics of doc-errata:
Characteristic Value
Superclass Role: landmark
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-example (role)

An illustration of a key concept of the work, such as a code listing, case study or problem.

<figure role="doc-example">
   <figcaption>Example 1 — Hello World!</figcaption></figure>
Characteristics of doc-example:
Characteristic Value
Superclass Role: figure
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-footnote (role)

Ancillary information, such as a citation or commentary, that provides additional context to a referenced passage of text.

The doc-footnote role is only for representing individual notes that occur within the body of a work. For collections of notes that occur at the end of a section, see doc-endnotes.

<aside id="6baa07af" role="doc-footnote">
   * Additional results of this study and similar studies can be found at …
</aside>
Characteristics of doc-footnote:
Characteristic Value
Superclass Role: section
Related Concepts:
Inherited States and Properties:
Name From: author

doc-foreword (role)

An introductory section that precedes the work, typically not written by the author of the work.

<section role="doc-foreword">
   <h2>Foreword</h2></section>
Characteristics of doc-foreword:
Characteristic Value
Superclass Role: landmark
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-glossary (role)

A brief dictionary of new, uncommon, or specialized terms used in the content.

The structure of a glossary SHOULD make it possible for end users to identify each term and associated definition (e.g., using the [HTML] dfn element).

<section role="doc-glossary" aria-label="glossary">
   <dl><dt id="bcc0f155"><dfn>Credit default swap</dfn></dt>
      <dd>
         A credit default swap effectively insures against
         default by a borrower.
      </dd></dl>
</section>
<section role="doc-glossary" aria-labelledby="glosshd">
   <h2 id="glosshd">Glossay of Technical Terms</h2>
   <ul>
      <li id="gtt00110001"><dfn>algorithm</dfn> A set of rules …</li></ul>
</section>
Characteristics of doc-glossary:
Characteristic Value
Superclass Role: landmark
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-glossref (role)

A reference to a glossary definition.

<p>
   This is indicated in the cost of a
   <a href="#bcc0f155" role="doc-glossref">credit default swap</a></p>
Characteristics of doc-glossref:
Characteristic Value
Superclass Role: link
Related Concepts:
Inherited States and Properties:
Name From:
  • contents
  • author
Accessible Name Required: True

doc-index (role)

A navigational aid that provides a detailed list of links to key subjects, names and other important topics covered in the work.

<section role="doc-index">
   <h2>Index</h2>
   <section>
      <h2>A</h2>
      <ul>
         <li>A/B testing, <a href="chapter03.xhtml#page230">230</a></li></ul>
   </section></section>
Characteristics of doc-index:
Characteristic Value
Superclass Role: navigation
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-introduction (role)

A preliminary section that typically introduces the scope or nature of the work.

<section role="doc-introduction">
   <p>Everyone has some experience with marketing … </p>
</section>
Characteristics of doc-introduction:
Characteristic Value
Superclass Role: landmark
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-noteref (role)

A reference to a footnote or endnote, typically appearing as a superscripted number or symbol in the main body of text.

<p> … as studies have shown.<a href="#fn01" id="fnref01" role="doc-noteref">[1]</a></p>
Characteristics of doc-noteref:
Characteristic Value
Superclass Role: link
Related Concepts:
Inherited States and Properties:
Name From:
  • contents
  • author
Accessible Name Required: True

doc-notice (role)

Notifies the user of consequences that might arise from an action or event. Examples include warnings, cautions and dangers.

<section role="doc-notice">
   <img src="warning.png" alt="warning icon"/>
   <p>Just because you can include a font doesn’t mean you should.
      Think carefully about readability. Also, be respectful of intellectual property.
      There are many excellent free open-source fonts available.</p>
</section>

Authors SHOULD include a label when the notice needs to be navigable to.

<div role="doc-notice" aria-label="Explosion Risk">
   <p><em>Danger!</em> Mixing reactive materials may cause an explosion.</p>
</div>
Characteristics of doc-notice:
Characteristic Value
Superclass Role: note
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-pagebreak (role)

A separator denoting the position before which a break occurs between two contiguous pages in a statically paginated version of the content.

Page break locators are also commonly used to provide static markers in purely digital publications (i.e., where no statically paginated equivalent exists). These markers provide consistent navigation regardless of differences in font and screen size that can otherwise affect the dynamic pagination of the content.

Authors MUST ensure the name of the page break is an end user-consumable page number that identifies the page that is beginning so that assistive technologies can announce the page as needed (e.g., in a command to identify the current page).

The page break locator MUST precede the content of the page it identifies. If a page includes a header (doc-pageheader), the page break locator SHOULD be located before it, even if the header includes a visible page number. The page break locator may be used with the page number in a page header if the number precedes all other content in the header.

When reproducing page break locators from a static page equivalent, it is sometimes the case that words are hyphenated across pages. When this happens, the page break locator SHOULD be placed either before or after the word to ensure it does not interfere with text-to-speech playback.

Characteristics of doc-pagebreak:
Characteristic Value
Superclass Role: separator
Related Concepts:
Inherited States and Properties:
Name From:
  • contents
  • author
Accessible Name Required: True
Children Presentational: True

doc-pagelist (role)

A navigational aid that provides a list of links to the page breaks in the content.

<nav role="doc-pagelist">
   <h2>Pages</h2>
   <ol>
      <li><a href="chapter.xhtml#Page_1">1</a></li>
      <li><a href="chapter.xhtml#Page_2">2</a></li></ol>
</nav>
Characteristics of doc-pagelist:
Characteristic Value
Superclass Role: navigation
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-pageheader (role)

A section of text appearing at the top of a page that provides context about the current work and location within it. The page header is distinct from the body text and normally follows a repeating template that contains (possibly truncated) items such as the document title, current section, author name(s), and page number.

The doc-pageheader role MUST be used on every instance of the page header.

Assistive technologies MAY allow the user to read the document content continuously without interruption from the page header.

<section role="doc-pageheader">
   <div>War and Peace</div>
   <div>321</div></section>
Characteristics of doc-pageheader:
Characteristic Value
Superclass Role: section
Inherited States and Properties:
Name From: prohibited
Accessible Name Required: False

doc-part (role)

A major structural division in a work that contains a set of related sections dealing with a particular subject, narrative arc, or similar encapsulated theme.

<section role="doc-part">
   <h2>Part One</h2>
   <section role="doc-chapter">
      <h2>Chapter 1</h2></section></section>
Characteristics of doc-part:
Characteristic Value
Superclass Role: landmark
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-preface (role)

An introductory section that precedes the work, typically written by the author of the work.

<section role="doc-preface">
   <h2>Introduction:A Guide to the Galaxy</h2></section>
Characteristics of doc-preface:
Characteristic Value
Superclass Role: landmark
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-prologue (role)

An introductory section that sets the background to a work, typically part of the narrative.

<section role="doc-prologue">
   <header>
      <h2>Prologue</h2>
      <p>Chorus</p>
   </header>
   <p>Two households, both alike in dignity, …</p></section>
Characteristics of doc-prologue:
Characteristic Value
Superclass Role: landmark
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-pullquote (role)

A distinctively placed or highlighted quotation from the current content designed to draw attention to a topic or highlight a key point.

Unlike a passage quoted from another source, a pullquote is a direct repetition of text in the current document. As a result, authors must ensure that the presentational occurrence is hidden from users of assistive technologies (e.g., using the aria-hidden attribute).

The following example shows the identification of a pullquote that will be presented elsewhere (e.g., via a script). In this case, the pullquote is not hidden as the marked text is not presentational.

<p>… I may die, but first you, my tyrant and tormentor, shall curse the sun that gazes on your misery.
   <span id="pq01" role="doc-pullquote">Beware, for I am fearless and therefore powerful.</span>
   I will watch with the wiliness of a snake, that I may sting with its venom. … </p>

The next example shows a pullquote that duplicates the text. This quote is hidden because it is for presentational purposes only.

<p>… Better habits pave the way to growth, and growth leads to greater happiness.</p>
<aside role="doc-pullquote" aria-hidden="true">
   Better habits pave the way to growth, and growth leads to greater happiness.
</aside>
Characteristics of doc-pullquote:
Characteristic Value
Superclass Role: section
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-qna (role)

A section of content structured as a series of questions and answers, such as an interview or list of frequently asked questions.

<section role="doc-qna">
   <h2>Interview with the Author</h2>
   <dl>
      <dt>Q: When did you begin writing this book?</dt>
      <dd>A: I first got the idea …</dd></dl>
</section>
Characteristics of doc-qna:
Characteristic Value
Superclass Role: section
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-subtitle (role)

An explanatory or alternate title for the work, or a section or component within it.

<header>
   <h2>Chapter 2 The Battle</h2>
   <p role="doc-subtitle">Once more unto the breach</p>
</header>
Characteristics of doc-subtitle:
Characteristic Value
Superclass Role: sectionhead
Related Concepts:
Inherited States and Properties:
Name From:
  • contents
  • author
Accessible Name Required: False

doc-tip (role)

Helpful information that clarifies some aspect of the content or assists in its comprehension.

<aside role="doc-tip">
   <h3>Tip</h3>
   <p>You can assign a variable a new value that is the result
      of an expression involving its previous value.</p>
</aside>
Characteristics of doc-tip:
Characteristic Value
Superclass Role: note
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-toc (role)

A navigational aid that provides an ordered list of links to the major sectional headings in the content. A table of contents may cover an entire work, or only a smaller section of it.

<nav role="doc-toc">
   <h2>Contents</h2>
   <ol role="directory">
      <li><a href="preface_001.xhtml">Original Transcriber’s Notes:</a></li>
      <li><a href="introduction_001.xhtml">ETYMOLOGY.</a></li>
      <li><a href="epigraph_001.xhtml">EXTRACTS (Supplied by a Sub-Sub-Librarian).</a></li>
      <li><a href="chapter_001.xhtml">Chapter 1. Loomings.</a></li></ol>
</nav>
Characteristics of doc-toc:
Characteristic Value
Superclass Role: navigation
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

4. Security Considerations

This section is non-normative.

This specification introduces no new security considerations.

5. Privacy Considerations

This section is non-normative.

In accordance with Web Platform Design Principles, this specification provides no programatic interface to determine if information is being used by assistive technologies. However, this specificaton does allow an author to present different information to users of assistive technologies from the information available to users who do not use assistive technologies. This is possible using many features of the DPUB-ARIA specification, just as this is possible using many other parts of the web technology stack. This content disparity could be abused to perform active fingerprinting of users of assistive technologies.

A. Change Log

This section is non-normative.

A.1 Substantive changes since the last Working Draft

A.2 Substantive changes since the DPUB-ARIA 1.0 Recommendation

B. Acknowledgments

This section is non-normative.

The following people contributed to the development of this document:

B.1 Enabling funders

This publication has been funded in part with U.S. Federal funds from the Department of Education, National Institute on Disability, Independent Living, and Rehabilitation Research (NIDILRR), initially under contract number ED-OSE-10-C-0067, then under contract number HHSP23301500054C, and now under HHS75P00120P00168. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.

C. References

C.1 Normative references

[EPUB-SSV]
EPUB Structural Semantics Vocabulary. IDPF. URL: http://www.idpf.org/epub/vocab/structure/
[HTML]
HTML Standard. Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174

C.2 Informative references

[dpub-aam-1.0]
Digital Publishing Accessibility API Mappings. Richard Schwerdtfeger; Joanmarie Diggs. W3C. 14 December 2017. W3C Recommendation. URL: https://www.w3.org/TR/dpub-aam-1.0/
[fingerprinting-guidance]
Mitigating Browser Fingerprinting in Web Specifications. Nick Doty. W3C. 28 March 2019. W3C Working Group Note. URL: https://www.w3.org/TR/fingerprinting-guidance/
[infra]
Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
[SVG2]
Scalable Vector Graphics (SVG) 2. Amelia Bellamy-Royds; Bogdan Brinza; Chris Lilley; Dirk Schulze; David Storey; Eric Willigers. W3C. 4 October 2018. W3C Candidate Recommendation. URL: https://www.w3.org/TR/SVG2/
[WAI-ARIA]
Accessible Rich Internet Applications (WAI-ARIA) 1.1. Joanmarie Diggs; Shane McCarron; Michael Cooper; Richard Schwerdtfeger; James Craig. W3C. 14 December 2017. W3C Recommendation. URL: https://www.w3.org/TR/wai-aria-1.1/