Accessibility question: TTS and ligatures

[doubleshuffle]

Thanks, Tex, for all the useful links. I'll spend some time with them, I guess.

Meanwhile, here's a quickly assembled test epub for testing the features I am intersted in for the book I'm preparing right now:
- images as initials,
- ae- and oe-ligatures,
- words and phrases in French, Italian and German within an English text.

tts-test-epub3-corr.epub

Everybody feel free to run this through any TTS app you might have.

[JSWolf]

Originally Posted by doubleshuffle

I've decided to try and make my next upload to the MR library conform to accessibility standards. The text contains some ae- and oe-ligatures (which I am very fond of and would like to keep). Does anyone know if TTS programs are able to deal with them properly, or will I have to sacrifice them in the name of accessibility?

Versions of ADE/RMSDK 2.0.1 and later all support ligatures. So if you have fl in the text, you will be shown the fl ligature if the font supports it. So you don't need ligatures specifically in the text. Just let ADE/RMSDK do the ligatures.

[doubleshuffle]

Originally Posted by JSWolf

Versions of ADE/RMSDK 2.0.1 and later all support ligatures. So if you have fl in the text, you will be shown the fl ligature if the font supports it. So you don't need ligatures specifically in the text. Just let ADE/RMSDK do the ligatures.

My question was specifically about ae- and oe-ligatures...

[Turtle91]

Originally Posted by JSWolf

Versions of ADE/RMSDK 2.0.1 and later all support ligatures. So if you have fl in the text, you will be shown the fl ligature if the font supports it. So you don't need ligatures specifically in the text. Just let ADE/RMSDK do the ligatures.

Forgive me my ignorance here - I'm unfamiliar with languages that use ligatures and it's been a few years since I learned about the ß in High School!

Is it proper for a ligature to be used in ALL cases where two possible letters are together? For example, if I am using a font that has an fl ligature defined I would NOT want it to automagically create/use a ligature for a proper name like Florida, would I??

It seems like ligatures should be used when a specific language is tagged, rather than just when a font has a ligature available.

edit: by tagging the language, I would HOPE that would inform the TTS software how to render/pronounce the word or phrase.

[jackie_w]

Originally Posted by doubleshuffle

Thanks, Tex, for all the useful links. I'll spend some time with them, I guess.

Meanwhile, here's a quickly assembled test epub for testing the features I am intersted in for the book I'm preparing right now:
- images as initials,
- ae- and oe-ligatures,
- words and phrases in French, Italian and German within an English text.

Before going ahead creating mp3 files for more voices, I thought it might be worth giving you a sneak peek at the first one, in case you want to make any epub additions/changes based on results.

The attached is an mp3 file renamed as a .doc because mp3 isn't a supported upload format on MR. The TTS app used was TextAloud 3 running on Windows 10. The voice used was Ivona British English female Amy.

Let me know how you want to proceed.

P.S. Probably not relevant to this current sound testing but, Epubcheck reports a couple of errors in your test epub3

[jackie_w]

Originally Posted by Turtle91

...I would NOT want it to automagically create/use a ligature for a proper name like Florida, would I??

To the best of my knowledge it's case sensitive. There would need to be an Fl ligature glyph in the font for it to be used for Florida, The fl ligature would only be used if your text was florida.

[doubleshuffle]

I had put the <title> tags in the wrong place in the svg's, hence the errors.

I've uploaded a corrected file to my original post: https://www.mobileread.com/forums/sh...2&postcount=16

However, the app seems to ignore the "alt" descriptions in the images anyway, but reads the hidden letter, so this is a fine way to deal with decorative initials.

I'm a bit dismayed how the language tags are completely ignored, so listening to at least parts of the book I'm preparing will be a real pain, unless other apps do use the language tags.

Anyway, thanks a lot for the help. I don't think other voices are necessary at the moment; I guess the results will be the same, since you would use all of them with the same app, wouldn't you?

[jackie_w]

Originally Posted by doubleshuffle

