The purpose of this checklist is to identify and document challenges to making immersive technology accessible, for the purpose of easing the creation of appropriate accessibility documentation, alternative access plans, and easing the purchasing decision process. 

In order to do so, it will help the user to divide technology accessibility for education into a three-step workflow: 1) purchasing software and hardware, 2) providing technical support for software and hardware, and 3) ensuring user access to software and hardware. 

Because the administrative structure for carrying out this workflow varies between educational institutions (purchasing offices, funding requests, how equipment is accessed and stored, etc.), this checklist does not specify what types of documentation these questions should be applied to. Instead, it aims to document the software and hardware used, the information provided by vendors, the methods by which access is provided to learners, and the potential accessibility barriers involved. 

The results can be used to fill out information in purchasing requests, Equally Effective Alternative Access Plans, syllabi, or to even draft custom documentation. Some questions may not be easily answered and that fact should be noted as a potential area that may require additional attention in the future. This list is meant to help the user be more aware of design realities and reduce the intimidation or sense of unpreparedness that can come with needing to provide accommodations.

Hardware

• Which platforms are supported?

  • Ex: Mobile vs. Headset VR

  • Different brands and styles

• What hardware is required?

  • Will the experience require controllers or other gear in order to use?

Software

• What is the name of the experience?

• What is required for someone to purchase and download it?

  • Is the website accessible? Tools like the WAVE Web Accessibility Evaluation Tool can help you determine this.

• Is there a Voluntary Product Accessibility Template (VPAT)?

• Is there an accessibility page or other documentation?

  • Ex: Oculus has a comfort rating system.

• List any content warnings.

  • This can include information around flashing lights, violence, sexual themes, etc.

Operability

User interface components and navigation must be operable by users.

• What are the physical requirements for gameplay?

  • Who are the targeted users?

    • Age range

    • Experience levels with immersive technologies

    • Disabilities

    • Experience in relevant subject material

  • What hardware will they use?

    • Controllers (how many controllers?)

    • Gloves

    • Headsets

    • Phones

    • Computer

    • Etc.

  • How will they wear/operate that hardware?

    • Think about all the physical requirements required to utilize the hardware:

      • Will they need to maneuver and react suddenly?

      • Will they be sitting or standing?

      • Will they need to focus on buttons and dexterity?

  • Other noteworthy information

• What are the physical assumptions of the experience?

  • The previous questions tell you how the experience is operated, which translates into assumptions (i.e., this experience assumes the user will be able to rotate quickly, use two controllers, wear a headset, etc.). In other words, what does a user have to be physically capable of doing in order to use an immersive experience?

Perceivability 

The information and user interface of the experience is perceivable to users’ relevant senses (visual, auditory, tactile, etc.).

• What is the contrast ratio?

  • If you take screenshots of representative scenes from the experience, you can use a tool like WebAIM’s Color Checker to see the contrast ratio (they provide guidance on appropriate contrast: Contrast and Color Accessibility).

• Are there text alternatives to audio?

  • Captioning should convey speech, as well as other relevant sounds.

  • For information on creating good captions: Captions/Subtitles | Web Accessibility Initiative (WAI) | W3C

• How are actions and options communicated?

  • Audio alerts (bells, dings, and other sound effects that communicate instructions to the user regarding progressing through the experience)

  • Visual cues (flashing lights, visual interactables, color signals, and other visual indicators that communicate instructions to the user regarding progressing through the experience)

  • Haptic feedback (controllers, gloves, chairs, and other hardware that physically vibrates or reacts to communicate events during an experience)

  • Other

• Are there customization options?

  • Can volume, color, captions, and other features of the experience be turned off/on or otherwise customized?

• Are there flashing lights?

  • Guidance on appropriate measures for flashing/strobing/etc. lights can be found on the page Three Flashes or Below Threshold

• What is the frame rate?

  • This information may be provided in the experience. PC’s also have a number of ways to measure framerate.

• Is audio clear and easy to distinguish?

  • Is audio muffled or drowned out by white noise and loud background sound (example: games with gunfire in the background may muffle drown out verbal instructions).
    Understandability

Users must be able to comprehend the information and user interface of the experience.

• What types of onboarding takes place within the experience? 

  • Safe mode (controlled, low-pressure space for users to engage game mechanics)

  • Guided play (controlled, guided portion of a game where users are given exercises to familiarize themselves with game mechanics)

  • Text-based (textual directions that guide users through game play/mechanics)

  • Auditory (verbal instructions on how users engage an experience)

  • Haptic

  • Other forms of documentation or guidance on using the experience

• Are cues intuitive/easily understood?

  • Is plain, simple language used?

  • Are cues distinct from one another? (example: haptic cues that indicate success vs. failure need to be distinguishable)

Robustness

The immersive experience must be able to work with user agents, including assistive technology and assistive devices.

• Does this game or experience work well with physical assistive devices?

  • Wheelchairs

  • Prosthetics

  • Crutches

  • Hearing aids

  • Canes

  • Glasses

  • Other assistive technology/devices used by users

• Does this game work well with other assistive technologies/extensions?

  • Accessibility extensions

  • Screen readers

  • Other assistive technologies/extensions

Documentation

• Who’s responsible for ensuring accessibility or aiding you in doing so?

• Who are the stakeholders involved in accessibility within your institution?

  • Users

  • Experience creators

  • Administrative offices (example: disability services)

  • Educators

  • Others

• What communication needs to occur between stakeholders?

  • Individual learning plans

  • Accommodation letters

  • Special curricular exceptions

  • Complaints

  • Feedback

  • Other administrative information

• What types of documentation does your institution currently use to communicate to different stakeholders?

  • Organizational charts (may be useful when ensuring students know who to contact with questions and concerns)

  • Equally Effective Alternative Action Plan (EEAAP)

  • Accessibility statements

  • Others

• What laws and standards does your institution adhere to?

  • The Americans with Disabilities Act

  • Web Content Accessibility Guidelines

  • Internal guidelines

  • Local/State mandates

  • Game Accessibility Guidelines

  • Other laws or standards

• Where is documentation currently hosted?

  • Public Website

  • Intranet (i.e., private, locally shared network)

  • Local shared server

  • Cloud server

• Where should it be hosted, in order to be compliant with institutional policies and support local needs?

  • Consider:

    • Security

    • Access

    • Efficiency

    • Collaborative editing needs

    • Preservation