Quote:
Originally Posted by theducks
Tex
If you use a Image break, it should have an alt="meanwhile, later, scene break...." <select for the least jaring
The reader is supposed to say the Alt phrase
|
Quote:
Originally Posted by jackie_w
"Supposed" being the operative word  I haven't yet seen a reading app with TTS which uses the <img> alt text - and I have tried a lot of them. |
Exactly. Key word is "supposed" (I haven't run across one yet that reads alt either).
But remember, these ebooks won't necessarily could be read in ereaders only... they could be read using full-blown Screen Readers (and those DO support reading alt text, even if most ereader apps don't).
Side Note: We discussed this more in-depth in the
Accessibility question: TTS and ligatures topic. This also discussed dropcap images with alt text.
* * *
But
IF you're using images, definitely use meaningful alt text:
WebAIM article on Alternative Text
Quote:
|
Even if/when app developers do get around to implementing this feature my guess is that users will immediately ask for a "disable" option because, if the ebook creators have set non-blank alt text, it's text to help themselves, not the user, e.g. a page number or the image's filename. I have a vague memory that some Brandon Sanderson books did try to use alt wisely.
|
No. Alt text SHOULD be meaningful (see WebAIM article above).
But yes, many programs output even worse than useless garbage like filenames. InDesign is notorious for this crap (but they're getting better. I think latest versions now let you more easily see alt tags.).
It would be better to have a blank alt="" than to have absolute gibberish in there.
Note: A similar issue with <title>. See
my discussion on the topic (and more Accessibility links) here.
Note #2: For help in catching/generating/fixing some of this stuff... see Accessibility plugins like
Access-Aide Plugin for Sigil.
Note #3: Also see this speech at ebookcraft 2017:
In the Trenches with Accessible EPUB (
Slides here.) This was a technical talk behind one of the checking tools, and discusses many of the things automated tools can't handle, but should still be kept in mind when designing/checking ebooks.
Quote:
Originally Posted by jackie_w
As an aside, if everything worked as it should, I wonder what a good "TTS scenebreak phrase" might be. Anything longer than a couple of words might get very irritating if it occurs often. Personally I think some kind of sound might be better, but we're a long way from that in your average reading app  |
"New Scene"
"Scene Break"
"Subchapter"
I personally don't mind the TTS saying:
"asterisk asterisk asterisk" OR "... (Pause)" I currently get in Gitden Reader.
What would a real person do while reading? Take a long breath, take a longer pause, and continue reading the next scene.
Note: In the future, reading apps may also take more advantage of HTML5's <section>. Each scene/subchapter could be treated slightly differently.
* * *
And back to "Why Not Use Images for ChapterTitles/Scenebreaks"...
I already
answered in the Reddit posts too (because one of the users was using images for his chapter titles), but I'll reproduce some of my reasoning here. :P
Here's the code example the user gave:
Quote:
In the book I formatted with images for the headings, I used this code:
Code:
<h1 title="1"><img alt="1" src="../Images/01.gif" /></h1>
Then it shows up nicely on an auto-generated table of contents, and the alt gives a fallback for text-to-speech.
|
Why Not Use Images?
The disadvantages are numerous:
Images typically:
- Don't scale
- Scale awfully (too low resolution)
- Don't match user font color (Night Mode)
You also have to recall that users can:
- Set font sizes HUGE (so text will be huge, and then you have a microscopic little fleuron)
- Read on very tiny devices (think cell phone)
- Flip landscape/portrait (many people forget to test code in landscape and it breaks)
Ebooks that have horribly low resolution images around their headings or scenebreaks. They may have "looked nice" when the book first came out, but as devices became higher resolution, or you mess with settings, they look awful.
Images With Text Have Accessibility Issues
For example, readers may be using:
- OpenDyslexia font for reading disability
- Older folks may need HUGEEEE fonts
- Certain colors for Background+Text due to contrast issues
Even "normal readers" may be using:
- Press/Hold to access Dictionary
- Auto-Translate (think Google Translate English->French)
- Highlighting/Copying/Pasting Text
- Searching
These also don't work on "text in images".
Text in Images Doesn't Follow CSS
Style the chapter title with CSS if you want (large, bold, embed fancier font for headings, fancier CSS3 boxes/shadows, etc.), but the worst choice you can make is embed the entire chapter name/number into an image.
Similar to embedding captions within an image... you're going to be shooting yourself in the foot when later on you decide to now make captions italic+right-aligned instead of bold+centered.