Re: Accessible Writing

#1
Accessible writing isn't just about making sure what you write is easy to read. In this instance, it's making sure that what you read is easy to *hear*, too. 

This matters to me because I frequently use text-to-speech (TTS) to follow along with my favorite stories here on RoyalRoad. I've tried some screen readers and eventually decided the extra bother of copy-pasting to use Balabolka was worth not hearing the headers dozens of dozens of times. My experience may not represent everyone using screen readers, so please do feel free to question me or share your own experiences. I intend to update this post as I find more things to share.


Free TTS Apps
If you want to experiment on your own, for Windows users I recommend Balabolka. It's free (like free coffee), it's (currently) maintained, and it's what my school recommended when I found out I have some dyslexia issues.
On Android, I've found @Voice works well for me with the voices supplied by my phone maker and Google. I haven't tried theirs.
My apologies to Mac / iPhone users. I am not among your ranks, and I won't pretend to know what's good for you.


Visual formatting is meaningless to a screen reader.

This matters mostly with LitRPGs that use tables to show off Voice of the World or System dialogs, but also impacts writers that showcase a character's thoughts intermixed with speech.
  • Cue phrases like "he thought" or "System popped up a dialog" make your story more easily understood for the visually impaired.
  • The symbols you type are the symbols TTS apps / screen readers read. If you use a bunch of equal signs as a scene break, you can safely assume a TTS app will read each and every one of those equals signs.
    • Repeating symbols and phrases ad nausem can be an accurate description of the experience of *hearing* a computer repeating what vision can easily skip over.
    • On the other hand, repetition is a valid writing technique *when used in moderation.* My own tolerance generally lasts for triples.
  • A lot of screen readers get weird when they see angle brackets < >. They treat anything in those angle brackets as stuff that should not be read aloud. Some also cut off any text between the opening angle bracket and the sentence -- or paragraph! -- terminator. On the other hand, text in square braces [ ] and parentheses ( ) get a slight pause.
    • Note: I think this is because a lot of Text-To-Speech engines use XML-based inputs.


Punctuation makes a huge difference when a computer is reading the text you've written. 

It's not even the whole "Let's eat Grandpa!" versus "Let's eat, Grandpa!" major meaning difference. Punctuation defines where people pause when speaking. It's the main reason why I'm such a huge fan of the nefarious Oxford comma. I frequently come across lists that include compound items, such as: ice cream and cake, sugar in the form of granule or syrup, and loving friendship (That last comma, the one after "syrup", is the Oxford comma, for those who may be wondering) (Also, that would be a list of potentially sickeningly sweet things). 


Using ellipses with screen readers can be super useful -- when used according to specs!
  1. Ellipses do not stand alone. While there is a certain visual appeal to writing a character's judging response as "…" (open quote, ellipse, close quote), it does not translate to TTS. At all. Consider changing that to something more like, "Silence.", "No response.", or "Crickets chirped in the distance."  Note: even if you properly punctuate the ellipse in this instance, it still will not make sense when read by a screen reader.
  2. An ellipse should be treated like a distinct word. That means proper spacing before and after. If the ellipse is meant to show dialog trailing off into nothingness, a period / question mark / exclamation mark should follow it. As with other words ending a sentence, do not place extra white space between the ellipse and the terminating punctuation.
    • Like early web browsers, not all TTS apps / screen readers will treat ellipses the same.
Examples
- Good: "Kana … Kana, are you …?"   
- Bad: "Kana…Kana, are you …" 

Balabolka will read the bad example as "Kana dot kana, are you." With the good example, the questioning lilt at the end of the sentence will be maintained, but not with the bad example.


Terminating punctuation does not stand alone. 

In fact, punctuation in general does not stand alone, but I only recall having seen this short-hand used with ellipses, question marks, and exclamation marks. When writing a story, please, use your words.


Commas
  1. First, remember that this post is addressing how to make your stories more accessible to people using assistive tech (i.e. screen readers). TTS technologies treat commas as short pauses in the flow of your words. They help to set off subordinate clauses from the primary ones, and to distinguish when you link two sentences together (as I just did here).
  2. Overuse, of commas, can inhibit, or even distort, the meaning, which you, as the author, intend, to convey. That last sentence, by the by, is as grammatically screwed up as it is painful to listen to. A grammatically correct sentence, at least when considering comma placement, is much easier to listen to.
  3. Not using commas just makes your sentence sound like someone who never takes a breath and keeps on talking and talking to the point where you just wish they would SHUT UP! Some of this can easily be alleviated by editing. As a rule of thumb, shorter sentences are easier to follow.


