I agree with this. Also remember, its not necessarily the person producing wrong mark up by using the tool wrong, but sometimes the software itself, even if it is due to converting from another format (think of some of the problems which have been raised here in the past about the DAISY add on for word).
I never quite know what is the best way to solve this: If software allows plugins whether one should produce an accessibility checker/correction plugin (IE. try and solve the problems at source) or have it as separate tools/processes for people to do.
Also I wonder whether using heuristics for automatically finding/correcting these common problems might be useful or whether it could turn into an annoying feature. Probably something not for now, I think there are plenty more important matters to deal with and simply being able to manually correct it might be enough.
Michael Whapples On 11/09/2013 01:46, Keith Creasy wrote:
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 casesUp 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
