|
The goal of adding semantic meaning is laudable. And epub3 has taken this a real step forward by allowing epub:type attributes to be attached to provide semantic meaning in many places (just not in guide/landmarks).
But I truly wonder if any accessibility software ever takes advantage of any of it. Many screen based text to speech routines never see the actual code and instead simply grab the text from the screen buffer meaning that none of the semantic meaning of the code will ever be seen let alone used.
And has anyone read all of the different web pages that try to explain the difference between i and em and b and strong? They seem to need actual translators themselves and end up being more confusing that actually helpful. The printed page had italics and bold and at one time these made sense and everyone understood them. Now we as ebook authors have to intuit the authors meaning by using these which is never 100% clear no matter what approach is used.
I would prefer we reverted to the i and b tags and then added an attribute to them (either an aria-role or epub:type or a special class name) that indicates how the author meant it to be used semantically and stop adding long span tags that simply end up cluttering the code.
Of course I am older and grumpy and don't like change! ;-)
|