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

Saturday, 13 June 2015

Something new, something old, something blue, something blorrowed

The something new is that 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.

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, 6 June 2015

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