Accessible Digital Media Guidelines
Guideline D: Digital Publications

Guideline D
Provide access to digital publications.

Accessible electronic books (e-books), digital talking books (DTBs) and on-line, HTML-based textbooks and training materials can bridge the gap that often exists for students or workers who require adapted reading materials, such as braille or audio recordings. Electronic versions of learning materials, if properly designed, can make curricular content equally accessible to all learners, at the same time.

While there are established digital talking book services, braille-production and tactile-graphic facilities that specialize in producing educational materials for blind children, major obstacles exist that force many students to begin class without the braille version of their books. At the K-12 level, teachers must identify all the texts that will be used in class well ahead of time and request adapted versions. At the post-secondary level, students must anticipate their own needs for adapted texts in each course they plan to take and request adapted versions. Often, these are custom requests, which must be created from scratch since teachers at all levels and in all fields keep current with new materials. The result is that students who require adapted textbooks, such as braille or audio recordings, often do not receive them before class begins.

Moreover, electronic files are needed to produce the braille version of the book. Math and science textbooks are among those most difficult to produce in braille. Too few transcribers are available with a knowledge of Nemeth code, the braille code for math. And the electronic files that publishers provide for some textbooks are not properly coded to translate mathematics automatically the way other text can be translated. This has led to a serious shortage of braille textbooks, especially those in the fields of math and science, for blind students.

Blind or low-vision students can use audiotaped books or books on CD for some content but this format is linear, does not allow easy navigation or bookmarking, is expensive, and is only available for popular trade books. Many learners who rely on audio versions of textbooks or professional publications utilize digital talking books (DTBs).

Strictly speaking, a DTB is a multimedia representation of a print publication that provides access to the text through digitally recorded human voice or synthetic text-to-speech technology. DTBs are largely aimed at blind or visually impaired users, but are also used to help improve reading and comprehension skills in students with learning disabilities. They provide various levels of navigation, from partial to complete, and can be read on dedicated hardware devices or on software players that run on Windows or Macintosh computers.

As more and more publishers issue electronic textbooks, it is anticipated that integrated multimedia will become more common in these materials. Biology texts would be able to illustrate cell division through the use of a short movie in addition to words and static images, for example. Audio-only clips could also be used to embed early recordings of famous speeches into a student's political science text. These types of media can all be made accessible through the use of captions and audio descriptions, and all can be integrated into e-books, DTBs and HTML texts.

A fully accessible electronic textbook can ensure that every student in class is using the same book, and that everyone receives it on the first day of school. The suggestions specific to math and science in these guidelines can reduce the barriers to studying these subjects that students with disabilities currently face and contribute to greater representation of people with disabilities in science and math-focused professions.

Checkpoint D1
Provide accessible on-line HTML books.

HTML-based on-line textbooks are similar to Web sites in that they can be made accessible by using proper markup. The following structural elements are commonly encountered in on-line textbooks and may be made accessible using techniques found throughout these guidelines as well as the Web Content Accessibility Guidelines.

• images
• image maps
• charts and graphs
• tables
• forms
• multimedia
• scientific or mathematical expressions

Navigation features required for accessibility in an on-line textbook include:

• links for moving forward or backward by chapter, placed at the beginning and end of each page or section.
• links which move the user to the top of the page or beginning of a chapter.
• links that lead directly to the table of contents and/or index.
• headers to divide chapters or sections of information.
• search capability.

Checkpoint D2
Provide accessible electronic books (e-books).

There are three factors that must be addressed for e-books to fulfill their potential to provide equal access to all readers — the content format, the use of accessibility techniques within that format, and the device used to render the material (text, images, multimedia, etc.) itself.

While there are several popular e-book formats available, not all are entirely accessible to blind or visually impaired users. E-books which are created using basic accessibility techniques tend to give the user the greatest chance of having an accessible reading experience. Such techniques include the use of alt on all images, properly worded links and the use of headers to divide chapters or categories of information.

Adobe, through its Adobe Reader, has made an effort to offer accessible reading experiences through the use of built-in text-to-speech engines that offer the user varying degrees of control over the document's presentation. The usability of the reader will vary according to the individual's needs. Adobe Reader will read the document's text aloud to the user, but offers very little else in terms of true accessibility: it has no provision for distinguishing alt text from body text, and it doesn't announce headers or hyperlinks. This may be not be problematic for users with mild visual impairment, but will not necessarily be helpful for someone who is reliant on text-to-speech technology. However, in many cases PDF e-books can be quite accessible to a screen reader when authored according to basic Web-accessibility principles.