I intend to update this post as I find more aspects of writing that impact the oratory output. If you have thoughts or questions, please share!

Re: Accessible Writing

#3
Is it possible to configure screen readers to recognize specific characters as text-specific cues and substitute a phrase? 

For example, suppose an author preceded every system dialog table with a symbol that wasn't used elsewhere in the story, such as an at-symbol. Could a screen reader be configured to replace all mentions of that symbol with a preset phrase, such as "system dialog?" Even if this weren't possible, having a parseable marker that was less obtrusive than "System popped up a dialog" would give a brief cue to the listener.

Re: Accessible Writing

#4
This thread should be moved to Guides By the Community, because it is very useful. There are some style guide elements here I had never considered before, partly because I have never before used a TTS reader to listen to a web story.

In my personal prose style guide I've adopted for years and years, I have one punctuation note that I believe in nonstandard in most styles: When I use ellipses, I... well, I put a space after the ellipses, even for at the end of a sentence... ...But no space at the beginning of a sentence, for some reason. Is this something that messes up TTS readers? I've never liked the look of ellipses in prose in the AP style, but I also don't want my work to be less accessible to those who don't/can't read the prose itself.


Also, in regards to the brackets, thank you very much for that info. My next novel is going to make significant use of bilingualism to the point that I will likely need a different marker to make sure that the difference in languages is understood, but now I know not to use <>. Also, now I realize that I have absolutely no clue how to format this in a way that will work for TTS readers. Crap. 

Re: Accessible Writing

#5

Oskatat Wrote: Reading your own text out loud has always been one of the main recommendations in general

Would that help with this too?


I don't know. I think that would depend on the author / reader. I know that I don't always share the sense of how long a pause should last as my TTS reader, and my aim with this post is to focus on how a *computer* will read things.

Re: Accessible Writing

#6

ferdielance Wrote: Is it possible to configure screen readers to recognize specific characters as text-specific cues and substitute a phrase?

Most of the screen readers I've come across, yes, but it is something the reader has to do. Those are usually handled in global settings, meaning it would apply to all the text the screen reader parses and not just one particular story.
ferdielance Wrote: For example, suppose an author preceded every system dialog table with a symbol that wasn't used elsewhere in the story, such as an at-symbol. Could a screen reader be configured to replace all mentions of that symbol with a preset phrase, such as "system dialog?" Even if this weren't possible, having a parseable marker that was less obtrusive than "System popped up a dialog" would give a brief cue to the listener.

