Best way to do three-line space/pause, for accessibility?

[JSWolf]

Originally Posted by bookman156

Good news. I used the following code on my web-page equivalent of my EPUB code, and took the margin off the p tag, and it looks great, much better than I expected. Glad to know the page is now accessible for the blind. Will adapt for the EPUB in due course:

hr.transition {
    margin: 1.5em 40% 1.6em 40%;
    border-top: 1px solid darksalmon;
  }

The line needs to be dark and 2px. If someone is reading this book on a 300DPI eInk screen, your lighter 1px line will not stand out enough. It can be too thin and too light. I did the default 1px and it did not work all that well.

[JSWolf]

Originally Posted by bookman156

Sure, attached.

That looks good on an LCD screen. Not so good on an eInk screen. The line should be more visible (black and maybe thicker).

[bookman156]

That looks good on an LCD screen. Not so good on an eInk screen. The line should be more visible (black and maybe thicker).

Yes, I'm sure you're right. I'll adapt when I've had a chance to test in ereaders. I do it all as a webpage first to sort out all the code.

[bookman156]

I make what I call 'web-books' in addition to EPUB and PDF and print, which provides a good workflow for EPUB preparation. By making a web-book available as well there's more choice for people who read books on smartphones and tablets (and PC screens maybe too), since they don't have to use an EPUB reader they can use a browser and take advantage of its superior rendering capabilities. And blind people probably have a better experience using the web-book rather than the EPUB.

Matthew Butterick sort of pioneered a conception of web-books, such that he doesn't even provide PDFs or EPUBs:

https://practicaltypography.com/why-...ok-or-pdf.html

I think he makes some good points there, though I myself prefer a range of options.

[Tex2002ans]

Originally Posted by phillipgessert

Those are ok as section breaks and the hr is fine.

Yes. Seeing a picture of the example, I agree.

<hr> in that case is fine. (So is asterisks...)

Originally Posted by phillipgessert

Adding an inappropriate semantic element is not an accessibility improvement, [...].

Yes, sometimes you have to be careful, because you can cause more harm than good + make things things WORSE than "doing nothing".

I highly recommend reading all the blog posts from:

• MarcoZehe.de: "The web accessibility basics"

He is a blind web developer, and he describes a ton of the mistakes he runs across on the web.

A lot of it is people using the proper HTML, but then overriding or doubling up "in the name of good"—and getting it wrong.

Imagine it like a spectrum from 0 to 100.

You can get 80–90% there by just doing basics:

• Headings <h1> (not <p class="heading">)
• Paragraphs <p> (not <div class="paragraph">)
• Tables <table> + <th> + <td> (not <img> or <p class="table">+CSS)
• [...]

but you can go backwards if you:

• Mark the wrong HTML lang + xml:lang
  
  • Or wrongly butcher language at the paragraph- or word-level.
• Use bogus alt tags like auto-generated filenames (instead of blank/meaningful descriptions).
• Use bad <title>s
• [...]

Originally Posted by bookman156

I'll bear that in mind about list items. I've never used them for anything other than standard short lists and navigation, but for textual display that's an interesting one worth looking at.

Be very careful. I'd only use <ul> for shorter+simple lists with actual bullet points.

In ebooks, things start going awry once you begin getting:

• Multi-page lists
• Multiple paragraphs per item
• Nested lists
• Alternate symbols
• [...]

And, while not correct, that's one of the few cases where you'd save a lot of headaches by "emulating it" with:

• • (U+2022) BULLET
• + CSS

You can see a lot of that real-life discussion in 2021: "Google Play Books and Nested Lists - Some Weird Display Issues".

- - - - -

Side Note: And, again, you have to remember the reality of buggy <ol> in ebooks.

For more detail on that, I just wrote a post last month:

• 2022: "Footnote numbers have gone AWOL"

Things might work if you always start from 1, but they get a lot buggier once you begin tweaking the variables and need to handle more and more edge-cases.

For example, one book I worked on had 3 distinct sets of numbered footnotes—Author, Editor, Translator—and some footnotes were 7 pages long. (And another book had over 5000 notes.)

For more info on that, see the famous thread:

• 2018: "Endnotes within Endnotes" (Post #5+)

- - - - - -

Originally Posted by phillipgessert

I could also see calling each one a blockquote.

Yes, that could be a possibility too.

For example, the latest book I worked on had a huge compilation of quotes (1–3 paragraphs).

I had to change the ebook's layout:

<blockquote class="largequote">
	<p>This is the quoted text.</p>
	<p>More quoted text.</p>
	<p class="attribution">—Author Name, <i>Book Title</i> (Year), p. 123.</p>
</blockquote>

This, in the future, allows you to easily treat each as a distinct chunk.

(For example, adding a colored background... or borders above/below!)

Originally Posted by bookman156

The print book of course simply uses a 3-line space, and I hadn't thought of doing it differently for the EPUB until it dawned on me that a 3-line space on an ereader would be indistinguishable from any old space that ereaders may shove in (so I have made widows and orphans 1 also).

One of the major problems with "the gap" is there are a ton more page breaks in ereaders than physical books. You have no idea what's an actual page/scene break + what's one put on your device.

If you read through those linked "scenebreak threads", you'll probably stumble across my example of Moon+ Reader + The Expanse:

When I read one of the ebooks on my cellphone, I was very confused, because sections of text seemed to "randomly" begin jumping characters/locations. Turns out, they used "the gap", where in all the previous books, they used a symbol. When Moon+ overrode the book's CSS, that distinction was completely lost.

(And, just so happened to be, that book was a long novella, no chapters, and had A TON of much shorter scenes.)

So I kept on scratching my head... until I eventually opened it up on Sigil and saw the original formatting. You know what would've solved it? Damn symbols for scenebreaks! :P

- - -

Side Note #2: Another use-case of overriding original CSS is Reader Mode in browsers like Firefox.

If I'm reading on my phone, I'm always using Reader Mode, because these "mobile-friendly sites" use ENORMOUS MARGINS + HUGE FONTS... and you can barely fit 4 words on a line.

Originally Posted by bookman156

I make what I call 'web-books' in addition to EPUB and PDF and print, which provides a good workflow for EPUB preparation. By making a web-book available as well there's more choice for people who read books on smartphones and tablets [...]

Release in as many formats and in as many places as possible.

Each format—Print/PDF, Ebook, HTML—satisfies different purposes which all complement each other.

Definitely check out my posts in:

• 2020: "What are options for this circumstance?"

- - -

Side Note: If you haven't figured it out yet, you can find a ton of information by typing this into your favorite search engine:

any ebook search term Tex2002ans site:mobileread.com
any ebook search term Hitch site:mobileread.com

and come across a ton of great info/discussions over the past many years.

For example, I've written tons about:

Accessibility Tex2002ans site:mobileread.com

to find over 300 topics. I'm one of the biggest proponents of marking up books properly. :P

(Hitch runs one of the largest conversion companies—Booknook.biz—and has handled thousands of books/authors. And I've converted 650+ ebooks for a handful of publishers—mostly Non-Fiction.)

[bookman156]

Be very careful. I'd only use <ul> for shorter+simple lists with actual bullet points.

That would be my instinct, though they're good for web navigation. I have actually made some use though of definition lists beyond simply glossary stuff (on the web, not epubs). I've never quite understood why people hardly use definition lists.

Cheers for the marcozehe.de link, that looks really useful.