Multimedia can be accommodated by directly embedding elements such as video or audio clips into the book, or by using internal or external links to launch and play the media. See Guideline H for complete information on creating accessible multimedia, and Guideline I for details on integrating accessible multimedia into e-books.

Other e-book formats may not offer enough accessibility to be useful to blind or some visually-impaired readers, although their accessibility may satisfy most deaf or hard-of-hearing users. For example, the desktop versions of MobiPocket and Palm eReader (PRC and PDB formats, respectively) will offer screen-reader users limited accessibility: desktop and laptop users may be able to access the text of these formats by using specific screen-reader modes (such as screen-reader cursor mode), but doing so only allows access to text, not images, hyperlinks or other information. External links to multimedia presented in these formats (embedded multimedia is not supported) will likewise be inaccessible to anyone who cannot see the screen or use a mouse.

In addition, the accessibility of the device used to read an e-book should be taken into consideration. E-books which can be read on laptop or desktop computers tend to provide the greatest flexibility for users of assistive technology. Handheld devices, such as dedicated e-book readers, PDAs or even cell phones, can be used to read certain formats of e-books but provide limited or no accessibility for blind or visually impaired users. (Deaf or hard-of-hearing users, however, may find these devices sufficient for reading e-books.)

Digital Rights Management (DRM)

Accessibility problems in e-books are sometimes linked to issues surrounding digital rights management, or DRM. DRM can be used to control how the content is presented to the user as well as how much control the user is given over the e-book. For example, some e-books can be printed on paper in their entirety by the user, whereas some allow only certain pages to be printed. Others allow no printing at all. Similarly, some e-books can be issued so that the built-in text-to-speech feature is disabled, or so that screen-reader access is limited.

DRM can be applied through various methods. Software reading devices themselves do not normally apply DRM; rather, the e-book content arrives with DRM restrictions already in place and the devices implement the requested restrictions. Most hardware reading devices are also capable of implementing or enforcing DRM.

Open standards

While many e-book formats are proprietary or locked in some fashion using DRM, there exists one non-proprietary method of authoring e-books: the Open eBook Publication Structure (OEBPS) format. OEBPS is an XML-based framework specification for content, structure and presentation of electronic books. It was created by the International Digital Publishing Forum (IDPF, formerly the OEBF, the Open eBook Forum) as a way for authors, editors and publishers to create and distribute texts that can be used by a variety of electronic publishing systems and reading devices (collectively known as reading systems).

OEBPS-formatted materials can be read by any reading system that supports the format. There is at least one native OEBPS-format e-book reader — eMonocle — which renders native OEBPS publications, just as a Web browser reads HTML files directly. A number of distilled formats also exist, such as MobiPocket's PRC, and eBook Technologies' IMP. These are optionally DRM-restricted e-books created directly from OEBPS source files. These reading systems will not, however, read native OEBPS files themselves.

Authors familiar with creating accessible Web sites will find creating accessible OEBPS files to be a similar process. By following the basic principles discussed in these guidelines, as well as those detailed in WCAG 2.0, it is possible to create a highly accessible e-book (with or without multimedia) in the OEPBS format.

However, the accessibility of OEBPS-format e-books to users who rely primarily on screen readers is largely a function of the user agent (the software or hardware used to read the book), not just the way the book is structured. Creating an OEPBS document that follows accepted accessibility guidelines is one thing; finding a compatible reading device that is accessible to blind or visually impaired users is another.

Despite the existence of this non-proprietary format, however, there remains the problem of content availability. Compared with the number of titles available in distilled formats such as PDF, there are few native OEBPS e-books circulating today. In addition, there are no simple-to-use applications for creating books in this format. While authors can use automated tools to create an HTML version of the e-book, the .opf file, which controls the presentation of the material, is usually constructed by hand or created with tools generally targeting a particular distilled format. While not necessarily difficult for anyone familiar with XML, creating the .opf file may not be a task that a casual author or small publisher will want to handle.

