View Single Post
Old 04-09-2023, 11:29 AM   #39
Tex2002ans
Wizard
Tex2002ans ought to be getting tired of karma fortunes by now.Tex2002ans ought to be getting tired of karma fortunes by now.Tex2002ans ought to be getting tired of karma fortunes by now.Tex2002ans ought to be getting tired of karma fortunes by now.Tex2002ans ought to be getting tired of karma fortunes by now.Tex2002ans ought to be getting tired of karma fortunes by now.Tex2002ans ought to be getting tired of karma fortunes by now.Tex2002ans ought to be getting tired of karma fortunes by now.Tex2002ans ought to be getting tired of karma fortunes by now.Tex2002ans ought to be getting tired of karma fortunes by now.Tex2002ans ought to be getting tired of karma fortunes by now.
 
Posts: 2,297
Karma: 12126329
Join Date: Jul 2012
Device: Kobo Forma, Nook
Quote:
Originally Posted by Hitch View Post
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:

* * *

... 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:

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:

And applied a lot of this to examples like Tables:

or:

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:

- - - - - - - - - - -

Also see:

And that's the end of my EPUB Accessibility masterclass.
Tex2002ans is offline   Reply With Quote