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.