Re: Discussing Blind Accessibility Specifications
Eventually this should be its own repo, but for now, it can dovetail on another project.
I have broken down Audio Game interfaces in my master's thesis.
What it comes down to though, is following established user experience heuristics, such as Jakob Nielsen's 10 heuristics.
We just need to give ideas on how each area relates to games and what is normally done. Each of these areas should be debated and commented on. Here is my initial set of thoughts:
Visibility of system status
In audio games, there are several system status messages that should be conveyed:
1. Is the game running. This can be done through music or environmental sounds, such as the guards shouting outside the safezone in Swamp.
2. When the user first logs in, there should be some recognition that something happened. This is done through a status message, such as the message in Swamp or Survive the Wild.
3. When the user is moving, there should be some kind of feedback. This is often done through footstep sounds, such as in Swamp, or engine sounds, such as in Cyclepath.
4. Barriers. There needs to be something that tells the user they can't go in a direction. Adventure at C does this very well by repeatedly making a sound when the user hits a wall. The problem with Adventure at C, is that new users may not understand that the knocking sound is actually hitting a wall and not a footstep (I showed adventure at C in a workshop and someone spent 5 minutes running into the first wall in the tutorial level). Swamp makes one hit sound, and the footsteps stop. People who don't know they should be hearing footsteps don't realize they can't move, they just think the game is broken. So I have used a "uh" sound coupled with another sound and every person I have shown the interface to seems to get that is a hit sound, especially if they are told once that is a hit sound.
5. Pressing keys, such as "h", to hear your health and "g" to get items on the ground. Messages are read through the text to speech.
Match between system and the real world
Sounds should be as close to the real-world as possible. Mario is a famous example where the sounds were too abstract for people to understand without playing the game. Yes, the themes were very distinct, but it did not make sense without playing the game. In A Hero's Call, there is the sound of water when you get near water, there are the sounds of fires if there is a camp fire. They use auditory Icons (sounds that are of real objects) to represent a data point, like a camp fire, in the game world. Sounds that are just beeps and buzzes are OK, but they take a while to understand. A good example is the navigation system in A Hero's Call. Doors have a particular sound that take a little while to understand, but it is very unobtrusive, not like the doors in Manamon, that sound like doors, but I don't want to stand by a door and listen to it for more than a couple minutes.
User control and freedom
Menus and dialogues should not be super hard to exit out of. Menus have existing conventions, such as up and down arrow keys to move through items, enter to select an item, and escape to go back in the menu. Dialogues need a way for you to repeat the message, go forward through the messages, and preferably go back through the messages (escape is also used to close messages). The game itself has a menu where you can save, load a game, pause, and that is gotten to by pressing escape.
Also, for speech, I have found that players prefer to use their own screen reader most of the time, rather than the system voices. There should always be a self-voicing feature, but screen reader access should be an option.
Consistency and standards
The second chapter of my thesis and this ICAD paper talk all about conventions within audio games and each interface type. For tree interfaces (or menus), up and down arrow is used to move through items (except in some games that use left and right arrows), escape exits out of the menu or goes back, enter selects an item, there is often first-letter navigation, page up and page down jump by 5-10 items, and home and end jump to the top and bottom of the menu. There is also something (either a voice saying "top of menu" or a sound that plays, and the top item repeated, so you know you're at the top or bottom of the menu.
Each interface has its own conventions, and these should be followed.
Error prevention
Many developers think that hitting a wall in an audio game is an error, and this is not necessarily the case. Games like Entombed and Swamp, make wall hitting part of the experience. A Hero's Call and Manamon do a great job in warning users before they hit a wall, that there is a wall coming up.
For lava, or something of that nature that users should not step on, there is a warning of generally two steps that means "danger". Adventure at C and the Gate do this very well.
Also, important messages should not go away in a button masher if you press a button. Enter and space generally mean "accept, but if someone is pressing space to fire a gun, space to accept a message while they're firing is not a good idea.
Recognition rather than recall
Part of this is using iconic sounds of the environment rather than symbolic earcons (beeps and buzzes) for entities in the world, but also, instructions should be present at the end of the important information. For example, if there is a dialogue, the system should say the dialogue, then after the important information is done, a message like "Enter to continue, r to repeat" should be said.
Flexibility and efficiency of use
Menus should give you access to almost everything. Tactical Battle is an excellent example of this principal. You only need to know to press enter and arrow keys to play the game. Everything can be retrieved through the menus. If there is a key shortcut, it should be placed at the end of the menu item. "Attack, A". The readme should have a key commands section as well, and there should be a keymap, like Swamp has, where users can change key commands if they wish.
Tutorials and cut scenes should be skippable when you press enter.
Aesthetic and minimalist design
When users press "h" for health information, it is better to say "55 health remaining", not "You have 55 points of health remaining". This keeps the important information at the front so users can interrupt the message once they have the "55", if they know that is the important part. Also, don't have so many key commands to start playing. Tactical Battle is great with minimal key commands, and Survive the Wild takes a while to learn what you need to take a drink.
Help users recognize, diagnose, and recover from errors
If the user is doing something that they should not be doing at that time, let them know that is a feature, but they should be doing X instead. Also, if users do the wrong command, like trying to drink a rock, the message should indicate what kinds of things you can drink from: "Drinking that would be difficult. Perhaps water would be better." Or if you need a cup to drink from a fountain,: "Drinking from that would be unsanitary. I should find something to put the water in first."
Help and documentation
Unlike most mainstream games, many Audio Game players expect a readme. This should be included in any game, but there should also be in-game help messages and an in-game tutorial to help users get familiar with the game. If users are doing something wrong, like repeatedly hitting a wall more than 10 times in 5 seconds, then it would be helpful if a message said "You're hitting a wall, it, you should probably go the other way or figure out how to get past the wall".
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
