Game accessibilty in special education


Published on

These are the slides for my talk at the Games for Health Game Accessibility Day conference. There are notes attached to the original by the way, so hopefully you can view those for reference.

Updated May 28 with better notes.

1 Like
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • These are the slides from a talk at Games For Health Accessibility Day 2010, Boston MA The total talk time was 15 minutes, but I loaded in a few extra slides and things at the end, in case there was time. The audience was specifically oriented around games and accessibility of a broad spectrum. My talk is specifically about games for the special education space. The ideas are based a lot on my own recent introduction to the special education space via PCI and I think would apply to a broad range of interactive applications. Also, a note. Because I’m from both the education and the game space, and because I think games and education are interesting mirrors of each other, I have a tendency to interchange the word “player” and “student”. “Can the player figure out the game” and “Can the student figure out the lesson” are two ways of saying the same thing.
  • First I want to go over some specifics about the players, the environments they are in, and so forth. Any time you create something for someone, you need to know who your audience is. And for me, the player is someone with special needs. It’s not necessarily the parent, caregiver or teacher – though clearly one has to deliver something that meets their needs too.
  • Let’s start with a list of factors and realities for players. This is your roadmap for what players are dealing with that might be difficult. I personally think it’s better to look at a list of factors like this rather than use specific labels for different conditions. What “disability” means is so broad and comes in so many forms of varying levels, that it can be hard to say “OK this game is for people identified with condition X”. Instead, I think it’s better (and easier) to look at the factors that come into play with an individual. Not every player will obviously be dealing with these different issues. Some players will share a single diagnosis but actually have varying needs. Memory - Understand that the player may have problems with remembering things – short term, medium term and long term. So when you are creating content, think about what that mean to them. Those with memory problems may have problems managing a long (or short!) sequential task if can’t remember the sequence. Consistency is also a big deal here. If it takes someone a long time to figure out something, don’t go change it on them unless you’ve got a really good reason to. Problem Solving - Problems some people think are easy, others may find hard. This might be figuring out an online form, arranging items or any number of things. And what you don’t even realize is a problem to be solved, might be a big deal for someone else. Attention – this can be a really big deal for some people, and it can go both ways. Some people have a short attention span and a hard time staying on task. But at the same time they may pay too much attention to details that aren’t important to the task at hand. So keep the player focused, but not for a long time. Reading, linguistics and verbal comprehension - Basically, the player may not be able to read at all. They may not be able to understand verbal instructions, and they may not be able to talk at all. Or they may absolutely not understand the concept of sarcasm or parody, meaning you may have to be very literal in your written content. Math comprehension - Some people just will have a harder time with math than others. And keep in mind it doesn’t necessarily mean, “Can’t multiply 5 x 6”. It might be “Has a hard time clicking a button three times by just counting it” Visual comprehension – This is another one of those things that can be cognitive or physical. Physically, a player may have problems with their vision ranging from poor vision, difficulty with eye tracking or even full blindness. Or it might be an issue with color blindness for example. The other side for vision is in the cognitive space. For example it might be a big deal here might be making mental ties between things. A player might understand what a stop sign is in a book, but when they see a photograph of a real stop sign, not be able to make the same connection. Physical Disability – Along with the cognitive issues, a player may have physical issues at the same time. It might be limited mobility, lack of fine motor skills, or any number of other issues.
  • These are some prejudices and assumptions that I think can really mess up your ability to create a good game. By “mess up” I mean make a game that doesn’t meet your customer’s needs, or make design decisions that mess up your ability as a developer to actually deliver because you’re unable to solve the problem of “How do I make a game for special education?” Here are a few things I think you should be careful to not assume. First is that the player is somehow “different” (note the quotes). That somehow they are aliens who can hear colors and you’ll need a whole new mental model of humanity to get it. Second is that players don’t know what games are. Don’t think, “Oh well these kids don’t get games at all so we’ll just give them a book to ‘read’ when they push a button. The other kids can be playing games and everyone will be happy.” Next is age – or rather then mixing of mental and physical age. “This poor 18 year old has the mental age of a 3 year old. Hey I bet they’d love to play this game my 3 year old likes then!” Last is the assumption that you have to come up with new design rules. That you have to throw out the proverbial book to create something different because your audience is different.
  • So let’s flip the assumptions around and look at how they are wrong or bad traps to fall into. First is the idea that the player is different. They aren’t different, they are “normal” (whatever that is) with some of those factors we talked about earlier taken out of the statistical norm. We all have problems with memory sometimes, or solving a problem or seeing something. These players just have some of those things taken to a greater level. They aren’t aliens. They are human beings with some interesting variables. Second is that players don’t know what games are. They sure do know what games are. And they sure wish they could play them. And they know when the game you have them play isn’t the same as the game that the ‘normal’ people play. And that is a good segue into the age thing. Yes ok so maybe the player has the mental ability of a three year old. But they aren’t three years old. They are maybe 18. And they know what 18 year olds like or do. And if you give them a game or book or anything else meant for a three year old, they know it. And it’s not very dignified. Last is the assumption that you have to come up with new design rules. Not at all. You can use all the design rules you’ve used normally, just that you have to keep those different variables and factors in mind. It’s just plain good design for example to not make the player memorize complex sequences – unless of course that’s the point of the game. It’s just good design to have a consistent user interface where the “button” graphic is always the same.
  • Let’s talk about how users (players) interact with games. At a really simple level, some players will have to interact with your game with the simplest of interface devices. It might be that they can only use one button – one very big button. That might be because they have physical issues that prevent fine motor control. They *get* that a keyboard has a lot of keys, they just can’t hit them. Or they have a hard time with the complexity of a conventional system and need to have a simple one button controller for everything. Mouse or touch screens. Some players will do fine if you give them a mouse for interaction, or a touch screen or maybe an interactive white board. Again it might be a motor control issue, or it might be a cognitive one. The iPad has some hugely interesting potential here. And like I mentioned earlier in the slide, there might be a problem with fine motor skills that make using a keyboard or mouse impossible. Imagine trying to type using a 10 foot long pole and maybe you get the idea. And last is timing. Players may not have the ability to physically or cognitively react quickly to an event. That means “twitch” games that depend on fast reaction times can be a problem. Give the player extra time to set up their shot or plan their move.
  • So now let’s talk about how the game interacts with the user – how the game (or can’t) communicate with the user. First, the player may not be able to read or may have minimal reading abilities. They may be able to recognize some words, but not necessarily deal with written instructions. That means no text-only instructions or text-based “help screens”. I read once that people with reading difficulties don’t scan a web page like some people do – where you glance quickly over the whole page and zero in on things you’d like to read. Instead they have to plow through the words. They have to read (or try to read) each piece of text to find what they are looking for. Next, because of memory issues, they may have a hard time with long sequential tasks. So you need to think about how you communicate instructions for sequences. Think about how to guide the player through a complex sequence without overburdening them. Consistency is hugely important. It may take the player a long time to figure out the “rules” of the user interface for example, so for goodness sake, don’t go changing the rules on them! Consistency also helps with non-readers or people who rely on visual cues. Lastly, highlight important stuff and mute (or remove) the unimportant stuff. This keeps the player from being distracted, helps them get focused in on the problem to be solved, what needs to be remembered and what needs to get their attention. A player with reading problems may not “scan” a page of text, but instead may “plow” each sentence, picking it out word for word.
  • OK one more thing on the “facts” list. Learning and games are variations on the same thing. You can learn a lot about games by just looking at learning. And of course learn a lot about learning by looking at games. When you start talking about games (and/or learning) you find yourself tossing around words like “mastery” and “assessment” and “measuring achievement” and many others – and the definitions are surprisingly similar. One last thing to put on this slide. If you haven’t read about Universal Design for Learning (UDL), do so. It’s a great set of three principles for designing educational content that work just as well for games as for education. Google “universal design for learning” and you’ll find a lot of good information. Here is one resource  The three principles of UDL are… Principle I. Provide Multiple Means of Representation – give your message to the student/player multiple ways because some people find some ways of getting information easier or harder. Think “verbal versus visual” for example. Principle II. Provide Multiple Means of Action and Expression – give the student/player different ways to interact with you, because different people find different ways of interacting easier or harder. Principle III. Provide Multiple Means of Engagement – give the student/player varying ways to be engaged. Some people might one aspect of a game and that keeps them playing, but others may enjoy a completely different aspect.
  • OK I talked about facts, factors and some of the realities and variables involved. Now it’s time to get into the philosophy of how you should approach your design effort.
  • So here’s a mantra for you to use - design with extreme purpose. I’m saying you should really really mean what you do when you design something. Really focus and target your decisions based on what you know about the player. And you focus your design in an extreme way because the player themselves has extremes, which makes them a challenge to match. And that match is important, because if you don’t match their needs, you fail. You don’t risk a sort of “kinda fail” like you might with a more mainstream game, you risk an “epic” fail. Making a game that requires reading for a non-reader is like making a game in Finnish for the Japanese market. Making a game that requires 4 buttons for a person who uses one is like First point. You do not have to come up with new design rules to succeed. You’re not designing for an alien species, you’re designing for human beings. Take what you know already in the form of design rules, best practices, clean design and so forth, and really really apply them with purpose. And also apply them in a possibly extreme way. You know it’s good to not confuse the player with too many input options, but with the special education player, you may need to go from 20 options to 2 in some case. You know some people think it’s kind of hard to click the mouse on that little “close” button on a window, but some people can’t even use a mouse. You know you need to scaffold gameplay, having the player master simple skills first and complex ones as they advance, but with the special education player you may need to go slow and keep skills simple. So really take what you know and focus it in. And take what you really know what you is true and right and stick to that. Because if you are really delivering for your player, you have become their advocate. You might be able to get away with the “Oh we added in that feature because the publisher liked it” thing, but if you start down that path of adding junk just “because marketing wanted it”, you’re going to not be delivering what the player really needs. Yea, that corporate logo in the corner might be nice PR, but it’s also potentially a huge distraction to some users. And lastly, realize that there are no fallbacks. You can’t say, “Oh the players will figure it out sooner or later” or “Players can’t seem to figure this part out, so we’ll just put in an extra page in the manual.” Beyond another person right there helping out, there is no fallback.
  • Along with designing with extreme purpose, you need to have your number one goal being enabling player mastery. Mastery is making sure they can DO something, and that mastery starts at at possibly a very low level. For example, can they actually interact physically or cognitively with your user interface? You might have the nicest looking “OK” button ever on the screen, but if the user can’t point and click on it somehow, it is worthless. So first, make sure they can master the user input and interaction method. Make sure they know how to use that big switch or touch the screen. Once they’ve mastered the input methods, get them to master the user interface. They know how to click now, but do they know where they should click or why they should click? Do they get your user interface? Make sure they can actually operate your game. Only after they have mastered input and the UI do you really start to care about whether they can master the game itself. It’s pointless to worry about whether they get the idea of hitting a button to make their character walk down a virtual street if they can’t even figure out how to push the button. Or they can’t even PUSH the button even if they understand it. The last kind of mastery is the mastery of frustration. Special Ed players can and will have issues with frustration, and *nobody* likes to be frustrated. Imagine what it’s like when you’re frustrated, and you don’t know why. Or you can’t figure out how to solve the problem of not being frustrated anymore. You just know you’re frustrated. One more point to round this off is that as these levels of mastery build, make sure you don’t break the lower levels. Make sure your solution for game mastery doesn’t break user interface mastery for example.
  • Now some stuff about how you can approach helping the player reach mastery. First, let’s think about learning from failure. You learn by failure by having something not be right, remembering that fact, and then thinking next time “OK I won’t do that again”. Great idea, unless the player has memory problems and can’t remember that they failed before, or why. If you try and use learning by failure, you very well may just have the player continually beating their head against the wall and not being able to figure out why. One way to deal with failure is to allow for it in a graceful which leads to the correct answer. You can do this by allowing the player to retry a problem with incorrect choices removed until they get it right. Essentially give them a set of choices, of which some are wrong and some are right. If they choose a wrong choice, then remove it from the list of available choices, and present them with the problem again. If you keep doing this, they will ultimately get to the right answer. It may not be mastery if they don’t get it right the first time, but if you allow them to repeat it enough, they hopefully will learn mastery Remember this isn’t an “everybody wins!” approach – not at all. It’s going back to that notion that learning from failure isn’t necessarily a realistic approach. Repetition is another way to allow for mastery. Lots and lots of repetition. During some learning exercises for example, the student might have to repeat a task a hundred times before they gain mastery. And that’s ok. And the student may not mind at all, or even realize there is all that repetition. But keep in mind this is not mindless repetition -- this is repetition that ultimately leads to mastery. It’s repetition that eventually leads to them choosing the right answer the first time with a greater frequency. And lastly, sometimes you have to declare victory where you can. Some players may simply be happy and content having mastered the input methods or the user interface. So declare victory and be happy the player has mastered your game at some level. If they are happy and having fun, who’s to say it’s wrong? Of course if you have specific educational goals in mind, then you obviously have a problem.
  • You really really have to think about patience with players. You, your game, and the player must be patient. They may not master a concept in a minute, an hour, a day, or even a week. They may have to do a task hundreds of times to gain mastery, so you need to make sure your game allows for this. At the same time, be patient if emergent gameplay occurs. If players end up doing things you just never thought about, but seem to enjoy the activity and it involves mastery and not mindless activity, then let it happen! And don’t get frustrated by the student if they can’t figure something out. If you ever catch yourself thinking, “Why can’t they just figure it out!” then you need to take a break :)
  • OK, here is the summary slide. Use what you know already – you do not have to invent new design approaches, but instead just use the ideas you already have. Then take everything you know and magnify it by many orders of magnitude. That’s because the player is living in a world of extremes with some part of their life, and you need to match that. And make sure you are enabling mastery. If all you do is “dumb down” your game thinking that’s going to do the trick, you have failed. You don’t master mindless activities. And really, you and your software and your design has to be patient.
  • Wait there was another nut in the nutshell bowl!
  • It would be great if players of all kins could play together and have the same experience. I don’t mean “OK you play the special ed verison I’ll play the regular one” but more like “Let’s play that game we both like and can play.” And for goodness sake, someone come up with cheaper controllers! The cost of setting up just one big button switch that emulates hitting the enter key can cost $150, which is ridiculous! And really, stop making dumb games. Stop thinking “Oh let’s just take our regular content and dumb it down” or “let’s just take that thing that kindergarteners love and call it special ed” And of course, start making good games.
  • Game accessibilty in special education

    1. 1. “ It is simplicity that is difficult to make.” - Bertholdt Brecht
    2. 3. Player Factors and Reality <ul><li>Memory </li></ul><ul><li>Problem Solving </li></ul><ul><li>Attention Span </li></ul><ul><li>Reading, linguistics and verbal comprehension </li></ul><ul><li>Math comprehension </li></ul><ul><li>Visual comprehension </li></ul><ul><li>Physical disability </li></ul>
    3. 4. Some Bad Assumptions <ul><li>The player is “different” </li></ul><ul><li>Players don’t know what games are </li></ul><ul><li>“It’s a 3 year old in the body of a teenager” </li></ul><ul><li>You need to come up with new design rules </li></ul>
    4. 5. Some Good Assumptions <ul><li>The player is “normal”, with some factors very magnified </li></ul><ul><li>The player knows what games are </li></ul><ul><li>The player knows their age, so treat them with respect and dignity </li></ul><ul><li>Common sense design rules are fine </li></ul>
    5. 6. User Input Realities <ul><li>Some people use single switch input </li></ul><ul><li>Some can use the mouse or maybe a touch screen </li></ul><ul><li>Some have no fine motor skills </li></ul><ul><li>“Twitch” games are out because timing is an issue </li></ul>
    6. 7. Game Output Realities <ul><li>No reading </li></ul><ul><li>No complex or sequential tasks </li></ul><ul><li>Consistency in all things </li></ul><ul><li>Highlight important things, mute the unimportant </li></ul>
    7. 8. Learning is Games is Learning <ul><li>You can learn a lot about games by looking at learning (and vice versa) </li></ul><ul><li>Mastery, assessment, engagement, and lots of other concepts are shared </li></ul><ul><li>Read up on Universal Design for Learning (UDL) </li></ul>
    8. 10. Design with Extreme Purpose <ul><li>You don’t need to come up with new design rules </li></ul><ul><li>Take what you know to work to extremes </li></ul><ul><li>Really do what you know to be true </li></ul><ul><li>There is no fallback </li></ul>
    9. 11. Enable Player Mastery <ul><li>Mastery of the user interaction methods </li></ul><ul><li>Mastery of the user interface </li></ul><ul><li>Mastery of the game </li></ul><ul><li>Mastery of frustration </li></ul>
    10. 12. Approaches to Mastery <ul><li>Learning from failure doesn’t work – consider a zero-failure approach </li></ul><ul><li>Repeat, repeat, repeat and then repeat again </li></ul><ul><li>Teach UI mastery first, game second </li></ul><ul><li>Sometimes mastering the UI is the game itself </li></ul>
    11. 13. Patience is Golden <ul><li>The player won’t master the game overnight </li></ul><ul><li>Allow for lots and lots of repetition for gaining mastery </li></ul><ul><li>Watch for emergent gameplay </li></ul><ul><li>Don’t be frustrated by the student </li></ul>
    12. 14. In a Nutshell <ul><li>Take all you know and can learn about games, UI, user interaction and human nature </li></ul><ul><li>Magnify it by many orders of magnitude </li></ul><ul><li>Aim to enable mastery </li></ul><ul><li>Work from the standpoint of patience </li></ul>
    13. 16. Some Game Challenges <ul><li>Create cooperative experiences for all players of all abilities </li></ul><ul><li>Come up with affordable controllers </li></ul><ul><li>Stop making dumb games </li></ul><ul><li>Start making good games </li></ul>