epubjs
Version:
Render ePub documents in the browser, across many devices
108 lines (106 loc) • 6.57 kB
HTML
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Chapter 2. Building a Better EPUB: Fundamental Accessibility</title>
<link rel="stylesheet" type="text/css" href="css/epub.css" />
<meta name="dat-origPath" value="/html/body/section/section" /><link rel="prev" href="./ch02_11.html" /><link rel="next" href="./ch02_13.html" /></head><body>
<section class="sect2" title="SVG" data-origPath="/html/body/section/section/section[12]">
<h3 class="title" id="_svg">SVG</h3>
<p>Rounding out the tour of image functionality is SVG. It comes up for debate
every so often just how accessible SVG really is, and while you can argue
that it can be more accessible than non-XML formats like JPEG and PNG,
there’s no blanket statement like “SVG is completely accessible” that can be
applied. Like all content, an SVG is only as accessible as you make it, and
when you start scripting one, for example, you can fall into all the typical
inaccessibility traps.</p>
<p>The advantages of SVG for accessibility are noteworthy, though. You can scale
SVG images without the need for specialized zoom software (and without the
typical pixelation effect that occurs when zooming raster formats), the
images are accessible technology-friendly when it comes to scripting and can
be augmented by WAI-ARIA, and you can add a title and a description directly
to the markup without resorting to the messy techniques the <code class="literal">img</code> element requires:</p>
<pre class="screen"><svg:svg xmlns:svg="http://www.w3.org/2000/svg">
<svg:title>Figure 1.1, The Hydrologic Cycle</svg:title>
<svg:desc>
The diagram shows the processes of evaporation, condensation,
evapotranspiration, water storage in ice and snow, and
precipitation. …
</svg:desc>
…
</svg:svg></pre>
<p>Note that the SVG working group also provides a guide to making accessible
SVGs that should also be consulted when creating content: <a class="ulink" href="http://www.w3.org/TR/SVG-access/" target="_top">http://www.w3.org/TR/SVG-access/</a></p>
<p>The accessibility hooks are also why SVG has been promoted up to a
first-class content format (i.e., your ebook can contain only SVG images;
they don’t have to be embedded in XHTML files). But if you are going to go
with an image-only ebook, the quality of your descriptions is going to be
paramount, as they will have to tell the story that is lost in your visual
imagery. And to be frank, sometimes descriptions will simply fail to capture
the richness and complexity of your content, in which case fallback text
serializations should be considered.</p>
</section>
<section class="sect2" title="MathML" data-origPath="/html/body/section/section/section[13]">
<h3 class="title" id="_mathml">MathML</h3>
<p>Why is MathML important for accessibility? Consider the following simple
description of an equation: the square root of a over b. If you hastily
added this description to an image of the corresponding equation, what would
you expect a reader who couldn’t see your image to make of it? Did you mean
they should take the square root of a and divide that by b, or did you mean
for them to take the square root of the result of dividing a by b?</p>
<p>The lack of MathML support until now has resulted in these kinds of
ambiguities arising in the natural language descriptions that accompanied
math images. Ideally your author would describe all their formulas, but the
ability to write an equation doesn’t always translate into the ability to
effectively describe it for someone who can’t see it. And sometimes you have
to make do with the resources you have available at hand at the time you
generate the ebook, and lacking both academic and description expertise is a
recipe for disaster.</p>
<p>MathML takes the ambiguity out of the equation, as assistive technologies
have come a long way in terms of being able to voice math equations now.
There are even Word plugins that can enable authors to visually create
equations for you without having to know MathML, and tools that can convert
LaTeX to MathML. The resources are out there to support MathML workflows, in
other words.</p>
<p>But although EPUB 3 now provides native support for MathML, it is still a
good practice to include an alternate text fallback using the <code class="literal">alttext</code> attribute, as not all reading systems
will support voicing of the markup:</p>
<pre class="screen"><m:math
xmlns:m="http://www.w3.org/1998/Math/MathML"
alttext="Frac Root a EndRoot Over b EndFrac">
<m:mfrac>
<m:msqrt>
<m:mtext>a</m:mtext>
</m:msqrt>
<m:mi>b</m:mi>
</m:mfrac>
</m:math></pre>
<aside class="note" title="Note">
<h3 class="title">Note</h3>
<p>The preceding description was written in MathSpeak. For more information,
see the <a class="ulink" href="http://www.gh-mathspeak.com/" target="_top">MathSpeak™ Initiative homepage</a>.</p>
</aside>
<p>If the equation cannot be described within an attribute (e.g., it would
surpass the 255 character limit, requires markup elements, like ruby, to
fully describe, etc.), it is recommended that the description be written in
XHTML and embedded in an <code class="literal">annotation-xml</code> element
as follows:</p>
<pre class="screen"><m:math xmlns:m="http://www.w3.org/1998/Math/MathML">
<m:semantics>
<m:mfrac>
…
</m:mfrac>
<m:annotation-xml
encoding="application/xhtml+xml"
name="alternate-representation">
<span xmlns="http://www.w3.org/1999/xhtml">
Frac Root a EndRoot Over b EndFrac
</span>
</m:annotation-xml>
</m:semantics>
</m:math></pre>
<p>Note that a <code class="literal">semantics</code> element now surrounds the
entire equation. This element is required in order for the addition of the
annotation-xml element to be valid.</p>
</section>
</body>
</html>