This document is also available in this non-normative format: ePub
This document, “Digital Publishing and Accessibility in W3C Documents” describes how W3C guidelines (including but not limited to [WCAG20], [ATAG20], [UAAG20], and [WAI-ARIA]) and their principles, guidelines, and success criteria can be applied to the needs of Digital Publishing. It provides informative guidance, but does not set requirements.
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 http://www.w3.org/TR/.
This is a work in progress. No section should be considered final, and the absence of any content does not imply that such content is out of scope, or may not appear in the future.
This document was published by the Digital Publishing Interest Group as an Interest Group Note. If you wish to make comments regarding this document, please send them to email@example.com (subscribe, archives). All comments are welcome.
Publication as an Interest Group Note 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.
The disclosure obligations of the Participants of this group are described in the charter.
This document is governed by the 1 September 2015 W3C Process Document.
This document provides a gap analysis concerning Digital Publishing needs in the context of existing WAI W3C guidelines including (but not limited to) [WCAG20], [ATAG20], [UAAG20], and [WAI-ARIA]. Where appropriate, this document is also informed by other ongoing W3C projects including, but not limited to, Portable Web Publications [PWP] and the Web Annotation Working Group.
The World Wide Web Consortium (W3C)'s W3C Web Accessibility Initiative (WAI) is primarily concerned with web technologies; however, its guidance is also relevant to technologies which are not exclusively web technologies. The digital publishing industry, which creates composite web and non-web publications using web-based technology tools and standards, is reliant on the standards set by the W3C.
The current document is focused on the accessibility of digital publishing to people with disabilities and is not intended to supplant any other W3C work.
Digital Publishing is a generic term for the broad ecosystem of electronic journals, magazines, news, or book publishing (authors, creators, publishers, news organizations, booksellers, accessibility and internationalization specialists, etc.). Formats used by eBook readers and tablets for electronic books, magazines, journals, and educational resources are W3C Technology-based. (X)HTML, CSS, SVG, SMIL, MathML, and various Web APIs are all part of modern digital publishing workflows. Commercial publishers also rely on W3C technologies in their back-end production workflows all the way from authoring through to delivering printed or electronic product and beyond. In general, one can say that the Publishing Industry is one of the largest communities relying heavily on W3C specifications and technologies.
However, a gap currently exists between the alignment of Publishing Industry needs and the various W3C recommendations. Features necessary for the success of digital publishing may be missing in W3C documents, or may be in draft only; as a result, for example, EPUB 3, the standard for electronic books, introduced extensions to support publishing-specific requirements.
The audience of this document includes involved people creating and modifying existing W3C specifications, especially those oriented around accessibility.
A gap exists between specific digital publishing industry requirements and W3C standards Working Group efforts to date. Requirements that WAI efforts may address in the future are listed here in order of priority. Additional publishing industry requirements exist, but cannot sufficiently be addressed without further research documented Appendix A. Some suggestions request changes or additions to W3C WAI Specifications and Guidelines. Additional proposals seek changes to existing W3C technique documentation and offer suggestions for further outreach. Where possible, we indicated which of the existing W3C guidelines might be best positioned to address the change.
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.
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.
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.
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]
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:
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.
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:
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:
Reference: [CSS-Paged-Media] Module Level 3 Page-Margin Boxes
Multiple digital publishing use cases exist to enable AT solutions to support phonetic spelling of proper nouns and jargon. For example:
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.
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
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
<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.
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 (
<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..
The Digital Publishing Interest Group is not making any recommendations on the following items at this time. They are included to increase awareness of the work we believe still needs to be done for accessibility in the digital publishing space. Existing W3C Working Groups are already addressing some of these points. Others will be investigated by the DPub IG Accessibility TF shortly.
Comments: There is currently no reasonable, scalable, generalizable and sustainable method to provide information about the layout of text on a page to screen readers and braille displays.
Certain literary styles such as poetry may use the placement of text to convey extra meaning. There is no consistent method for content creators to make this additional information available to a non-visual display such as a screen reader. We have no suggested approaches at this time. More research and investigation is warranted.
Suggestion: Although a solution is needed, the DPub IG has no good suggestions at this time. More research and investigation is warranted.
Annotations are a general web requirement, but they are a vital need in the digital publishing industry. These annotations (including: highlights and adding personal notes to a document) must be accessible for creation, editing, and access. The W3C Annotations WG is aware of the requirements of accessibility both in UAs as well as the format.
Because of the importance of annotations in the industry, the DPub Accessibility TF will continue to stay in communication with the W3C Annotation WG and its descendants to address the open issues in this area.
Suggestion: Communicate regularly with the W3C Annotations WG.
Suggestion: Although a solution may be needed, DPub IG has no good suggestions at this time. More research and investigation is warranted. Possibly all use cases can be addressed with CSS.
[ETS] and members of the IMS Accessibility Task Force are leading the effort to harmonize the IMS QTI/APIP accessibility model with HTML5/ARIA and WCAG. A gap analysis is underway at [ETS] and recommendations for enhancements to both guidelines (including techniques and best practices) and standards, such as the addition of new ARIA attributes. The bulk of these recommendations will come from their group; we will coordinate with them as they request. We've done initial outreach.
Suggestion: The DPub Accessibility Task Force will coordinate with the IMS Assessment Accessibility Task Force
There is currently no reasonable, scalable, generalizable and sustainable method to provide information about mathematical rendering using HTML with CSS or SVG to screen readers and braille displays.
While MathML is part of HTML5, virtually all mathematical and scientific content on the web is rendered using HTML (with CSS) and SVG. While these standards are sufficient for visual rendering, there is no consistent method for content creators to make mathematical and scientific information available to a non-visual display such as a screen reader.
The newly created [Math-on-Webpages-CG] Community Group plans to address rendering issues as well as accessibility related issues, focusing on a bottom-up approach of improving the web platform overall to help improve current and future technologies.
Suggestion: The DPub IG could follow and support the efforts of the math-on-webpages Community Group and encourage a joint Task Force between the Community Group and the W3C's ARIA WG to investigate potential solutions such as a mathematics/STEM-related ARIA module.
The Accessibility Task Force of the Digital Publishing Interest Group performed a gap analysis identifying the needs of the digital publishing industry and WCAG. We did not perform a gap analysis for any other W3C standards. The meaningful results of the gap analysis have been broken out into this Note. However, the full gap analysis of the various techniques are refenced here which link out to the respective wiki tables. Here the team investigated each technique, whether or not it is a requisite for digital publishing, and indicated in initial comments what should be the jumping off point for discussion in the group.DPUB Specific WCAG General Techniques
DPUB Specific WCAG HTML Techniques
DPUB Specific WCAG CSS Techniques
DPUB Specific WCAG Client Side Scripting
DPUB Specific WCAG Server Side Scripting
DPUB Specific WCAG SMIL Techniques
DPUB Specific WCAG Plain Text Techniques
DPUB Specific WCAG ARIA Techniques
DPUB Specific WCAG Flash Techniques
DPUB Specific WCAG Silverlight Techniques
DPUB Specific WCAG PDF Techniques
DPUB Specific Common Failures
DPUB Specific Techniques
Some open specifications under development or maintained outside the W3C have great relevance to the accessibility in the digital publishing sector. Members of the W3C involved in accessibility within digital publishing need to be aware of work happening in these spaces. Here we describe some key projects that are relevant to our work.
EPUB is quickly becoming one of the de facto standards in digital publishing and is gaining global traction. Some existing reading systems read EPUB books. This standard is actively being updated and improved. EPUB is based on HTML5 and adheres to the WCAG accessibility standards.
[IDPF] (International Digital Publishing Forum) created and maintains the EPUB® standard.
Beginning with EPUB 3.0, the primary accessible publishing standard, DAISY DTBook and the primary commercial publishing format merged. DAISY’s Digital Talking Book [DAISY-DTD] is an XML-based file format and puts an emphasis on structural encoding to enable reading for the visually impaired audience. EPUB 2 allowed DTBook as an alternate syntax. The EPUB 3 specification merged DAISY and EPUB, making accessibility considerations a concern for all publishers, authors, and readers. The EPUB 3.0.1 specification is available at [EPUB3]. One of the features of this relationship is the [IDPF-EPUB-Structure-Semantics-Vocabulary], a namespaced vocabulary that enables semantic inflection of HTML elements. In 2015, several of these terms have been transformed into prefixed ARIA roles in [DPub-ARIA-1.0].
The IDPF and W3C Digital Publishing Interest Group work closely together on many issues, including broadening the definition of Web Accessibility to include long-form content. The Digital Publishing Interest Group’s Charter includes advancing EPUB 3 as one of the goals. Among the success criteria are providing advice to the IDPF EPUB 3.1 Working Group and advancing what is now called Portable Web Publications [PWP], a vision for the convergence of future of digital documents and the Web. Integrating the accessibility functionality that is native to the Web with the additions that DAISY and the IDPF have created is part of that vision.
The W3C standards bodies have developed multiple ways of creating extended descriptions for certain page elements, available for accessibility purposes. WAI-ARIA 1.1 draft proposes using ARIA-DETAILS and ARIA-LINKTYPE, and HTML5 has longdesc [HTML-LONGDESC]. Although the proposed ARIA changes address most of digital publishing's use cases, there is still need to have these extended descriptions accessible to those who may not be using assistive technology. [DIAGRAMMAR] is being developed to address this set of use cases.
The Diagrammar team intends to support a [DIAGRAMMAR] XML data to HTML transformation for presentation. Therefore, it will be useful for ongoing communication to continue.
[DIAGRAM-Center], a [BENETECH] initiative, in partnership with the WGBH National Center for Accessible Media and the US Fund for [DAISY], develops [DIAGRAMMAR].
In the early days of the web, there was recognition that images were an obstacle to persons who are blind and others who could not process the visual information. Today, we find that there are much more types of information objects that are not perceivable to persons with disabilities. Furthermore, publishers and other content creators recognize that alternative mechanisms for conveying information can benefit everybody. These extended descriptions not only pertain to images but any web element that is visually complex, requiring a description in more detail; the DIAGRAM Center hosts [DIAGRAMMAR] use cases for extended description information in multiple formats. Alternative representations may be required, and we need a way to link a specific web element to multiple representations be it an extended description, simplified description, or a tactile or auditory representation of the element.
[DIAGRAMMAR] is an XML framework to hold multiple extended description types, to make a wide range of content types accessible: images, tables, charts, animations, 3D animations, etc. [DIAGRAMMAR] defines a data model for extended descriptions and associated metadata. It provides a structured, standard way for modeling extended descriptions data, including different modality types for extended descriptions.
Any current discussion of digital publishing and accessibility should reference PDF and the accessibility efforts surrounding that technology.
PDF was released in 1992 and through the 1990’s quickly became the defacto standard as a replacement for "camera ready copy." PDF eliminated the problems associated with differences between computers and printers. One could finally take a single PDF file, print it anywhere and it would look identical. Publishers would take high resolution PDF pages and provide them to their printing houses for printing and binding; in fact, this remains the primary mechanism used today.
While printing of PDFs was a primary use case, the ability to be able to view the content consistently on any screens (just as on printers) became very popular and led to its adoption in many industries such as legal, engineering and government forms. These industries, combined with the printing industry, brought PDF to international standardization through the ISO as ISO 32000-1:2008.
This ability to be able to digitally represent both born-digital and paper-based content and distribute it through either formal or ad-hoc means is considered by some to be a form of digital publishing.
Unfortunately, PDF was not designed with accessibility in mind. While a PDF could be presented on a computer screen, Assistive Technology (AT) could not dependably read the PDF. In short, PDF was inaccessible to persons who are blind.
Over the years, PDF has added many features to enable greater accessibility (starting with PDF 1.3) in the form of Tagged PDF. This work was done in collaboration with the W3C and the WCAG working group and led to the publication of “[PDF-Techniques-for-WCAG-2.0]”
PDF/Universal Accessibility, commonly called PDF/UA is the informal name for ISO 14289, the International Standard for accessible PDF technology. PDF/UA became an ISO Standard on 15 July 2012. The latest release, PDF/UA Part 1, was approved as an ISO Standard on 18 December 2014. This standard specifies how to create accessible PDF files, create compliant PDF readers and also AT devices. The combination of the three providing a rich ecosystem for accessible PDF.
The adoption of PDF/UA has been slow, probably because of the lack of authoring tools, reading system interactions with AT, and general lack of training needed to add the additional tagging necessary to meet PDF/UA.