Accessibility As A Success Story

About Accessibility

Accessibility is one of the biggest buzzwords in the industry right now. People are discussing its importance and which studios are not doing a good job. However, very little information is openly shared with game developers about what they can do to improve the accessibility of their games.

We ran our accessibility project with Stories Of Blossom, made by Softleaf Studios, over two years, ensuring that players' feedback was built into the game's roadmap. This meant we were actively designing for accessibility rather than it being an afterthought.

Our Method

So how do you do accessibility testing? The key is your players, using free and accessible social media channels such as Twitter and discord. By sending out an open google form designed for players to self-indicate their accessibility needs, Softleaf studio got a pulse on anyone willing to participate in testing.

As we reviewed the responses together, we began to categorise players into four different cohorts;

• Those with visual needs

• Those with audio needs

• Those with motor needs

• Those with cognitive needs

We had a great response and found that we now had a pool of willing participants without any cost to us or the studio. So what did we do next? We met again to discuss what we needed to ask our players and, more importantly, what we wanted to learn from them.

We designed four surveys (one for each cohort) to ensure we gathered any feedback that could be unique to one of our cohorts. This was completed on a survey tool which again has a free option. While these surveys were extensive, you can start by asking, "what issues did you encounter today" if you do not feel comfortable with surveys.

Now that we were ready, we were anxious to get feedback and review it. We started by supplying a build and the relevant survey to all selected players, via the Go Testify platform which allowed us to capture verbal feedback alongside their playtest footage.

Findings

As we saw the survey responses and footage roll in, we would meet again when one cohort was complete to review the issues they had raised. We would assess this in two ways, what issues came up most frequently (number of players) and which problems were most severe (levels of frustration/confusion)

When all feedback rolled in, Softleaf and I would discuss, with all the findings we had, what would be a priority both for the players and for the developers roadmap. We would review the challenges, and while I could assess the importance for the players, the developer would determine the difficulty/complexity of the fix. For some issues, we could turn to games praised for being accessible, assess how they have done things, and ask our players if this system/fix works for them before building. Players, a central part of the conversation, would also share with us alongside problems, any ways that they have seen others overcome this issue.

When we had solved a significant challenge, we would redistribute the new build and ask the affected players to assess the fix. Did this fix the problem? Did this cause new issues we had not anticipated? By having players at the centre of our conversations, we could identify quick solutions rather than building complex solutions that our players did not want.

Applied findings;

So, in the end, what did we find? Players were eager to give feedback and be as involved as possible. This meant no cost for the studio and saved them development time as they could have regular conversations with players before work was done.

What changes did we make based on player feedback?

• We could make options that already existed in the game easier to use and understand, which would have otherwise needed to be utilised by visually impaired players. This work would have gone to waste.

• We added context to the design, making it easier for players with Autism to understand subtle story cues and solve puzzles they previously could not solve.

• We were able to build more audio cues that helped players with hearing needs progress who were previously unable to due to a lack of information.

• We identified weaknesses in our text-to-speech that left out vital information for puzzle solving that those who were able to read the text did not experience

• We added a buffer to the selection system that helped players with motor issues prevent misclicking items/decisions/skipping story prompts that were important.

Wins;

What did we take away from this experience?

• 100% of players said that they did not feel in any way disadvantaged and were able to complete the game in the same way that players without any accessibility needs could

Studio Wins

• Stories Of Blossom is the first game on steam to have audio descriptions.

• Stories Of Blossom was featured on "Can I Play That?" a site that showcases highly accessible games.

• The studio gained the attention of Microsoft and now has a working relationship with them, featuring on the XBOX showcase

What Softleaf had to say about their experience

" Running accessibility tests with Go Testify gave us a better understanding of the barriers players were facing in our game.

We could quickly jump to these problem areas, and take note of the improvements needed. It also highlighted the areas players were happy with, and any opinions expressed.

This information, along with the player surveys, were key for the accessibility of Stories of Blossom "

Summary

We created a mutually beneficial relationship by putting players with accessibility needs first and giving them a seat at the table. This resulted in significant success for the studio and allowed players to feel included while taking part in an enjoyable experience that allowed them to say they helped to shape and make a game.

Check out Stories Of Blossom on steam, by following this link