Abstract

Accessibility of web content requires semantic information about widgets, structures and behaviors in order to allow assistive technologies to convey appropriate information to persons with disabilities. This specification defines a [WAI-ARIA] module encompassing an ontology of roles, states and properties specific to the digital publishing industry. These semantics are designed to allow an author to convey user interface behaviors and structural information to assistive technologies and to enable semantic navigation, styling and interactive features used by readers. It is expected this will complement [HTML5].

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. Other documents may supersede this document. 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/.

This is a Candidate Recommendation of Digital Publishing WAI-ARIA Module 1.0 by the Digital Publishing ARIA Taskforce, a joint task force of the Accessible Rich Internet Applications Working Group and the Digital Publishing Interest Group. This is a call for implementations; the Accessible Rich Internet Applications Working Group requests that initial implementations be submitted by 20 January 2017. The Working Group targets 27 January 2017 to complete the testing process and produce the implementation report. A history of changes to Digital Publishing WAI-ARIA Module 1.0 is available in the appendix.

Exit Criteria: The Accessible Rich Internet Applications Working Group intends to exit the Candidate Recommendation stage and submit this document for consideration as a W3C Proposed Recommendation after documenting interoperable implementability of each feature. The expectations and procedure for this are listed in the appendix.

Comments: The Accessible Rich Internet Applications Working Group primarily seeks feedback relation to implementation of Digital Publishing WAI-ARIA Module, but feedback on any aspect of the specification is accepted. To comment, file an issue in the W3C ARIA GitHub repository. If this is not feasible, send email to public-dpub-aria-comments@w3.org (comment archive). Comments are requested by 27 January 2017. In-progress updates to the document may be viewed in the publicly visible editors' draft.

This document was published by the Accessible Rich Internet Applications Working Group as a Candidate Recommendation. This document is intended to become a W3C Recommendation. W3C publishes a Candidate Recommendation to indicate that the document is believed to be stable and to encourage implementation by the developer community. This Candidate Recommendation is expected to advance to Proposed Recommendation no earlier than 27 January 2017.

Please see the Working Group's implementation report.

