Saturday, 23 May 2015

Accessibility observations part 3

It's been longer than I intended between posts in this accessibility miniseries, but I had work troubles and I had holiday non-troubles.

Today: Menus.

Lots of IF projects make use of menu mechanisms. The player's choice from a menu might trigger a branch in gameplay or reconfigure some aspect of the game presentation. The whole menu system might be a self-contained ecosystem outside of the game world, a way to present browsable material like game instructions, hints or about-the-author information. An IF project may feature any or all the above mentioned modes, or more.

I had thought it would be easy to start to talk about designing menus which lean to screen reader-friendliness, but I've realised this is actually a complicated area. Different IF platforms handle text output and player input in different ways. Some projects can be played online, some offline and some both ways. Anecdotes from the recent discussion topic about accessibility over at suggest that screen reader compatibility with online CYOA games is variable.

By the way, notice how I included all of the words 'the recent discussion topic about accessibility over at' in the hyperlink, rather than just attaching it to, say, the '' part. This approach is an accessibility help for web content in general, since screen reader users can hop amongst hyperlinks as landmarks. If they're scanning about to see what links are on a page, or looking for a particular link, just having a single word for the link might not make it clear where the link's going to or why it's there.

Now, I can also imagine that if you elongated all body text links of a link-heavy page in this fashion, the result might be visually painful for sighted users. This situation strikes me as an example of one in which it's good to be aware of the accessibility issues, but where individual writers and authors need to work out the best approach and balance for their own content in particular cases.

Back to the menus – so there's probably a lot of work to be done in the future by game and screen reader engine programmers in getting the two worlds to be able to talk each other more consistently. As is the case with many IF projects, work on this kind of thing to date seems to have been done mostly in isolation, where interested individuals program up solutions to existing problems. As an example, I point to the Win Glulx and Win Frotz compatibility addons for the open source screen reader NVDA (search for 'Win Glulx' and 'Win Frotz' on the target page). However, the scope of my posts is about what game authors can do today.

First it's worth remembering some of the principles of typical good menu design that will help any player:

  • Don't make menu entries too long.
  • Don't include too many entries in one menu.
  • Don't use too many submenus within a menu. A bit of popular neuroscience in editor circles says that readers of a book will find more than five levels of heading too confusing, and that readers of a webpage will find more than three levels of heading too confusing. The latter is probably applicable to IF menu depth.
  • When possible or relevant, use a consistent delivery style and author voice for the menu entry prose.

Screen reader programs can read one line of text at a time under the user's control. This means that as an author, you can expect that a player who is using a screen reader will be able to browse up and down through your menu options if they need to be reminded of the content of any of them.

On the other hand, a player using the built-in text-to-speech features of their computer's OS and/or of an interpreter itself probably won't have the same luxury. They may have to listen to a read-through of the whole menu, then go through further full reads if they need to hear any option more than once. Players in this situation are unlikely to enjoy encountering long menus or unnecessarily long menu options.

If the principal input device is the keyboard, as is the case for the majority of parser-driven games, assigning a unique keypress to each menu option (eg 1-9, then A-Z as needed) is a good way to go. I went with a system like this for my new Inform 7 Menus extension in 2014. So did Daniel Willis when he wrote a new menu extension for Kerkerkruip. We happened to write our extensions independently of one another but roughly at the same time, both with screen reader compatibility in mind. My extension broke in the major new version of Inform and I have only recently fixed it – see my blog post about Menus version 3.

If the principal input device is the mouse (ie the menu options are hyperlinks) a screen reader user should be able to activate the options the same way they can activate links they have selected on a webpage... if the game itself is being delivered by a webpage. The screen reader functionality for clickable links within a game delivered by an IF interpreter is probably unknown turf for now.

EDIT - OK, it's not so unknown. In response to my comment here, Daniel says in a comment on this post: "Just one comment, which is that the feedback we got from some of the guys at was that not only do links work in screen readers, but they prefer them. So Kerkekruip's menu uses hyperlinks when the game is in screen reader mode."

A menu presentation which is pretty anti-accessible is one that involves a moveable cursor as the selection instrument. There are all kinds of problems for the user, including keeping track of the location of whatever ASCII element has been chosen to represent the cursor, and the tediousness of having to move that symbol around with keypresses while potentially listening to re-reads of the menu choices. In an all-text environment, the method for updating the display with the cursor's new position might also involve reprinting the whole menu in the game window; again, this is unhelpful for screen readers.

The old standby menu extension for Inform 7, Emily Short's Menus, exhibited most of these problems, which is why both Daniel Willis and I happened to have similar ideas about updating it at the same time. I'm not ragging on Emily's Menus per se – obviously it's been a terrific thing (and generally the only thing!) allowing users to add menus to their Inform games for years and years.

In the next episode: The topic of non-alphanumeric characters, at least.

Sunday, 3 May 2015

Leadlight Gamma reviewed at Gamerz Unite

Leadlight Gamma just received a positive review over at Gamerz Unite. It's fun to see it on a site with a big focus on LAN parties. That's to say, not on a site where I might traditionally have expected it to be reviewed.

I think it's a fun time for IF in terms of being able to see a wider range of reactions to your game if you let a wider circle of people know about it than just traditional IF circles. This effect has probably been more evident – or maybe more transparent – to people producing choice-based games, since they travel more easily than parser-driven games. And sometimes their authors had no connection to longstanding IF circles in the first place.

So there are buyable parser games around like The Warbler's Nest or Death off the Cuff or Hadean Lands or Leadlight Gamma, et al., which have appeared and said, 'Here I am.' (Hadean Lands said it louder, but I think you get where I'm coming from. Textfyre also released parser games commercially, though with a more fully-fledged business model which, as I understand it, proved hard to sustain.) Other buyable parser games, like Cypher, still go with the 'It's the return of the text adventure' schtick. We're in a time where I expect you can get traction (albeit different kinds of traction) either way, but I think increasingly you don't need the 'ye olde' schtick. There's so much serendipity in the kinds of games a person can buy now that I think a parser-driven game looks like just another type in this context.

I would say it's more important that the game or project is good than whether it solves problems the IF community has raised about whether the medium faces some kind of developmental blockage. And of course, the two goals aren't mutually exclusive.

In my previous big game, which was Six, I explicitly tried to make a super helpful parser. If I did that game now, the only thing I would change is that the instructions would be delivered in tutorial form as well, on top of their written form which exists both in the game and in a booklet. But I don't intend to revisit it just for that.

Thursday, 30 April 2015

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.

Sunday, 26 April 2015

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 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.

Friday, 17 April 2015

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 for US$4. The game file is cross platform compatible and I offer various configurations of installer or interpreter+game bundles on the site:

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

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.

Saturday, 11 April 2015

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.