Two current standardization efforts within the IDPF may enhance the accessibility of OEBPS content. First, the Unified OEBPS Container Working Group is developing a standard for the packaging of all OEBPS e-book components (the package, HTML markup, style sheets, images, etc.) into a single file entity. While one application of the container will be for the delivery of e-book content from publishers and other content creators to the sales or distribution channel, it is likely that future OEBPS reading systems will natively render this format. Such native rendering abilities may allow accessible content to flow directly to users in need of such functionality. Second, the OEBPS Working Group has been re-chartered. Its mission is to develop the next generation of the OEBPS content standard; continuing and extending the accessible nature of such content is a high-level requirement of the working group.

Other non-proprietary approaches are also being explored. Currently in development, the new OpenReader format is a next-generation XML-based publication framework inspired by the OEBPS 2.0 work done by OEBF/IDPF between 2001 and 2003. It is a cross-platform approach to authoring many types of digital publications, from books to newspapers to certain types of business and government documents. As with OEBPS, OpenReader is not a software or hardware reader, but is an XML-based file framework which can be read by such devices. No OpenReader-compatible devices have been released yet although one company, OSoft, has created a Java-based reader that supports the delivery of open-standards documents. Called ThoutReader, it is available for a number of platforms and operating systems. In late 2005, OSoft announced that it will support the OpenReader format in open-source, Perl-based software due for release in mid-2006.

Because of its modular, extensible design, OpenReader will be able to support documents of other XML vocabularies. In later versions, OpenReader is planning support for SMIL, a non-proprietary multimedia-integration language from the W3C. Assuming that OpenReader-compatible reading devices are accessible to assistive technology such as screen readers, OpenReader has the potential to provide an accessible reading experience for all users.

Technique D2.1
Create accessible PDF e-books

The Adobe Reader — the primary reading device for PDF e-books — can provide a reasonably accessible reading experience for blind and visually impaired users provided authors and publishers take care to create accessible documents and not shut out features through overly strict application of DRM. Adobe Acrobat provides a convenient method for applying "tags" which provide structural information to assistive technologies which in turn can deliver content in an accessible manner to users. Documents containing text, pictures and links can, generally speaking, be made quite accessible, while some structural elements, such as forms and data tables, are still not very accessible in PDF. Adobe's ongoing efforts to make PDF more accessible are described at Adobe's accessibility site.

Two resources detailing what is necessary to create accessible PDF documents are shown below.

• Adobe's Creating Accessible PDF documents, a detailed set of instructions for creating accessible PDF documents.
• WebAIM's PDF accessibility tutorial, a concise set of instructions and shortcuts for creating accessible PDF documents.

Acrobat offers a number of accessibility features through the Advanced/Accessibility menu, including support for automatic tagging. However, Acrobat's tagging feature should not be considered a foolproof approach to providing accessible PDF documents. After adding tags, authors must still test the document for proper reading order, tab order, element identification, etc., using a screen reader. Similarly, Acrobat's built-in accessibility checkers (Quick Check and Full Check) should be used as supplements to, not as substitutes for, rigorous testing with a screen reader and keyboard.

In addition to implementing the advice offered in the above tutorials, authors should provide a set of access instructions at the beginning of the book. These instructions can include information about navigational structure as well as multimedia clips if they are used (how to access and control them, for example, or where they are located in the book). Ensure that the access instructions are available in the table of contents; authors can even place a link to the instructions on the title page. You can see an example of an access-instruction link in a PDF e-book in the image below.



Complete information about providing accessible multimedia in PDF e-books can be found in Guideline I.

Technique D2.2
Create accessible OEBPS e-books

As discussed previously, there are no software applications currently available that create cross-reading-system OEBPS e-books. However, authors can create the source material in HTML (styled with CSS) which can then be prepared for use in an OEBPS-compatible reader. (Note that OEBPS documents can contain a broad subset of HTML and CSS, but not a complete implementation. Read the list of supported HTML elements and attributes and CSS properties before authoring the OEBPS e-book.)

The accessibility of OEBPS-format e-books to users who rely primarily on screen readers is largely a function of the user agent (the software or hardware used to read the book), not just the way the book is structured. Creating an OEPBS document that follows accepted accessibility guidelines is one thing; finding a compatible reading device that is accessible to blind or visually impaired users is another. OEBPS-compatible reading devices include the Mentoract Reader (still in beta), and eMonocle.

