Accessibility observations part 2

Here in part 2 of this n-part series (where n is probably 4) I begin to discuss what I've learned about how the way you format your game material on the screen can help or hinder screen reader users.

Some formatting approaches are inherently helpful or not helpful while others may be particularly helpful for a particular game design. In other words, integrating an accessibility layer into your game is like integrating any other layer of design whose goal is to help deliver your game optimally to the player. If you're thinking about a segment of your audience that has reduced vision or no vision, and which uses a screen reader instead of sight, you need to think about how the screen reader will react to your material the same way you'd think about how an eye reacts to a visual UI. In either case, you want the relationship between the instrument of perception and the game content to be as intuitive as possible.

Because we're talking about games which are essentially text, the currency of screen reader software, the good news is that neither the formatting considerations involved nor the solutions to problems – at least the ones I've encountered so far – are generally too difficult. They simply require thought and perhaps a little programming action. Or no programming action, if you're lucky. The majority of existing IF projects already play pretty well with screen readers, excepting their status bars or extra windows (to be discussed below) and menu systems (next post!). And since it's probably also true that the status bars in the majority of IF projects aren't doing much, that issue at least is a minor one for those games.

So how does a screen reader interact with the text? It can simply read through all text on a screen for the user, but its focus can also be moved about in an intentional way.

Consider first the example of webpage content. The human eye can tell headings from body content from links at a glance. Someone using a screen reader doesn't get that overall view. So they can either sit through a reading of all the content to find the part they want – which they might do if they're new to their software, or expect to be interested in the whole page – or they can use shortcut commands to jump to different types of content. For example, to the next link or to the next heading. It's easier for the software to identify these kinds of landmarks if the website being scanned has been coded in a conventional or accessible way. Features like flash navigation or graphics standing in for words can make navigation tedious or intolerable.

An IF project is usually delivered in a far more linear way than a webpage. Text is dispensed in the order it's meant to be read, and it's intended that the player always reads (or scans) everything that the game dispenses. The main exceptions are likely to fall in the areas of information contained in status windows, or in other extra windows or novel bits of user interface a game might make use of.

In a screen reader, switching the focus to the status window or any other window is generally an intentional action the player must take. This is fine if the player is only expected to check the status window occasionally. In a game where important information is being updated there all the time, the author could consider offering a screen reader mode which dispenses part or all of the same information in the main window every turn. This includes things like exit lists or important PC stats (à la Leadlight Gamma) which might change every turn. If a user gets tired of seeing these in the main window or finds they don't need them any more in a particular game due to familiarity, they can just turn them off.

If an IF project uses lots of sub-windows, that might be fine if the player only needs to check different windows semi-frequently. Kerkerkruip is an example of a game which mobilises a number of windows and has been received well by screen reader users. Its extra windows don't necessarily have to be consulted frequently, keyboard commands can be used to quote the same information you'd get from them and important stat info is quoted automatically in the main window at relevant moments in the game.

So the point is that if you have more than one window or panel in your game screen, you need to think about how you're using those panels re: accessibility. If some extra window content needs to be viewed so frequently that you can imagine it would be a pain to have to intentionally switch to and from it all the time, it's a good idea to program in appropriate accessibility-enhancing alternatives.

To be continued in part 3.

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.

Presenting Leadlight Gamma

Last week I released Leadlight Gamma, a new Glulx incarnation of my 2010 Apple II-coded interactive fiction-survival horror-CRPG hybrid, Leadlight (here's Leadlight on IFDB). You can buy Leadlight Gamma for MacOS, Windows, Linux or iOS at itch.io for US$4. The game file is cross platform compatible and I offer various configurations of installer or interpreter+game bundles on the itch.io site:

http://wade-clarke.itch.io/leadlight-gamma

15-year-old Belinda Nettle is studying at Linville Girls High School in Australia's Blue Mountains. After falling asleep in the library one afternoon, she wakes from her mundane existence into a nightmare. Her classmates are transformed, nameless terrors seek her out across the schoolgrounds, and traps and tricks threaten her life at every turn. 

Can you help Belinda survive this terror-filled night and solve its mysteries? And will there be a new day?

The game also has a standalone site at http://leadlightgamma.heiresssoftware.com/

At the core of Leadlight Gamma is a faithful port of the original game, now enhanced for modern platforms with graphic automap, tutorial mode, unlockable extra content, behind-the-scenes tour mode and easter eggs, original soundtrack, artwork gallery and an accessibility mode for vision-impaired players.

Unfortunately the accessibility mode isn't a go on Macs yet because the only Mac interpreter that can run LLG is Gargoyle, and Gargoyle doesn't work with screen readers. I plan to talk about this and the various other technical challenges to accessibility programming I've been running into and learning about in another post in the near future.

---

You might wonder what motivates someone to spend a long time remaking one of their games instead of moving onto the next one. I can summarise what happened like this:

A few years ago I was tossing about ideas for a sequel to the original Leadlight. It would have been all modern. No two-word parser, no Apple IIs in sight – just a brand new game. While these ideas weren't coalescing, I opened Inform up one evening and copy-pasted the description of Leadlight's first room into it to see how it looked. Before long I'd pasted some more rooms in, and I was experiencing a degree of pleasure and narcissism in being able to walk around in this world again in a new context. I got hooked on building the whole thing anew after overcoming the first engineering challenge I encountered (though I don't remember exactly what it was, now). I also realised the port would bring the game to more players, and just make it easier to get at.

So I've ended up doing a 180 on the idea I previously expressed that I had no interest in porting the game to Inform. I'd thought the 'building a ship in a bottle' feel of the original 8-bit project (for me) might be rendered invisible or pointless-feeling by taking it to a platform which could, relatively speaking, do anything. I didn't realise it would end up being another interesting permutation of the same experience. It was like building a scale model of the ship in the bottle, partly by squinting through the glass at the original ship, and partly by studying the microscopically scaled plans used to build the original ship.

Lo, an astrolab!

This is Wade Clarke saying these things to you. I have just established Wade's Important Astrolab, a blog (and virtual astrolab) where I can infrequently post about interactive fiction (IF) that I have made or that others have made.

The blog title is courtesy of the IF name generator and was originally just 'An Important Astrolab'.

It pained me to have to reject the following blog titles I also derived from the IF name generator –

Wade's Sweet Pyramid of Anharos
Wade's Ooze of A Coherent Narrative
Wade's Literacy Night Out
Wade's Journey into Holy Joystick
Wade: Got Mummy's Crypt?

– but I felt I didn't want to go Super Wacky because then there'd be a danger of the title gradually becoming annoying with the passing of time. So Wade's Important Astrolab it is.