Publication as a Candidate Recommendation does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 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 1 September 2015 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 [HTML5], [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 MUST and SHOULD are to be interpreted as described in [RFC2119].

This specification indicates whether a section is normative or informative. Classifying a section as normative or informative applies to the entire section. A statement "This section is normative" or "This section is informative" applies to all sub-sections of that section.

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

Informative 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 in order to conform to this specification.

3. Important Terms§

This section is non-normative.

While some terms are defined in place, the following definitions are used throughout this document.

Accessibility API

Operating systems and other platforms provide a set of interfaces that expose information about objects and events to assistive technologies. Assistive technologies use these interfaces to get information about and interact with those widgets. Examples of accessibility APIs are Microsoft Active Accessibility [MSAA], Microsoft User Interface Automation [UI-AUTOMATION], MSAA with UIA Express [UIA-EXPRESS], the Mac OS X Accessibility Protocol [AXAPI], the Linux/Unix Accessibility Toolkit [ATK] and Assistive Technology Service Provider Interface [AT-SPI], and IAccessible2 [IAccessible2].

Assistive Technologies

Hardware and/or software that:

  • relies on services provided by a user agent to retrieve and render Web content
  • works with a user agent or web content itself through the use of APIs, and
  • provides services beyond those offered by the user agent to facilitate user interaction with web content by people with disabilities

This definition may differ from that used in other documents.

Examples of assistive technologies that are important in the context of this document include the following:

  • screen magnifiers, which are used to enlarge and improve the visual readability of rendered text and images;
  • screen readers, which are most-often used to convey information through synthesized speech or a refreshable Braille display;
  • text-to-speech software, which is used to convert text into synthetic speech;
  • speech recognition software, which is used to allow spoken control and dictation;
  • alternate input technologies (including head pointers, on-screen keyboards, single switches, and sip/puff devices), which are used to simulate the keyboard;
  • alternate pointing devices, which are used to simulate mouse pointing and clicking.
Attribute

In this specification, attribute is used as it is in markup languages. Attributes are structural features added to elements to provide information about the states and properties of the object represented by the element.

Class

A set of instance objects that share similar characteristics.

Element

In this specification, element is used as it is in markup languages. Elements are the structural elements in markup language that contains the data profile for objects.

Event

A programmatic message used to communicate discrete changes in the state of an object to other objects in a computational system. User input to a web page is commonly mediated through abstract events that describe the interaction and can provide notice of changes to the state of a document object. In some programming languages, events are more commonly known as notifications.

Informative

Content provided for information purposes and not required for conformance. Content required for conformance is referred to as normative.

Normative

Required for conformance. By contrast, content identified as informative or "non-normative" is not required for conformance.

Object

In the context of user interfaces, an item in the perceptual user experience, represented in markup languages by one or more elements, and rendered by user agents.

In the context of programming, the instantiation of one or more classes and interfaces which define the general characteristics of similar objects. An object in an accessibility API may represent one or more DOM objects. Accessibility APIs have defined interfaces that are distinct from DOM interfaces.
Ontology

A description of the characteristics of classes and how they relate to each other.

Property

Attributes that are essential to the nature of a given object, or that represent a data value associated with the object. A change of a property may significantly impact the meaning or presentation of an object. Certain properties (for example, aria-multiline) are less likely to change than states, but note that the frequency of change difference is not a rule. A few properties, such as aria-activedescendant, aria-valuenow, and aria-valuetext are expected to change often. See clarification of states versus properties.

Role

Main indicator of type. This semantic association allows tools to present and support interaction with the object in a manner that is consistent with user expectations about other objects of that type.

Semantics

The meaning of something as understood by a human, defined in a way that computers can process a representation of an object, such as elements and attributes, and reliably represent the object in a way that various humans will achieve a mutually consistent understanding of the object.

State

A state is a dynamic property expressing characteristics of an object that may change in response to user action or automated processes. States do not affect the essential nature of the object, but represent data associated with the object or user interaction possibilities. See clarification of states versus properties.

Taxonomy

A hierarchical definition of how the characteristics of various classes relate to each other, in which classes inherit the properties of superclasses in the hierarchy. A taxonomy can comprise part of the formal definition of an ontology.

User Agent

Any software that retrieves, renders and facilitates end user interaction with Web content. This definition may differ from that used in other documents.

Widget

Discrete user interface object with which the user can interact. Widgets range from simple objects that have one value or operation (e.g., check boxes and menu items), to complex objects that contain many managed sub-objects (e.g., trees and grids).

4. Digital Publishing Roles§

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

4.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 principle 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
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
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 illustratration 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 pagebreaks in the content.
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 principle ideas, concepts and conclusions of the work, or of a section or excerpt within it.

Example 1
<section role="doc-abstract" aria-label="Abstract">
   <p>Accessibility of web content requires semantic information about widgets, structures,
      and behaviors …</p>
</section>
Characteristics:
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.

Example 2
<section role="doc-acknowledgments">
   <p>I would like to extend my sincere gratitude to … </p>
</section>
Characteristics:
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.

Example 3
<body role="doc-afterword">
   <h1>Afterword: Why I Wrote This Book</h1></body>
Characteristics:
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.

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

doc-biblioentry (role)§

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.).

Authors MUST ensure that elements with role doc-biblioentry are contained in, or owned, by an element with the role list.

Example 6
<section role="doc-bibliography">
   <h1>Cited Works</h1>
   <div role="list">
      <p role="doc-biblioentry" id="b8cab5dd-bc24-459c-9858-7afa9da69b64">
         John Steinbeck, The Grapes of Wrath (New York: The Viking Press, 1939)
      </p>
   </div></section>
Example 7
<section role="doc-bibliography">
   <h1>Select Bibliography</h1>
   <ul>
      <li role="doc-biblioentry" id="faulkner-dying">
         William Faulkner, As I Lay Dying (New York: Jonathan Cape & Harrison Smith, 1930)
      </li>
   </ul></section>
Characteristics:
Characteristic Value
Superclass Role: listitem
Related Concepts:
Required Context Role: doc-bibliography
Inherited States and Properties:
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.

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