With this caveat in mind, the techniques below outline the basic process for creating an OEBPS publication that could be accessible to all users. Authors interested in a more in-depth approach to creating OEBPS e-books should read the Open eBook Publication Structure 1.2 specification. Portions of the material below were adapted from this document.

Create the HTML source, following the accessibility practices outlined in these guidelines as well as the techniques detailed in WCAG 2.0. Once you have finished writing the source, create an Open eBook Package File that uses the extension .opf for the filename. The OPF is an XML file consisting of specific information about the contents and structure of the book. The major parts of the OPF are as follows:

• the package identity
• metadata, such as title, author, publisher, date, etc.
• the manifest, a list of items that comprise the publication (HTML pages, images, etc.)
• the spine, which lists the elements of the book arranged in a linear reading order
• tours (optional), giving the reader alternative reading sequences of the book
• guide (optional), locating the a table of contents, forward, bibliography, etc.

Note that "tours" and "guide" are optional. All other elements are mandatory.

Below is an example of a basic .opf, showing mandatory elements only.


Begin the OPF file by declaring the DOCTYPE:


Next, enter metadata describing the publication. OPF metadata are based on Dublin Core metadata within a <dc-metadata> element. Any number of Dublin Core elements may be used, including multiple instances of the same type. A few are shown below.


Multiple dc:Identifier elements may be specified, generally including a scheme attribute to declare the type of identifier (e.g. ISBN, DOI). At least one dc:Identifier must have an id attribute; the top-level package element must reference one of these ids via its unique-identifier attribute to specify the publication's primary identifier.

Once you have finished describing the contents in the metadata, create a <manifest> containing all elements of the publication, including style sheets, images and, if applicable, multimedia elements (such as movies, audio clips, etc.). The <manifest> does not require that these elements be listed in any particular order.



Note the use of the fallback attribute, which is used by reading devices which do not support certain media types specified in the manifest. Typically, fallback items are in the formats specified by the OEBPS core media types. OEBPS-compatible reading devices must support all of the core media types and may optionally support others. If you are providing non-core media types in your publication (such as a QuickTime movie), for example, you must also include a valid fallback.

Next, in the <spine>, list all the components of the publication. The <spine> requires that all components be listed in the desired sequential reading order.

In the example above, the first item the reader will see in the book is the title page, taken from the file href="vo_coverpage_oeb.htm", and the next item will be the actual body of the document, taken from the file href="vo_oeb.htm". The final item is the additional notes found in notetext.

The author may include <tours> and <guide> elements, if desired. A <tours> may be used to lead the reader to specific areas of interest in the publication. A <tours> may include multiple <tour> elements. Here is an example of <tours> code.


Finally, the .opf may contain a <guide> element, which is used to identify important components of the publication. An OEBPF-compliant reading device may use the <guide> to provide access to specific sections of the book, similar to a table of contents.

Technique D2.3
Create NIMAS files

NIMAS (the National Instructional Materials Accessibility Standard) requires publishers to provide electronic files in a consistent format designed to make digital talking book (DTB) and braille production of K-12 texts easier and faster.

NIMAS, an XML format, is a subset of the DAISY ANSI/NISO Z39.86 standard. The full specification includes all the tags needed to mark up a digital book, with some exceptions (mathematics, multimedia) that are still subject to ongoing work in the DAISY/NISO maintenance committee.

The original committee that formed to develop the standard (the National File Format Technical Panel) agreed to a list of baseline tags that would be part of NIMAS and therefore required in files provided by textbook publishers. The committee also agreed that the remaining tags in the DAISY/NISO spec would be optional: publishers can provide those tags if they wish, or they may be added afterward where needed by organizations developing accessible materials for student use.

The NIMAS Web site also provides exemplars, which are complete NIMAS files for use by organizations developing NIMAS files or tools. Below is a fragment from one exemplar.


The following image shows how a simple visual style sheet might render a page from this book.



Detailed information describing the structure of NIMAS documents is available on the NIMAS at CAST Web site. The full DAISY/NISO specification is available at the DAISY Web site.

The value of the NIMAS format is that it can be transformed in many ways, to produce braille, large print, audio books, or accessible electronic text. This is just one example of what is possible.

