XR Accessibility User Requirements

As with the WebXR API spec and as indicated in the related WebXR explainer, this document uses the acronym XR to refer to the spectrum of hardware, applications, and techniques used for virtual reality or immersive environments, augmented or mixed reality and other related technologies. Examples include, but are not limited to:

• Immersive or augmented environments used for education, gaming, multimedia, 360° content and other applications.
• Head mounted displays, whether they are opaque, transparent, or utilise video passthrough.
• Mobile devices with positional tracking.
• Fixed displays with head tracking capabilities.

The important commonality between them being that they all offer some degree of spatial tracking with which to simulate a view of virtual content as well as navigation and interaction with the objects within these environments.

Terms like "XR Device", "XR Application", etc. are generally understood to apply to any of the above. Portions of this document that only apply to a subset of these devices will be indicated as appropriate.

Virtual reality and immersive environment definitions vary but converge on the notion of immersive computer-mediated experiences. They involve interaction with objects, people and environments using a range of controls. These experiences are often multi-sensory and may be used for educational, therapeutic or entertainment purposes.

Augmented and mixed reality definitions vary but converge on the notion of computer-mediated interactions involving overlays on the real world. These may be informational, or interactive depending on the application.

Some of the challenges within immersive environments (and gaming) accessibility include the use of extremely complex input devices, control schemes that require a high degree of precision, timing and simultaneous action; ability to distinguish subtle differences in busy visual and audio information, having to juggle multiple complex goals and objectives [web-adapt].

There are also currently very useful accessibility guidelines available that are specific to gaming [game-a11y].

Modality relates to modes of sense perception such as sight, hearing, touch and so on. Accessibility can be thought of as supporting multi-modal requirements and the transformation of content or aspects of a user interface from one mode to another that will support various user needs.

Considering various modality requirements in the foundation of XR means these platforms will be better able to support accessibility related user needs. There will be many modality aspects for the developer and/or content author to consider.

XR authors and content designers will also need access to tools that support the multi-modal requirements listed below.

The following inputs and outputs can be considered modalities that should be supported in XR environments.

The following are example of some of the diverse input methods used by people with disabilities. In many real-world applications these input methods may be combined.

• Speech - this is where a user's voice is the main input. Using a range of speech commands, a user should be able to navigate in an XR environment, interact with the objects in that environment using their voice alone.
• Keyboard - this is where the keyboard alone is the user's main input. A user should be able to navigate in an XR environment, interact with the objects in that environment using the keyboard alone.
• Switch this is where a since button Switch alone is the user's main input. A user should be able to navigate in an XR environment, interact with the objects in that environment using a Switch alone. This switch may be used in conjunction with an assistive technology scanning application within the XR environment that allows them to select directions for navigation, macros for communication and interaction.
• Gesture - this is where gesture-based controllers are the main input and can be used to navigate in an XR environment, interact with the objects in that environment make selections using their voice alone.
• Eye Tracking - this is where eye tracking applications is the main input. Using a range of commands, a user should be able to navigate in an XR environment, interact with the objects in that environment using these eye tracking applications.

The following are a list of outputs that can be available to a user to help them understand, interact with and 'sense' feedback from an XR application. Some of these are in common use on the Web and other exploratory (such as Olfactory and Gustatory.)

• Tactile - this is using the sense of touch, or commonly referred to as haptics.
• Visual - this is using the sense of sight, such as 2D and 3D graphics.
• Auditory - this is using the sense of sound, such as rich spatial audio, surround sound.
• Olfactory - this is the sense of smell.
• Gustatory - this is the sense of taste.

As mentioned, there are a range of input devices that may be used. Supporting these controllers requires an understanding of what they are and how they work. There are a variety of alternative gaming controls that may be very useful in XR environments and applications. For example, the Xbox Adaptive Controller.

While XR is the experience, the controller plays a critical part in overcoming some complexity as well as mediating issues that may relate to other challenges around usability and helping the user understand sensory substitution devices.

Controllers such as the Xbox Adaptive Controller and other switch type inputs allow the user to remap keyboard inputs to control or interact with virtual environments. These powerful customizations allow the user to "do that thing that is difficult" for them with ease. In conjunction with this controller, for example, users with limited mobility they can also simulate actions in the XR environment that they would not be able to physically perform. WalkinVRDriver is a good example of this where motion range, position and orientation can be set to the user's ability.