doc-biblioref (role)§

A reference to a bibliography entry.

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

doc-chapter (role)§

A major thematic section of content in a work.

Example 10
<body role="doc-chapter">
   <h1>Chapter 1. Loomings.</h1></body>
Characteristics:
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.

Example 11
<section role="doc-colophon" aria-label="About the type">
   <p>This publication was set using … </p>
</section>
Characteristics:
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.

Example 12
<section role="doc-conclusion">
   <h1>Summary</h1>
   <p>A central task in feminist scholarship is to expose and dismantle the stereotypes … </p>
</section>
Characteristics:
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.

Example 13
<img role="doc-cover" src="coverimage.jpg" alt="A Room of One's Own by Virginia Woolf"/>
Characteristics:
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.

Example 14
<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:
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.

Example 15
<section role="doc-credits">
   <h1>Photo Credits</h1></section>
Characteristics:
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.

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

doc-endnote (role)§

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.

Authors MUST ensure that elements with role doc-endnote are contained in, or owned, by an element with the role list.

Example 17
<section role="doc-endnotes">
   <h2>Notes</h2>
   <ol>
      <li id="6baa07af" role="doc-endnote">Additional results of this study can be found at … </li>
      <li id="7b2c0555" role="doc-endnote"></li></ol>
</section>
Example 18
<section role="doc-endnotes">
   <h2>Notes</h2>
   <section id="ch1-notes">
      <h3>Chapter 1</h3>
      <div role="list">
         <p id="6baa07af" role="doc-endnote">1. Additional results of this study can be found at … </p>
         <div id="7b2c0555" role="doc-endnote">
            <p>2. The primary source of infomation …</p>
            <p class="note-cont">In the case of secondary studies …</p>
         </div></div>
   </section>
</section>
Characteristics:
Characteristic Value
Superclass Role: listitem
Related Concepts:
Required Context Role: doc-endnotes
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.

Note that the doc-endnotes role is never applied directly to the list of endnotes. See the doc-endnote role for more information.

Example 19
<section role="doc-endnotes">
   <h2>Notes</h2>
   <ol>
      <li id="6baa07af" role="doc-endnote">Additional results of this study can be found at … </li>
      <li id="7b2c0555" role="doc-endnote"></li></ol>
</section>
Characteristics:
Characteristic Value
Superclass Role: landmark
Related Concepts:
Required Owned Elements: doc-endnote
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.

Example 20
<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:
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.

Example 21
<body role="doc-epilogue">
   <header>
      <h1>Epilogue</h1>
      <p>SPOKEN BY PROSPERO</p>
   </header>
   <p>Now my charms are all o'erthrown, …</p></body>
Characteristics:
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.

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

doc-example (role)§

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

Example 23
<aside role="doc-example">
   <h1>Hello World!</h1></aside>
Characteristics:
Characteristic Value
Superclass Role: section
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.

Example 24
<aside id="6baa07af" role="doc-footnote">
   * Additional results of this study and similar studies can be found at …
</aside>
Characteristics:
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.

Example 25
<body role="doc-foreword">
   <h1>Foreword</h1></body>
Characteristics:
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.

Example 26
<dl role="doc-glossary"><dt id="bcc0f155" role="term">Credit default swap</dt>
   <dd role="definition">
      A credit default swap effectively insures against
      default by a borrower.
   </dd></dl>
Characteristics:
Characteristic Value
Superclass Role: landmark
Related Concepts:
Required Owned Elements: term, definition
Inherited States and Properties:
Name From: author
Accessible Name Required: False

doc-glossref (role)§

A reference to a glossary definition.

Example 27
<p>
   This is indicated in the cost of a
   <a href="#bcc0f155" role="doc-glossref">credit default swap</a></p>
Characteristics:
Characteristic Value
Superclass Role: link
Related Concepts:
Inherited States and Properties:
Name From: author content
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.

Example 28
<section role="doc-index">
   <h1>Index</h1>
   <section>
      <h2>A</h2>
      <ul>
         <li>A/B testing, <a href="chapter03.xhtml#page230">230</a></li></ul>
   </section></section>
Characteristics:
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.

Example 29
<section role="doc-introduction">
   <p>Everyone has some experience with marketing … </p>
</section>
Characteristics:
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.

Example 30
<p> … as studies have shown.<a id="fnref01" role="doc-noteref">[1]</a></p>
Characteristics:
Characteristic Value
Superclass Role: link
Related Concepts:
Inherited States and Properties:
Name From: author content
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.

Example 31
<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.

Example 32
<div role="doc-notice" aria-label="Explosion Risk">
   <p><em>Danger!</em> Mixing reactive materials may cause an explosion.</p>
</div>
Characteristics:
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.

Example 33
<span id="pg04" role="doc-pagebreak" title="4"/>
Characteristics:
Characteristic Value
Superclass Role: separator
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: True
Children Presentational: True

doc-pagelist (role)§

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

Example 34
<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:
Characteristic Value
Superclass Role: navigation
Related Concepts:
Inherited States and Properties:
Name From: author
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.

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

doc-preface (role)§

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

Example 36
<body role="doc-preface">
   <h1>Introduction:A Guide to the Galaxy</h1></body>
Characteristics:
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.

Example 37
<body role="doc-prologue">
   <header>
      <h1>Prologue</h1>
      <p>Chorus</p>
   </header>
   <p>Two households, both alike in dignity, …</p></body>
Characteristics:
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.

Example 38
<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.

Example 39
<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:
Characteristic Value
Superclass Role: none
Related Concepts:
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.

Example 40
<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:
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.

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

doc-tip (role)§

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

Example 42
<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:
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.

Example 43
<nav role="doc-toc">
   <h1>Contents</h1>
   <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:
Characteristic Value
Superclass Role: navigation
Related Concepts:
Inherited States and Properties:
Name From: author
Accessible Name Required: False

A. Schemata§

This section is non-normative.

The HTML Working Group has incorporated the WAI-ARIA attributes into HTML 5. Official support for WAI-ARIA in HTML is provided in that specification.

Editor's Note

Validation support for the roles defined in this module will be added once the specification reaches recommendation.

For information on incorporating WAI-ARIA into other grammars, refer to Appendix A of [WAI-ARIA]

B. Candidate Recommendation Exit Criteria§

This section is non-normative.

For this specification to be advanced to Proposed Recommendation, it has to be proven that roles defined in this specification have sufficient usage by the target communities. More specifically, it has to be documented that each Digital Publishing Role is used (at least in preliminary prototypes, not necessarily in full production yet) by two, independent document author/publisher as a means to structure document, where “usage” means:

Testing Digital Publishing WAI-ARIA Role Module relies on the guidance in Digital Publishing Accessibility API Mappings [DPUB-AAM-1.0]. For each feature, successful test results in any two implementations mapping any of the accessibility APIs referenced in any of the AAMs using any host language will be considered sufficient for the purpose of determining implementability and interoperability of this specification. It is not as expectation that the DPub-AAM itself be at Candidate Recommendation or later stage in order to support Digital Publishing WAI-ARIA Module testing.

In the case where the epub:type attribute is used, the author/publisher should also clearly state that the plan is to replace epub:type by the ARIA role attribute when this specification is published as a Recommendation. Furthermore, it is also required that at least two, independent authors/publishers use a comprehensive, although not necessarily complete, set of role attribute (as opposed to epub:type).

C. Change Log§

This section is non-normative.

C.1 Substantive changes since the last public working draft§

C.2 Other substantive changes since the First Public Working Draft§

D. WAI-ARIA Role, State, and Property Quick Reference§

This section is non-normative.

The following table provides a quick reference to the supported states and properties for all WAI-ARIA roles that may be used in markup.

In addition to the states and properties shown in the table, the following global states and properties are supported on all roles.

Placeholder for global states and properties

Placeholder for quick reference table

E. Acknowledgments§

This section is non-normative.

The following people contributed to the development of this document.

E.1 Participants active in the DPUB-ARIA task force at the time of publication§