That's a possibility. In that case, I would suggest not going overboard with the symbols. Some things to keep in mind there are:
  • The at sign @ will probably be read by the TTS engine as "at" which could be confusing. More broadly, most of the TTS I've worked with will read the meanings of symbols, but not the symbol names. 
  • Assuming out of the box configs for most screen readers, each and every symbol will be read. Triples are about as far as I can stand before I'm annoyed. Other people have other tolerances.
  • Triple hash tags (#) or triple asterisks (*) are already commonly used for scene breaks.
  • A lot of screen readers these days do understand more than just ASCII text, but unicode implementation is still spotty.
I have seen what you're talking about successfully pulled off when the author treated System interfaces like a command line system, marking the start of System text with a single # and prompts for the responses with an right angle bracket >. My TTS software reads that as "greater than", by the way.  Also, the problem with dropping text because of the angle brackets has only consistently occurred with the paired brackets.

Re: Accessible Writing

#7

Thedude3445 Wrote: This thread should be moved to Guides By the Community, because it is very useful. There are some style guide elements here I had never considered before, partly because I have never before used a TTS reader to listen to a web story.

I wasn't quite sure about that. It's not a topic that comes up every day, and it can be hard enough for authors to get started without adding on something that can feel like an extra pressure. I figured the Writing Tips section is for authors looking to step up their game, and it has less of a "do or be dam*ed!" feel to it.
Thedude3445 Wrote: In my personal prose style guide I've adopted for years and years, I have one punctuation note that I believe in nonstandard in most styles: When I use ellipses, I... well, I put a space after the ellipses, even for at the end of a sentence... ...But no space at the beginning of a sentence, for some reason. Is this something that messes up TTS readers? I've never liked the look of ellipses in prose in the AP style, but I also don't want my work to be less accessible to those who don't/can't read the prose itself.

I ran your post through the TTS apps I use and the ellipses read fine in one and were ignored altogether in the other. I'm not sure if it would be okay in all screen readers or TTS apps. An odd thing I did notice is that in Balabolka, "don't/can't" read as "don apostrophe t slash can't" while in @Voice it read just fine.
Thedude3445 Wrote: Also, in regards to the brackets, thank you very much for that info. My next novel is going to make significant use of bilingualism to the point that I will likely need a different marker to make sure that the difference in languages is understood, but now I know not to use <>. Also, now I realize that I have absolutely no clue how to format this in a way that will work for TTS readers. Crap.

There are actually a few styles for quotes. Double and single quotes ("" and '') are just what's common for English. I'm assuming you're working with a standard English keyboard, so you may have to use key commands to type angle quotes «» or high-low quotes ‟„ . Windows has had a built-in app called the Character Map since I want to say XP, and in Win10 at least you can use it to look up different font symbols and get their key commands. You can also offset non-standard speech with odd punctuation. It'll read a little weird in TTS, but that isn't necessarily a bad thing as it will at least signal to the reader that something's non-standard about what they're hearing.

Re: Accessible Writing

#8
This is just such an excellent, succinct description of how to make things easy for hard-of-sight or readers with other difficulties regarding reading. 

 I plan on sharing this thread around to the other writers I know, just because its so clean and useful. Much appreciation and hope that you continue to find great stories easy for your TTS programs to parse!

Re: Accessible Writing

#10
This is actually somewhat a problem I have thought of before when I first got a text-to-speech and speech-to-text app. I ended up not using them for long because I found them more frustrating than the benefit I received from having a machine read things aloud for me, and dictation was extremely awkward. I especially disliked how some of the apps struggle massively with words like don’t or words that sound similar but are spelled in a particular way and especially how TTS apps pronounce the occasional word completely incorrectly.

My main problem is that some of my intentions while writing actually go counter to accessibility in some cases. I personally like “nonsense” writing to some extent, especially the usage of made up works like Jabberwocky and Frumious. Being an avid fan of the Fantasy genre, using made up terminology for worldbuilding purposes is almost a necessity. 

Names get especially annoying when it comes to accessibility apps and auto-correct. I know pretty well how Xhosa, or Dlugele, or Ngabanthu, or Tswane would probably be pronounced and I am at times quite invested in the exact spelling more than I am the pronunciation itself, but these things do not go well with accessibility. On the balance of things, I’d rather continue writing weird made up words and my preferred naming conventions for fewer people than abandon my efforts altogether, but I try to be open to options for improving accessibility as much as I can. If there are ways to help TTS machines read uncommon usages of languages I’d be happy to learn more about them, but translating some kinds of language usage will likely always be wrought with difficulty and lose some of the meaning along the way.

Re: Accessible Writing

#11

Endless Wrote: My main problem is that some of my intentions while writing actually go counter to accessibility in some cases. I personally like “nonsense” writing to some extent, especially the usage of made up works like Jabberwocky and Frumious. Being an avid fan of the Fantasy genre, using made up terminology for worldbuilding purposes is almost a necessity.

Names get especially annoying when it comes to accessibility apps and auto-correct. I know pretty well how Xhosa, or Dlugele, or Ngabanthu, or Tswane would probably be pronounced and I am at times quite invested in the exact spelling more than I am the pronunciation itself, but these things do not go well with accessibility.

If I'm following you, you're concerned about the legibility of the words you're using? The thing is, people who use TTS are aware of the limitations of TTS engines, too. As long as you *can* pronounce what you're writing, the TTS engine's I've had experience with (including the ones shipped with my computer) can get close enough for listeners to seamlessly follow along. And as long as you're not writing "Xcabard" and expecting people to read "Doug" you're probably getting to good enough.
The Wandering Inn comes to mind. The old school antimium in there have names that almost all lack vowels. The TTS engines I've used revert to spelling those names, and they are distinct enough that I have no qualms about making a global override for the reoccurring characters.

Re: Accessible Writing

#13
I suppose that for those LitRPGs that are quite common, if we could assign the Alt Text to the table and thus instead of the TTS reading HP,100,MP,100,Dex,125... (ad nauseum)

It would then hopefully pick up the ALT text for -> "Looking at the system, while most stats had remained the same, an increase of 251 experience was visible, meaning that the main character was just shy of leveling up by another 22 points. They could also denote that their skill in basic crafting increased from Level one to Level 2"

Where another user, could go through said table, decipher it and come to their own conclusions. Would this suggestion assist if a TTS could pick up on alt text?

I am just thinking as some LitRPGs are desired for their table-porn. Where people like to observe those changes before / after. Where just having a 5 minute laundry list read to you would be a major detractor.

I know I've used TTS in the past in school. However, that was mostly hating the fact that we had to read frankenstein and I figured I could throw it into a TTS at 160 words per minute and get enough to pass tests, while working on math homework.

Re: Accessible Writing

#14

Dragonkinn02 Wrote: I suppose that for those LitRPGs that are quite common, if we could assign the Alt Text to the table and thus instead of the TTS reading HP,100,MP,100,Dex,125... (ad nauseum)

Would this suggestion assist if a TTS could pick up on alt text?

The if there being the key word. I haven't come across a screen reader or TTS app that won't read out the text in a table. After all, it's still text, even if it is formatted for a more concise display.

I do like the thought, though.
Quote:I am just thinking as some LitRPGs are desired for their table-porn. Where people like to observe those changes before / after. Where just having a 5 minute laundry list read to you would be a major detractor.

Maybe this is a Your Mileage May Vary (YMMV) situation. Most of the authors I've run across who show off the hurking long status page tables tend to do so in spoilers at the end of chapters, and those are easy enough to skip over.

Re: Accessible Writing

#16

Nine Wrote: Did you find any quality differences between Balabolka and @Voice Aloud? (I'm actually using @Voice Aloud as an additional proof reading tool... great minds think alike :-))

The voice engines make the most difference, the apps not as much. Balabolka, as a desktop app, has a lot more options for tinkering with the text and applying the xml tags that SAPI and SSML based voice engines use to distinguish homophones and numeric formats. When I'm saying voice engines, I'm talking about the named voices, like Microsoft Hazel or Ivona Amy or Nuance Sam. Generally, the voices that come with an operating system are good enough while the voices that you buy separately are better over all. I just haven't found good ports of the choices i like for mobile devices yet.

Does that answer your question?

Re: Accessible Writing

#17

BlueCoffeeJava Wrote:
Quote:The if there being the key word. I haven't come across a screen reader or TTS app that won't read out the text in a table. After all, it's still text, even if it is formatted for a more concise display.



Well, if you could find out that there is a desire for that and that the admins would allow for such a feature, I could throw together a TTS that uses the HTML5 TTS APIs for just royal road to detect their main text section and only queue up the known text and trigger tables to use alt text. Not a terrible thing to do, not a terrible amount of work/testing. It would only work for the modern browsers on PC and phone:

PC:
  • Chrome v33+
  • Edge <= 18
  • Firefox 49
  • Opera 21
  • Safari 7
  • IE is still a bastard child that nobody should use
Smartphones
  • Android (Native: 4.4.3, Chrome: 33, Firefox: 62, Opera: N/A)
  • iOS 7
  • Samsung Internet 3.0
That could be a phase 1 and a later phase could do some of the other suggestions to swap out special characters to text to either force a break/pause on Ellipses or try to pick other known 'quirks' to small text samples.

Re: Accessible Writing

#18
Dragonkinn02 Wrote: Well, if you could find out that there is a desire for that and that the admins would allow for such a feature, I could throw together a TTS that uses the HTML5 TTS APIs for just royal road to detect their main text section and only queue up the known text and trigger tables to use alt text. Not a terrible thing to do, not a terrible amount of work/testing. It would only work for the modern browsers on PC and phone:

My first bounce on this is *impressed*. You're taking the idea of my post a lot farther than I originally envisioned. My second reaction is that you're also taking this in a more narrow direction than I intended.

And, before I get too far into explaining where my second reaction comes from, I apologize if I gave offense with my if emphasis. I wasn't trying to be a snot, but I get the feeling I succeeded there despite lacking ill intent.

So, my 2nd reaction boils down to scope. My original post here is intended to provide general tips that can transfer across sites and even across distribution channels. There are a lot of people who post their roughs to RoyalRoad and then go on to publish the more polished story as eBooks, not to mention authors who post on their own webpages as well as here and other story sites to broaden their publicity.

Which is not to say that the idea of adding in a TTS reader native to RoyalRoad is a bad idea! It's more of a branching idea, and I think it could even be a great addition. I'm having troubles logging into feedback.royalroad.com to add the suggestion myself, but I've got a ticket into support and as soon as that's cleared up, if no one else has put up the idea, I'll add it and post the link here.

Speaking of links, here are a few I found while thinking on your concept: