[brailleblaster] Editing Ebooks for Braille
- From: "Keith Creasy" <kcreasy@xxxxxxxxx>
- To: <brailleblaster@xxxxxxxxxxxxx>
- Date: Tue, 10 Sep 2013 20:46:17 -0400
All.
This evening I've spent some time reading and pondering the best practices
and accessibility guidelines for DTBook, NIMAS, and EPub. I've thought about
each item and how it relates to braille production and rendering. It has
caused me to change my outlook just a bit. The main point is that the reason
we have to make so many braille corrections is not because the standards are
insufficient but because creators do not follow best practices nor are they
likely to in many cases
Up until now I've resisted the urge to change the original document because
I regarded it as the work of the author and publisher. Up to now though none
of the documents ever go back upstream all the way to the publisher so why
not make corrections to the original markup so that the braille is correct
whenever possible? We already have plans to do that in some cases, such as
adding MathML in place of other, less accessible ways of representing math
and adding image descriptions.
Another example is the table of contents. All three of these standards have
very specific ways of representing the TOC of a book or section. If done
correctly there is no reason LibLouisUTDML should not be able to create an
appropriate braille TOC automatically. If it can't it is because the
original document is not marked up according to the best practices.
Likewise, using emphasis for only visual presentation is not considered the
best practice for any of these standards, so why not provide a way to remove
it when appropriate.
Yet another feature that may or not be used correctly is the "type"
attribute in XHTML5. Its sole purpose is to provide rich semantic
information for, among other things, accessibility. Why not use it to add
semantic information whenever possible and use it in our semantic action
files to give LibLouisUTDML more information on which to base the braille
output.
The advantage of this approach for BrailleBlaster is that it suddenly
becomes much more than a tool for creating braille, it becomes a tool for
producing a better EBook that more closely follows best practices, in
particular best practices for accessibility.
Along with this change to how we "fix" eBooks' for braille, we need to shift
the emphasis from DTBook and UTD documents to EPub3 and the content document
type XHTML5. So, for example, what I'm suggesting is that when a user
decides to create a new document XHTML5 or EPub3 becomes the default type.
Whether we support others is another question.
None of this involves any huge change from the current plans and may make
getting LibLouisUTDML to perform better on complex documents because it gets
better content to start with.
This is all mostly philosophical at this point but I hope others will think
about it and comment.
Regards,
Keith
Other related posts:
