Notes on Screen Reader Accessibility

Authoring General Design Discussions
1

The recent interest in screen reader accessibility has prompted me to write this summary of my experience with IF and the technology. I consider myself to have an average to above-average understanding of how to use my screen reader and the software needed to run IF. I use JAWS 14, the latest version. I think it is the most popular screen reader for people who are completely blind and who are of an age that might be involved with IF. Partially-sighted users like it as well, but they also use programs like Window Eyes or Zoom Text. NVDA is another reader that is popular, easy-to-use, and, unlike those I’ve already mentioned, free. However, most of these are available as a free demo version. JAWS can be downloaded for free from Freedom Scientific and it can be used in 40-minute mode, meaning it will shut off after that time has elapsed.

The following notes are based on the use of JAWS 14, Windows 7, Internet Explorer 9 (IE), Mozilla Firefox 22x (MF) and Google Chrome 28x (GC). I also have all the latest IF interpreters.

If you use JAWS and Windows 7 and you don’t have one or some of the issues that I mention below, please let me know. I’d like to know what the problem is and how to get around it.

Inform

I read somewhere that Filfre is screen reader friendly, and I agree. I think it is the best interpreter for zcode and glulx games. The built-in text-to-speech functions include with some zcode and glulx interpreters is okay, but the voice is really annoying, and it can be difficult to understand at times. Also, it reads a chunk of tex and stops. It won’t repeat the description unless you redo the action. With JAWS, I can go through the text line-by-line or word-by-word, which really helps when I need to check spelling of unusual words.

Parchment is usually good, but I seem to remember that I can’t “press a key to continue” in IE. Not sure if this holds for MF or GC.
Playfic is bizarre: MF works fine, but IE doesn’t recognize anything I type.

Gargoyle doesn’t work with JAWS.

TADS

HTML TADS interpreter is great. Online interpreter, tested with Blighted Isle, shows errors and won’t accept input (perhaps because of the menu system), for IE and GC. I get the introductory text in MF, but then “Press a key to continue” phrase appears and I can’t proceed. I didn’t log in to IMFDB to play.

Quest and Adrift

Quest and Adrift 5 offline interpreters aren’t accessible; the online Quest interpreter is accessible.

	Other Systems

Undum, Varytale, and Choice of … games work on GC, MF, and IE.
Twine works on MF all the time, IE some of the time, and GC never (haven’t tried a lot, though)

Stay tuned for how authoring systems stack up.

Neil

2 Likes
2

Thank you for posting this! We in the IF tool world know very little about accessibility tools, which is terrible.

(I have only looked at the situation for iOS.)

3

Most interesting. How of curiosity, since they are also very popular interpreters (and mine of choice), how are your experiences with Windows Frotz and WinGlulx/WinGit?

4

Frotz and WinGlulx work with JAWS as well. I just like Filfre because it plays both file types. The tts function I mentioned for Inform in the previous post was referring to tts Frotz and WinGlulx (with its speech enabled).

Neil

5

Thanks Neil, this is valuable information!

6

