Hello All-
I’m tinkering with an Inform game in which ASCII images are a central part of the mechanic, not just decoration. Obviously, this makes a challenge for visually impaired players. What are the best practices for making such a game accessible?
I was thinking of a “screen reader” mode which would describe the image instead of displaying it. But I have a feeling that this is well-trodden territory, so perhaps someone can tell me what the standard practice is.
Thanks!
In my efforts to come up with accessible documentation for Seastalker, the fact of its reliance on ASCII maps led me to wonder several times if documentation alone could make the game enjoyable to persons who rely on screen reader technology.
While some high-cost, high labor approaches were mentioned, it ultimately did not seem feasible to come up with a better solution than step-by-step walkthroughs of the relevant parts.
Of course, I’m sure accessibility was not a design goal for Infocom in those days. Perhaps “designed-in” accessibility will have better results. I’m certainly interested in the issue and look forward to following the thread.
Yes, this is my big worry with just trying to describe the images. It can’t really compare. But perhaps paying some attention to writing vivid or poetic descriptions would be sufficient? I don’t know.
I have a short WIP Screenreader extension whose behavior is to make “Are you using a screenreader?” the first thing the game prints. This sets a global that can be consulted and acted on subsequently.
If Flexible Windows is included, it closes the status window first, and leaves it closed if the answer is yes. It becomes the author’s responsibility to ensure that there’s never any information in the status bar that screenreader users don’t get. My understanding is that at least with most clients, screenreaders don’t read the status line, so leaving it out doesn’t make things worse and I think it’s a feature to make it more obvious to authors that they shouldn’t rely on it as the exclusive means of conveying any given bit of information.
The basic part of it scarcely justifies an extension. (I had written a lot of complicated code in an attempt to automate detecting whether anything that would have appeared in the status line hadn’t been duplicated in the description… and then decided it was better to declare it as author’s responsibility.)
Use screenreader query translates as (- Constant SCREENREADER_QUERY; -).
Include (-
[ EnterYorN t key;
TEXT_TY_Say(t);
while(key = VM_KeyChar()) {
if (key == 'y' or 'Y') rtrue;
if (key == 'n' or 'N') rfalse;
if (key == -6 && t) { print "^"; TEXT_TY_Say(t); }
}
];
-).
To decide if ask y-or-n for/with a/an/-- (T - a text): (- EnterYorN({T}) -).
Interface-value is a kind of value.
Some interface-values are default-interface, screenreader.
The interface is an interface-value that varies.
First when play begins when the screenreader query option is active (this is the ask about screenreader rule):
if ask y-or-n with "Are you using a screenreader? ", now interface is screenreader;
clear the screen;
Part bogus clear screen (for use without Basic Screen Effects by Emily Short)
To clear the screen: say "[line break][line break]".
Volume Use screenreader (for release only)
Use screenreader query.
And subsequently one’s code can just test if the interface is screenreader [...].
So you don’t have to encounter the question every time during development, it acts only if Use screenreader query was included, which is included automatically for release only.
And I realize I said all that and didn’t really address the actual question: yes, I’d say the appropriate approach is to write alt text for all of your ascii images and display that in the screenreader case.
Well, that’s hella useful. I was not looking forward to coding another mode. Is there anything you haven’t made an extension for? You’re just a fountain of neat Inform tricks.
Buy my game Leadlight Gamma if you wanna see how a screenreader mode looks in practice.
Asks if you’re using one, remembers your choice, you can toggle it during the game, it tells you what changes there are in screenreader mode, and it includes descriptions of images when the mode is on.
Also, buy it anyway!
-Wade
I cleaned up my Screenreader extension. and pushed it to the Friends repo. There are a bunch of differences from the code above.
When I look at the back-log of mostly finished projects, sometimes it feels like “no”.
(Oops, sorry to everyone for going all Inform 7-specific at such length; I’d missed that this thread was in General.)
Web accessibility is part of my day job. This Alternative text guide discusses principles. What’s at the heart of accessible alt text is that one conveys whatever the relevant informational content of the image is in context. For instance, if an image were a photo of a person, in a huge number of contexts, it wouldn’t be relevant to describe what they’re wearing. If the whole point of the image was that the person was wearing something unusual, then it’s relevant to describe it.
Just like closed caption-writers include things like “[dramatic music]” and don’t try to give some blow-by-blow description, saying something like “jagged abstract image suggesting shattering” would be much better than trying to describe how many triangles are depicted and in what colors. And if something is truly just decorative and its omission wouldn’t hurt things, sometimes the right thing is to omit alt text. (How many times have you seen a customer support web page with a stock photo of someone wearing a headset? It’s a better experience for a screenreader user to not get slowed down by a description of that.)
I thought about putting it under the Inform category, but decided that the topic probably affected all formats, so I put it here. I know you are used to seeing me tilt at windmills in the Inform section! I am grateful for your Inform-specific commentary, and if folks have comments for other formats, they are certainly welcome here.
I find it interesting to listen to the descriptive audio tracks in movies. If you own any DVDs/blu-rays, you probably have some available.They’re designed to convey the most important information about a series of images as efficiently as possible (obviously the description of a shot can only be as long as the shot itself, and it has to fit around the dialogue). For an example I happen to have at hand, here’s the description of the beginning of the first scene on the remote island in The Last Jedi:
Hanging low on the horizon, a sun illuminates mountainous islands of black rock which form an archipelago in a vast, pristine ocean. Seen from above, a tiny figure clad in gray and white crosses a verdant, moss-covered hilltop between craggy peaks and approaches another figure wearing a robe. Staff slung over her shoulder, Rey stops before Luke Skywalker. A sea breeze billows his flowing robe. Her imploring expression turning resolute, Rey offers the lightsaber. Luke slowly raises his mechanical right hand and human left hand to accept the offering. Rey takes a step back, staring expectantly. Luke considers the weapon with an expression of solemnity. With his scraggly, graying hair fluttered by the gentle breeze, he lifts his bearded face to study the young woman before him.
This all happens in about 45 seconds, a span of time that includes establishing shots for a new environment, the visual introduction of two distinctive characters, and the beginning of a dramatic action. I don’t know who writes these things, but I often find them impressive. They can’t mention everything that appears onscreen, but they point out well-chosen details with little descriptive touches, finding the feature of each shot that’s most salient in its context.
In an IF game, you won’t face such tight constraints on the length of your descriptive text, but I suspect that’s still the spirit of what you should aim for - not an exhaustive description, and not waxing too poetic (unless that’s the equivalent of what the image itself does), but picking out the right vivid details.
Well, I’ll start off by saying thank you for taking accessibility into consideration 
.
I think you’ve been given some good advice, and as a visually-impaired player I tend to agree that the most practical thing to do is to provide descriptions of the graphics—either directly in-game or as image captions. I have been using assistive technology for years and I personally can’t think of a better way to adapt ASCII for accessibility. The characters look completely different when translated to Braille, and screen readers can only tell you the names of the characters being displayed—which sounds like total rubbish when you listen to the output 
. In some cases the image is dynamic, or just too complex to describe (like the Royal Puzzle from Zork III/Dungeon) and there’s really nothing to do but to follow a step-by-step walkthrough. I’ve never actually played a piece of IF with a separate screen reader mode though, and I would be very interested to find out how that would work.
I don’t know how you feel about horror games, but @severedhand 's Leadlight Gamma, linked above in this thread, has a separate screen reader mode.
I’m kind of shocked that this isn’t a settled question. I thought probably Inform would have a built-in extension for it and that there would be an established standard practice. I find it strange that we’re still discussing how to do this after nearly 50 years of IF. Thankfully @zed is on the extension.
Well, as was mentioned in an earlier comment, early game developers like Infocom probably didn’t have accessibility at the top of their list of priorities—not to mention that screen readers didn’t even exist back in those days. We have more tools at our disposal today, and I can definitely say some pretty cool things are happening … although it’s kind of funny that this type of snag pops up so often on a platform which is supposed to be accessible by default due to its “text-only” nature.
Well, it’s more accessible than most 
In my empirical experience as a game maker, the challenges are both technical and conceptual.
The conceptual are kind of on a spectrum where the more of them you address in a game, the wider its accessibility net gets and the more transparent the experience can become for people using screen readers, or who have other specific accessibility needs. You can get a big overview of the conceptuals by reading the IFTF’s accessibility survey/report: http://accessibility.iftechfoundation.org/ (edit: Yeah, sorry, their link is not secure. I really don’t think anything bad will happen if you go there!)
There are ideas in there that range from obvious and easy to implement, to non-obvious/very specific/I’m-not-even-sure-I-want-to-do that. But the bulk aren’t deal-breakers for players. That is, the more you add, the more graceful the experience might become, but the game is still going to be technically playable over a broad range of these being in or out.
The technical challenges are often simple stuff, but they can be total deal-breakers. Things like – does a press-a-key or click-to-see-more mechanism play nice with a particular screen reader? If not, it might lock the game, or cause text readouts in annoying ways that are too arduous to deal with.
The problems with the tech challenges include:
So that’s been my experience on the IF development side.
-Wade
What is the correct way to ask about screen reader usage?
The first question I have in my project is “Are you using a screen reader for visual impairment?”
Is that acceptable, or is there a better way to phrase it?
Generally I avoid asking personal questions, even if I’m not saving the information anywhere, both out of politeness, but also because some places have really strict laws about what kind of information you can ask for.
Instead of asking if the person uses screen reader, I would explain that the game makes use of ASCII images that can be a problem, and ask if they would like to remove them.
That’s also what I have observed triple-A video game companies do. They have accessibility related options in the game’s settings and they leave to player’s discretion how they want to play the game. At most, the game will advise that there are accessibility options available, but not ask anything personal about the player.
This game uses ASCII images, that is, it uses text character to create images. This can interfere with the proper working of assistive technologies such as screen readers. Would you like to hide the ASCII images?
Well, the way I’ve been doing it is:
‘(Game name here) has a mode for players using a screen reader. Would you like to turn this mode on now? Please press Y or N.’
If they say Yes, I turn it on and explain its features and such (as compactly as possible, because people may not be able to remember – or might not be pining to parse through – paragraphs of info before they’ve started playing). If they say No I remind them they can turn it on later with command (whatever).
I don’t need to know the specifics of why they’re using one, only that they are, in which case the game will try to accommodate known screen readers’ behaviour beyond how it would usually act.
-Wade
I would suggest “Are you using screen reader software for text to speech?” I imagine there could be other reasons besides visual impairment to use a screen reader.
My plan, when I get there, is to just use “Are you using a screenreader?” Ain’t none of my business why; it omits needless words and reduces cognitive load in apprehending the question.
I like that plan.
I think it’s good to say, perhaps after the answer, what the result will be: “Okay, this game will use text descriptions instead of ASCII art, and certain puzzles will be modified to fit this format.”