A-Blast app




Syntax can be clearer with more definition

User Requirement by category



1) Controls need to be personalised to support alternative mapping, rearranging of position, resizing and sensitivity.

  • FAILS - cannot be remapped

  • Consider the game design to determine which controls should be configured

  • Should you be able to rotate on different axis from the keyboard.  Discussion about one handed ability?
  • Define all the actions A-BLAST supports, make sure they are all mapped


2) Ensure that all areas of the user interface can be accessed using the same input method.[a]

  • Consider how user inputs their name for high score? Does on screen keyboard work?
  • VR often going from device to keyboard and other potential technologies
  • Where are the boundaries for "same input method"
  • Moving headset is an input method, and using hand trigger is another input method?
  • Does each method supported need to allow all to work?  If you support headset you can do everything, if you support keyboard you can do everything

Physical disability

3) Allow multiple input methods to be used at the same time.

  • Headset and Controller works with A-BLAST
  • Using xbox controller in one hand, and vr controller in other hand
  • Voice and keyboard work together
  • Headset and voice

Physical disability, COGA

4) Ensure hit targets are large enough with suitable spacing around them.

  • There should be a recommended volume here like 0.1M like Apple’s HIG or Nielson’s 1cm x 1cm
  • Specified cubic dimension hit target
  • Need to consider user moving closer to item, proximity to hit testing
  • How can you have a size if world supports unlimited zooming


5) Ensure field of view FOV in Immersive environments, are appropriate, and can be personalised - so users are not disoriented.

  • Normally constrained by device, could add support to reduce the field of view yourself
  • Looking for prefers-reduced-motion and decide to tie fov or stabilization


6) Ensure UI elements that are critical to progress are stationary.

  • A-BLAST meets this


7) Ensure multiple actions or gestures are not required at the same time to perform any action.

  • A-BLAST meets this
  • what is the definition of multiple actions or gestures (what are limits)

Physical , COGA

8) Allow user to change speed at which they travel through an immersive environment, or can perform interactions.

  • A-BLAST consider speed of enemies coming at you being controllable
  • A-BLAST consider changing speed of user's movement
  • Add more definition to


9) Ensure the user does not have to emulate a virtual motion or action physically. In order to perform the action.

  • Developers should have ability to map keyboard inputs to all gestures or speech

General, Physical

10) Do not lock orientation of XR content.

  • Consider rewriting rule to mention "users should not have to rotate their orientation"
  • Field of view should be controllable
  • What about feature should be controllable ie allow the user to lock XR Content
  • Example of problem: Moving user at symphony from direct to audience participant don't keep static graphic, support fading in or out
  • Defining applicability to types of XR experiences flat, portal, immersive


11) Ensure XR content is compatible with a range of AT.

  • No AT currently working other than keyboard but not fully because some actions missing
  • What APIs are available on specific devices, what's the support chart related to AT based on device

Epilepsy, photo sensitivity, also reducing nausea.

12) Avoid interactions that trigger simulation sickness[b] in XR.

  • What's definition of "trigger simulation sickness"


13) Allow timings for interactions or critical inputs to be modified or extended.

  • Controversial area… consider distinct game mode that meets 13
  • Terminology recommendations for these timing interactions (danger of easy mode)
  • A-BLAST consider speed of enemies coming at you being controllable

Epilepsy, photo sensitivity, Visual

14) Ensure flickering images are at a minimum, will not trigger seizures (more than 3 times a second), or can be turned off or reduced.


15) Allow symbol based communication to be selected as a default.

Sensory, COGA, Visual

16) Turn off non-critical or background animation


17) Use rich surround sound.


18) Use binaural recording.


19) Audio description


20) Allow bypassing of non-crucial content or aspects of the environment.


21) Enable a XR angle or helper for the user.

  • Keep accessibility setting clear and strongly visual in the settings content, options that are hidden won’t be found


22) Allow switching to mono audio output.


23) Support routing of audio output to multiple devices.


24) Support routing of text output or other game and environmental signals to other formats.


25) Clear start and stop mechanisms. XR experiences need to have clear start and stop points and well as easily accessible controls for both. It will be critical for people with disabilities that these are clear and interoperable.


26) Allow the user to check the context of their view in XR environments, and track where their focus is.


27) Inform the user of critical messaging and alerts in XR environments without loosing focus. They may need to route those messages to second screens.


28) Allow the user to reset and calibrate orientation/view in a device independent way.


29) Set time limit for any Immersive session. Some users may easily loose track of time, or too much time in any XR experience may effect their mental health adversely.


30) Allow customisable context sensitive reflow of text and subtitled content in XR spaces. The suitable subtitling area may be smaller than what is required currently for television&.

[a]In our discussion "the same input method" is confusing language.