Xbox Accessibility Guideline 107: Input

Goal

The goal of this Xbox Accessibility Guideline (XAG) is to ensure that a player can operate the gaming interface through input mechanisms of their choice.

Overview

Games often require the use of a wide array of input mechanisms like a mouse, analog inputs such as thumb sticks or triggers, the use of single-press digital inputs (like controller buttons or keyboards), voice or sound input, and many others. It's common for controller form factors as well as control schemes to often make assumptions about physical abilities without taking into account how diverse the player community is.

Players can be excluded from a game experience by the input mechanism requirements that a game has; for example, a PC game that can only be played with a mouse and doesn't support keyboard input. This exclusion affects players who are blind and can't use devices (like a mouse) that require hand-eye coordination and players who have low vision. They might have trouble tracking a pointer or cursor on the screen. Players who have hand tremors might also find using a mouse very difficult and might prefer a keyboard instead.

It's important to evaluate the type of input needed as well as the specific timing or speed needed to activate those inputs to play the game. For example, a player might be required to repeatedly mash two buttons to beat an in-game boss, or hold down the right trigger for 3 seconds to open a door. In these examples, players who can't meet the physical demands of quick, repetitive button presses or holding down buttons for longer periods of time are excluded from progressing through any points in the game beyond a boss battle or a closed door.

Similarly, when menu UIs are strictly navigable through mouse or analog thumb stick input alone, a player who can only access single-press digital buttons might be unable to configure their settings or begin their game altogether.

It's OK to have the primary interaction method for components in your game be through a mouse, an analog input, or any other mechanisms of your choice. However, to ensure that all players can enjoy the game, it's best to always provide alternative input options that a player can configure or choose to use. These alternate inputs should provide the player the same functionality as the default input option.

Scoping questions

Anywhere a player is required to use analog inputs, such as mouse movement or thumb stick movement, the player should also be given the option to use single-press digital inputs to perform the same tasks.

• Menu navigation: what input mechanisms are required to navigate your menu (mouse, keyboard, D-pad, or thumb stick)?

• Analog controls: does your game require the use of an analog thumb stick or mouse movement to control a character’s movement?

• Analog controls: does your game require the ability to use triggers to control a character’s movement (for example, a racing game where triggers control the speed of a car)?

• Are there areas in your game where a player must press buttons quickly or hold them for prolonged periods of time (2-3 seconds or more)?

Background and foundational information

It’s important to remember that input accessibility encompasses more than simple control remapping capabilities. While the ability to map a control from one button to a different button is critical to many players, this alone may not eliminate all input-related barriers for a player.

Consider the following additional aspects of input demands that may pose barriers to players, regardless of the ability to re-assign control mappings:

• Speed: Consider the speed at which players must activate controls to successfully navigate game scenarios. For example, in a close-combat situation, the player may only have seconds to rapidly activate controls assigned to different attack methods like punch, block, or swinging a weapon. While re-assigning these controls to other physical locations on a controller or keyboard that the player can more easily reach is helpful, this does not mitigate barriers for players who cannot perform button presses at rapid speeds to defeat enemies. It’s also important to keep in mind that players may be activating their inputs in non-traditional ways that typically take longer than hand-based control activation such as using switch buttons mounted near their head, arms, legs or other body parts that take more time and effort to move.

• Complexity: Game mechanics that require the activation of multiple buttons simultaneously or a rapid succession of button presses in a specific order can also pose additional barriers unrelated to basic control mapping solutions. For example, if a player must execute a combination of button activations, like X + X + RT + A to elicit a specific character attack needed to defeat a boss enemy, but the player cannot remember the combination or order of buttons due a to cognitive or learning disability, they can remain blocked from game progress regardless of their ability to assign X, RT, and A to different buttons on their controller.

• Duration: The amount of time in which a player must hold down a control can also pose barriers to access, regardless of what that control is remapped to. For example, if a player must continuously activate an input to perform key game actions, like holding down RT to keep the car accelerating throughout a 3-minute race in a racing game, and become fatigued, re-assigning “accelerate" to an input other than RT does not effectively eliminate the source of this barrier.

Instead, consider the following approaches that may be offered in addition to remapping that may help eliminate broader input-related barriers for more players:

• Control game speed: Consider allowing players to control the speed in which gameplay occurs. By allowing players to lessen game speed, they may have more time to perform offensive and defensive character controls in-between enemy attacks.

