Moon+ is a
horrible reader, and if it overrides your book at every step + doesn't follow the EPUB standards, then that problem's on
them. (Not to mention, it completely ignores/mangles SVG, ignores negative indents for poetry, etc.)
If you want an Android reader that follows the EPUB standards (
plus free TTS), use PocketBook Reader or Gitden.
A lot of this was written about in last year's topic:
"Epub-problems in tablets".
No. You can still design fantastic (and Accessible) ebooks that work across devices.
See this
ebookcraft 2019 talk, "Building Ebooks that Last".
She worked as an editor at Houghton Mifflin for many years, and explains why it's best to use proper markup + follow the standards.
Around 19 minutes in, she even shows a recipe book split from its CSS, and shows the differences between a mess (using <p class="heading1">), and a properly marked HTML document (using <h1>).
Your job, as ebook-maker, is to follow the standards and do your best.
Yes, you may even need to code some fallbacks for common use-cases/edge-cases, for example:
but you can only go so far.
If the ebook works properly on Kobo/B&N/Apple/Amazon (all the mainstream stores/readers), you'll be fine.
If the reader
still insists on using a program that disregards/overrides everything (like Moon+)... then that's not on you.
Like I said, using the <a> in this way is a hack + completely non-standard (and would break Accessibility).
HTML tags ARE NOT meant "for looks", they're meant to mark PURPOSE (semantics):
- <h1> = a heading, not "bigger font + bold"
- <em> = emphasis, not "make this look italics"
- <a> = a link within/between documents, not "blue + underline"
- <blockquote> = a long quotation, not "let me get some margins on both sides".
- [...]
Most browsers display that way by default, but lots of non-visible information gets carried over as well. For example:
- <h1-6> Headings allow proper navigation.
- A Screen Reader can jump to next chapter/section.
- Don't hackishly do <p class="heading1">.
- <em> can be spoken differently via Text-to-Speech
- A Screen Reader can separately list all <a> in a document, then use that to more easily navigate.
- Don't clog it with things that aren't links.
Proper <table> + <th> + <td> markup allows:
Code:
Name | Eggs | Bread
____________________
Joe | 2 | 2
Smith| 1 | 0
to be read out loud by a Screen Reader as:
"Name: Joe, Eggs: 2, Bread: 2"
"Name: Smith, Eggs: 1, Bread: 0"
not:
"Name Eggs Bread. Joe, 2, 2. Smith, 1, 0."
Wrong/Poor markup has been written about many, many times over the years. Here's a few of the latest:
And if you want to see what detrimental effects junk markup can do, see this talk given by a blind person:
ebookcraft 2019, "The User's Perspective: Accessibility Features in Action".