Welcome to the last part (for now) of my accessibility exploration of virtual reality
 |
It’s nice that there’s an option for short (or seated?) people that moves the controls lower, but is that plank wheelchair safe?
[Image source: Richie’s plank experience]
|
 |
Motion |
||
|
Test
|
Rationale
|
Recommendations
|
|
|
Virtual locomotion
|
|||
|
Explore the different
locomotion options, are there different ways?
Can the experience be
navigated:
●
From a stationary position?
●
Seated?
●
Whilst operating a wheelchair?
●
Lying?
●
Without controllers?
|
People have a wide
range of accessibility needs and personal preferences.
|
Providing different
interaction methods will engender greater immersion.
|
|
|
Balance
|
|||
|
Does the experience
require the user to have a good sense of balance or trick them into believing
that they need one?
|
Simulating the loss of
balance is potentially physically dangerous.
It may be unrealistic
to users that are seated or lying.
|
Provide an option to
skip sections that require physical abilities or a different way of achieving
the same goal.
|
|
|
Range of motion
|
|||
|
Does the experience
require users to push their physical boundaries?
Does the headset need
the user to have full range of head or hand/arm movement?
|
People have different
ranges of motion and may not be able to interact with such an environment.
|
Provide a restricted
movement option for people with different physical needs.
|
|
|
Strength / fatigue
|
|||
|
Is there a requirement
to perform repeated actions or hold specific positions for extended times
|
Different movements may
be difficult for some people.
|
Even in experiences
where this may be desirable (e.g. a fitness game), provide different levels
to cope with different levels of ability. Consider the potential for physical
therapy.
|
|
|
Recentering
|
|||
|
Is there a way to
recentre the user’s view without requiring them to turn their head?
|
Some people may have
movement difficulties or may just want to sit down in a non-swivel chair.
Giving the option to re-centre
the user’s view using a controller can assist with this.
|
Provide an option for
rotation control through the controller such as:
Blink mode or Snap turning from Cloudhead games
|
|
|
Timing
|
|||
|
Does the experience
require precision timing or activities to be achieved within a certain
timeframe?
|
Not everyone is equally
able. Whilst time dependent challenges can be entertaining they can also be a
barrier
|
If timing is part of
the experience allow it to be configurable, provide an alternative option, or
skip mechanism.
Don’t rush the user by
default - allow them to proceed in their own time and at their own speed.
Allow the experience to
be paused or progress saved.
|
|
 |
Room scale experiences are cool, but what about those without the space or freedom of movement?
[Image source: Steam VR]
|
 |
Orientation / position
|
||
|
Test
|
Rationale
|
Recommendations
|
|
|
Physical position
|
|||
|
Consider the different
positions that the user might physically be in whilst interaction with the
experience.
Can it be operated:
●
Lying
●
Seated in a non-swivel chair
●
Standing but unable to touch floor
●
Without jumping or reaching up high
●
Without turning around (physically)
●
At different heights
●
Equally in room and standing setup
|
A user lying on their
back (or seated) may not be able to turn around physically or look over their
shoulder. Virtual forward may not be equivalent to physical forward.
If a user is lying on
their back which way do the put their arm for up?
|
Provide options for
turning that don’t involve physical movement.
Don’t force users to
perform over the shoulder interactions or adopt uncomfortable positions.
Allow the user to
configure the experience to them self rather than being forced to adapt to
the experience.
|
|
|
Scale
|
|||
|
How does the “room
scale” experience compare with the “standing only” experience?
|
Some users do not have
the room for room scale or cannot use it for other reasons
|
Although the experience
will be somewhat different, neither experience should disadvantage the user.
Optimising the
experience for both will make porting to other platforms easier too.
|
|
 |
Providing lots of configurable options enables users to customise the experience to their needs / preference.
[Image source: Rec Room]
|
 |
Configurable
|
||
|
Test
|
Rationale
|
Recommendations
|
|
|
Feedback
|
|||
|
Check to see if the
user has control over the levels for:
●
Brightness
●
Audio
●
Haptic feedback
|
Individuals have
different tolerances and preferences.
Allowing control will
enable a better user experience and may help reduce cybersickness.
|
Let user control the
levels for audio, brightness and haptic feedback from the application.
Devices may not always allow this.
Don’t make large
unexpected changes to these levels.
|
|
|
Sensitivity sliders
|
|||
|
Does the experience
provide options to change:
|
Providing sensitivity
sliders gives users with different ability levels the option to better
control the experience.
|
Provide options to
control different aspects of the experience
|
|
|
Controls
●
How accurate or steady the controller needs to be.
|
Allowing adjustments to
the control sensitivity may help people with motion difficulties (e.g. muscle
control) or visual impairment.
|
Reduced sensitivity may
consist of giving the user a bigger target area for their controller.
Provide an option for
assisted control such as proximity locking will assist those with motor
impairment and speed up interactions for all.
|
|
|
Effects
For example:
●
head bob
●
weapon sway
●
movement blur
●
flashing lights
●
sound effects
|
Special effects affect
people differently and can contribute to the occurrence of cybersickness. But
others may enjoy the increased immersion.
|
Make them all optional
or scalable.
|
|
|
Speed
Could include:
●
player speed
●
effects speed
●
response time required
●
speed of interactive elements
|
Some people need longer
to interact. For some, the speed required for an interaction could be the
difference between being able to use an experience or not.
|
This could be a single
slider for the whole experience or individual ones for different aspects.
|
|
|
Closed captions
●
everything
●
all instructions and dialogue
●
only important instructions and relevant dialogue
|
For those that need to
or choose to use closed captions it would be useful to provide options as to
the level of detail provided.
Captions may be used by
those with hearing impairment, cognitive difficulties or those learning a new
language
|
Some may want
everything including dialogue and audio description to give mood. Others may
only want the important dialogue.
Generating closed
captions also makes it easier to provide support in other languages, or let
the community do it for you.
|
|
|
Difficultly
|
Having different levels
of difficulty will not only help those learning to use the the experience,
but may also assist those that would not otherwise be able to use it.
|
Allow the whole
experience to be adjusted in terms of difficulty not just the early levels.
Give the option to
bypass difficult stages of the experience so that users can still experience
the later stages even if they can’t complete all of them.
|
|
|
Head up display (HUD)
|
|||
|
Is a HUD being used in
the experience? If so, is it configurable?
|
The HUD is fixed in
position so the user does not have the option to move closer to be able to
read it more clearly
|
Allow the user to
configure the HUD to suit their needs or style.
Include the ability to
change both the size and placement of HUD elements.
Consider alternatives
to using a HUD - could menus be attached to the controllers or somewhere
else?
|
|
|
Text and User interface
(UI)
|
|||
|
Is the UI fixed, can
the user “lean in” for a closer look.
Consider taking a
screenshot and testing the contrast.
|
For those with visual
impairments in particular, perception may be difficult if the UI is fixed
|
Don’t fix the UI to the
“player camera”, allow them to move closer.
Ensure that the
contrast between UI and background is good or if dynamically changing at
least configurable.
Use an easily readable
(websafe) font.
|
|
|
Controllers
|
|||
|
Are both controllers
required
|
Other than obviously
excluding people with only one functioning hand, having to use two
controllers can also be a heavy cognitive load.
|
Try to keep controls as
simple as possible, If they can be reduced to one controller, provide that as
an option.
|
|
|
Can the default
controller be reconfigured or a third party controller be used?
|
Many of those with
accessibility needs will have a preferred or default controller that they
like to use. Some may not be able to use the default controller or at least
not in the way that is envisaged.
|
Allowing for third
party controllers or remapping allows the user more options and makes
integrating with new hardware easier.
|
|
|
Can virtual tools be
used to assist the user?
|
Some users may require
keyboard integration or want to utilise technology such as LeapMotion.
|
Provide a mechanism to
easily integrate with third party software as well as hardware.
|
|
|
Alternative input
|
|||
|
Are there any
alternatives to using a controller (e.g. speech, eye tracking)
|
This can benefit those
with physical disabilities, but can also be a better form of interaction for
all users in certain contexts
|
Consider providing
options for non-physical input such as verbal commands and enabling text to
speech (e.g. for in game chat)
|
|
 |
Menus do need to be attached to a head-up-display, this one is attached to the controller.
[Image source: Tilt brush]
|
Please let me know if you
have any comments or suggestions for items that I haven’t covered
Comments
Post a Comment