With respect to writing IF with the screen reader JAWS, I have the most experience using Inform 7 (a few years now). I tried Inform 6 way back when and, though completely accessible, I got buried in indecipherable error messages and frustrated by the need for, and hunting of, errant punctuation marks, such as “{”. I gave it up, but fortunately I don’t have that problem with Inform 7.

The IDE, Inform 7’s development environment, is largely screen reader friendly. An obvious excepttion is the skein, which I do wish I could use, but it’s a visual tool by definition. Some of the tabs at the top of the screen are inaccessible, but shortcut keys are provided for just about everything else.

I think the biggest problem is related to having the environment split into two panes. As far as I can tell, individual panes can be shortened, but there is no way to remove one and have a single pane. As for the problem: If you imagine splitting the source text into three columns and travel through a line word by word, JAWS doesn’t read the words in the middle-third column. The screen reader will read the line normally though, if you want to read the line as a whole or are reading the chunk of text as a paragraph. This doesn’t happen with any other text editor, and so I use a different editor (which really isn’t much of a problem). The only time this “silent column” is an issue is during editing when you need to check or change individual words or phrases, or when you are typing and you like to hear JAWS repeat the word that was just typed. For me, the frustration is mild-to-moderate, increasing when I’m trying to debug a game and just need to change a few words that hide in the silent zone (I need to either use another text editor or make a new line from the beginning of the zone, make the change, then re-join the line into one).

The only other real annoyance results from trying to read the game pane. It is accessible, but, unlike with other interpreters that I can read text line-by-line using JAWS mode, I need to read the text in chunks. I can’t check individual words or lines, and this is particularly a problem when listing rules and the rule you want to read is in a list of many. You need to listen to, say, ten rules before you get to the one you want to hear. I end up copying the output and pasting it in another text editor to read and dissect, but you can see how this can become tedious quickly during debugging. This issue could be avoided if I could use JAWS mode, but because the screen is split into to, I end up reading both panes in this mode, and the lines are read as a combination of source and output.

Despite these issues, and with some extra patience, I think writing IF with the IDE and a screen reader can be done. I hope so – I want to enter Spring Thing next year. I assume that other text-based authoring programs, such as TADS, Hugo, and Choice of Games, are also accessible to screen readers. I looked at TADS at one time, and I had no problems at all (well, not with accessibility anyway). And last I checked, Choice of games are written completely in text and with any editor. Hugo might be a good system but, last I checked, the interpreter isn’t accessible.

I have found that point-and-click interfaces, like those used for Adrift and Quest, are tedious and often inaccessible. Adrift 4 is mostly accessible to JAWS, but not all of the parts of some of the dialogue boxes are audible. And you don’t know what you are missing unless you think of asking someone. Last I checked, the Adrift 5 Generator didn’t work at all with JAWS. I’ve had minimal experience with Quest. Some things didn’t work with JAWS. However, had I spent more time with it, I may have figured out a work around. An issue shared with both systems, though, is that tabbing through options and windows is no substitute for the speed of pointing and clicking. With screen readers, you need to tab to the section of interest within a dialogue box, for example, instead of just clicking on it. Obviously, this isn’t a barrier to using them, just an annoyance. This is partly why I gave up on Quest; I thought that getting around the screen and dialogue boxes was just too tedious. It was much easier to just type the text myself in a text-based system like Inform. At the time I tried Quest, though, I had a lot of experience with I7, so newcomers with screen readers who don’t want to learn code may be willing to spend the time working with a system like Quest or Adrift. Maybe the time needed to learn I7 code balances the extra time needed to workl through a menu-interface like Quest.

I have only glanced at a couple of hypertext-based or CYOA style authoring systems. I think Choice of games uses a strictly text-based interface, but Twine is based on flowcharts.

In the end, I like text-based authoring systems because they are accessible, and the code is flexible enough to do what I want the game to do. I would recommend that screen reader users try a system like TADS or Inform because chances are good that you will be able to use all the relevant features of the development system, and you should be able to make games that do everything you want them to.

Neil

1 Like
7

A follow-up thought about text-based authorship and screen readers: Inform 7 uses highlighting to show different kinds of text (such as that which is a comment). The “Source file ended in the middle of a comment” error almost reduces me to tears. All I have to do, it says, is find where the highlighted text has changed color. Easy for you to say. In other words, hunting for errant punctuation can be a problem. I assume punctuation and its monitoring would be more difficult with a system like TADS or Inform 6 because they rely on it much more than does I7. I really don’t find it a problem with I7, except for the error mentioned above, or if I am missing one of a pair of bracketing punctuation, such as quotation marks. I don’t know how much of a ppain this is for sighted writers, and I assume menu-based input would avoid this completely.

Neil

8

While the main Twine editor is entirely graphical (each passage of text is represented by a box, with lines to other passages), you can also write Twine games entirely in a text editor and compile them with a command-line utility called “twee”. This is my favored approach, although it doesn’t seem to be popular with a lot of Twine authors.

9

It is also possible to use Inform 7 as a command-line tool. You lose the skein, obviously.

This doesn’t directly help you with “Source file ended in the middle of a comment”, but if you have a good text editor, you may be able to convince it to find an open square bracket which isn’t matched by a close square bracket. Or maybe there’s a text editor that does both syntax highlighting and accessible highlight-matching?

10

I’m afraid I don’t have a programming background, so I am learning how to use text editors to my advantage as well. I think you’re right, Zarf, I can use my text editor to find a missing bracket. I just haven’t really tried to figure it out yet (I hadn’t heard of regular expression matching until I read the Inform 7 documentation).

Can someone explain the purpose and function of a command-line tool/utility like the one that Shadow Wolf and Zarf mentioned? I think something like that would be helpful to me.

Thanks everyone for the info. I figured I would get some help when I posted.

I may take a closer look at Twine.

Neil

11

Command-line tools mean you don’t have to use the IDE (either Twine or the Inform 7 application) to develop a game. You can edit the source in your favorite screen-reader-accessible text editor, and then build the game from the operating system’s command line (which might not be designed for screen readers, but since it’s part of the OS, your screen reader almost certainly knows how to handle it).

12

Thanks for the information, Neil!

13

It might also be possible to configure your text editor so that you can run the command-line compiler (and possibly a z-code/glulx interpreter) from inside the editor, e.g. using a custom menu item or a hotkey. That would let you use your favorite editor as a sort of a mini-IDE. Of course, not all text editors support this kind of use, but the more advanced ones often do, especially if they’re designed with programming in mind.

Which reminds me, I should see if it’s possible to merge this Inform 6 emacs mode with this bare bones Inform 7 mode to get an I7 emacs mode with proper compile-and-run support. That would significantly reduce my dependence on the Inform 7 IDE (which I also find very awkward to use, even without trying to add a screen reader into the mix).

14

This is very useful, Neil. I have a tester who’s done a lot of work for me on a game, but I didn’t realize he wasn’t able to use a hint device because of the accessibility issue.

And I just realized I had two other questions, too.

First, do the interpreters note italic text in Inform 7? If not, what is a better way to represent it for people using screen readers? Unfortunately, I can’t find a way to stress something in another way. I also worry a row of asterisks may just cause the screen reader to say asterisks fifty times, which is unpleasant.

Second, what is a good way for a person using a screen reader to play Twine games? Are there any? My tester was only able to play Inform games this IFComp with the resources he knew of, but he wanted to try others.

1 Like
15

Hi,

Screen readers won’t read out any font attributes unless the user searches for them specifically. For example, with JAWS, you need to place the cursor on the text of interest and type the insert+F keys. Needless to say, I never do that. Symbols like asterisks are read out individually, so a series of five asterisks would be read “asterisk, asterisk, asterisk, asterisk, asterisk.”. Definitely annoying, and I stop listening, or move the cursor, after a few reiterations. It’s probably not a good idea to place important text between a series of symbols. I don’t have any suggestions on how to highlight text for screen readers, although bracketing it in single asterisks always catches my attention (although I can imagine for sighted users it may be a bit ugly).

My screen reader is JAWS, and I’ve never had a problem playing Hypertext-based games using Firefox.

Neil

1 Like
16

Thanks, Neil. I think it’d be useful to have this information around somewhere prominent, because I would be willing to take the time to make a game accessible. It seems more worth a formal document, but that seems like potentially even more significant of a time investment.

In my game, some very important text was lumped together as letters, so it created nonsense words. I found it was not to bad to write out conditional text that lets you space letters or, as you mentioned, put stuff between asterisks.

Ironically, I thought abbreviating Red as R and Yellow as Y was almost certainly easier and had no downside.

Thanks for the screen reader information!

17

Thanks for this thread. I work for an organisation supporting blind people in the UK, and we have a few writers who have shown an interest in creating IF. I’m looking for the easiest screen-reader compatible option available, and TADS seems promising.

18

Hello,

Maybe I can help, but that information is several years old, and I’m not sure if it is still accurate.

I think both TADS and Inform 7 work well for parser games. TADS is more technical, though. The natural language used by Inform is better suited to screen readers since it doesn’t use as many punctuation marks. For hypertext games I like squiffy. I tried Twine years ago but couldn’t get it to work right. With squiffy, you can just type the code into a text file. The code is simple and doesn’t require a lot of indentation, although a little knowledge of javascript would help.

Let me know if you have any more questions.

Neil

DA8E97B1917E4CE0BF697F3EDBA9BEA2.png
DA8E97B1917E4CE0BF697F3EDBA9BEA2.png708Ă—1 82 Bytes

19

Thanks Neil, this is very helpful. Beyond the few people I know with an interest in IF I don’t know if there’s going to be much overlap between our organisation’s writing, coding and gaming communities, but I’m hopeful that some will find this to be as fascinating an area as I do. This will help me present it to them in the best way possible, so I appreciate your assistance. :slight_smile: