Accessibility Design #1


I’d say that the accessibility state in The Sequence right now is still pretty incomplete, because I’m currently developing so much so quickly, but also because of a lack of testing this early in the project. I’m trying to wrap up the completeness of the features of the main engine while cleaning out the UI and making everything more easy to use.

UI is actually the first stop for accessibility. If your UI sucks for most players, its going to suck even worse for disabled players. That’s the bottom line. So many developers don’t understand how important UI is and take it for granted - UI is so powerful that it allows the shoddy work of Microsoft to continue to dominate in personal/office end user desktop interfaces.

Spyro 1 screenshot vs spyro reignited screenshot

Why is general UI important for accessibility? Lets compare Spyro 1 with Spyro Reignited. Notice here, for example, how in Spyro Reignited, there is a lot of blur, a lot of visual noise with all the grass effects. Also see how there is little contrast in important UI elements (the outline for the text is very narrow, spyro is lit in a way that makes him blend in with the background, the enemies and sheep are almost impossible to make out without a quicker glance). The art design is not contrasting enough for me to easily make out various parts of the level.

After playing for just a few hours on and off through a day, the game gave me such an intense migraine I almost threw up and had to lay down all day. This is what invisible inaccessibility in gaming is like and will never be solved with just a set of standards or guides - but rather a material understanding of the end user. However, I can play Spyro 1 with no problem. Why? Because Spyro 1 has clearly defined UI elements that don’t overwork my brain and cause my vision to have problems.

The second thing I wanted to point out is a commonly given piece of advice that says that you should plan for accessibility from the very beginning of a project. While I do think its important to consider accessibility from the very beginning of a project, it’s also important to remember that we as developers are really limited in what we can actually project.

For example, my first major game was Braillemon, which was a Pokemon game for blind/visually impaired people. It was pretty buggy and poorly written, but I learned a lot from interacting with the use cases to really focus on what the end users were trying to look for. So I tried to conceive models for what would help bridge the difference between blind users and sighted users. But I had a troubling epiphany - every end user is different and the needs of my testers will always be different than my players, because everyone interacts with software differently.

What does this mean? The end user can never be taken out of the situation. It doesn’t matter how many standards you have followed, how many check boxes you ticked, if your end users can’t reliably and efficiently use your software, you failed. If an edge case in a video game where a character only has a small chance to walk through a wall, destroying a save file, can be considered a “game breaking bug”, why can’t these minor issues that make the game unplayable for some players?

I propose we stop looking at accessibility through the lens of an abstracted concept of “disability” or “standards” and rather focus on the deeply material nature of what we’re working with here - machines. Imagine a mechanic who insists your car is working fine because it meets all the basic check ups - even if it can’t run at all! This is the world for accessibility, and disabled people are left with cars that can barely run with mechanics that say they’re fine. Software and video games are fundamentally interacting machines, recording devices for our inputs.

Two examples that I missed during my planning stage - deaf and colorblind accessibility! While testing my game with my friend, he pointed out he had minor color blindness that made telling the “set” item in the bag was really hard to tell because I just changed the color from white to yellow. By adding a symbol I made it clear, and he said this simple change really improved his experience because he didn’t have to try to force himself to see the color.

Adding a star onto an item list to indicate a set item

Another example - using sound effects to indicate when you can’t use certain things. You need to make sure you couple every sound effect with a visual cue somehow or poor deaf players are gonna be lost in the wake! So modifying it for my next update to be text both had the benefit of explaining to users what was going on, and making deaf players aware there was even a problem.

Perhaps when designing your game with accessibility in mind, you should be thinking less of following standards and more of making your UIs capable of dealing with changes, moddability and optional settings.

When designing my interfaces I focus on these:

  • Moddability (some level of control of the player to modify files/options to customize UIs)
  • Multiple Modes of Input/Output (allowing you to experience and interact with the game differently)
  • Emphasis on User Testing/Interaction (Try setting up a discord server with your friends to get started! This can help you weed out basic UI issues even if you have no experience with accessibility!)
  • Options, Options Options! The more options you have, the more the player can customize their experience. For example I have strong migraines that make a lot of games hard for me to play, but being able to turn off effects in my game when I need to is a lifesaver for me testing.
  • CONTRAST. Not just visual contrast, but rather the differentiation between elements of your UI. Its important that this also applies to blind players because often times (and ive made this mistake before) you can turn a game into a stream of noise if you’re not careful. Think too of how the star graphic increases contrast for color-blind players, versus having color. Contrast is subjective and caused by what we materially can experience through our bodies.
  • On that note - REDUCE NOISE. Something that makes it almost impossible for me to play modern games is how much detail many devs insist in putting in their textures, designs to look “photo realistic”. Not only does it look poor without proper art direction, but the detail makes your game unplayable for me!

I always try to avoid these tips though:

  • Anything involving completing a task instantly. This reduces a game experience for disabled players by removing core components of the game. Should only be implemented as a last resort (or just admit your game isn’t fully accessible, there is a labor component here too and resources ARE limited for many devs)
  • Anything involving mental health. Predicting the ability of physically disabled people is already problematic enough considering the incredible diversity of, for example, motor disabilities. Mental health is highly personal and complex and making assumptions about the capabilities of a player here can be read as extremely condescending. Instead, focus on giving as many options as possible and dissociate things like content warnings from disability, normalizing them with general use (after all many people could benefit from them who are not diagnosed with an illness).
  • Do not assume disabled people do not have reference to cultural references that you do. It’s true that a few guides suggest this and admittedly at first it seemed a bit intuitive to me as an audio-game dev but as many people have correctly pointed out this is completely false. Just describe these things as an alternative for people who don’t understand - this can benefit people who play the game who aren’t familiar with your culture, either!

Also, remember a few things about accessibility:

  • Accessibility is part of the UI system. Good accessibility = better UI.
  • Accessibility tools can be used by players in ways you never anticipated.
  • Do not think in archetypes, think in material conditions. Put a blindfold on your head. Play the game without sound.
  • You are privileged in understanding how your UI works.
  • End user collaboration is essential to making your UIs effective.

Essentially, do not ASSUME anything about the mental state of your players! What, are you telling me you’re a mind reader? Instead, give them the resources to figure it out themselves. The more resources they have, the better chance they can do it, but it doesn’t remove the challenge or talk down to players. Its true that some players will still be unable to complete the game, but at least they won’t feel cheated out because of a crappy UI.

This is a good reminder though, that basic accessibility functionality, like subtitles, epilepsy warnings (which surprisingly many accessibility guides omit!) are always a good idea whenever possible. If you’re concerned that a design feature may interfere with the aesthetic of your game, remember that many of these features can be triggered optionally. Some things may be functionally be more difficult to implement depending on your platform. But remember - flexibility will always be most important!

At the end of the day, you’re always going to first design the UI that you seem fit. You’re imposing your own UI hierarchy on the player unconsciously! Don’t get too upset, its just a consequence of being a developer. But being aware of it and focusing on your interaction with your end users helps improve the experience for everyone.

As always, if you find any accessibility issues in my game, please let me know, and I’ll try to rectify the problem.

Files

the-sequence-win-tech-demo.zip 45 MB
Version 32 25 days ago

Get The Sequence

Download NowName your own price

Leave a comment

Log in with itch.io to leave a comment.