Semantic markup question!

[Hitch]

Originally Posted by JSWolf

When has <em> ever been different to <i> outside of looking at the code?

Jon:

For those who are reading eBooks designed to be accessible and having them read aloud to them. You persist in viewing this, no pun intended, from the view (more non-punnery intended) of a sighted person. Stop doing that and consider what it would be like to have books read to you.

THAT is the simple difference. If you would simply stop and think about what it would be like to have a visual impairment and be required to listen to reading rather than LOOKING at it, the difference and the importance would be obvious.

Hitch

[Quoth]

Originally Posted by KevinH

It is way past time for ebook developers to start creating truly accessible ebooks (dropping epub2 and its old html whenever possible) and start caring about semantics (IMHO).

It can be done perfectly with epub2.
Also ebook developers are limited by source material and access to authors.

[KevinH]

How can epub2 use figcaption, figure, picture, search, etc that are new html semantic elements not supported by epub2? Semantics are one of the main reasons for these newer tags. Please see the link for the new search tag I posted.

Unlike epub3 which evolves with html and accessibility changes, epub2 is stagnant with unchanging features.

[Tex2002ans]

Originally Posted by Jellby

This should be the key to answer the original question. Is "No! No! No!" a single emphasized entity or three individual items that just happen to be side by side? If you were using a yellow background, would you like to see the spaces yellow or not?

I've found this colorization trick to work really well. I've been using it since ~2020, and it's fantastic for visualizing what you marked up properly + what you didn't mark up yet.

See my examples in:

• 2020: "Is there a way to edit EPUB or Mobi files such that the Quotes are in BOLD?"

of:

• Original PDF
• Colorized <blockquote>s (Blue) + page-breaks (Red) + no-indent (Peach)
  
  • I added Red/Peach to classes auto-spit out from OCR. Blue showed I marked it up properly!

As I corrected the document, less and less Red would show up and be replaced with Blue/White.

Then when my eyes were side-by-side comparing EPUB vs. PDF, all I'd have to see is a few blobs of color and know I had to take a closer look (or that I marked it correct).

Originally Posted by Jellby

While you're at it, why use <span> or <sup>? You can get exactly the the same with <i> (and proper CSS). So just use <i> everywhere. Actually, you don't even need the the text, you can get it through <i> as well, as in this proof of concept:

Now just mix some Javascript + CSS3 Calculations in there and we'll really be cooking!

Originally Posted by DNSB

One of the best one paragraph items I ran into on semantic vs. visual markup:

Originally Posted by KevinH

In fact, entirely new html tags are being added just to make semantic meaning clearer for accessibility reading systems:

Awesome. Wasn't aware of <search>. I'll have to skim through and refresh my knowledge on a lot of that bleeding-edge stuff.

Originally Posted by Quoth

I know what "printed" (really embossed) Braille is like, but not what a terminal is able to do.

See the post I wrote in:

• 2022: "Braille Files"

for some awesome videos/articles about blind users using phones.

[JSWolf]

Originally Posted by Hitch

Jon:

For those who are reading eBooks designed to be accessible and having them read aloud to them. You persist in viewing this, no pun intended, from the view (more non-punnery intended) of a sighted person. Stop doing that and consider what it would be like to have books read to you.

THAT is the simple difference. If you would simply stop and think about what it would be like to have a visual impairment and be required to listen to reading rather than LOOKING at it, the difference and the importance would be obvious.

Hitch

Which TTS software reads <em> different then <i>? Screen readers would not know the difference.

[Tex2002ans]

Originally Posted by JSWolf

Which TTS software reads <em> different then <i>? Screen readers would not know the difference.

Read the previous <i> and <em> topics. Nobody is going to waste their time rehashing the same information for you again and again.

JAWS and NVDA are two major Screen Readers that distinguish between all the HTML markup.

See the Braille topic I linked above for videos showing off the latest readers/apps/info + how blind readers actually read ebooks.

For all the latest bleeding-edge Text-to-Speech (TTS) research, check out the yearly Interspeech conferences, and some info I summarized in:

• 2021: "Telling a text-to-speech reader how to pronounce things?"

(And since my posts in 2021—wow, has TTS advanced like crazy!)

[Turtle91]

Originally Posted by KevinH

In fact, entirely new html tags are being added just to make semantic meaning clearer for accessibility reading systems:

See: the latest html whatwg spec:

https://github.com/whatwg/html/pull/7320

It is way past time for ebook developers to start creating truly accessible ebooks (dropping epub2 and its old html whenever possible) and start caring about semantics (IMHO).

