Showing posts with label accessibility. Show all posts
Showing posts with label accessibility. Show all posts

Sunday, 21 June 2015

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.


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:


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

Tuesday, 9 June 2015

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.

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

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