As part of our ongoing efforts to highlight the intersection of game-based learning and equity, we’re sitting down with Game Designer Colin Skinner for a chat about his recent work bringing new accessibility features to our recent iCivics game releases:
Today’s discussion is all about accessibility – as an educational game designer, how do you define the term? And why is it important that learning games are designed with player accessibility in mind?
As an educational game designer, I do my best to create experiences that have value―ones that reward engaged players with new knowledge, skills, or perspectives. But it’s not enough to design value into a game―we also want to make it easy for players to get the value out. That’s accessibility: the extent to which all people can access the value inherent in your product.
Emphasis on all people! As you alluded to above, an important part of accessibility is equity. When we make an iCivics game, we want it to be played by as many middle and high schoolers across the country as possible. That’s a diverse group of students with a wide range of backgrounds and capabilities. Our goal is to acknowledge those differences and design for them so that the opportunity to derive value from the game is extended to as many people as possible.
In recent years, you’ve played a major role in the development of a ton of new games for our partners at iCivics – can you tell us about some of the accessibility features introduced in these games?
Certainly! So one way to think about accessibility is to consider what barriers might stand in the way of someone deriving value. To start with an obvious example, as a highly visual medium, video games are often difficult or impossible to play for people who are blind or cannot see well. But this problem is more tractable than it may appear. The new version of Cast Your Vote includes a screen reader setting which provides audio descriptions of onscreen elements. With this enabled, it’s possible to navigate the game even if you can’t see it! (Possible being the key word here―I won’t say it’s easy. But sometimes accessibility is hard, and progress is progress.)
Game controls can also present barriers. Some people may not have the specific motor skills required to manipulate a mouse cursor, but have no problem pressing buttons on a keyboard. Cast Your Vote’s screen reader setting also enables keyboard controls, which make the game playable without using a mouse. Besides, many people find touchscreen devices to be more intuitive and comfortable than a mouse and keyboard. That’s one reason why iCivics has made it a point to release all their new games on iPad and Android tablets as well as on their website. Speaking of devices, releasing on multiple platforms is always a boon for accessibility. It’s all about meeting your users where they are.
Another potential barrier is the ability to read and understand English. There are millions of students in the U.S. today whose native language is not English, yet who must navigate an English-speaking school environment (source). What can we do to keep our game from being yet another reminder to these students that English isn’t their strong suit? For starters, we can translate it into Spanish, and let players switch between languages at any point in the game. (Spanish is by far the most common home language among English language learners.) Adding voiceover narration—and making it repeatable on demand—will help students whose conversational English skills are stronger than their reading. Finally, if our game includes any big words, we can provide definitions on demand. Features like these can transform a would-be frustrating experience into one that helps build critical language skills (in addition to content knowledge).
Reading ability or comprehension can be barriers even for native English speakers. Now, this is a tough one, because sometimes reading is an integral part of the core competency we are trying to teach. Take Newsfeed Defenders, a game about online fact-checking, or Cast Your Vote, a game about being an informed voter. If we are to model these skills in an authentic way, reading must be part of the experience. However, there are simple steps we can take to reduce the amount of reading involved. For example, don’t write four sentences where two will do. Or include a feature that highlights key words to facilitate skimming.
The most successful iCivics games tend to involve not only reading comprehension, but critical thinking, or “connecting the dots.” These games often employ a design pattern known internally as the decision support tool. The implementation varies from game to game, but the design intent is the same. These features target a critical gameplay decision and illustrate how the problem becomes more manageable when it is broken down into a series of smaller logical steps. Once students learn this thought process, they can practice it themselves and the tool becomes obsolete. The remastered versions of Court Quest and Argument Wars both have really nice implementations of this.
There’s one last type of accessibility barrier I’d like to discuss, and that’s what I call the engagement barrier. Suppose we’ve successfully knocked down all the barriers discussed above, but we discover in playtesting that players aren’t engaged. They’re not playing long enough or intentionally enough to get to the chewy value center of the Tootsie Pop that is our game. How to create engagement is a (the?) central problem in game design, so definitely a question for another day. Suffice to say, lack of engagement can prevent your audience from deriving value from your game just as surely as poor UX or inaccessible controls. Sometimes the lack of engagement is the thing you need to fix in order to boost your game’s accessibility.
What is your approach when tasked with introducing new accessibility features in our games? Is your design work heavily influenced by research? Or perhaps by other educational or commercial games?
Yes and yes! When designing for accessibility, I’m often designing for player profiles that don’t match my own, or use cases I may not be familiar with. Therefore, I can’t just rely on my intuition, and research is an essential part of the process. Sometimes I just want to know how much color contrast is recommended for colorblind users, for example. Or the interface used by a popular Unity accessibility plugin. On the other end of the spectrum, if I am working on a digital therapy game designed to treat a particular medical condition, I might set aside a couple of days to learn everything I can about the population I am serving and the special challenges they face.
I definitely turn to other games for inspiration and guidance, especially when faced with a tough design problem (accessibility-related or otherwise). I mentioned decision support tools earlier―the original incarnation of that feature was something Luke Jayapalan designed for the game Do I Have a Right? called the Legal Eagle. That feature was the inspiration for the compass in Immigration Nation, the profile analyzer in Cast Your Vote, and especially the Ask Ana feature in Court Quest and the Think About Card option in Argument Wars. It’s interesting to consider the different “shapes” of each game design and how each game’s shape ultimately informed the shape of its decision support tool.
Another quick anecdote about leaning on other games: the design of the new Court Quest was actually inspired by the board game Tokaido! The thing that drew me to Tokaido was the deceptively simple nature of the decision of which stop to visit next. Court Quest is kind of like a solitaire version of Tokaido where you control all the characters. The structure works quite well, even if the decisions aren’t as nuanced.
Clearly, game designers like yourself are a major force in making these accessibility features a reality – but were there other key players from iCivics/Filament who played a hand in bringing these features to life?
Absolutely. Our friends at iCivics were the driving force behind most of the accessibility features I mentioned previously―particularly the Spanish translation, voiceover, glossary, decision support tools, and several others I didn’t mention. There is a nice press release on iCivics.org that summarizes the changes and improvements from their perspective. iCivics’ commitment to accessibility is not only impressive, it’s also critical to their founding mission.
Specifically, Carrie Ray-Hill worked with other iCivics stakeholders to produce a spreadsheet detailing which games would get which features, and we all worked together to make it happen. Kristen Chapron at iCivics spearheaded the Spanish localization efforts, often working closely with an Argentinian company called RoundTable Studio.
iCivics’ distribution partner BrainPOP was the catalyst for the experimental features we piloted on Cast Your Vote, including the screen reader and keyboard controls. On Filament’s side, we have Alex Yaeger, Nick Curto, and Georgia Adkins to thank for making those a reality. I did very little there.
What were some of the biggest accessibility challenges the team faced during development of these games?
The biggest accessibility-related challenges were without a doubt the screen reader and keyboard control features for Cast Your Vote. None of us had prior experience developing features like that, so a lot of new ground was broken as the team figured out which text-to-speech technologies and plugins to use, implemented the features, and tested them using different screen reader programs. Fortunately, we were able to avoid having to code the features from scratch thanks to the UI Accessibility Plugin. But naturally the plugin didn’t work quite the way we needed it to out of the box, and Alex Yaeger ultimately had to fine-tune the behavior of each screen―and Cast Your Vote has a lot of screens.
When playtesting these games with middle school students, did you and the team gain any accessibility insights that you otherwise might have missed? And if so, how did these experiences influence your later development efforts?
I can share a couple of stories from playtesting Race to Ratify, an alternate-history game about the ratification of the U.S. Constitution. The game has a lot of click-and-drag interactions. In fact, most of the game involves dragging pawns and tokens around the screen.
When we first playtested Ratify in the classroom, we gave half of the students iPads, while the other half used Chromebooks. The Chromebook folks expressed their dislike for the dragging interactions, while the iPad folks didn’t mind at all. In retrospect, this made perfect sense to me as a longtime Chromebook user: all that coordinated mousing on a trackpad can be tiring. But it’s not something I would have considered if it weren’t for the playtest.
When we got back to the studio, we made it so that you can click on another character to make your pawn fly over to them. I subsequently found myself doing this a lot, even when using a mouse. This is a great example of how solving an accessibility problem can make the game better for everyone.
Repeated playtesting also allowed us to properly balance the difficulty of the game and the amount of strategy needed to win. One of my favorite things about Ratify is that it rewards strategic play while still remaining accessible to more “casual” players with non-strategic (but equally valid) playstyles. Asking playtesters to submit their game scores gave us the data we needed to continuously tune the game’s difficulty parameters throughout development.
Any advice for fellow educational game designers who wish to add similar accessibility features to their games?
I suppose I’ll answer this question by recapping some of the accessibility lessons I’ve learned from working on iCivics games. Here are the main takeaways!
- Accessibility is the extent to which all people can derive value from your game.
- Seek to understand and empathize with the users of your accessibility features so you can better meet their needs.
- Design features that provide extra support to those who need it, without degrading the experience of those who don’t.
- Lack of engagement can hurt your game’s accessibility.
- Playtest early and often.
- Accessibility features often benefit people other than who they were intended for, in ways you didn’t anticipate.
More educational game design resources from the Filament Games team:
Making Great Learning Games – Part I: Defining Learning Objectives
Designing Educational Games for International Audiences
Assistive Technology and Game-Based Learning