HTML tags

7 posts / 0 new
Last post

Sorry if this has been answered but I'm too dumb to find it.

Why is it that the simple formatting tags <b> <i> <u>, etc. aren't allowed by the EPUB spec?

These these tags would allow the reader to disable the formatting information from the style sheet (CSS file), and thus allow them format the document to their satisfaction, without losing the important context provided by these tags.

For example:
Johnny looked at the cloudy sky. <span class="ItalicClassDeclaredInTheCSS">What miserable weather we're having</span>


Johnny looked at the cloudy sky. <i>What Miserable weather we're having</i>

The former would "break" if the CSS file is disabled whereas the latter wouldn't.

Right, and CSS alone loses the intention of voice stress, change in tone, etc. which ATs can provide when present.

There's no such general restriction on the elements in the specifications, so not sure where, or why, you heard that you can't use them. The u element was deprecated in XHTML 1.1 and hence not a part of EPUB 2, though.

But people do tend to mix up the use cases for bolding and italics. The strong and em tags are for voice emphasis, the b and i tags infer a change in tone or mood or a semantic meaning without the voice stress, and CSS is for decorating text without meaning. I've been trying to document these kinds of issues in the accessible content guidelines I've been drawing up (still a work in progress, though), and the HTML5 spec also lays out their use if you read the definitions.

And the u tag has been given new life in HTML5, so it is valid to use again. I can't think of good real-world use cases for it off the top of my head, but you can take direction from the specification definition.

Hope that helps.

Thank you very much for the clarification and I apologise for my mistake.

The idea got stuck in my head because every EPUB creator software I've seen uses a "span" tag (which references a CSS class) to emphasise text. Even aside from accessibility problems it might create, it's generates a larger file to achieve an identical visual effect. That a programmer would go that route suggests that they've been "told" to rather than doing it by choice. As it's the writers of multiple, independent EPUB creator applications, I assumed it was the spec. forcing their hand. You know what they say about assuming things!

I've read a lot of EPUBs but, as a developer, I'm still learning my way around how EPUBs work. So I had a look at
It mentions that using CSS to emphasise text is "preferred". So I think I'll have to see if I can get in touch with the author.

Thanks again for your help.

Ah, right, by default a lot of layout tools will do very basic exports of paragraphs and spans with CSS. With InDesign, for example, you need to familiarize yourself with the styling functionality to generate much better quality EPUBs.

And, unfortunately, people often don't think about how readers who aren't looking at the content will interact with it, or what information they require to get an equivalent experience, which is where that kind of advice generally comes from. Not to self-promote, but I'd recommend having a look at the free O'Reilly piece I wrote on creating accessible EPUB 3 content for an intro to why structured content matters and some ideas on what to watch out for (if you don't want to register, you can get an EPUB 3 version from the samples project downloads).

Thanks again Matt, I'm reading my way through your guide. Honestly though, I'm not involved in creating EPUBs so it's more for personal knowledge than for practical use. However, if there were a way to put "Accessable EPUB 3" in front of the people who run the publishing houses, the world would be a better place.

I suspect that part of the problem is that the available software for creating EPUBs is still in it's infancy. So to creation of "good" EPUB content still requires technical knowledge possessed by, for example, web content creators but this isn't the traditional skill set possessed by the people in the book publishing industry. I am mildly optimistic that time will narrow the gap - improving the software and moving publishers towards the skills needed to use it well.

I totally disagree with the statement that CSS is for decorating text without meaning.

CSS selectors can be used for structure, semantics, presentation, styling, processing instructions and metadata. There is no such limitation defined in the CSS specification. In fact it explicitly states that selectors can AND SHOULD BE used for any purpose.

<i> and <b> are very explicit in what they define. It is incredibly easy for accessibility software to interpret these as <em> and <strong>. The <u> tag was "stupidly" removed in XML 1.1 (which is now largely irrelevant - like XHTML-2). Content owners need to be able to use text decoration for a semantic purpose and accessibility is automatic - the question is what will the reading devices do not the XHTML!?

With JQuery and other tools available in 2012 for readers it is easy to turn any element into accessible presentation in ways not conceivable three years ago. Tag the content naturally for presentation, and demand that reader interpret for accessibility. It is that simple. Any DOM element or property can be turned into ANYTHING at runtime. Concepts that were inconceivable when XML was invented, SMIL was invented, etc. just don't apply any more. Nothing is rigid. Everything is fluid.

In 2012 tagging is no longer an issue for accessibility - but tagging consistency is important. We need really good alt attribute support for images and table. We need really good sequence presentation support. But I can insert reading emphasis just as easily on <i>, <em>,<u> and <s> . These tagging rules just don't mean anything anymore. JQuery has changed all the rules. Thankfully.

Well, I never said that CSS cannot convey meaning; it obviously carries meaning for visual readers. I said in the context of emphasis and bolding that CSS should be used for presentational purposes since there are already semantic tags available. If you disgaree, please answer these two points:

1) what meaning does pure styling alone convey: is it the voice emphasis of strong and em or the mood change of b and i?

2) when is styling purely presentational and how is this conveyed if CSS means everything and nothing at the same time?

CSS only conveys the things you suggest when the document is presented in its rendered form to sighted readers. For anyone traversing at the DOM level via an AT (or accessible device) semantics are important since there is no visual context. I'm surprised you think accessibility doesn't matter and it's the fault of the reader if they can't follow bad tagging.

I'm not able to follow the rest of your post. There's no great magic in jquery; it just tries to take some of the thinking out of accessibility by doing common augmentations for the author. It can make some widgets more accessible, but that's a far cry from making a badly tagged document accessible.

And what happens when JavaScript isn't enabled?

Progressive enhancement to enrich the experience is perfectly fine, but most people start with a solid base and enahnce on top. I've not heard of anyone who tries to script accessibility on the fly using the DOM.

Secondary menu