My new years resolution is now to switch to ePub3...so I need to learn the differences and get much better at proper semantics/accessibility coding!

[Hitch]

Originally Posted by JSWolf

Which TTS software reads <em> different then <i>? Screen readers would not know the difference.

So, Jon, you are assuming that even if all readers read it the same, NOW, (and I'm not sure that they do) that they will always do so?

Given the pressure that ebook makers are coming under, to make every. single eBook. accessible, I wouldn't make that bet and I'll be damned if I'll have to go back and remake 2000 eBooks to change i to em.

Hitch

[Tex2002ans]

Originally Posted by Hitch

Given the pressure that ebook makers are coming under, to make every. single eBook. accessible, I wouldn't make that bet and I'll be damned if I'll have to go back and remake 2000 eBooks to change i to em.

Yeah, I recently wrote a few detailed PMs to a user asking me about the European Accessibility laws.

(I ripped the mandates a new one—when they smash against cold, hard, reality of ebook conversion + backlog!)

But, as the new books + the backlist naturally gets updated...

* * *

See the fantastic:

• "When Nothing Ever Goes Out of Print: Maintaining Backlist Ebooks"
• ebookcraft 2019: "Building Ebooks that Last"

* * *

... there can be incremental improvements in the right direction.

ESPECIALLY with the new "Find & Replace" added in Sigil 1.9.10+.

That "List-based Search/Replace" should speed up the transition much, much faster than the one-by-one replacements before.

Just like Spellcheck Lists transformed the speed of spellchecking entire books, I think this "Find & Replace Lists" will transform mass code updates as well.

But yeah, an <i> vs. <em> would be very low on my priority list. There's much more important Accessibility things you can focus on (like proper <table> markup + alt tags!).

But if you can fix 90% of <i> vs. <em> within a few minutes using a list... now, it doesn't sound so bad! :P

On the Reality of Backlog Updating + Ebook Accessibility

See my:

• 2022: "Best way to do three-line space/pause, for accessibility?"

Below is also a piece of my PM where I described:

• some applications of "Progressive Enhancement"
• + having to be leery of using some of the latest bleeding-edge bells-and-whistles.

- - - - - - - - - -

From a skimming of the topic, it looks like this "developer" went WAY overboard with a lot of this EPUB3 + "Accessibility" stuff, but they went too far, wrongly applying a lot of this code.

[...]

Better to have:

• good, clean, basic HTML + correct code.

vs.

• bad, overly-prescribed, wrong + "Accessible" HTML5/EPUB3 code.

For example, I recently wrote about that in:

• 2022: "Best way to do three-line space/pause, for accessibility?"

And applied a lot of this to examples like Tables:

• 2022: "<caption> In Tables"

or:

• 2021: "Formatting tables best practices"
• 2021: "Tables in ePub"

In reality, a lot of this HTML5/EPUB3-specific stuff like <figure> + <figcaption> SOUNDS good, but it might break on older readers.

Personally, I mostly just stick with good ol' EPUB2 compliant code.

Yes, you can have SOME "Progressive Enhancement" in your CSS, but you always have to keep in mind the fallbacks.

See more of the discussion in:

• 2022: "Embedding audio/video in epub files"

- - - - - - - - - - -

Also see:

• 2017: "Citing Websites"
• 2020: "Colored Text, EPUB, Android Dark Mode"
• 2020: "EPUB-Checker error: undefined property"

And that's the end of my EPUB Accessibility masterclass.

[JSWolf]

Originally Posted by Hitch

So, Jon, you are assuming that even if all readers read it the same, NOW, (and I'm not sure that they do) that they will always do so?

Given the pressure that ebook makers are coming under, to make every. single eBook. accessible, I wouldn't make that bet and I'll be damned if I'll have to go back and remake 2000 eBooks to change i to em.

Hitch

Given the accessible laws in the EU, either there are going to be changes reading <i> and <eM> and I don't think there ever will be.

[DNSB]

Originally Posted by JSWolf

Given the accessible laws in the EU, either there are going to be changes reading <i> and <eM> and I don't think there ever will be.

The problem is that you seem to be incapable of reading the posts where the posters have mentioned existing programs that will read <i> and <em> or <strong> and <b> differently. Yes, it does take a bit of setup for JAWS and NVDA to enable that feature but once enabled, it does work well.

[JSWolf]

Originally Posted by Tex2002ans

JAWS and NVDA are two major Screen Readers that distinguish between all the HTML markup.

How would you make these programs read <em> and <strong> differently then <i> and <b>?

If I had two lines that went...
<p>This is a really <i>bright</i> sunny day.</b>
<p>This is a really <em>bright</em> sunny day.</b>

How would they read each line? Would they be read differently?

[DNSB]

Originally Posted by JSWolf

How would you make these programs read <em> and <strong> differently then <i> and <b>?

If I had two lines that went...
<p>This is a really <i>bright</i> sunny day.</b>
<p>This is a really <em>bright</em> sunny day.</b>

How would they read each line? Would they be read differently?

Very simple, Jon. If the TTS program saw <em>, it would speak the words until the closing </em> with emphasis however it might be defined in that program much as a human reader would do when reading text though the human is going to base the decision on other criteria. So in your first example, there would likely be no change on the visual italic <i></i> while in the second example, the semantic <em></em> would have a noticeable change and bright would be spoken with emphasis.

Once again, we are not talking about visual appearance (i.e. you reading the text with your mark 1 eyeballs) but rather accessibility where the text may be spoken, displayed in Braille, etc. The audio results will not be up to the results from the use of a full-fledged SSML but it is better than nothing.

[Quoth]

And really it's not that critical to have every <em>. Much italic or bolds on print is a distraction (sometimes absolutely needed for textbooks and other non-fiction)· Excessive use of <em> is tiring to listen too and negates the impact, so if in doubt use normal or if copying an old paper edition, a minimal version (replace drop caps, small caps and maybe excessive italics added by publisher).

The most important thing is text for all images. Next most is how numbers and such are written as well as the layout of tables. Also for partially sighted and people with difficulty reading don't do egotistical drop caps, illuminated caps, small caps, coloured or grey text (loads of stupid websites out there). Make sure text readable with fall back fonts. Margins, line spacing (height) and font size user changes should work.

Using <em> or <strong> is appropriate in small doses if the author wants it.

Most so-called semantics are about people on the HTML standards exercising power, not about real accessibility. They've done stupid stuff in the past. Also not everything in epub3 or HTML is appropriate for ebook versions of printed books.

Test on small and large screens on eink and phone and tablet. Test without publisher fonts. Test at larger size for partially sighted. Test with basic and decent TTS systems. Test in regular and so-called darkmode.

Communicate with the author and don't guess at intentions of dead people.

Don't use new features because you can. Keep it simple if it's the ebook equivalent of paper. Consider an App if it's not an ebook equivalent of paper print.

[Turtle91]

Originally Posted by Quoth

And really it's not that critical to have every <em>. Much italic or bolds on print is a distraction (sometimes absolutely needed for textbooks and other non-fiction)· Excessive use of <em> is tiring to listen too and negates the impact, so if in doubt use normal or if copying an old paper edition, a minimal version (replace drop caps, small caps and maybe excessive italics added by publisher).

The most important thing is text for all images. Next most is how numbers and such are written as well as the layout of tables. Also for partially sighted and people with difficulty reading don't do egotistical drop caps, illuminated caps, small caps, coloured or grey text (loads of stupid websites out there). Make sure text readable with fall back fonts. Margins, line spacing (height) and font size user changes should work.

Using <em> or <strong> is appropriate in small doses if the author wants it.

Most so-called semantics are about people on the HTML standards exercising power, not about real accessibility. They've done stupid stuff in the past. Also not everything in epub3 or HTML is appropriate for ebook versions of printed books.

Test on small and large screens on eink and phone and tablet. Test without publisher fonts. Test at larger size for partially sighted. Test with basic and decent TTS systems. Test in regular and so-called darkmode.

Communicate with the author and don't guess at intentions of dead people.

Don't use new features because you can. Keep it simple if it's the ebook equivalent of paper. Consider an App if it's not an ebook equivalent of paper print.

Many good points here, but I’d caution against simplifying too much in the name of accessibility. Using good semantic markup should not interfere with how the book looks. You can have a fully accessible book that doesn’t change the visual look at all. It’s just takes more work.

Remember, the majority of people reading your book are actually reading it. Part of their experience includes the visual presentation. *Make your book visually appealing* within the bounds of reason (and technology).

There is nothing wrong with small-caps, when done properly. Likewise, for drop-caps. There is nothing wrong with purely visual decorative images. I’d have to check the standards again, but I’m pretty sure you don’t need anything in the alt="" tag for a purely visual decorative image.

Learn how to use media queries! You may will need to code things differently for different devices… especially for inadequate/older devices that don’t support the standards.