SVG

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.

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 img element requires:

<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>

Note that the SVG working group also provides a guide to making accessible SVGs that should also be consulted when creating content: http://www.w3.org/TR/SVG-access/

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.

MathML

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?

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.

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.

But although EPUB 3 now provides native support for MathML, it is still a good practice to include an alternate text fallback using the alttext attribute, as not all reading systems will support voicing of the markup:

<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>

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 annotation-xml element as follows:

<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>

Note that a semantics element now surrounds the entire equation. This element is required in order for the addition of the annotation-xml element to be valid.