In real life, one of my research interests is in the accessibility of software. It’s an issue that I believe is important not just morally but pragmatically. I want software to be more usable not just because it makes it available to more people, but because software that is accessible for those with disabilities is correspondingly more accessible to me. In one of my papers for the Computer Games Journal I make the point that we shouldn’t think of accessibility as something that only certain people need. We can all benefit from accessibility options at different times in our lives. One of the professors I worked with at the University of Dundee made the point that ‘extraordinary users are the same as ordinary users in extraordinary circumstances’. By this he meant ‘special needs’ are often dependent on the context. Someone trying to access an app on a juddering bus has as much need for accessibility support as someone with a degenerative nerve disorder. The only difference is in how long they need it.
One of the ways in which that is most applicable to me is in subtitles for games. See, the thing is – I usually don’t have the sound on when I’m playing a game. Often I play games late at night and I don’t want to wake Mrs Drakkos in the other room. Even when I play games during the day, I’m usually watching a movie or such on another screen. Subtitles, whilst often seen as purely an accessibility aid for the deaf, are by far my favourite way of experiencing game audio.
I digress a little here, but I’m coming around to my main point – accessibility is important, and we shouldn’t think that it’s something we do for ‘special users’. We do it for everyone.
With that in mind, it’s a little embarrassing when I think on Epitaph because we haven’t made much of an attempt to leverage the tremendous accessibility of text. It’s always been something that we’ll ‘make a proper push on later’. There’s been so much to do, and since we don’t have many players at all at the moment, it’s not high priority. Today though, I wrote a new quest and realised half way through that I was, once again, adding something blind-inaccessible to the game. The quest involves viewing a grid and making decisions based on that grid arrangement. There’s no way to render that in text whilst also making the information tractable. So, I resolved to spend a bit of time thinking about it and try to come up with a solution to not just that specific example, but to all the quests where grids are used to represent game state. We have quite a few of them.
I’m not one of those MUD developers who believes there is some kind of sacrosanct purity of the form that must be protected. For me, text is my medium because I think it’s more effective for what I want to do. The complexity of Epitaph, regardless of what programming abilities I may have, would be outside my scope as an indie game developer if I had to worry about how all these complex interactions would be represented graphically. That aside though, I think you can convey menace and subtleties of horror more effectively in the written word than you can graphically. As long as that basic element is not compromised, I’m prepared to push the boat out in terms of how the MUD actually presents itself.
Modern MUDs have access to a wide variety of supporting protocols. Epitaph supports a number of them. We support the Mud Sound Protocol (although we don’t use it much yet), the Mud Client Compression Protocol (which has a big impact on bandwidth, although we don’t actually *need* it given the generous allowances of our hosting), and the Mud eXtension Protocol (which we use all over the place). There are plenty of other protocols which we don’t support as of yet, because we haven’t had a role for them.
All of these make a big difference in creating an accessible game. MXP limits the amount of typing people have to do (thus, making gameplay available to those with mobility issues). MSP can be used to create audio cues for emergent events, allowing us to limit what we need to present textually. It strikes me that within these protocols lies at least part of the answer to creating an accessible game. However, they may require some forcing into moulds that they weren’t designed to fill. The problem of grid based output seems like it could potentially be solved with sound mouse overs – there are examples of these kind of games already in the wild. There are ‘audio bejewelled’ games. There are audio minesweeper games. Coincidentally, these kinds of games serve as the core of a number of our quests. Unfortunately, I don’t think any of the MUD client protocols actually support these kind of audio mouse overs, but in service of accessibility I’m certainly prepared to roll up my sleeves and do what I can to make it happen.
I haven’t yet investigated into the feasibility of this, but certainly after spending a lot of time thinking about it over the years I think it’s workable. The only other solution I’ve come up with is ‘don’t add those kind of things to the game’, but that seems like a cop-out. We shouldn’t give up on adding fun elements just because they’ll be hard to make accessible. Instead, we should be willing to spend the time and effort working out how we *can* make them accessible, and then we should spend the time and effort *making* them accessible.
We have a few blind people who log on occasionally – if any of them are reading this blog, I’m especially interested to know what we could be doing better. To get the ball rolling on it, I want to list some of the current ‘high profile’ accessibility things I want to get up and running, ideally before we release Epitaph 1.0. All of these would be optional, and available to any player. Remember, accessible interfaces are good for everyone.
- Custom ordering of room description elements, so that you can be informed of pressing danger at the top rather than after the descriptions.
- Audio prompts for in-game information. When a gun goes off in the game, you’ll hear it.
- A ‘screen reader on’ command that automatically switches off some of our ASCII garnish like in game maps.
- A removal of ‘discriminatory’ text in the game, such as telling people they can’t do certain things because they’re blind.
We’ve already incorporated a number of accessibility features over the years. Landmarks are available within substantial regions (like Dunglen) that allow people to navigate without having to consult a map. We’ve cut down on irrelevant text by allowing people to ‘earmuff’ an awful lot of the in game descriptions. We’ve made it much easier for people to ‘block out’ gobbledygook such as when someone is speaking a language you don’t know. We’ve added some options that allow you to make certain kinds of text output easier to deal with – turning side by side columns of text into lists, for example.
We’ve also made a conscious effort to avoiding adding in *some* inaccessible elements. We don’t have any ASCII art for example – while I would have liked it for the login screen, it’s painful for those using a screen reader. It’s possible to have two different ports people can connect on and treat one of those as the ‘accessible’ port, but I hate that idea. Stigmatization is already one of the big reasons why people turn away making use of support that is available, and I’m certainly not going to segregate MUD players based on which gate through which they chose to enter the game. Plus, it misses out on the whole ‘accessible interfaces are for everyone’ principle that is at the core of my thoughts on this.
We’ve done quite a lot, but I’m always conscious of the fact that we *can* be doing more and that we *should* be doing more. I’m also conscious of the fact that we should be doing more very early on so that people who log in are aware ‘we take accessibility seriously’. We don’t do that yet – ASCII maps are on by default for example, and the syntax to switch them off isn’t ‘newbie friendly’. The important thing is that all of those rough edges are going to be smoothed away as we edge towards release. Hell, the release date I put out there already looks much closer this side of Christmas – as we *race* towards release.
Accessibility may be my ‘real world area’, but it’s one thing to know about the problem academically, it’s another entirely to be able to appreciate when things *are* inaccessible. I know accessibility isn’t an issue that is taken very seriously by a lot of people. It’s taken seriously by me. I would be grateful in the extreme if people could highlight areas when we’re causing problems and giving us their thoughts on what adjustments they would like us to make.
 http://tcjg.weebly.com/uploads/9/3/8/5/9385844/whitsun2012_m_heron.pdf – I have a second paper accepted for there, specifically on the topic of text based games. The one here though is on accessibility in games.
 For that is what I am.
 A graphical client is somewhere in Epitaph’s future, for example.
 Limiting text clutter means that the game can be more accessible for the blind.
 As in, we may require a dedicated Epitaph MUD client at some point to fully support our ambitions.
 Seriously, some of the assumptions made about blindness in the code we have inherited from DW is straight out offensive. ‘You’re blind! You can’t count your money!’ is one example, but there are others.
 Where we’ve added those things that are fundamentally inaccessible, like the quests indicated above, it’s because we want that thing in the game because it’s fun. But it’s never added without thinking ‘we’re going to need to look at that later’
 In this context, I mean ‘things that you can’t make accessible with text alone’.