A lot of the time, accessibility just happens. Parser games naturally have an affinity for it. And yet, sometimes, things don’t work out. Something I’ve had in mind for a while is designing for accessibility. I think there are some basic steps to take: alt text for images, for instance, or thoughtful use (or not using at all) of special characters.
I think this means testing, too. Are there preferred interpreters when it comes to screen reader support? What reader technologies are used for IF? What can I do to check my work before release?
I would love to put together some sort of “accessibility bible” for IF development, so that I could make games that are accessible from the ground up.
As a tiny example, I was advised to highlight printed commands, directions, and magic names by bracketing them with asterisks. I also had footnotes in-game, and the convention for footnotes is to surround the in-text annotation with brackets. Someone recommended that I made this conditional to use asterisks instead of brackets for screen reader users, and I did.
I would welcome thoughts and suggestions about accessible design. Interpreter and reader tech are in-bounds, too.
Note: this is not a thread about whether things ought to be accessible or how accessible things should be. That would be off-topic. This thread is about deliberately making accessible games and technologies.
I find myself periodically linking to the following on this forum – the IFTF’s 2019 accessibility report. Get ready for more ideas than you’d bargained for.
Thanks for the links! I think that these would be great references for an article, but I don’t think I would tell someone looking for advice to search through all of that information.
I will make an effort to examine all of this content and summarize best practices. There are probably a couple of risks:
Some information may be outdated or obsolete.
I may lack the appropriate expertise to interpret the information.
There’s likely other ground to cover. For instance, which recommended interpreters support screen reader technologies? This is probably a moving target.
Even though I will be looking at these links, I still would like to proceed dialogically. I see two benefits of doing so (there may be more):
Authors can share what they’ve been up to with regard to accessibiliy.
Users of screen readers and other assistive technologies can share their own experiences and recommendations.
Lots of stuff to think about! Several of the things I’m wondering about (tools, special characters, testing for accessibility) are named follow-ups.
EDIT: but since it’s there in the report, let’s talk about sound. Is anyone using sound to complement notifications like score increases? I don’t think this is frequently done, but the rationale in the report makes sense.
I can share what I’ve been doing with my WIP. Here’s how it’s going with a lot of the options from the report:
Use alt text for all non-textual content (including “text art”) - Y
Allow the player to set text preferences, including “dark mode” - Y, function of interpreters Pair special updates with sounds - MAYBE
Offer quick-travel and other in-game shortcuts - Y
Offer an Undo command - Y
Offer hints and walkthroughs - No especial hints, a design choice
Parser IF should offer a separate “training ground” for new players - N, but has a tutorial
List content warnings, when applicable - Y List obvious exits and objects - Y
Prominently display a command guide - No, but HELP commands list commands
List frequently accessed information in separate panes - Somewhat
Avoid assuming able-bodied life experience - Y
Longer games should offer saving - Y
I bolded a couple to talk about.
Re: “List obvious exits and objects”, I’m providing a command to list all objects in a location, and that has turned out to be a big operation. Half the parser ‘cheats’ and many programming sleight of hands that you you might have used no longer stand up so well because if the prose says (or strongly implies) something is there, that thing had better appear in the LIST. And how’s that going to happen? You have to implement it, when previously you may not have had to do so. So it’s actually changing the design, programming and writing.
Now, implement means at the very least, ‘create the object’. But if it’s there, you will then probably have to do some more work on it, or if you’re me, a lot by choice so that it’s genuinely implemented. The outcome will be good for the game, but it’s a new level of work.
Re: special updates with sounds, this is technically easy, but my game’s sort of too ‘open’ or maybe naturalistic for me to easily be able to decide what should get a sound. You’re not looking for treasures. You rarely know if a thing is puzzle-useful when you pick it up, or if you’re even looking for something puzzle-useful. So if a ‘ding’ is meant to have a consistent meaning, I haven’t been able to work out what that meaning would be in my game, yet.
The LIST would definitely alter player experience, and that would need to be accounted for. I will probably do a command, which I didn’t do in the last game. I still have a lot of time (he said, sweating profusely).
I don’t think I could deliver a story with multiple opening and closing panes for the data. I get the logic behind the suggestion; I just don’t think I have the skill.
While I haven’t caught myself making assumptions, I think that I take a lot for granted. This is the one I worry about the most, since it isn’t about specs or procedures.
I get where you’re coming with sound. I actually read the IFTF report when it was first posted here, but I haven’t found a good way to apply the advice. I doubt I’ll have a scoring system for the next project. Even if I did, it would probably be too weird to benefit from sounds.
Thanks for letting us know where you’re at with this stuff!
Yeah. I mean maybe I’m being blase in saying, ‘Done/doing that,’ but because I’m writing in a very character-centric way, the experience and biases of each PC are their own, and conveyed in their inner dialogue and the voice of all their prose. My goal is to be true to each PC. I think inevitably, as I’m also playing up the differences of each PC from the next, that’s a pretty good countermeasure against any one particular view of the world dominating.
This is something I’ve just begun to look into. I’m not sure how good most screen readers are with content that isn’t ARIA compliant. If I wanted to test a screen reader with my game, which one works best in browser web pages?
let’s not lost sight of the other side of the technical problem: how text readers work ? esp. how are feeded ? how they handle (and interpret) special characters ? there’s a standard markup for text readers ?
oh, minor point: alt text should be also for sound ?
You can download a trial version of ZoomText with Speech from Freedom Scientific. It remains operational but limits to 30 minutes of use at a time.
Freedom Scientific also produces JAWS for Windows. A demo version is also available. JAWS is TTS only.
I have used ZoomText since 2000 it’s options for for enlarging text and other materials on the display and the amount of verbosity are quite versatile.
If you’re on Windows, NVDA is free/open source. It works better with Firefox than with Chrome. On Mac, VoiceOver is built-in, you just have to turn it on.
NVDA doesn’t work quite as well as JAWS, but actually for testing you probably don’t want to use the best thing, you want to know what the worst experience is, so that’s probably good, actually. If it works well in NVDA/Firefox, I think you’re pretty safe that it works everywhere.
(note for NVDA: learn to use the keyboard shortcuts. You can mouse-over things to read them, but that’s mostly a debug option for sighted developers, and there is at least one place at which it reads things differently than the keyboard navigation that people actually use). Insert+Up/Down will get you quite a long way.
Also, re: Twine: unless you’re doing fairly major interface stuff, you shouldn’t need to know anything about ARIA. AFAICT all of SugarCube’s built-in macros are good out of the box. Harlowe is weaker (last I knew cycling links didn’t automatically read when they changed, for instance) but mostly not terrible. I haven’t looked at Chapbook.
If you’re doing web dev kind of stuff yourself, most of it’s pretty common sense, if you avoid the modern stupidity of using divs and spans for everything, and stick with using the HTML elements that already have the meanings that you want. Put alt-tags on images (or tag them as aria-hidden if they’re useless ones so they don’t waste people’s time). Add aria-live="polite" to the main game area where the contents change. That’ll get you a pretty long way.
Making a map accessible has been a thing that has bothered me, because you can make an ASCII map in-game, or a PDF map as an extra, and neither of those will help for visually impaired players. In a game with a small map, you can do things like “The dining room is south of the living room. The living room is west of the kitchen… etc,” but that won’t be very helpful for a huge map. Any thoughts?
For the record, have a minor issue here; I have a map intentionally largerly linear on two level with a ladder at one end, (let’s say a sort of U with some) but I have scrapped the passage at the other end for sake of, uh, ergonomic consistency, and I’m still mulling on how to replace it…
The solution I went with (which was recommended by some of the screen-reader users on the forum) was to create a simplified copy of the map, which only shows the room name, and the connections. When checking the in-game map, the game switches to the “map player character”, allowing you to walk around the simplified environment without interacting directly with mechanics or event triggers in the game world.
Also, when the map versions of the rooms are really simplified (so the description is basically just the exits list), then it takes very little time for the screen reader to run through the description, and there’s very little in the way of the information.
I was hesitant to reply at first, because I didn’t want to sound like I was just advertising myself or something, but this was a problem that I had been mulling over for quite a while and asked around for ideas, so it’s really the only thing I’ve come up with as a solution, and the only thing I can give.
Also, it’s not a perfect solution, but hopefully it’s a step towards a better one. The map character could even have a few extra abilities and multiple layers of simplified maps (region map, etc) to help someone quickly narrow down the room they’re looking for when switching the map mode.
Nonsense. If you’ve done something useful in a game that you’re willing to share, there’s nothing wrong with that. And nothing wrong with reminding folks who haven’t played your excellent game that there are other reasons besides fun for authors to play it. I often play games solely because someone recommended it as a good example of something, and I don’t think anyone feels like it’s wrong to recommend your own. Teaching and learning from each other is a glorious thing.
Ah, I see. That’s certainly better, although a very large map would still make this a headache. But I guess large maps are ALWAYS challenging for every player, and one of my favorite parts of playing is making my map. I suppose we could go too far overboard here and oversimplify things that can be happy features of IF in attempts to be accessible.
You definitely should! If there’s a best practice, we should try to work towards it as a community. & maybe document it someplace. Not signing you up for that! I’m just recognizing in general that “it’s one of many possibilities somewhere in this decade-long conversation” is not a guideline. So, how can we find the best thing and make it easy for people to discover and replicate?
I guess there’s always the question of “what is the map for?” In the old days, maps were part of a hinting system and were very spoiler-y. There’s also automapping, which is a way to keep track of progress and exploration, and then there’s what I guess I would call tactical awareness, which a map in your game would provide.
Thanks, Max, for pointing a topic in NPC talking whose has sense in my WIP and totally escaped my mind !
Joey: concur with Amanda and Drew, I suggest that the map player mode can be converted into a contrib library, with the addition of checking for “visited room” status, because can be an useful tool, not only for blind people, but also for Imps.
Also, hello! It’s nice to return to so many replies. I think that I’ll try start updating the topic/top post/OP with things that have been brought up. I probably won’t be able to get to that for a while, though.
Or how terps work with them. I do not believe that all interpreters support screen reader tech, though I don’t think anyone has performed a survey.
Of course. Thanks for reminding me.
I’ll check it out! I have the demo of JAWS that I use to check special characters (I use NVDA, too), but I should take a look at ZoomText.
of the other side of the technical problem: how text readers work ? esp. how are feeded ? how they handle (and interpret) special characters ? there’s a standard markup for text readers ?