Accessibility observations part 5

In part five of this accessibility miniseries, and most likely the final one, I talk about writing text descriptions of graphics in your IF project.

Graphics in IF – they're on the rise!

Allow me to set the scene for this episode by saying that the IF projects of today are increasingly making use of graphics. Again.

To qualify this broad and vague statement, what I mean is that adventure games started out as text. Then they combined graphics and text. Then the commercial scene went into a mode where the graphics became the engine instead of the text (eg point-and-click). The non-commercial scene remained focussed on the text, but today, as more powerful IF creation tools and add-ons are becoming available to a wider range of people, more of those people are adding graphics to their text-centric games.

For the cause of making IF accessible, the ideal is that authors provide text descriptions of all important graphics. Again, I think that allowing a player to switch these on or off as part of a blanket accessibility mode, or via an explicit 'provide text descriptions for graphics' toggle option, is a good idea.

Which graphics should one describe using text?

Deciding which graphics are 'important' in the above-mentioned sense should not be too hard. It just requires the application of some commonsense and an assessment of the function of different graphic elements in your game.

Any graphic presented to the player as part of primary game content should be described. I define primary here to mean that the graphic is presented as part of the story or narrative experience, or that it's presented in any way where the player is directed to do nothing during a particular moment but view that graphic.

Graphics that constitute the user interface (pretty borders, window frames et al.) are non-primary by my definition. This is where you need to assess what these elements are doing for the player. In turn, you will be able to decide whether a description of them is warranted, and if you think it is, when and how it should be supplied.

As an example, if your multi-window interface is capped by a magnificent crest graphic for decorative and atmospheric purposes, that's probably worth describing. When should you do so? A good opportunity might be once per game session on first presentation. So after a boot, you could present the text description of the crest when the interface first appears, then maybe never again in the same circumstances until the game has actually been closed and rebooted. Alternately, not again until the player has at least exited to a main menu and then returned to the game interface as part of a new or restored game.

The important thing is that text descriptions of non-primary elements that you still deem to be of some importance should not be printed too frequently. Nor should they be printed so infrequently or unpredictably that a player who wants to read them again would have trouble finding them.

Run-of-the-mill window divisions, whether prettified or not, are unlikely to be worth describing, except perhaps as part of an overall description of a very pretty interface. Remember that your user interface is essentially functional. As the author, you took the time to arrange the UI elements to convey important game information in a certain way. For players who don't have full access to the visual UI for some reason, your focus should always be on finding methods of conveying the same important information to them. Some of these methods will be non-analogous ones; that's why describing the aesthetics of the divisions of your interface is unlikely to be valuable in most cases. You're not just replacing the interface verbatim with words. You're redirecting whole streams of information. The end product will still be words, but which words you stream and when and how often must all be determined by the emphases of your game.

How to actually write text descriptions of graphics – an exploratory case study

Leadlight Gamma has about 30 graphics that are primary content. I wrote text descriptions for all of them, an exercise which proved to be fascinating and challenging.

When I initially thought to do it, I looked online for relevant examples of this kind of writing. I thought that there might be particular styles or conventions or rules to follow that other people had already worked out for this sort of thing. There weren't.

I found that The World Wide Web Consortium tried to provide a standard HTML mechanism for supplying text descriptions of online images, but that this mechanism, the longdesc attribute, has barely been used by anyone. It was removed from the HTML5 standard for four years and only reinstated in February of this year, 2015.

For information on longdesc and similar text description mechanisms in HTML, click this line to visit the DIAGRAM Centre.

So the internet had no demonstration material to offer me. The closest thing I could think of was the style of narration used to deliver audio descriptions of movies on DVD. At that point I thought, 'It's time to just have a go at writing these things.'

Thus it turns out that as I blog this info, there is the opportunity for authors to be a bit pioneer-y in the field of writing text descriptions of graphics. There are few precedents. I worked out what I thought was the appropriate way to write my descriptions for Leadlight Gamma by experimentation, and so below I will share the thought processes I followed. Something to keep in mind as you read is that I have a lot of experience as a visual artist, so some of the approaches I bring to bear may not come naturally to people who don't draw or paint. And my text descriptions came out pretty thorough; you may only want or need much simpler text descriptions for graphics in your project. However, if you have no instinct for this kind of thing yourself, it might be worth collaborating with someone else who does.

