A number of weeks ago I began asking some questions about the accessibility of interactive fiction for blind and visually impaired players (often called “audio gamers”). It was requested by a few members of the IF community that I share any information that came out of those discussions. I promised I would.
Here, then, is the link to my blog post on the topic: http://www.inthecompanyofgrues.com/?p=220.
Thanks for this. It’s very informative.
Interestingly enough, in some classes I’ve been working on there was a similar desire to remove the status line entirely. These were all sighted authors, so it wasn’t for reasons of accessibility so much as it was for the perceived “intrusiveness” of the status line itself. Likewise, menus were pretty much thoroughly disliked among my classes (both the writers and the players).
Beyond that, one of the major things we did consider was an altering of the interface to represent a sort of mental map of the protagonist. (This was done, in fact, to partially alleviate the need for the “extensive note taking and mapping” that’s mentioned in the blog post.) It sounds like current interpreters and screen readers will not respond too well to this modified user interface, however. This would not be a graphical element but rather a set of text that mentions the name of the location, the vialble exits from it, plus other information that may be relevant. For example, inventory might be there or contextual information (such as relationships the protagonist has observed).
I’m wondering if it makes sense for us to focus on some sort of progressive enhancement approach. Meaning, if an interpreter is set to be playing in “accessible” mode, that interface simply wouldn’t appear. Then relevant commands could be used to bring up the same information that would have been in the window. I don’t know if this is possible somehow with checking what’s available on the interpreter and tailoring the experience accordingly.
Neo, thanks for doing this! I’ve commented on your blog, and will leave that discussion there.
Jeff, why did everyone so dislike the status bar so much? I can guess that in some works it might suck, but the thing in itself has so much potential I can’t see why it’s reviled. Many books have chapter titles in their headers after all! That’s actually what I’d consider the best use of the status bar, something akin to a chapter title. In Violet it’s the current problem to solve. Does that really break immersion?
In most cases everyone felt that it was redundant in that if it mentioned the location name, this was already known by the player. No one ever felt they were in a location doing something for so long that they simply forgot where they were. The other side of it was that most games my classes had looked at had the status line presenting score and turns, both of which were felt to be unnecessary. (Writers tend to want to get rid of the presentation of score and turns pretty quickly I’ve found.)
I think part of it was the name as well. “Status” of what? Where I’m located is not usually considered “status” and so I think people had cognitive friction. Score and turn did match “status” (as in my “status” in the game – which would really be better thought of as a “Progress Bar” than a “Status Bar”) but, again, writers aren’t took keen on those concepts, which have nothing to do with story.
Agreed and people did respond somewhat positively if the status line was used to indicate “story location” (i.e,. Book 1: The Progression – Chapter 2) as opposed to geographical location or other information.
There was some talk of using the “mental model window” (mentioned in another thread) as part of the status line but that quickly proved to be way too cumbersome. Given the discussion about accessibility that the referenced blog has pointed out, I’m actually curious as to how to implement this now.
From an accessibility perspective, if the screen readers read all text that has changed, the mental model window wouldn’t change at all unless the player learned something in that room, and it was added to the “mental” inventory, as it were. However, screen readers would read all the text again in the window and not just the part that changed. (Visually my writers wanted to have it so that new additions to the mental map were initially bolded to indicate a change. The bolding would alert the reader that something changed and would stay until the next turn was achieved, at which point the mental model window showed all text in normal type again.)
Based on this, I’m making it a point in the next class to bring up a focus on accessibility concerns and how the solution needs to be oriented to the specifics of mechanics for various types of interpreters.
There’s a lot more that interpreters could do for accessibility, but I wonder if it would be good for authors to also be able to control more. Maybe Glk could have something akin to ARIA’s aria-live property, so that authors could specify that some elements are not to be spoken, while others should take precedence. Glk also needs a way to specify alternative content (for images, perhaps for ascii art too.)
I think that status bars can be sensibly announced via screen readers. I’d be interested to see how this mental model side window would work, but it would probably need more Glk options, otherwise stuff would be read out twice (once when it was bolded and once when it went back to regular.)
Also, the people you talk to seem to have a lot of problems with terminology! Status lines, command prompts etc… are you feeding them these names? Unless you’re an author you probably wouldn’t have ever heard of the names for these things. If you are an author… well I feel like saying “get over it!” as all programming has weird terms that don’t make complete sense.
Well, they also read the manuals to the systems (like Inform and TADS) and those terms come up so it’s pretty hard not to get exposed to them. Even if they don’t see the term, people logically ask “What’s that thing up at the top?” or “Does the greater than sign ever become less than or something else?” It’s not that they have problems with terminology in all cases, but rather terminology that doesn’t match what it says (i.e., “status bar” is really “progress bar” from one logical point of view). That being said, writers tend to question everything, including why something is one way rather than another. I treat it as an eye for detail and making the fewest possible assumptions – but I try not to let it become too much of a focal point of classes.
Right, but the status line and command prompt are exposed to users, not just authors. Any time you expose the implementation model you have to consider how various audiences may reflect upon it, even if, in the end, you basically do tell them to “just accept it.”
As far as status bars being sensibly read by screen readers, I am curious about that. If a status bar just presented the “Book 1 - Chapter 1” thing, that should not change much (certainly not as much as the location indicator), which hopefully means that screen readers won’t read that every single turn. I was actually thinking along the same lines as you with the ARIA kind of thing, not only in terms of what does and does not get spoken but also where there’s a sort of progressive enchancement of technique presented.
It sounds like I have some experimenting to do. I’d like to try to play some actual textual IF works through screen reader software.
It’s made more complicated by the fact that Inform naturally prints the status bar last. But by setting the status bar to aria-live=“assertive” and the main window to aria-live=“polite” then in turns when the status bar changes it will be read before the new text that was added to the main window, even though it was printed last. (Read more about ARIA live regions.)
This would actually be easy to implement in Parchment, but I want to do it properly and make the turns and score never be read out. I have an idea of detecting common status bar templates and altering them so that they’re no longer in a fixed width character window, but instead separate blocks of text which can be positioned with CSS and will display in nice proportional fonts.
Interesting stuff here. Beyond the important accessibility implications, it’s sounding like I need to get more familiar with Parchment and use that in the classes. (I was aware of it, but I simply didn’t give it the attention I should have.) In my class many people did ask if web pages or web applications would be a little more flexible than the interpreters, particularly since how some concerns that were coming up were already challenges being faced when providing web-based experiences.
I also know a focus on accessibility and audio users will be very welcome to writers simply because of the popularity of audio books.
So my thanks to both Neo and yourself! You have both given me an interesting direction to go in here since the next classes are focusing much more on design and implementation concerns.
I play muds a fair amount, and this usually is the approach they use. God Wars 2 does a particularly good job of making its interface (which can have many graphical elements) accessible in an all text format. I think a third or so of its players are blind.
I wrote this as a comment on the blog, but thought it might be useful to post it here anyway:
Thanks for this: it’s thorough, precise, well-argued and just really useful. I’m going to try and take your advice on board for the game I’m currently working on, and try and integrate accessibility.
I could do this by myself, going on your advice and the resources you’ve linked to. However, I enjoy collaborative work, and I think the process would benefit from have a sort of “accessibility advisor” on board, especially if they had programming abilities to help implement some of the suggestions. I understand that may not be possible, but do you think there might be people who are interested?
Interactive fiction authors need to do most of this themselves, rather than having an interpreter-level solution, I think. It’s pretty hard to predict what, exactly, should be done to make a given game more accessible. Obviously, though, our ability to do some things depends on multiple game (sub)windows working well with the screenreader, which Neo’s document suggests isn’t the state of things right now.
Once that technical issue is resolved, we need to grease the wheels to make creating maximally accessible games easy for authors. A while back, I proposed an extension that would, when the player specified that she was using a screenreader, open graphics windows as text windows instead, displaying alternate text content (provided by the author, of course); something similar could be done with pictures displayed in text windows (displaying text instead). I never did create the extension; there was pretty much zero interest expressed. But it would be simple enough for anyone with some familiarity with Flexible Windows to do something similar.
It would also be easy to create an extension that could handle Jeff’s suggestion, i.e., providing an accessible mode with alternate commands which users could get status updates rather than opening secondary windows. This, of course, would be useful (and usable) right now. (Though a blind user did tell me that opening alternate text windows for graphic content would work nicely under Zoom + VoiceOver, so possibly that combination already provides good results.)
–Erik
Thanks.
The gamers that I talked to were a very smart bunch. Many of them are programmers (creating amateur and commercial audio games) or writers, so partnering with them on accessibility projects would be both highly recommended and extremely beneficial.
In fact, just this morning I received a message from audio gamer Jacob Kruger highlighting a clever and creative way that “sound” can be added to a game. There’s the risk of overdoing it, but as a nice touch it’s a great idea. Here’s what he said:
As for interpreter-based solutions, I’m not a programmer (not even close!), but from what’s been said it sounds like a few small changes have the potential to make an enormous difference.
Good to hear. What’s the best way to get in touch with possible collaborators?
In the links section, there’s a bunch of sites listed. Joining Audyssey and posting there would be a good start.
It really depends on the scope of what you’re thinking and whether you want testing or programming. What platform you’re developing for is a big decider, too, as some of them are more proficient at coding for certain operating systems than others.
If you’re interested in a particular individual, let me know. I have some direct email addresses.
There are elements which are better on one side and elements which are better on the other.
Definitely, an I7 extension (and equivalent for other systems) which adds an “accessible” command. Neo’s blog post mentions changing the command prompt (“>” to “Command?” maybe); beyond that, the author needs to be involved. The obvious design approach, I guess, is to print out status-line information before the prompt if it has change and is important enough to notice. Otherwise, have a “statusline” command which prints just the information that would normally be in the status line. Some of this can be handled semi-automatically, if the author is using the left-hand and right-hand variables for status line display. But it will still require some adjustment. (There’s no point in quoting the turn count every turn. Probably not score either, since there’s a standard “notify” command.)
For Alabaster, in further example, this pre-prompt information would include some text description of the changing illustration.
What an interpreter can do is handle scrollback better (in buffer windows). Again, I only know what I read in the blog post, but it seems that we need to be able to scroll forwards and backwards a turn at a time in a way that the screen reader can cope with. (Maybe adding “one turn ago”, “two turns ago”, etc before each chunk of text is read.)
Some game-playing environments, such as the collaborative ClubFloyd, cannot show status bars or other windows. I would think a standard command to call up its contents would be ideal, possibly with a preamble prepended to the command prompt if something changed, cuing the player that entering the command would be worth it.
As for turn count, I can’t say I’ve ever used it as a player.
Having new commands is great for new games, but what about old games? How about having an interpreter command like “\status”, that would be intercepted before the VM would get a chance at it and show the status in the main window?