Navigating Within Multiple Documents or Packaged Documents

Digital publishing use cases exist to allow users to navigate among multiple documents or collections of documents that make up a publication's whole. For example:

• Bidirectional linking: A user follows a hyperlink from a publication index to a paragraph in middle of chapter 23 and subsequently realizes that the second index entry may have been a better choice. The user must now return to the publication index (very likely a separate HTML document) to access the link to the second index entry.
• A publisher wants to test publication accessibility of an ordered collection of documents to assess whether users can access all elements listed in the publication's table of contents - a single document in the collection specific to navigating an ordered collection of HTML documents. The navigation page and the ordered collection of HTML documents make up a single content package.

The Gap: Individual HTML documents in a package may not all be WCAG-conformant due to the lack of elements such as navigation, but the content package itself is WCAG-conformant because the detailed navigation HTML document is a directory of the entire package. As such, a package could be considered WCAG-conformant, but a non-sighted reader may not be able to identify or access non-WCAG-conformant documents within the package. Content developers did not catch this singular oversight when they were checking the package navigation document for WCAG conformance instead of every document in the package.

Many digital publications are made up of more than one document. A common practice exists to divide every chapter in books into individual HTML files. EPUB 3 titles, for example, are packaged using a specified mechanism enabling navigation to each publication component. Current W3C WAI Specifications and Guidelines provide no treatment or suggestions for navigating through ordered, packaged content documents. Existing W3C WAI Specifications, Guidelines, and most tools related to accessibility assume that the user is encountering a single whole document.

Potential options for addressing the gap:

1. Add discussion of the packaged document use case to W3C WAI Specifications and Guidelines.
2. Add an author extension that addresses use cases to W3C WAI Specifications and Guidelines.

Discoverability

Digital publications are often distributed through various channels, for instance in online bookstores. These channels are typically aggregators that have almost no control over publications' content and quality. Besides, a single intellectual work can be distributed as several digital editions, with varying quality and accessibility features.

When users want to acquire digital publications, they need to know if the content will be accessible to them. Therefore, it is crucial that accessibility properties of a digital publication exist as metadata, and that such metadata can be made available to any interested party. For instance, an online bookstore would access such metadata to convey the information to users so that they can discover which digital distribution of a title contains the accessible features specific to their needs.

The Gap: There is no current recommended standard or specification for recording digital publishing metadata stating that a title is accessible and enumerating the properties of the publication that are AT-compatible.

Potential solution for addressing the gap: Work with W3C WAI community to identify and recommend a mechanism to enable the declaration and discoverability of metadata on a digital publication, notably to describe its accessibility properties.

References:

• [[SCHEMA-ORG]]
• [[WEB-SCHEMAS]]
• [[ONIX-EPUBLICATION]]

Optimized publications

Unlike general Web content, some digital publications are legitimately designed and optimized for specific user groups; this is the case of audio or braille books made for persons with print disabilities. These publications target specific reading modalities. By design, they cannot meet the universal accessibility principles identified in WCAG, despite the fact that they are accessible to their intended audience.

The Gap: Guidelines to author and evaluate optimized, accessible digital publications do not exist.

Potential solution for addressing the gap: Work with the W3C WAI community and WCAG WG outreach committee to provide guidelines to author and evaluate optimized digital publications, and to convey their nature to users.

Skippability

A digital publishing use case exists to allow users to "skip" through components as they read. For example, a screen reader user does not want to read page numbers or headers by default. The user does want to read the footnotes when they encounter a footnote callout within the text. Alternately, a mobility-impaired user, reading a textbook on a mobile device, knows that the textbook chapter contains multiple long tables which are difficult to scroll past. The user wants to be able to designate tables as elements which can be skipped or displayed in some minimal form.

Skippability is a common user preference in assistive technology (AT) tools allowing the user to personalize the content read aloud to a very precise specification. Assistive technology users expect to be able to customize which content components get read aloud or displayed to the user. Non-assistive technology users also need access to the capability.

• Users expect to be able to navigate or go back to skipped elements at a later time.
• Previously-skipped elements must remain discoverable to assistive technology and user agents.
• Skippability require support in visual as well as aural presentation; both screenreader and visual users need access to skippable structures.

The Gap: Current W3C WAI accessibility Specifications and Guidelines do not address what would be considered implementation guidance to provide this functionality either to assistive technology users or to non-assistive technology users. We are not aware of any well known implementations within the publishing community.

Potential options for addressing the gap: Add language to the W3C WAI specifications discussing the need for User agents to implement skippability.

Reference: DAISY Skippable Structures Recommendation [[DAISY]]

Escapability

Multiple digital publishing use cases exist allowing readers to move immediately to the next non-contained block element. Moving quickly within text is a particular problem for readers who browse the web and read at high magnification or mobility impaired readers, regardless of device platform. Escapeability require support in visual as well as aural presentation; both screenreader and visual users need access to escapeable structures.

More specifically, a user in the middle of an element of length needs to be able to move to the next sibling or parent with a simple command. Similarly, the user may need to escape back to the previous text block. Examples include:

• A chemistry book has a long table of each of the elements in the periodic table. The reader has entered the table, and realizes they do not need to see all of the elements in the table, but they do need to read the text immediately afterward. The user needs to get from the table to the next sibling or parent element without endless scrolling.
• A user is reading a magazine article and realizes the next item in the article is an inset sidebar of a document containing a multitude of different types of data, including a chart, an image gallery, an infographic, a video, and some text. This information takes up several screens of content at the reader's zoom level. The user wants to escape the sidebar and return to the content after the enclosing container.
• A student reading a physics textbook encountered a math equation but has forgotten what the previously introduced symbol X represented. The student would like to return to the previously escaped block element to review the text describing the purpose of symbol X.

The Gap: Current W3C WAI accessibility Specifications and Guidelines do not address what would be considered implementation guidance to provide this functionality either to assistive technology users or to non-assistive technology users.

Potential options for addressing the gap: Add language to the W3C WAI Specifications and Guidelines discussing the need for User agents to implement escapability.

Page Markers / Pagination

Multiple digital publishing use cases exist for allowing users to work with and manipulate paged content that does not necessarily flow vertically similar to the content of most web pages. Many electronic publications have intentional correspondence to printed publications. Some electronic publications may have the equivalent of page markers for coordinating specific points in text across multiple editions. Therefore, the concept of page markers/locators is not a throw-back to print publishing.

Specific examples of page marker/pagination use cases include:

• A magazine publishes both print and online editions. The publisher distributes the online edition as a website (rather than as a standalone EPUB). To boost sales of the magazine's print edition, the publisher would like to provide special interactive features to print subscribers. The interactive features require that readers are easily able to jump to the page marker they're currently reading in the print edition, or to know what page of the print edition corresponds to the website content they are currently viewing.
• A high school teacher has assigned a novel, and all the students are reading a particular published edition for convenience. One of the students uses AT and is reading the ebook with AT preferences set to resize and reflow the content. In class, the teacher instructs the students to turn from page 56 to page 53. The reader must also be able to locate pages 56 and 53 to keep pace with the rest of the class.

  The student using AT has set the page size on the viewable area of their AT to a particular zoom level, so their paginated view in their ebook reader does not correspond to a page of the print edition. The student remembers they saw something they needed three screens ago and wants to skip back those three screens.

The Gap: Current W3C WAI Specifications and Guidelines do not contain discussion of the user need to identify and navigate content based on markers (also called locators) that may or may not correspond to printed publication page numbers. Readers need a means of quickly and accurately navigating digital publications by locators corresponding to printed page markers, regardless of whether or not the user has set their preferences to resize or reflow text. Further, the mechanism to support navigating text by locators and page markers should not disrupt continuous reading for students using Aural AT solutions.

Potential options for addressing the gap: The CSS Paged Media Module Level 3 [[CSS3-PAGE]] describes a method for providing page numbers in the context of a scenario where the text is paginated when sent to a printer from a web page. User agents could implement a similar solution facilitating access to accurate page numbers and pagination.

The W3C WCAG and DPub groups should engage with the Pagination Task Force of the CSS Working Group to determine whether an acceptable, accessible solution for addressing page numbers and pagination already exists.

Potential interim options for addressing the gap:

1. Add language to W3C WAI Specifications and Guidelines implementing a concept corresponding to the EPUB 3 specifications to create print pagination corresponding locators using page-list and pagebreak concepts.
2. Provide implementation guidance to User Agents instructing the need to enable, where relevant, both distinct concepts of pages (described below), including allowing users to jump to page numbers in either model or view specific pages in either model.

Reference: [[CSS-Paged-Media]] Module Level 3 Page-Margin Boxes

Phonetic spellings of proper nouns and jargon terms

Multiple digital publishing use cases exist to enable AT solutions to support phonetic spelling of proper nouns and jargon. For example:

• A chemistry book needs to use the accepted pronunciations of chemistry terms to maximize clarity. It references a pre-existing pronunciation dictionary made available by the American Chemical Society that uses community-agreed-upon standards.
• The trade novel THE LIVES OF CHRISTOPHER CHANT by Diana Wynne Jones, in which there is a plot point that a character's name is spelled "Ralph" but pronounced "Rafe," can be correctly encoded using a local pronunciation dictionary.
• Reading systems support the pronunciation dictionary reference and expose the data to Accessibility APIs.

Publishers need to be able to put in suggested pronunciation for proper nouns, acronyms, and field-specific jargon terms. The Pronunciation Lexicon (PLS) and Speech Synthesis Markup Language [[SSML]] lack widespread adoption, probably because of the lack of tools useful for large-scale publishing production as well as the lack of reading system support.

The Speech Synthesis Markup Language [[SSML]] is another option for phonetic pronunciations, but it is currently not supported in HTML. EPUB attempted to address this shortcoming through the introduction of [[SSML]] attributes, but the attributes are unique to that format, limited to XHTML and not well supported within it. A solution that similarly simplifies SSML but brings support to all HTML user agents is needed.

The Gap: Current W3C WAI Specifications and Guidelines have poor implementation with regards to phonetic spelling, probably due to lack of authoring tools, reading system support, and implementation guidance.

References:

• Pronunciation Lexicon Specification (PLS) [[PRONUNCIATION-LEXICON]]
• Speech Synthesis Markup Language (SSML) [[SSML]]

Deeply Nested Heading Levels Best Practices

Digital publishing use cases exist to support encyclopedias and similarly detailed reference works containing many levels of headings.

It is not easy to determine what best practice is for deeply nested headings, headings that go beyond <h6>. Best Practices should be clearly established and easy to find. Use cases in books are more frequent than other circumstances. This is likeliest to occur if an <aside> begins with <h5> or <h6>.

The Gap: Current W3C WAI Specifications and Guidelines do not address what are considered implementation guidance to non-assistive technology users. ARIA has heading guidance, but ARIA should be a fallback, only when HTML is inadequate. Furthermore, most content creators are unclear of what it announced to AT when there are nested levels of <h#>, <header>, <role="header">, and <aria-level=#>. Clearer documentation of this interaction is necessary.

Potential solution for addressing the gap: Add specific guidance related to supporting deeply nested heading levels in reference works to W3C WAI Specifications, Guidelines, and Tutorials.

References:

• Item #3: 15 May 2015 DPub Minutes [[DPub-Minutes-3]]
• Using role="heading" to identify headings [[WAI-Wiki]] April-June 2015 [][WAI-IG-Minutes]]

Semantic List-Head

A digital publishing use case exists to support a semantic title or head within a list.

The Gap: Currently, no clear method of associating a title with a list exists in any W3C specification.

Creating the visual effect of a list containing a semantic title or head can be accomplished using markup wrappers such as <div>, but list elements (<ul> and <ol>) should include titles.

Consider the following simple example:

<ul>
    <listtitle>Noble Gases</listtitle>
    <li>Helium</li>
    <li>Neon</li>
    <li>Argon</li>
    <li>Krypton</li>
    <li>Xenon</li>
    <li>Radon</li>
</ul>

It is tempting to use HTML5 h1 – h6 elements or add role="heading", but in both cases the result is unwanted default navigation. This heading should specifically self-identify as lists to screen readers. A potentially useful option would be to include a role value as part of an element called "listtitle" (or something similar). The option to include a semantic title in a list requires support in visual as well as aural presentations; both screen reader and visual users need access to the list header..