Authors! Designers! Developers! Lend me your eyes!
Now that you’ve got no eyes, think about that project of yours - can you still play it?
Nowadays, there are many devices to play IF in, and many players who want to play your game. But those devices may have limitations, and some of your players - maybe the ones who will be your biggest fans - may have some disability that’ll prevent them from enjoying your masterpiece.
You didn’t know about all that? That’s ok, you don’t have to know, maybe no one bothered to bring it up. Well, what follows is a list - hopefully a growing one - of things you should consider. Fair warning: I’ll be freely mixing together accessibility and usability. They’re not the same thing… but it’ll help you to think of them as kissing cousins.
You don’t have to follow these guidelines strictly and religiously. Let’s get that clear right now. You make the game that you want to make. Accessibility and usability are always about compromise, and it’s your game and, ultimately, your choice. What these guidelines hope to do is make sure you make an informed choice. [size=85](contribution by Oreolek)[/size]
These all boil down to:
- Understanding that sight- and/or sound-impaired players will want to play your game (accessibility)
- Understanding that your game will be played on a variety of systems and interpreters, including even mobile devices (usability)
BEFORE WE GO ANY FURTHER
Before we even begin talking about the details, there’s one very big thing to keep in mind: target platforms (and I’m including “web” as a separate platform).
Some tools, like ADRIFT and TADS, allow you to export a game in .exe format, which is readable by Windows machines. The upside is that your players don’t have to fiddle with interpreters, which can result in more Windows users playing your games; the downside is that you’ll be forcing Linux and Mac users to jump through a few hoops, and are ruling out possible future interpreters for Android, iOS and whatever else the future brings.
Unless you’re certain that it’s what you want to do - unless you’re certain you want to lock your game into a platform, for the sake of some of your players having an easier time - you should probably avoid these bundling tools. Consider instead the two following techniques:
- Check whether you can distribute the interpreter along with the game.
Noteworthy examples are Windows Frotz and at least the Windows implementations of Glulxe and Git. If you distribute the interpreter and the game and then proceed to rename the interpreter (let’s say that you game is called MotherGoose.zblorb; rename your interpreter to MotherGoose.exe) and it will automatically open the game when you launch the interpreter. Much safer than bundling into .exes - because the raw data files are still there, and can be opened in any other platform that has an interpreter.
- Make an online and offline version of your game.
Are you making an Inform game? Consider releasing it along with a Parchment interpreter (or make good use of the “http://iplayif.com/” service), or Quixe if it’s a Glulx game. TADS 3 games that are not too fanciful can also be exported to a Web-playable format. The vast majority of web-based games out there (I’m speaking from experience) can easily be packaged and distributed in a single .zip file for offline play.
On the other hand, don’t just distribute the web-bundled games. Distribute the raw files as well, and if there’s an existing interpreter for a certain platform then it’s almost guaranteed the interpreter will provide a smoother experience. Give the player the choice, and they’ll thank you for it - and play the game you intended to make.
This is not as inconsequential as it sounds! People who use terps regularly, such as myself, have customised them to within an inch of their lives to make the reading/playing experience optimal (this is vital in those iOS and Android devices), and will prefer to have everything in terps. But hyperlink games in Inform 7 play havoc with screen readers when playing offline [size=85](source: Neil. Thanks, Neil!)[/size], so you’ll want to provide online versions of hyperlink-heavy (even hyperlink-exclusive) Glulx games! If you really care about accesibility and usability, give this some thought.
We’re not asking you to redevelop the tool you’re using; if your development tool of choice doesn’t have these niceties, just shrug them off. But take the time to know it well; maybe it does have them, and if you use and abuse them you’ll have more people enjoying your game!
GRAPHICS
Avoid having vital information in graphical form alone
It may be super stylish to have your introduction written in an image file, to be displayed when the game begins. Or to have your graphics hint at objects which you didn’t describe - on purpose - in a certain room. But what if the player’s sight is impaired? Or what if the interpreter doesn’t support graphics? Or even, what if your graphics fail to appropriately convey what you want to?
If there is important information in the graphics, it should also go in the game’s text. If you want to be really fancy, you can have two toggleable modes - one with graphics, relying on them all the way, and one without, replacing all the graphics with all of that extra info. Everyone’s happy!
It goes without saying that you should beware of graphics-based puzzles!
Consider the size of your graphics window
It’s somewhat common, when using Inform 7 especially, to define the graphics window as taking up the top half of the screen, or a specified fixed amount on the left side. It looks killer on your desktop, and you want people to experience it.
Fair enough. But did you know that on the iOS, for instance, the keyboard is toggleable? On the iPod, if you turn off the keyboard, you have a nifty split window, half graphics and half text… and the minute you toggle the keyboard on to actually play the game, your game text gets obscured!
My suggestion would be to avoid images that are larger than one third of the game’s height (as for width, Counterfiet Monkey shows that the vertical split causes no issues at all). One-fourth would be even better. Just be sure to use RELATIVE dimensions when you can - avoid setting a specific size, because you don’t know what devices your game will be played in!
SOUND
Avoid having vital information in sound form alone
Not every interpreter can play sound, you know. Plus, not every player can hear it! If you want sound to just be an integral part of the whole experience, you should totally go ahead; but if you want sound to be vital for solving the game, then you have to provide cues in the text as well.
It goes without saying that you should beware of sound-based puzzles!
FANCY EFFECTS
Hyperlinks on touchscreens [size=85](contributor: heartless zombie)[/size]
On a smallish tablet or a mobile phone, text is usually much smaller than a finger (like 3-5 lines under my finger tip). That means that if hypertext links have no spacing (at least 1.5 centimetres is ideal) then it can be frustratingly hard to select a link accurately. In web games you can use CSS to define minimum spacing and hit areas.
Links composed of small text should have a large hit area so it is easy to activate them. A common mistake is to make only the letters be the hit area (not a block of space surrounding the link) so that one taps away madly trying to hit a pixel of the letters. (That happens to me way too often! It’s built into some systems, unfortunately. --Peter Piers)
Hyperlinks in general [size=85](contributor: Neil)[/size]
Hyperlinks are a bit of a hit-and-miss. “Simple” html links work, although I can’t really define simple. Just remember that the fancier you make your text, and whatever funky magic you do to manipulate how links work, will probably be very hard to use with screen readers.
Hyperlinks work in glulx, but I think that will depend on the screen reader. It’s tricky to activate these links in offline interpreters, and it takes patience an an experienced user to know how to do it. In fact, I wouldn’t play a game offline if it depended on links; just too tedious. I think online play is okay, though. (So making a game offline- or online-only often isn’t the answer - you want to provide both if you can! --Peter Piers)
Status bar
The status bar is a great place for all sorts of information, keeping track of all sorts of variables. But it rather breaks down when you’re trying to use a screen reader, because switching the focus between the main text and the status bar is more than a bit of a hassle. Also, try to put too many text there and some mobile terps will complain! If you want to abuse the status bar, make sure that there’s a selectable alternative - like, for instance, displaying all of that nice info after a certain command, or automatically after every turn if applicable.
ASCII Art
Did you ever stop to imagine how the Royal Puzzle in Zork III would play like using a screen reader? Ok, so in some cases ASCII art really is the best solution, but you should always make sure there’s an alternative. It’s never good to rely exclusively on ASCII art to convey information, especially in these days of varying device sizes - have a backup plan!
Text colour
Sometimes it’s tempting to make full use of your colour capabilities. Make this text red! That one, purple! Oh, this bit over here should be golden, or failing that, bright yellow, to symbolise this, that or the other!
Well, since you’re going that way, go the whole way! Consider also changing the background. You’ve no idea whether your player will have a white, black, blue, grey or sepia background (at times, I’ve personally had all of these. I’ve settled on a nice light grey). Red text looks ok against white or light grey, for instance, but it’s really hard to read against black. Yellow on sepia or white is not much better! If you choose the background colour, you’ll minimise all these unexpected nasty surprises.
Glulx users, you have a middle ground here! You can customise the foreground AND background colour of any given style, therefore ensuring that your emphasis is always leggible without having to change the background colour![size=85] (contributor: heartless zombie)[/size]
PS - Colour-blindness is a thing! So are, potentially, terps that don’t support colour. A lot of games that use this effect to emphasise vital text, like keywords, offer a choice to the player - instead of having coloured text, they can have emphasised text, like bold or italic. This is A Very Good Idea! The more options you give the player, the more likely it is your game can be accessible to everyone!
Highlights and screenreaders [size=85](contributors: heartless zombie and Neil) [/size]
Typically, bold and colour text does not cause any effect when a screen reader translates it into speech. When bold or colour are used to highlight text, the highlight is inaccessible via a screen reader. A work can provide an alternative version using special symbols or words to distinguish highlighted passages - the screen reader can convert these signals to speech so they are accessible. [size=85](heartless zombie) [/size]
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). size=85 [/size]
Real time and teletype effects [size=85](contributor: Neil) [/size]
I don’t think real-time delays are a problem with screen readers, except that users would not necessarily know the text has changed. The user would have to check for changes, but that’s not necessarily a problem since it is likely the new text will be noticed when the user starts to read or attempts a command. Any effects based on really short time intervals, though, would be missed, like the “teletype” actions described in real-time delays.
Arrow keys? ESC key? Are you sure?
Arrow keys are so comfortable when navigating menus. They are the most obvious choice! And pressing ESC to go back to a previous menu, I mean, what could be better?
But if you stop to think about mobile devices… suddenly there’s no arrow keys! No ESC key either!
When using these special keys, it’s good form to allow alternatives, like (N)ext / §revious, or the now-old-fashioned JKsomething-something keys, or even WASD if you want to. But have those alternatives ready! Don’t rely on your players’ devices actually having those arrow keys!
Text size
Text size is often an artistic choice, but a choice that needs some care behind it. Any game that allows the player to customise the size of the text is doing A Good Thing. Consider that your players will want to play your game on all sorts of systems - yesterday’s font sizes of 800x600 (yesterday? I’m showing my age!) are straining legibility today at 1440x900 and beyond… then all of a sudden they have to look good on tablets and phones as well!
This is not specific exclusively to web-based games! You can check out Narcolepsy and Photopia for two examples of games that came bundled with lovely graphics, and with a lovely fixed window format, that makes for a difficult reading experience unless you reduce your desktop resolution to 800x600, or even 640x480.
The usual caveats apply - if the game that you want to make requires some fixed font sizes, like Narcolepsy (which managed a very interesting visual style), go for it. If you can make an alternate version as well, though, that’d be super, and a lot of players would thank you for it! Not just sight-impaired players - but also people playing on mobile devices!
WEB-BASED GAMES
Internet access
So your newest masterpiece is a multimedia tour-de-force, using sound and graphics and playable on a web browser for everyone to enjoy. Congratulations! I’m looking forward to playing your game…
…except that I do the vast majority of my IF gaming on the go, without web access, because I have very little time to be at the desktop these days. Darn! Guess I’ll have to give your game a miss!
To avoid scenarios like this, consider embedding as much data as you can into your game. Do you really need to link to that YouTube file - can’t you just embed its music? (if there’s a copyright issue with distributing that music, are you sure you wouldn’t rather use something in the public domain instead anyway?) Do you really need to link to that image instead of just embedding it?
Sure, sometimes website access is a must. You may be doing really crazy things that need a server operating elsewhere. Power to you; I’ll try to get around to your game when I can. But if you’re not, you can increase usability simply by bundling the game together, avoiding links to any online-only content,
…and while we’re on that subject…
…it’d also be superb if I could download your game to play on the go! No internet access all the time, remember? That means that people who want to play your excellent game should have the chance to - and they will, if you give them a downloadable file! Together with all the extra content. Sure, it can get a little big, but the people who complain about the size are the people who’ll probably want to play it on the web anyway, so they won’t be bothered; the people who really want to play it offline know that things are as big as they need to be [source needed].
Saving your game
This is especially true for web-based games. Never assume that people will finish your game in a single sitting! It’s worth devoting some time to making sure you have a working SAVE/RESTORE mechanism in place. There may be a power surge! Your mobile device’s battery may run out! You may fall into an open sewer manhole, break your legs and starve for days because you were walking home late, using a deserted shortcut that no one uses any more, and no one hears your cries because you’ve gotten hoarse from screaming - and wouldn’t it be nice if, by the time you finally got out, broken, smelling of sewer, a remnant of your former self, you could pick up that game from where you left off once you finally finish those years of physical and mental therapy?
Ok, so I may have exagerated a teeny weeny bit. You wouldn’t really starve, I’m sure someone would hear you within, oh, five hours or so. Six hours, tops. Maybe seven. Certainly only long enough for your broken leg to slightly infect.
Save-and-resume is a general problem not specific to web. Any computer can crash - if there isn’t active automatic saving then you lose your game. If you can only play slowly and have limited hours on computers, the lack of saving means you only have access to partial experiences of games. [size=85](contributor: heartless zombie)[/size] Thankfully, though, most interpreters for games designed to be played offline provide a savegame functionality. You can override it, like Jon Ingold did with Fail-Safe - but know what you’re getting into!
Point and click - or point and hover?
Hovering the mouse above some text can be used to wicked effect sometimes. But of course - a touchscreen has no mouse. You’ll want to consider that! If your effect is so amazing that you just can’t do without it, that’s obviously fine - there’s a difference between Not Knowing About It and Knowing And Then Making A Choice. And Now You Know!
Needing to use the BACK function on your browser
With Twine 2 this has ceased to be an issue, but you should still know. Some Twine authors have made the artistic decision to not provide a “go back” link in their games. This was used in passages that were inconsequential in terms of gameplay; flavoured text. Object descriptions. The idea is that players would need only press the BACK button on their browser to return to the main node.
But what if your browser has no BACK function? Whoops! Unplayable game! And yes, these do exist. Playing offline on my iPod, the only web browser I could find that reads local files can’t deal with the BACK function required by a local file.
Twine 2 includes UNDO/REDO buttons by default, which is amazingly good. But the cautionary tale remains! Never assume any functionality on part of your player or their system!
FEELIES
(“Feelies” is the usual description for anything extra that you choose to release along with your game; depending on how you do it, even your documentation and README can be feelies, as in the game Enlightenment. If you’d never heard of this before, I encourage you to look up Infocom, with their still very playable and enjoyable games and their remarkable, still unequalled treasure trove of “feelies”)
The proper format [size=85](contributors: gravel and Neil)[/size]
You’ll be pleased to know that the usual format for feelies is either PDF, HTML or simple text files, and all three of these are supported by screen readers. Text files are obviously a surer bet - if you have a serious concern about your game being played by someone who is visually impaired, that’s probably what you’ll want to use. Generally, nowadays most PDF files are readable with screen readers, and if your intended audience needs a screen reader chances are excellent they’ve already found the PDF reader they like best. And unless you’re doing something really, really fancy with HTML, that’s viable too. So that’s good news all around!
It goes without saying that, if you put visual information in your feelies, screen readers won’t cope. Let’s say that you want a brochure, a flyer, a note. Something atmospheric. Something handwritten. Go ahead and don’t hold back (I’m a sucker for those things myself) but remember to also make it available in text-only form. Just in case. 
THE NITTY-GRITTY
This section is for peolpe who are serious about accessibility and usability. If you want to address some of these, they’ll have to be on your mind all the time while you’re coding. Then again, some of the things in here have more to do with the tool that you’re using than with anything that you, the game author, can control. If these things matter to you, you’ll want to take them all into consideration so they’ll help you choose the engine that’s best suited to your goals!
The importance of short alphabetical synonyms and abbreviations for mobile users [size=85](contributor: heartless zombie)[/size]
Mobile Speech-to-Text and automatic word suggestion is based on looking in a dictionary to identify what word the letters/phonemes the user is supplying most likely belong to. Often suggestions can be made after you supply a few letters/phonemes - for many users, it’s faster to pick a suggested option than to enter a long word accurately. But suggestions don’t work for unique or special words (names, jargon, slang) which aren’t in the dictionary.
Symbols which are not letters may require extra interface actions e.g. to switch to an auxiliary virtual keyboard with extra symbols. (Then to switch back to the alphabetical virtual keyboard.)
(Some game terps have an autocomplete feature, which greatly alleviates this, but you can’t rely on them all the time because most of them won’t. --Peter Piers)
The importance of text reflow [size=85](contributor: heartless zombie)[/size]
Text reflow smoothly and automatically adapts text to different size displays (including different orientations like portrait [tall, narrow] vs landscape [short, wide]) and different zoom levels. Avoid hard linebreaks in connected prose. Avoid fixed-width fields or design elements. Avoid absolute size elements.
Inform 7: Flexible Windows [size=85](contributor: Neil)[/size]
(Flexible Windows is an extension for Inform 7 that makes it possible to have many different windows open at the same time. This allows for all sort of effects, ranging from simple graphical panels to various bits of the screen displaying tons of different information. See Kerkerkruip for a good example of this latter)
The accessibility of extra windows will depend on the type of screen reader and the knowledge base of its user. Windows created by the Flexible Windows extension can be read, but it is very confusing to read because it mixes the text in the window with the text in the main window. This makes reading the contents … challenging. I would recommend having an option to remove the window and put the text in the main window.
(Again, Kerkerkruip is a great example on accessibility and usability, because all of those extra panels are toggleable. --Peter Piers)
Know your tool [size=85](contributors: Neil and bphennessy[/size])
This is the last item on the list, but it may be the most important. Now that you have all of these suggestions, you have to know what to expect from the tools that you want to use. This will also help you actually decide on a tool to use. Some of this has been said before. You should know that:
-
The default Twine 2 format (Harlowe) makes heavy use of custom tags, and (…) a lot of screen readers are just not equipped to handle that. Other formats [may] also have problems. […] Some experimentation shows that both the Harlowe and Snowman formats seem to work properly with the latest version of NVDA if you add aria-live=“polite” aria-atomic=“false” to the main story tag (which is
for Snowman and for Harlowe). This also seems to work for the latest version of JAWS, but I was working with a limited-time trial version there so I don’t know for sure. [size=85](paraphrasing bphenenssy a bit)[/size] -
Twine is not stellar at text reflow/word wrapping on smaller devices, at least not with the browser that I found works best for my gaming (hey, I’d love to use another one, but they all pretty much suck at reading local files).
-
Any system that requires specific functionality (like arrow keys, or the BACK button for browser games) will have reduced usability unless a workaround is coded in.
-
Any system that allows player customisation - and offline, terp-based systems like Inform, TADS, ADRIFT, Quest, HUGO, ALAN, etc excel at this - will have improved usability. You never know what colour scheme or font size your players will require so they don’t strain their eyesight. Any web-based games that provides this extra customisation on the player’s end is a system worth investigating.
-
In offline play, hyperlinks in Inform games will not work properly with screen readers (so consider an online version as well). size=85[/size]
-
Inform has some accessibilty features built-in; you can, for instance, define “alternate text” for your graphics. Then it will be up to interpreters to use this information meaningfully.
-
Please help me expand this list!
More resources [size=85](contributor: bg[/size])
-
http://webaim.org/resources/ is a compendium of various resources and articles about accesibility, including such awesome resources as screen-reader simulations. Special mention goes to a contrast checker at http://webaim.org/resources/contrastchecker/ where you can see straight away how readable your colour scheme is. [size=85](contributor: bg[/size])
-
Please help me expand this list!
(this space intentionally left blank. I hope to expand as people help fill this in. Every thought and suggestion welcome! Please PM me, so as not to clutter the thread, and I’ll copy/paste your suggestions verbatim, allowing only for the formatting I’ve got going)