The group would like to thank all members of the DAISY and EPUB 3 working groups who developed the structural semantics vocabulary from which this module was drawn, with special thanks to Sanders Kleinfeld for his assistance analyzing the initial set of semantics for inclusion.

E.2 Enabling funders§

This publication has been funded in part with Federal funds from the U.S. Department of Education, National Institute on Disability, Independent Living, and Rehabilitation Research (NIDILRR) under contract number ED-OSE-10-C-0067. 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.

F. References§

F.1 Normative references§

[RFC2119]
S. Bradner. IETF. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119

F.2 Informative references§

[AT-SPI]
The GNOME Project. Assistive Technology Service Provider Interface. URL: https://developer.gnome.org/libatspi/stable/
[ATK]
The GNOME Project. ATK - Accessibility Toolkit. URL: https://developer.gnome.org/atk/stable/
[AXAPI]
Apple Corporation. The Mac OS X Accessibility Protocol Mac OS 10.10. URL: https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSAccessibility_Protocol/index.html
[DPUB-AAM-1.0]
Richard Schwerdtfeger. W3C. Digital Publishing Accessibility API Mappings. 17 March 2016. W3C Working Draft. URL: https://www.w3.org/TR/dpub-aam-1.0/
[EPUB-Content]
IDPF. EPUB Content Documents 3.1. URL: http://www.idpf.org/epub/31/spec/epub-contentdocs.html
[EPUB-SSV]
IDPF. EPUB Structural Semantics Vocabulary. URL: https://idpf.github.io/epub-vocabs/structure/
[HTML5]
Ian Hickson; Robin Berjon; Steve Faulkner; Travis Leithead; Erika Doyle Navara; Theresa O'Connor; Silvia Pfeiffer. W3C. HTML5. 28 October 2014. W3C Recommendation. URL: https://www.w3.org/TR/html5/
[IAccessible2]
Linux Foundation. IAccessible2. URL: https://wiki.linuxfoundation.org/accessibility/iaccessible2/start
[MSAA]
Microsoft Corporation. Microsoft Active Accessibility (MSAA) 2.0. URL: https://msdn.microsoft.com/en-us/library/ms697707.aspx
[SVG2]
Nikos Andronikos; Rossen Atanassov; Tavmjong Bah; Amelia Bellamy-Royds; Brian Birtles; Cyril Concolato; Erik Dahlström; Chris Lilley; Cameron McCormack; Doug Schepers; Dirk Schulze; Richard Schwerdtfeger; Satoru Takagi; Jonathan Watt et al. W3C. Scalable Vector Graphics (SVG) 2. W3C Working Draft. URL: http://www.w3.org/TR/2015/WD-SVG2-20150915/
[UI-AUTOMATION]
Microsoft Corporation. UI Automation. URL: https://msdn.microsoft.com/en-us/library/ee684009%28v=vs.85%29.aspx
[UIA-EXPRESS]
Microsoft Corporation. The IAccessibleEx Interface. URL: https://msdn.microsoft.com/en-us/library/windows/desktop/dd561898%28v=vs.85%29.aspx
[WAI-ARIA]
James Craig; Michael Cooper; Shane McCarron et al. W3C. Accessible Rich Internet Applications (WAI-ARIA) 1.1. W3C Working Draft. URL: http://www.w3.org/TR/wai-aria-1.1/
[WAI-ARIA-IMPLEMENTATION]
Joseph Scheuhammer; Michael Cooper. W3C. WAI-ARIA 1.0 User Agent Implementation Guide. 20 March 2014. W3C Recommendation. URL: https://www.w3.org/TR/wai-aria-implementation/
[WAI-ARIA-PRACTICES]
Joseph Scheuhammer; Michael Cooper. W3C. WAI-ARIA 1.0 Authoring Practices. 14 July 2016. W3C Working Draft. URL: https://www.w3.org/TR/wai-aria-practices/
[WCAG20]
Ben Caldwell; Michael Cooper; Loretta Guarino Reid; Gregg Vanderheiden et al. W3C. Web Content Accessibility Guidelines (WCAG) 2.0. 11 December 2008. W3C Recommendation. URL: https://www.w3.org/TR/WCAG20/