I began by sitting down with the game's title page in front of me – which I'd drawn myself four years earlier (I have yet to work out whether it helps or hinders to be the author of the image you're trying to describe) – and considered what I thought the picture was saying, how I thought it should be described. That second point quickly led to me asking myself: 'Why do I feel a sense of obligation here? Obliged to do what?'

I realised that I thought it was important to address compositional elements in each picture for the sake of objectivity. A picture has been drawn or framed in a certain way, and has specific content, and that specificity is what I'm trying to get across. So if a sad-looking girl is on the left side of the picture, I will say that she's on the left side of the picture. It's not enough to just say that it's a picture of a sad girl. I got into the habit of trying to describe the position of important elements relative to each other in each picture. Sometimes the composition of an image leads the eye in obvious ways, and this can be used as the cue for the order in which to describe things. At other times, a general macroscopic to microscopic cataloguing approach did the trick. In the case of complex pictures featuring many interrelated elements, I discovered it can be hard to disassemble them all into words using this objective approach.

Obviously descriptions needs to cover more than just what is where. For each image, I described the medium (Photo? Ink illustration? Painting?) the way the medium was being used (If it was a drawing, how was it drawn? Freehand? With a ruler? By crosshatching? Shading?) and in many cases, the orientation (Portrait? Square? Landscape?).

Then there was the human and tonal content. What expressions and attitudes did the characters exhibit? What were they doing? I tried to be careful here to report on what could be seen in the image rather than on what could be projected into it.

Overall I was trying to be both completist in the sense that I would not omit descriptions of anything important from the picture, but also succinct in that I did not want to belabour points. If a whole description became a little laborious to read at times (usually when I was describing where a series of things were in relation to each other) that was okay with me if it meant the picture was accurately described.

In case you were wondering, colours are worth mentioning/describing. There are many webpages on this topic you can Google up, but here's just one of them which I think summarises things rather handily:

Webpage link: Why Describe Color in Video Description?

Finally, here are a couple of images from Leadlight Gamma followed by the descriptions I wrote for them. The first image was drawn by me, the second by Steve Amm.

"A loading splash screen briefly flashes up the name of the publisher, “Heiress”, in a pink-red font. It is replaced by the Leadlight Gamma title page, a high contrast black-and-white ink illustration. The right side of the image shows a beautiful teenaged girl with elaborate jet hair in profile by a window. She has adopted a subdued ballet stance. Her eyes are downcast as if her thoughts are directed inward. Her arms are slightly raised as she stands on the toes of her left foot, her right leg raised behind her. She wears a crushed T-shirt, a tutu and black tights. The venetian blind on the window is raised but askance, and the bright light from outside throws the shadow of the girl’s en pointe leg onto the wooden floor behind her.

The left side of the image is a black panel containing the game’s title text. In the top left corner of the panel, gothic white lettering spells out “Leadlight”, then the word “Gamma” follows beneath it in glowing red. In smaller white lettering, towards the bottom left corner of the panel, is the byline “by Wade Clarke”.

In the bottom right corner of the image is the artist’s signature: “Wade 27/1/2010”."

"Freya’s ballet class sketch is a lead pencil drawing filling a tall, narrow sheet of white paper. The linework is lively and agitated, giving the impression the drawing was executed quickly. There is a lot of white space showing.

The sketch shows eight girls in leotards doing barre work. Half the girls stand on one side of the barre, the other half opposite them on the other side. The girls' legs and arms are extended in unison. Movement lines show the motion of their legs. The barre itself runs from frame right up towards frame left at an angle before ending against the mirrored wall of the dance room. The mirror reflects all eight dancers and gives the illusion that a column of sixteen girls are all working at one long barre as wide as the sketch. The mirror reflection has been drawn sparsely compared to the rest of the image. The girls in the mirror are depicted as quick, simple outlines devoid of detail.

The artist has signed her name, “Freya” in the bottom right corner of the sketch."

Something new, something old, something blue, something blorrowed

The something new is that adventuregamers.com reviewed Leadlight Gamma.

Collectively, the something old, blue and blorrowed is that I've gathered up the first five proper text adventures I made (about 25 years ago), and the design notes I found for three of them, for my site Wade-Memoir. In chronological order they are:

Dungeon Of Death (1988)
Complex (1988)
The Sword Of Evil (1988) (with original notes)
Dark Arts (1990) (with original notes)
Demon's Keep (1990) (with original notes)

The book that got a 13-year-old me from approximating adventure games on the Apple II with a bunch of hectic GOTO statements to building BASIC programs that had real databases of verbs and nouns in them was Usborne's Write your own Adventure Programs for your Microcomputer; you can download a PDF of it from the linked page. The engine for the demo game in that book, Haunted House, became the starting engine for my games. I wrote five games with it, making things a bit better each time.

Today, I don't think Dungeon of Death or Complex are much good. They're just what got me started.

The Sword Of Evil is starting to get decent, though it still has no save/restore features.

Dark Arts and Demon's Keep are sufficiently respectable fantasy games of the two-word parser variety. Though Dark Arts still has too many empty rooms in it.

Today we have a wide variety of sophisticated and flexible systems available to help us make these games. We also have effectively unlimited RAM. While revisiting my old games is of personal interest for me, what I think may be of particular interest to folks who weren't around in that era is the demonstration of the amount of planning required to write games like this back then. The Usborne book told me to plan and list everything on paper before even touching the computer, so that's what I did. Have a look at my design notes for Dark Arts or Demon's Keep to see what I mean.

Demon's Keep was the last adventure I wrote from scratch for the Apple II. After that I switched to using the Eamon system, and went in for more RPG content and fewer puzzles.

Accessibility observations part 4

Today, I talk about the non-alphanumeric spray.

What is the non-alphanumeric spray? This is a phrase I came up with (and which I quite like) to describe one of those moments in a text-based game when the game suddenly prints something like this –

!@#*&!@(!!!!!!!!

– or a row of 80 hyphens, or any other kind of solid run of characters that aren't letters or numbers.

The author might be using a spray for textual effect reasons. For example, to convey comic book or Q*bert-style swearing, or to present the output of a computer going berserk. Or the spray's purpose might be to provide visual formatting, like a row of hyphens used to draw an ascii line across the screen.

Most screen readers have configurable verbosity settings so that the user can control how much punctuation they want to have explicitly read out to them. For instance, at the most explicit level, a row of 80 hyphens would be read out as:

"Hyphen hyphen hyphen hyphen..." (80 repetitions – the user is likely to skip ahead once they get the idea, if they have the capability, but there will be circumstances in which they won't have the capability)

At the opposite end of the verbosity scale, this spray might be abbreviated or omitted altogether.

Like any player testing out what elements of a game's UI are important to them via experimentation, a screen reader user can set the verbosity to a level that gives them as much or little non-alphanumeric information as they need from your game. What is worth thinking about as an author is that (a) there will be circumstances and pieces of software in which users can't configure verbosity, and (b) that you might want to convey alternative information to vision-impaired players during spray moments – and if you do, what will it be?

Again, this is where having a screen reader mode in your game can help. Ask the player if they want this mode on at boot time, and if they do, then you can customise spray stuff throughout your game accordingly. What I did in Leadlight Gamma in this regard was to strip out excess punctuation and any ascii visual formatting. The combat prose in particular is normally full of asterisks, plus signs and hyphens; I suppressed those for screen readers. I also chopped out screen dividing ascii content. In other cases, I actually went the other way, expanding abbreviated questions so that they'd be read out more nicely in English.

The more esoteric the use of your spray, the more creative you might need to be in your alternate solution. To return to the computer going berserk example, maybe you think you would like the player to hear something like 'Exclamation hyphen exclamation open parentheses exclamation...' (times 20) at this particular moment in the game, to convey the berserkness. But remember that if user software verbosity is set to low, such content could effectively disappear. So it's probably wiser to come up with an alternate piece of English prose to convey the berserkness and drop that in instead if the player has turned on screen reader mode.

I think I've got one or two more small episodes to come in this series.

Inform 7: Menus version 3

In 2014 I wrote an updated version of Emily Short's venerable Menus extension. Right after I completed it, the huge upgrade of Inform (6L02) came out and the extension broke.

Kind people posted a supposedly fixed version of my Menus to Github, but it wasn't really fixed – don't use that one, which is version 2. Then the project was in limbo for ages because I didn't want to touch the new Inform until after I'd finished Leadlight Gamma.

Yesterday I finally got around to working out what broke in my extension (indexed text substitutions) and fixed it. So today I present Menus version 3, which is good for 6L38 and should be good for 6L02:

Download the menus_v3.zip from my dropbox

In the zip you will find the files Menus.i7x and Basic Help Menu.i7x

(There is a degree of chaos in the I7 extensions management world at the moment. I just want to say that if you're one of those people helpfully filing stuff in Github or whatever, please feel free to file these appropriately. Thanks.)

Here's the summary of the extension from the docs, then I'll give a bit more detail:

Lets you include a menu system of help, hints and/or other information in your Glulx or Z-Code project. This is an upgrade of Emily Short's Menus extension featuring user-friendly single keypress controls and a more sophisticated UI. It also has configurable options, a book mode with automatic pagination, isolated message content to make translation to other languages easier and a Screen Reader mode. Old Menus format tables can be upgraded for use with this extension with a little work.

So first, there is no more moving a cursor around with arrow keys to choose things. Every option is activated by an automatically assigned keypress.

There is no more of the repeated transcript clutter that used to happen with the original Menus.

You don't have to back out of all menus to get back to the game. You can exit straight to the game with a keypress (your position is bookmarked for your return). You can also jump to the topmost menu at anytime while in the menus.

You can still use the hint-dispensing mode familiar from the original Menus.

You can toggle screen reader compatibility at any time.

The extension no longer relies on the ESC key, so it's compatible with virtual devices which don't offer one.

The extension always shows contextually-sensitive instructions in the status window, or in the main window if you're using a screen reader.

All content is automatically paginated for a book mode (move through all content with left and right arrow keys). You can let the player switch between menu and book mode as they please, or you can force one or the other. In book mode, hints can be gathered at the back of the book, with warnings about their location. Or you can just block them from book mode.

If you're having trouble compiling your menu system, there's a debug mode which shows everything that's happening during the startup scan of your content. The extension can diagnose a few common errors itself.

The 'you can't choose option H' bug from previous versions is gone. (Thanks Hanon Ondricek)

Finally, if you happen to want ye olde Basic Help Menu, I've also made a compatible version of that.

... So if you're in the market for a menus extension for your brand new Inform game, I encourage you to use this one. It's modern, extensively documented and accessibility-friendly.

Also, in the selfish reasons department, I don't want to move a cursor around with arrow keys in your game anymore. Sorry, but in these shiny times, that's too angrifying.

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 intfiction.org 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 intfiction.org' in the hyperlink, rather than just attaching it to, say, the 'intfiction.org' 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 audiogames.net 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.

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.

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.