Can you have an ebook format for education that doesn’t support math? (Note: it’s a rhetorical question!)
Math is pervasive, despite the common perception that it’s only for STEM. Even novels have been known to include equations from time-to-time.
And yet consumer-end MathML support in digital works is still lacking, despite two decades of work in W3C. If you want the whole story, Peter Krautzberger has written a fantastic article on the history of MathML and support in browsers that I’d highly recommend reading. I’m not going to attempt anything similar today, as there’s nothing of value a math neophyte like me could add.
Rather, what has me thinking MathML is the upcoming second EDUPUB conference, and the lack of consistent rendering, and voicing, of math in EPUB reading systems. In particular, how do we effect real change?
But first, if it needs justification, there are lots of good reasons why we need MathML, not least of which is that math equations are not pictures — despite the prevalent belief to the opposite among web-goers.
I think there’s a tendency to forget that the pictures you get in ebooks today have to come from somewhere, and authors aren’t drawing them by hand. The problem is that MathML on the back-end doesn’t often see the light of day because support has been, and still is, so spotty. (I realize some people will have LaTeX behind the scenes, but assuming getting to MathML isn’t what prevents it being used in outputs.)
Math is a text format, so representing it as pictures is on par with adding pictures of headings or other text. Let me correct that, it’s worse than plain old text in images because describing a math equation is so much more complex. The alt text is rarely a one-to-one representation of the text in the image.
To cite the simple example I put in the book, what does the description “square root of a plus b” translate into? There are two ways to read it. With MathML (and voicing), anyone could figure out the correct interpretation, as the equation becomes part of the DOM and can be walked over. Without… well, you’re at the mercy of a description.
Assuming you believe me that MathML is a key need for accessibility, why does native support in browsers, and by extension reading systems, matter so much? We’ve lived with plugins and polyfills this long, right?
While these solutions work for the web generally, neither represents a great solution for ebooks. Plugins, for example, simply aren’t viable for reading system apps. The reader has to use a browser to take advantage of them. And when you start putting restrictions on what devices and applications a reader can use, you ghettoize accessibility, which is what making accessibility a core tenet of a mainstream format like EPUB was intended to get away from.
To use Design Science’s plugin doesn’t mean only limiting yourself to IE9 and below (now that IE doesn’t support plugins), but means limiting yourself to only reading systems that directly run inside a browser.
Polyfills have greater range, but suffer a kind of impedance mismatch with ebooks and reading systems. For one, who implements the polyfill? Is it the reading system that lacks native support, or is it the content author who wants to ensure the ebook will render no matter the reading system?
And if it is the author, why is it incumbent upon them to integrate what is a rendering engine into their content? It’s bizarre — almost beyond words — for a standalone format, and barely more tolerable for regular web pages.
There are other technical reasons why native is better than code that has to be run at rendering time and/or live on top of the browser. Speed of rendering is a commonly cited one. Access to fonts another.
We’re lucky to have MathPlayer and MathJax to bridge the gap, don’t get me wrong, but ultimately the goal has to be integration into the core.
Fixing the equation
So what can be done to improve the situation?
What is interesting from reading Peter’s article is how MathML is treated as peripheral technology not worth investing resources into. I can see that pre-HTML5, but I’d have expected that view to have changed with support being integrated. It’s odd, to say the least, that unless volunteers are working on these implementations they go nowhere.
That said, this lack of priority also gives a possible clue about what needs to be done. Either the organizational disinterest in supporting math needs to change, or developers need to be financed to finish the work (even if they’re volunteers as far as submitting the code goes).
There is a persistent belief that MathML is underused, because images are what appear in web and EPUB content. An analysis of web markup isn’t going reveal much of anything about the amount of MathML that flows through publishing, for example, or how much is stifled before it ever makes it out the door.
It might be time for a concerted push by the large publishers and/or publishing organizations to raise awareness that treating MathML development as a peripheral need has to change. A little heft couldn’t hurt.
Barring that, funding a developer to finish the WebKit code might be another alternative. If it is as key to digital publishing for education as I believe, finding that money shouldn’t require moving mountains. How it would go over with the browser engine folks I couldn’t say, but I’m only out to speculate on options.
Maybe I’m being naive and have stars in my eyes, but now that MathML is a core part of HTML5, pushing support over the final hurdles seems like a goal everyone can share.
Of course, MathML rendering doesn’t mean MathML voicing, so there are still hurdles, but we have to start somewhere.
But before I go off too long on this, I’ll wrap up by expressing how frustrating it is to have more “potential” for accessible math than actual support.
When I can’t convince myself that I’d trust MathML rendering… and unformatted math is as inaccessible for sighted readers as pictures of math can be for blind… well, that’s how we get stuck in these cycles.
It’ll be interesting to see what comes at this next EDUPUB meeting, and whether a strategy for MathML hits the radar.