• Remappable actions: Consider providing the ability to remap game actions instead of individual game controls. For example, if players must press A and B at the same time to perform the action of “picking up items,” instead, allow players to remap the action of “picking up items” to simply the X button. This provides players with an opportunity to further customize their gameplay and focus on performing the action at hand without being blocked by their physical ability to hold multiple buttons at once or remember the button combination associated with an action.

• Toggles and “auto” holds: For game controls that must typically be held down for longer periods of time like accelerating, sprinting, firing a weapon, repetitive jumping, etc. consider allowing players to toggle this action on permanently. For example, in Minecraft, players can enable “auto-jump” – instead of activating the jump control each time a step is approached, the character automatically jumps over. This similar approach can be taken for controls like auto-fire, auto-sprint, and more depending on the nature of the game.

Implementation guidelines

• UIs throughout the game should support digital and analog navigation, including menu UI and in-game UI.

• A UI should be navigable by using single, non-simultaneous key presses.

• Players should be given the option to remap all of the controls within the game itself, regardless of platform-level remapping support that might be present. This includes remapping analog and digital controls, inverting both the x-axis and y-axis individually for each individual control stick, and the Esc key on PC games.

  • This should ideally allow the player to assign an action to all potential game inputs, as opposed to simply swapping button assignments.

• When a player remaps a control within the game, the labelling of the new mapping is represented correctly across any hints, tips, tutorials, or controller map schemes.

• All interface components should be fully operable with digital input—even if the primary mode of input is intended to be analog. This relates to the function, not the input technique. For example, if a player is using analog triggers for gas in a racing game, the game should work properly if the control is remapped to a digital control like the “A” button.

• Avoid introducing mechanics where a player is required to repeat or execute multiple keystrokes or button presses within a short period of time (like quick-time events (QTEs)).

• Avoid introducing mechanics where a key or button should be held down for an extended period before the input is registered.

• Avoid introducing mechanics where a player is required to press two buttons simultaneously to activate a function.

• If inputs that require repeated button strokes, prolonged button presses, or simultaneous button presses cannot be avoided, provide an alternative input option that is either less physically demanding or allow the player to bypass game events that require the use of using these mechanics, or that part of the game experience altogether.

• Ensure that content can be operated without multi-point gestures—or the functionality can also be operated by another method, such as a tap, click, double-tap, double-click, long press (less than 3 seconds), or click and hold.

  • Multi-point gestures are interactions that require two or more points of contact with touch-screen input devices such as mobile phones or tablets. For example, using a “pinch to zoom” gesture or a two or three finger swipe.

• Ensure that content can be operated without path-based gestures. This includes mouse/cursor movements as well as touch-screen, path-based gestures.

  • Path-based gestures usually require a single point of contact. However, these gestures require a certain level of dexterity and coordination to move the cursor in a specific way like swiping horizontally or vertically, clicking and dragging, or drawing specific shapes to initiate the operation.

• For content that can be operated with a single pointer (like a mouse/cursor or touch screen), use the following guidance.

  • The down click or down press (the down event) on an item doesn't automatically activate that item. Activation occurs on the up event, which is when the button or press is being released. (For example, when a player hovers their mouse over a button and clicks, the button’s function is not immediately activated as the player presses their mouse button “down.” The button is only activated on the up event, or as the player is releasing the mouse button. This also applies to touch-screen experiences.)

  • A mechanism is available to cancel the action before completion. (For example, if a player touches down on the wrong location or item, they can move their cursor or finger away from that location before the up event or click release. This cancels the unintended action.)

  • If a mechanism to cancel the action isn't available, a simple mechanism to undo the action is provided.

  Note

  There might be circumstances where activating the function on the down event is essential. If it's essential, the previous guidelines shouldn't be taken into consideration for that specific function. (Essential down-event functions can include experiences like a simulation of playing the piano or shooting a gun. The experience would become very unnatural if activation didn't occur until the up event).

• Any gameplay-critical input that uses speech or motion controls as a default has an alternative digital input mechanism (for example, a keyboard alternative for a motion-based game).

• Games should not require the use of two analog sticks (or an analog stick and directional pad) to complete mechanics.

  • Some games natively support a single stick due to the style/genre of game. However, even games that traditionally require two sticks (for example, first person shooters) can include options for single stick control.

  • Some games recognize a press-in (or "click") of a stick as an input. Even if the game is not using a second stick for directional input, if a click is required on that second stick, that input should be able to be remapped to another button.

  • Some games use D-pad for behaviors beyond character movement, such as weapon or item selection. If a game requires using a D-pad for such input, that input should be able to be remapped to other unused buttons or activated through other means other than analog sticks (such as from a menu).

• For games that support keyboard input, players should be able to access all controls needed to start the game, adjust settings, play the game, and exit from the game back to the platform's home screen using a keyboard alone.

• An option to adjust sensitivity of analog controls individually should be provided at the game level. This includes the ability to adjust the sensitivity of analog thumb sticks, joysticks, triggers, racing wheels, and mouse movement as applicable.

  • Players should be able to increase or decrease sensitivity by at least 50% of the default sensitivity.

Guidelines for mobile input

The following guidelines are specific to touch-based inputs or controls (typically present on mobile gaming experiences).

The term “touch target” refers to any defined space on the device’s screen that activates a specific control or game input upon contact with the player’s hand or finger.

• Offer players the ability to use non-touch input types such as:

  • Standard controllers
  • Adaptive controllers
  • Physical keyboards
  • Mouse
  • Assistive technologies (platform switch access, voice input, head movement-based controls via the device’s camera, etc.)

• Support mobile-native input accessibility features.

  Note

  Many mobile platforms like iOS and Android natively support switch access, movement-based controls, and voice controls as described in the following text.

  • Switch control: Players who are unable to interact with their devices directly through touch may be using switch-access buttons mounted near other parts of their body such as their head, arms, or legs to navigate their mobile devices. Ensuring your game is compatible with platform-supported switch access navigation allows these players to use these assistive technologies during their gaming experiences as well.

  • Voice control: Some device platforms support mobile device navigation via voice control. Players may be able to use voice commands to activate inputs or game controls.

• Support gameplay in both portrait and landscape screen orientation.

  Note

  Some users have their mobile devices mounted in a fixed position onto their wheelchair arm or table. By supporting play in both portrait and landscape orientation, these players can avoid having to change their mounting position or set up.

• Allow players to adjust the size, spacing, and positioning of all touch targets at their discretion.

• Provide a range of pre-set touch target layout configurations.

• The default touch target layout and pre-set layout configuration options should adhere to the following:

  • Touch target areas should be large enough to see and interact with easily. The following are the suggested minimum default sizes:

    • Mobile phones:

      • 15 mm high by 15 mm wide, or 15 mm in diameter
      • 59 by 59 px at 100 DPI
      • 118 by 118 px at 200 DPI
      • 236 by 236 px at 400 DPI
      • Scale linearly as DPI increases

    • Tablets:

      • 24 mm high by 24 mm wide, or 24 mm in diameter
      • 94 by 94 px at 100 DPI
      • 189 by 189 px at 200 DPI
      • 378 by 378 px at 400 DPI
      • Scale linearly as DPI increases

  • Touch targets should be spaced widely enough to prevent accidental activation of other controls.

• Consider surrounding each touch target with a small amount of inactive space to limit accidental activation of other controls.

• Provide players with an opportunity to cancel a decision or correct a recent interaction mistake. For example:

  • Allowing a player to Short Press and Drag to cancel a button press.

  • Allowing a player to undo an action via an “Undo” button.

  • Allowing a player to release a held object or entity by pulling it outside of the playable area.

• Allow players to adjust aspects of input such as swipe sensitivity.

• Consider offering simplified control schemes or options to reduce the number of controls needed to play the game.

• Avoid or provide alternative input options for common challenging input types including:

  • Prolonged touch target holds

  • Dragging or swiping gestures

  • Rapid taps

  • Multi point gestures

  • Multi-finger gestures or simultaneous button presses

  • Speech input

  • Gyroscopic controls such as tilting or shaking the device

• Control activations should occur on touch-end or mouse-up events.

  Note

  Touch-end: The control is activated when the user removes their finger from the screen, not the point in which initial contact is made.

  Mouse-up: The control is activated when the mouse button click is released, not the point in which it is initially clicked downward.

• Support speech-to-text or dictation-based input. This is important for areas like text-based input fields and text-based party chat experiences.

• Ensure the customization process itself is fully accessible. This includes all necessary tasks needed to resize controls, move controls, re-assign controls, or select pre-set layout configurations.

Potential player impact

The guidelines in this XAG can help reduce barriers for the following players.

Resources and tools