Title: Writing for Voice Synthesisers

I found Francis' comments about converting source code into a speech synthesisable form interesting. Anyone attempting to undertake such a project might be interested in the fact that some synths can read text using different voices according to various attributes. So, instead of saying "comment" for //, you can read the comment in a different voice, which could be better because it's obvious where the comment ends (and also if someone wrote the word "comment" in a program it wouldn't get so confusing). Screenreaders can already read things in different voices that are displayed in different colours, so in conjunction with a syntax highlighter you can get somewhere (although if you're a beginner then you need someone else to set it up for you). Many email programs can write quoted text in a different colour than the main text, and with some synths it is quite easy to get them to read the quoted text in a different voice without saying "greater than" every so often. This can be quite effective.

(Another thing you can do is embed voice control codes in email itself. I managed to do this at the RNIB college once, but it relied on my knowing what sort of synth the recipient was using, as well as the fact that the client mailer program passed the escape sequences through.)

Unfortunately not all synths have this capability and, on those that don't (or on humans that don't know what expression to put in your text), you have the classic "reserved word" problem. If you use any word to denote a special symbol or other thing you want to say, things get confusing when someone uses that word in the text. That's why I (these days) try to avoid using identifiers like "slash" and "comma" (easily done when you're writing some kind of text parser).

The only way I can think of to get around this is to have all your "reserved words" very obscure, but this is not a perfect solution and does give your program a steep learning curve! Also, if you choose long words, you'll be getting less information across in unit time. (This is what I don't like about these "speech navigation" products that sighted inventors often want to make. I get nightmares of some computer telling me in a slow, soothing voice, "Information. You are about to walk off..." aaaargh! "... the edge of a cliff.") It's too easy to ignore written information on the screen and not realise that people with speech synthesisers may have to listen through it in order to extract the useful information, and it's hard to strike a balance between this and being informative enough.

One obvious way to improve code for synth readability is to add comments to closing braces. Often in a deeply-nested structure you get "right brace, right brace, right brace, ..." which is not often helpful. I've found that, as a result, blind programmers tend to write well-structured code with no very deep nesting (they'll prefer to introduce more functions or methods). Perhaps everyone should be made to work this way! ☺