Give the user the ability to modify their input preference or use a variety of input devices. The remapping of keys used to control movement or interaction in virtual environments is not currently required by WCAG. It is nevertheless noted in the literature as desirable.

A user with a disability may have several input devices or different assistive technologies. A user may switch 'mode' of interaction, or the tools used without degrading the user experience where they lose focus on a task and cannot return to it, or make unwanted input.

Complexity needs to be managed and co-ordinated between different kinds of assistive technology in immersive environments. There is a platform level requirement to support multiple assistive technologies in a cohesive manner. This would allow combinations to be used in a co-ordinated way e.g. where the users day-to-day AT, can be used with other AT that may be embedded in the environment already for example.

There may be tracking issues when switching input devices. A tracking issue is where the user may lose their focus or it can be modified in unpredictable or unwanted ways, this can cause loss of focus and potentially push the user to make unwanted inputs or choices.

Outputs sent to multiple devices will need to be synchronised.

An XR application should have a high level of usability for someone with a disability using assistive technology. Therefore, communicating affordances successfully is critical and needs to be done in a way that supports multiple modalities. Some related questions are:

• How can affordances be successfully translated from one modality to another?
• Can affordances be mediated or transformed, as needed by the users own modality preferences?
• Should affordances change depending on context of use? What interactions are allowed or not allowed?
• How can we ensure what happens in one modality, is reflected in another? So various modalities are not out of sync e.g. synchronization of captions between real time text transcriptions and other alternatives such as symbols or AAC?

• User Need 1: A user of assistive technology wants to navigate, identify locations, objects and interact within an immersive environment.
• REQ 1a: Navigation mechanisms must be intuitive with robust affordances. Navigation, location and object descriptions must be accurate and identified in a way that is understood by assistive technology.
• REQ 1b: Controls need to support alternative mapping, rearranging of position, resizing and sensitivity adjustment.
• REQ 1c: Objects that are important within any given context of time and place can be identified in a suitable modality.
• REQ 1d: Allow the user to filter or sort objects and content.
• REQ 1e: Allow the user to query objects and content for more details.

• User Need 2: A person with a physical disability may want to interact with items in an immersive environment in a way that doesn't require particular bodily movement to perform any given action.
• REQ 2a: Allow the user performing an action in the environment, in a device independent way, without having to do so physically.
• REQ 2b: Ensure that all areas of the user interface can be accessed using the same input method.
• REQ 2c: Allow multiple input methods to be used at the same time.

• User Need 3: Users with cognitive and learning disabilities may need to personalize the immersive experience in various ways.
• REQ 3a: Support Symbol sets so they can be used to communicate and layered over objects and items to convey affordances or other needed information in way that can be understood according to user preference.
• REQ 3b: Allow the user to turn off or 'mute' non-critical environmental content such as animations, visual or audio content, or non-critical messaging.

• User Need 4: A user with limited mobility, or users with tunnel or peripheral vision may need a larger 'Target size' for a button or other controls.
• REQ 4a: Ensure fine motion control is not needed to activate an input.
• REQ 4b: Ensure hit targets are large enough with suitable spacing around them.
• REQ 4c: Ensure multiple actions or gestures are not required at the same time to perform any action.
• REQ 4d: Support 'Sticky Keys' requirements such as serialization for various inputs when the user needs to press multiple buttons.

• User Need 5: A user with limited mobility may want to be able to use Voice Commands within the immersive environment, to navigate, interact and communicate with others.
• REQ 5a: Ensure Navigation and interaction can be controlled by Voice Activation.
• REQ 5b: Voice activation should preferably use native screen readers or voice assistants rather than external devices to eliminate the additional step needed to pair devices.

• User Need 6: Color blind users may need to be able to customise the colors used in the immersive environment. This will help with understanding affordances of various controls or where color is used to signify danger or permission.
• REQ 6a: Provide customised high contrast skins for the environment to suit luminosity and color contrast requirements.

• User Need 7: Screen magnification users may need to be able to check the context of their view in immersive environments.
• REQ 7a: Allow the screen magnification user to check the context of their view and track/reset focus as needed.
• REQ 7b: Where it makes sense (such as in menus) interface elements can be enlarged and the menu reflowed to enhance the usability of the interface up to a certain magnification requirement.

• User Need 8: Screen magnification users may need to be made aware of critical messaging and alerts in immersive environments often without losing focus. They may also need to route these messages to a 'second screen' (see REQ 14 Second Screen).
• REQ 8a: Ensure that critical messaging, or alerts have priority roles that can be understood and flagged to AT, without moving focus.

• User Need 9: A blind user may wish to interact with a gestural interface, such as a virtual menu system.
• REQ 9a: Support touch screen accessibility gestures (e.g. swipes, flicks and single, double or triple taps with 1, 2 or 3 fingers). See REQ 14 Second Screen.
• REQ 9b: Using a virtual menu system - enable a self-voicing option and have each category, or item description, spoken as they receive focus via a gesture or other input. As the blind user gestures to trigger both movement and interaction they may get more detail about items that are closer to them. The user must be allowed to query and interrogate these items and make selections.
• REQ 9c: Allow for the re-mapping of gestures to associate different actions with different input types or gestures. This may be a virtual switch that can map to new macros on the fly. This will allow the user to change defaults and employ gestures to carry out new actions offered by the immersive environment as required.

• User Need 10: A deaf or hard of hearing person, for whom a written language may not be their first language, may prefer signing of video for text, objects or item descriptions.
• REQ 10a: Allow text, objects or item descriptions to be presented to the user via a signing avatar (pre-recorded only).
• REQ 10b: Any signing videos should be 1/3rd minimum of the original streams signing size. This requirement comes from research of 240 ASL videos intended to be watched by deaf signers, that found that nearly all set signer size to at least one-third the size of the full video. [raja-asl]

• User Need 11: People with Cognitive Impairments may be easily overwhelmed in Immersive Environments.
• REQ 11a: Allow the user to set a 'safe place' - quick key, shortcut or macro.

• User Need 12: Users may be adversely affected by spending too much time in an immersive environment or experience, and may lose track of time.
• REQ 12a: Provide a platform integration with tools that support digital wellbeing, allow the user to access alarms for time limits during an immersive session.

• User Need 13: A screen magnification user or user with a cognitive and learning disability or spatial orientation impairment needs to maintain focus and understand where they are in immersive environments.
• REQ 13a: Ensure the user can reset and calibrate their orientation/view in a device independent way.
• REQ 13b: Ensure field of view in Immersive environments, are appropriate, and can be personalized - so users are not disorientated.
• REQ 13c: Provide clear visual or audio landmarks.

• User Need 14: Users of assistive technology such as a blind, or deaf-blind users communicating via a RTC application in XR, may have sophisticated 'routing' requirements for various inputs and outputs and the need to manage same. 
• REQ 14a: Allow the user to route text output, alerts, environment sounds or audio to a braille or other second screen device.
• REQ 14b: Ensure that the user can manage the flow of critical messaging, or content to display on a second screen.
• REQ 14c: Support touch screen accessibility gestures (e.g. swipes, flicks and single, double or triple taps with 1, 2 or 3 fingers) on a second screen device to allow the user to navigate menus and interact.

• User Need 15: Users with physical disabilities or cognitive and learning disabilities may find some interactions too fast to keep up with or maintain.
• REQ 15a: Allow users to change the speed they can travel or perform interactions, in an immersive environment.
• REQ 15b: Allow timings for interactions or critical inputs to be modified or extended.
• REQ 15c: Provide help for the user with a cognitive or learning disability.
• REQ 15d: Provide clear start and stop mechanisms.

• User Need 16: Users with vestibular disorders, Epilepsy, and photo sensitivity may find some interactions trigger motion sickness and other affects. This may be triggered when doing teleportation or other movements in XR.
• REQ 16a: Avoid interactions that trigger epilepsy or motion sickness and provide alternatives.
• REQ 16b: Ensure flickering images are at a minimum, will not trigger seizures (more than 3 times a second), or can be turned off or reduced.

• User Need 17: Hard of hearing users may need accommodations to perceive audio.
• REQ 17a: Provide spatialized audio content to emulate three-dimensional sound forms in immersive environments.
• REQ 17b: Provide text descriptions of important audio content.

• User Need 18: Users with spatial orientation impairments, cognitive impairments or hearing loss in just one ear may miss information in a stereo or binaural soundscape.
• REQ 18a: Allow mono audio sound to be sent to both headphones so that the user can perceive the whole soundscape through either ear. [mono-ios].

• User Need 19: Users may need to customise captions, subtitles and other text in XR environments.
• REQ 19a: Provide support for captioning and subtitling of multimedia content.
• REQ 19b: Allow customisable context sensitive reflow of captions, subtitles and text content in XR environments. The suitable subtitling area may be smaller than what is required currently for television. [inclusive-seattle]