epubjs

Version:

Render ePub documents in the browser, across many devices

58 lines (55 loc) • 4.38 kB

HTML

<?xml version="1.0" encoding="UTF-8" ?><!DOCTYPE html><html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <title>The Coded Word: Scripted Interactivity</title> <link rel="stylesheet" type="text/css" href="css/epub.css" /> <meta name="dat-origPath" value="/html/body" /><link rel="prev" href="./ch03s03_11.html" /><link rel="next" href="./ch03s04_1.html" /></head><body> <h2 class="title" id="_the_coded_word_scripted_interactivity" data-origPath="/html/body/section/h2">The Coded Word: Scripted Interactivity</h2> Whether you’re a fan of scripted ebooks or not, EPUB 3 has opened the door to their creation, so we’ll now take a look at some of the potential accessibility pitfalls and how they can be avoided. One of the key new terms you’ll hear in relation to the use of scripting in EPUB 3 is progressive enhancement. The concept of progressive enhancement is not original to EPUB, however, nor is it limited to scripting. I’ve actually been making a case for many of its other core tenets throughout this guide, such as separation of content and style, content conveying meaning, etc. Applied in this context, however, it means that scripting must only enhance your core content. We’ve already covered why structure and semantics should carry all the information necessary to understand your content, but that presupposes that it is all available. The ability for scripts to remove access to content from anyone without a JavaScript-enabled reading system is a major concern not just for persons using accessible devices, but for all readers. And that’s why scripting access to content <a class="ulink" href="http://idpf.org/epub/30/spec/epub30-contentdocs.html#confreq-cd-scripted-spine" target="_top">is forbidden in EPUB 3</a>. If you try to circumvent the specification requirement and treat progressive enhancement as just an “accessibility thing,” you’re underestimating the readership that are going to rely on your content rendering properly without scripting. Picture buying a book that has pages glued together and you’ll get an idea of how excited your readers will be that you thought no one would notice. <aside class="note" title="Note" data-origPath="/html/body/section/aside"> <h3 class="title">Note</h3> Note that it’s not a truism that you can expect JavaScript support in EPUB 3 reading systems. There will undoubtedly be widespread support for scripting in time, but support is an optional feature that vendors and developers can choose to ignore. </aside> Meeting the general requirement to keep your text accessible is really not asking a lot, though. As soon as you turn to JavaScript to alter (or enable) access to prose, you should realize you’re on the wrong path. To this end: <ul class="itemizedlist" data-origPath="/html/body/section/ul[1]"> <li class="listitem"> Don’t include content that can only be accessed (made visible) through scripted interaction. </li> <li class="listitem"> Don’t script-enable content based on a reader’s preferences, location, language, or any other setting. </li> <li class="listitem"> Don’t require scripting in order for the reader to continue moving through the content (e.g., choose your own adventure books). </li> </ul> Whether or not your prose can be accessed is not hard to test, even if it can’t be done reliably by validators like <a class="ulink" href="http://code.google.com/p/epubcheck/" target="_top">epubcheck</a>. Turn off JavaScript and see if you can navigate your document from beginning to end. You may not get all the bells and whistles when scripting is turned off, but you should be able to get through with no loss of information. If you can’t, you need to review why prose is not available or has disappeared, why navigation gets blocked, etc., and find another way to do what you were attempting. </body> </html>