Checkpoint D3
Provide textbooks for handheld devices.

While they haven't disappeared entirely from the market, dedicated hand-held e-book readers have lost popularity to multi-use devices such as laptops, PDAs and even cell phones. The eBookwise 1150 and the ETI e-book readers are among the few dedicated hardware e-book readers still available in North America. Sony has also announced plans to issue a new E-Ink-based hardware reader in 2006, called the Sony Reader. Another device, the iRex iLiad, also features E-Ink technology.

For the time being, for those authors planning to include multimedia in e-books who also want to provide versions for handheld-device users, the practical choices are restricted to Palm and Windows Pocket PC/Mobile (2003/2003SE and Windows Mobile 5) operating systems. There are several e-book readers for these OSes, such as Adobe Reader (Palm and Windows Pocket PC/Mobile) and MobiPocket Reader (Palm only), plus iSilo and eReader Pro (Palm and Windows Pocket PC/Mobile), and Plucker (Palm only). No handheld reader currently supports embedded multimedia, but some will link to remote clips through players such as Windows Media Player or Kinoma Player. Note that while screen readers are slowly becoming available for Windows Pocket PC/Mobile OS devices (such as Humanware's Maestro or CodeFactory's Mobile Speak Pocket) these have yet to be proven reliably compatible with e-book software. For now, cautious authors may still want to view handheld e-book software as inaccessible to blind users. However, deaf or hard-of-hearing users may benefit from reading e-books on these devices, and videos or audio clips incorporated into handheld e-books can, in most cases, include captions (see Guideline H).

Checkpoint D4
Provide textbooks as digital talking books (DTBs).

Strictly speaking, a digital talking book (DTB) is a multimedia representation of a print publication that provides access to the text through digitally recorded human voice or synthetic text-to-speech technology. DTBs are largely aimed at blind or visually impaired users, but are also used to help improve reading and comprehension skills in students with learning disabilities. They provide various levels of navigation, from partial to complete, and can be read on dedicated hardware devices or on software players that run on Windows or Macintosh computers. There is also at least one DTB player for Windows Pocket PC/Mobile devices.

In addition to providing accessible text to blind or visually impaired users, even the most basic DTB reader can accommodate accessible audio clips — that is, in-line audio clips with integrated audio descriptions. These described clips can be inserted directly into the DTB's structure wherever they are necessary, and will be played automatically by the DTB reader when the user is listening to recorded speech.

Properly created DTBs are based on the DAISY ANSI/NISO Z39.86 standard. As with any XML-based markup language, DTBs can be coded entirely by hand using any text editor, but there are a variety of software applications which simplify and speed the creation of DTBs . See the DAISY Consortium's list of DTB production tools for more information. DTBs can also accommodate linked and embedded multimedia; for instructions on creating books with these features, see Guideline J.

Checkpoint D5
Provide accessible multimedia in on-line textbooks.

Multimedia may be embedded in an electronic textbook or it may be launched in a separate, stand-alone player. Embedding a video or audio clip in a Web page can make for neater design, but most embedded clips don't offer full keyboard access to caption or audio-description preferences, making it difficult for deaf or blind users to find these features. Some embedded players can't be controlled without a mouse, making them impossible for keyboard users to manipulate. Giving the user the option of launching a stand-alone player is often the safest way of presenting multimedia because users can more easily control the presentation.

For details on creating accessible multimedia and adding it to e-books, see Guideline I.

Checkpoint D6
Provide alternative presentations of electronic or on-line textbooks.

Hard copies of the textbook should be available for those who wish to read with magnifying hardware, and braille copies complete with tactile graphics should also be available. Once created, the brailled textbook can be made available through the publisher's distribution mechanism, through an arrangement made with the braille production facility or via the course instructor. Availability of brailled materials should be clearly documented on the Web site, including contact information. Brailled books should also be listed with the American Printing House for the Blind, a central source of information on how educators can locate accessible materials, listed in Appendix 1. Also see Appendix 1 for information on braille services.

When providing equivalent access via brailled textbooks or tactile graphics, consider timeliness. Ensure that the service provider receives the original materials as far in advance as possible. Depending on the subject matter, the length of the textbook and the complexity of the graphics, it may take up to several weeks to create the braille or tactile copies.