Accessibility observations part 1

This is the first of a number of posts I will be making about figuring and programming accessibility into your interactive fiction game project.

I speak not as an expert, but as a game author who has now spent a fair bit of time trying to do this. I just released a large Inform 7-programmed game (Leadlight Gamma) which I tried to make fully and explicitly accessible, so my goal here is to share what I've learned about the issues and technology involved along the way. The game is fresh so I'm still learning. In other words, I'm still getting feedback about this aspect of it from the real world.

When I say accessibility, I refer primarily to making the content of your game available to players who have various degrees of visual impairment. This is because formatting game material in a way that maximises its compatibility with screen reading software (the software that reads text aloud to a player) is something you can have a significant degree of control over as an author or programmer. Solutions to some accessibility problems are entirely beyond your control, but IF has always had this gaming strength for players with limited or no sight because the content is essentially text and the games don't depend on reflexes.

The subject of accessibility came to my attention last year when I set out to program a new, more modern menu-generating extension for Inform 7. Right now I'm trying to update it for the latest version of Inform. When I asked about people's needs and wants in such an extension, Neil Butters on the intfiction.org forum described some of the quirks of the way his screen reading software interacts with IF. I then sought to program the extension to cooperate with screen readers. In programming Leadlight Gamma, I sought to extend accessibility principles across the whole game.

This kind of accessibility work doesn't just apply to a game itself, but to related materials, too. Here is an example from the 'learning from my mistakes' department: I drew attention to my game's accessibility upon its release, but the homepage I'd built for it was not as accessible as the game, something a blind journalist quickly pointed out to me. In real terms, this means my website content did not play nice with screen-reading software.

The world of IF technology remains querulous (will this or that interpreter run my game? Will there be pictures? Will there be sound? Will things change colour when I want them to? Can I control the fonts? Will it run online? Will it run on Macs and PCs? etc etc) and I've learned that life with screen-reading software can be as querulous in general. There is no perfect software which can interpret all websites in some idealised fashion because there is infinite variety in website design, programming methods and presentation. Screen reader users have to develop habits and nouse which allow them to find the information they want when online, and some sites don't cooperate with their software at all.

In the case of the Leadlight Gamma website, I had just spent a lot of time redesigning it and my other websites using responsive technology. That is, website code which strives to produce a fluid, attractive and logically presented website on the fly, no matter how big or small or oddly proportioned a user's screen is, or whether they're using a desktop or mobile device. The Rapidweaver themes I'd invested in to get this done did not consider accessibility. My solution was to code a plain text version of the site with screen reader-friendly navigation. I put a link allowing a visitor to switch to the text version of the site at the head of the graphic version.

In a future post I will talk about presentation issues within a game. That is, what you can do to present content helpfully within an IF interpreter screen.

Something you may be interested to watch is journalist Robert Kingett's video how blind people use the web. You can see/hear a screen reader in action and look at some examples of websites which work with one and websites which don't.