Anyway, thanks a lot for the help. I don't think other voices are necessary at the moment; I guess the results will be the same, since you would use all of them with the same app, wouldn't you?

I think the results would be similar with other voices in the same app as regards not using <img> or language attributes. I think different voices might sound better/worse with your ligature test.

Over the years I've found voices can differ in their ability to speak (or rather, not speak) certain punctuation combinations. Being British many of my books use single-quotes, rather than US-style double-quotes, wrapped around speech. I think the double-quotes style is less likely to produce pronunciation errors (possibly because more testing is done by, and for, US companies???).

My Windows app can edit the open epub and you can assign its own version of voice-change tags where appropriate before speaking out loud or saving to mp3. If I owned a French/German or Italian voice (which I don't) I could demo it. However, this is hardly a solution for the casual book listener. The effort involved to insert those tags in a full book would be large.

I will try your corrected epub in some of my Android apps to see if there are better results there. I'm not hopeful on the language front, not least because I don't have any non-English voices there, either. I do have different flavours of English voices - British, US, Australian - that could be tested if your language tags can differentiate that way.

[doubleshuffle]

Originally Posted by jackie_w

My Windows app can edit the open epub and you can assign its own version of voice-change tags where appropriate before speaking out loud or saving to mp3. If I owned a French/German or Italian voice (which I don't) I could demo it. However, this is hardly a solution for the casual book listener. The effort involved to insert those tags in a full book would be large.

Yes, I know about the effort, because I've inserted about 3000 language tags in the book I'm working on. Had I known that they probably won't work... Well, I'll consider it an investment in future progress. What I hadn't thought of at all is the fact that a different language means a different voice, so even if the tags worked, you would always have a switch between voices. That can't be too pleasant an experience either...

Originally Posted by jackie_w

I will try your corrected epub in some of my Android apps to see if there are better results there. I'm not hopeful on the language front, not least because I don't have any non-English voices there, either. I do have different flavours of English voices - British, US, Australian - that could be tested if your language tags can differentiate that way.

I'm uploading a new test file, with the document language set to en-GB, and two short passages in the very first chapter tagged en-US and en-AU, respectively; perhaps that might work...

tts-test-epub3-v2.epub

[DaleDe]

Note also the forum thread https://www.mobileread.com/forums/sh...d.php?t=148097 that has test files. and the wiki page EPub Reader Test. Perhaps accessibility could be added.

[Tex2002ans]

Originally Posted by doubleshuffle

Meanwhile, here's a quickly assembled test epub for testing the features I am intersted in for the book I'm preparing right now.

Gitden Reader v4.5.3, Android (using Google TTS):

• It crashed when trying TTS on the SVG pages
• It did speak the æ + œ ligatures (and pronounced them correctly)
• It did not speak the alt tags
• It did not speak the hidden letters
• It did not flip language in the middle of a sentence, but when the chunk STARTED with a foreign word, it flipped the entire chunk to that language's TTS.
  • Probably based on the way Gitden parses the sentence by punctuation marks (instead of tags) to feed it to TTS.

Originally Posted by doubleshuffle

Yes, I know about the effort, because I've inserted about 3000 language tags in the book I'm working on. Had I known that they probably won't work... Well, I'll consider it an investment in future progress.

It will work on more advanced screen readers:

NVDA's User Guide (Voice Options)

Automatic Language switching
This checkbox allows you to toggle whether NVDA should switch speech synthesizer languages automatically if the text being read specifies its language. This option is enabled by default. Currently only the eSpeak NG synthesizer supports automatic language switching.

Automatic Dialect switching
This checkbox allows you to toggle whether or not dialect changes should be made, rather than just actual language changes. For example, if reading in an English U.S. voice but a document specifies that some text is in English U.K., then the synthesizer will switch accents if this option is enabled. This option is disabled by default.

... and more advanced users can even tweak the screen reader to do certain things (like play a sound) when hitting certain HTML tags/attributes:

http://www.freedomscientific.com/Tra...ds_Schemes.htm

[doubleshuffle]

Originally Posted by Tex2002ans

Gitden Reader v4.5.3, Android (using Google TTS):

• It crashed when trying TTS on the SVG pages
• It did speak the æ + œ ligatures (and pronounced them correctly)
• It did not speak the alt tags
• It did not speak the hidden letters
• It did not flip language in the middle of a sentence, but when the chunk STARTED with a foreign word, it flipped the entire chunk to that language's TTS.
  • Probably based on the way Gitden parses the sentence by punctuation marks (instead of tags) to feed it to TTS.

Thanks for testing! No support for either svg, alt tags or hidden letters means ditching fancy initials for accessible books, I guess. So there will definitely be two versions...

I have just installed NVDA on my PC, but it will take me a while to understand it and get it running on epubs...

[jackie_w]

@doubleshuffle, I've finished the testing on both Android and Windows.

Android - 5 apps:

Bookari and Pocketbook - both ADE-based ebook readers.
Moon+ and FBReader - both ebook readers but not ADE-based
@VoiceAloud Reader - a general purpose read aloud app. Can read web articles and various ebook formats.

Android image/text results:

• Nothing speaks the <img> alt text.
• Pocketbook & @VoiceAloud
  - speak text contained in the hidden <span>
  - do not speak text in the SVG <title>
• Bookari
  - does not speak text in either hidden <span> or SVG <title>
• Bookari, Pocketbook & @VoiceAloud
  - correctly display the images/text they are supposed to display
  - correctly hide the text which is not supposed to be visible
• Moon+
  - speaks text in the SVG <title>, but not the hidden <span>
  - wrongly displays the SVG <title> as well
  - correctly doesn't display the hidden <span>
• FBReader
  - speaks text in both the SVG <title> and the hidden <span>
  - wrongly displays the SVG <title> as well
  - correctly doesn't display the hidden <span>

Windows 10 - TextAloud 3, can be used 2 different ways:

• Open epub directly and read inside the TextAloud app
  A single text-only file is extracted from the epub. The app will then read exactly what is on the screen. This means:
  - speaks text from the hidden <span>
  - does not speak text from the SVG <title>
  - no images or styling displayed
• Display the HTML in a browser and use a TextAloud browser extension (Chrome in my case)
  - speaks text from both the SVG <title> and the hidden <span>
  - all images and text display nicely and correctly.

Language/dialect tags:

Not used by anything in either Android or Windows. The only exception being what I previously mentioned about being able to add your own voice-change tags inside the TextAloud app. The voice transitions were very jarring with loudness variations. Maybe this is tune-able but not really relevant to this discussion.

Ligatures:

If you use the same voice in both Android and Windows the results seem to sound the same everywhere.

Conclusion:

• Images: if you're an individual user you can probably manipulate your epubs to work in selected apps. This year's solution may not be next year's solution. If you're creating epubs for the masses, well, good luck with that!
• Language tags: not this year decade.
• Ligatures: Nothing new to report. Probably varies by voice.

[doubleshuffle]

Originally Posted by jackie_w

Conclusion:

• Images: if you're an individual user you can probably manipulate your epubs to work in selected apps. This year's solution may not be next year's solution. If you're creating epubs for the masses, well, good luck with that!
• Language tags: not this year decade.
• Ligatures: Nothing new to report. Probably varies by voice.

Thanks a lot for all the testing. Much appreciated!

I can only agree with your conclusion. All it boils down to is that I will produce two different versions: one with fancy initials and ligatures, one without. Adding language tags makes sense anyway, as a bet on future developments, and in the hope that people who really depend on accessibility will have access to the more advanced apps that Tex mentioned.

[Tex2002ans]

Originally Posted by doubleshuffle

Adding language tags makes sense anyway, as a bet on future developments, and in the hope that people who really depend on accessibility will have access to the more advanced apps that Tex mentioned.

Along with TTS, proper language tags also help for proper Hyphenation + Dictionaries + Spellchecking + Search Engines + a bunch of tangential stuff under the surface you don't really think too much about.