Accessibility in VR
Tools Used
Sketch, Adobe Illustrator, Figma
Strategies:
UX/UI design, User Research, Prototyping, Teamwork
Timeline
Feb-May 2019 (3 months)
Team:
Thomas Knoepffler, Jelani White
Design Problem
Virtual Reality is an exciting technology and is a new market for interactive experiences. However, due to the nature of the creation of Virtual Reality, often the games are only created for a specific type of person or movements. These could be a certain height, fine motor control, full body movement or simply being able to hear. If someone doesn't have the necessary paramaters to be able to interact with the game then they are excluded. You don't necessarily need a disability to be excluded however the lack of accessibile games is a huge problem.
Equal Entry posed my team with the question how do you bring awareness of accessibility to Virtual Reality developers so that more inclusion occurs in the Virtual Reality space?
Background Research
- Equal Entry provided links to lectures on problems with Accessibility in Virtual Reality
- Microsoft Inclusive Design Toolkit is an educational tool that provides designers and developers guidance on Inculsive Design
User Research
Our goals for our user research was to understand the complexities of the problem as much as possible. We wanted to understand the motivations and desires of people with disabilities so we could properly promote the necessary accessibility for them. We also needed to understand the process of game developers since they will be our end user.
Accessibility
We set up 7 interviews with people with disabilities including people who identify themselves as "Disabled Gamers". I was the note taker for half of the interviews.
"Does not use VR because of a lack of games people in a wheelchair can use"
- Disabled Gamer
Key Take Aways
- They want to be able to use the technology on their own without outside help
- Interested in using technology to feel connected to media, friends and family
Game Developers
We interviewed a total of 5 game developers, 3 of which I personally interviewed and I discovered...
- When developers add accessibility features they are mainly thinking about what makes them uncomfortable and how to fix it
- Time and money is a huge issue
- A clear Game Development process emerged
Game Design Workflow
By asking about the Game design workflow I was able to figure out where in the process designers figure out who they are designing for so that we understand what areas of their process to target.
VR Developers Survey
I took the research a step farther to understand VR developer trends by creating and distributing a Survey to NYU Game Design Masters, and PHD students. The goal was to understand the awareness of pre-existing accessibility tools and confirm our beliefs about their workflow.
Results
66% hadn't heard of Microsoft Accessibility Toolkit
83% decide who they are designing for in the first half of their process
"When designing for access, you always have to, in a way, start with yourself. If you cannot for a moment consider a time when you were vulnerable or hurt and needed others to help you, then you must be extremely privileged in that regard."
- Game Developer
The User Persona I created based off the interview results
Research Synthesis
After analyzing all the pain points we uncovered in our research, I consolidated them into 3 requirements for our project....
1. Maintain considerations for developers time and resources
2. Introduce awareness of accessibility early in the process
3. Make it easy for developers to integrate features for accessibility
How do we not only introduce accessibility to developers but also keep it in their minds as they are creating their projects?
In order to create a solution that answers this question we looked back at the Game Design Workflow along with our previous research to figure out where to target. We decided to focus on the first half of their process with the most emphasis on the mechanics stage which occurs while they are working in the application of their choice. We decided to focus on Unity since it is most widely used.
The solution...
A Unity plugin that will keep track of a developer's progress while developing a game. It will analyze the architecture of their code and alert them if they inadvertently create instances of inaccessible design. The developer can choose to enable/disable the plugin and customize the parameters of who they will be designing for from the start of the project.
The Product
We split the product into two parts...
#1 New Project in Unity
This targets the ideation and Mechanics phase of the Game Developers process by forcing the Game Developer to think about who they are designing for while setting up a new project within Unity. The goal is to not only get them thinking but also inform them on what they need to include in their game to make it accessible. I focused on creating this part of the prototype
#2 Within a Project File
This targets the mechanic and Prototyping phase of the Game Developers process by providing continueous information for the developers about the accessibility of the game.
User Flow for part 1 (New Project in Unity)
User Flow for part 2 (Within a Project File)
Part 1: New Project in Unity Screens
When opening Unity, you are prompted with a new project screen. This section of the prototype occurs between that screen and the opening of the project. It sticks with the visual design rules of Unity. I created these screens as a short survey to gather information from the user so that accessibility suggestions can be made to their project.
Who?
The goal of this screen is for the user to identify who they are designing for so that while they write code it can be check to make sure parameters are being met for these people
What?
By gathering information on what features they want, the product can suggest how to keep these features as inclusive as possible
How?
After gathering information, this screen is an informative way for the user to identify what they need to include to maintain accessibility. It then creates a checklist of these items within the project
Part 2: Within a Project File
These screens went through multiple iterations with the most recent screens seen below. The designer on my team who had used unity did the original screens in Sketch. We used the plugin "Plant" to collaborate. I redesigned the checklist that was added into Unity on the left side of the screen and fixed some typography spacing.
If a user inputs inaccessible code that doesn't fit the parameters set in the checklist then the a popup appears that highlights the problem. The idea is to bring awareness to the problem in the code since the developer might not realize that it is inaccessible.
If the user goes to build the project they are able to see the amount of progress made to the checklist with the Accessibility progress bar. If the bar isn't full they are prompted with a pop up. This is a way to provide a last chance to bring awareness to the issues in their project.
Completely accessible game
If the checklist on the left side is complete, and the progress bar full than all the red signifiers are green showing complete accessibility throughout the project.
Once these screens were all complete I prototyped the interactions in Figma.
Interact with the prototype here
Conclusion
My largest challenge on this project was balancing the needs of the developer with the accessibility guidelines that need to be in place. I found it was really insightful talking to developers while still having the conversations from talking with people with disabilities in my mind. It allowed me to ask specific questions about accessibility in the process when talking to developers.
Next steps...
We are currently working towards User testing this project with developers to get their insights into how this solution would work with their current flow on a project.