Xbox Accessibility Guideline 106: Screen narration

Goal

The goal of this Xbox Accessibility Guideline (XAG) is to ensure that all on screen visual information can also be represented aurally through screen narration software. This benefits players who can't read on screen content because of things like blindness, low vision, learning disabilities, or temporary/situational circumstances.

Overview

Screen narration technologies are often used by players who are blind or have low vision. However, there are also players who might be able to see the screen clearly but are unable to read because of age or learning disability. The screen reader presents information that's visibly on screen through a synthesized audio voice. Elements like menu text, instructions (“press A to select”), and visual information within the active game environment necessary to play are narrated aloud. This eliminates the need for the player to read the screen themselves if they are unable to.

Screen-reading technologies can be used through either platform-wide technologies or game-specific technologies. Check with your platform provider for further details to determine if any existing platform-level technology can be used by your specific game or if you must create a screen-reading system for your game.

Whether you're developing for a platform-level screen reader or creating a game-specific screen-reading technology from scratch, it's important to keep the following guidelines in mind. They can help ensure that all necessary pieces of visual information are accurately and holistically expressed to a player using screen reading technologies.

Scoping questions

First, review the items in the following "What aspects of the game should support narration?" section.

• Does your game include any of these elements?

• In your game, do these elements present key information to a player?

• If a player couldn't read any of these key text elements, would they be blocked from configuring, starting, or playing the game in its entirety?

Background and foundational information: Screen narration

Introduction to screen narration

This section contains high-level guidance that's intended to help scope the basic components of games that should have screen narration support.

What aspects of the game should support narration?

Support for narration means that while an item doesn't have to be narrated by default, if a player enables their console or in-game narration functionality, these areas are read aloud to the player.

• All on screen text:

  • Menu labels, sub-labels, roles, values, and description text

  • Control types/interaction method like “Press A to select”

  • In-game UI elements: heads up display (HUD) (like inventory or health), objectives, hints/tips, maps, and more.

  • Player-to-player communication: incoming party chat messages, chat wheel options, or pre-written messaging options

  • Images, diagrams, and tables

  • Real-time updates and notifications (incoming chats, toast messages, error messages, friend joining or leaving game)

When should narration occur?

When any of the following events occur, these changes should be appropriately narrated.

• Change in context (opening a dialog box or opening a different app)

• Focus change (going to another button or going to another game in a game list)

• Real-time notification changes, information change, error messages or alerts

How should an item be narrated?

All elements should be labeled, regardless of a player’s primary sense for perception. If a sighted player can see and read a control’s label, a non-sighted player should hear the same label via narration.

For both web and software, this information is usually given to the player in the order of name, role, value/state, indexing (if required), and interaction information (if required).

Narration should include the following important information.

• Labels/names

• Control types/roles

• Values/states

• Indexing/enumeration

• Navigation/interaction models

Other key concepts

• Confirmation of action: This means that a player tried to do something, and they know that they did it based on feedback. They also need to know what they’re attempting to act on so they have an expectation of what will happen for each action. For example, the player configures their preferred settings and knows how to save their configuration from the “press A to save” interaction prompt. If they press "A" and nothing happens, they are unsure if their work has been saved. If they press "A" and the game narrates “settings saved,” the player is aware that they have successfully saved the setting that they want and can confidently progress to the next UI screen.

• UI hierarchy and intuitive navigation order: This should be consistent and intuitive for players. For detailed guidance on this area, see XAG 112: UI navigation.

  Caution

  Don’t overdo narration. While it's important to ensure that all necessary information is conveyed to a player with screen reading enabled, too much narration can easily get repetitive and distracting to a player.

  • For example, instead of narrating a text chat message as, “iheartgames4ever ‘you go left, I’ll go right,’ press d-pad up to activate chat pane. Go to settings to change shortcut. Go to settings to change amount of information you hear when you get a chat.”

  • You can simplify narration by front-loading the key information and eliminating repetitive narration in real time. However, it's important to ensure that those commands or options can be found in settings or as a single reminder on the chat pane itself.

    • Simplified example: “iheartgames4ever ‘you go left, I’ll go right’.”

Implementation guidelines

• All core game UI text (main menu, options, HUD, state changes, players in the game, and time-based events) should support the screen readers that are available on the platform or voice out of the UI through a speech synthesizer. The use of recorded audio files can also be a solution but isn't ideal. (All references to "text" refer to text that can be voiced by using these technologies.)

• Interactable UI elements that behave as lists, tabs, radio buttons, check lists, or combo boxes, must enumerate how many child items belong to that element, the type of input the element requires, as well as the current state or value of that input element. As an example, “Worlds, Tab, 1 of 3, selected,” or “Music Volume, slider, 52%.”

  • Enumeration should occur at the end of a narrated string. For example, "Gama, slider, 38%, 6 of 9."

  • An option to disable enumeration narration can be provided for players who prefer simplified narration.

• The text alternatives for charts, diagrams, pictures, and animations should make the same information available in a form that can be rendered through auditory output. Text alternatives can be used as needed to convey the information in the non-text content.

• Ensure that text alternatives for graphics convey the purpose and operation of the UI components.

• Non-text content that's purely decorative, used only for visual formatting, or isn't presented visually, should not be spoken.

• Support a focus order that's aligned with the meaning or operation of the UI. If the navigation sequence is independent of the meaning or operation, align the focus order with the flow of the visual design.

• After navigating to the last item in the UI/menu structure, the player should be taken back to the first item in the UI/menu structure and vice versa.

  Note

  This guideline only applies to linear menu structures where focus can be moved either up or down or left or right. Menu structures that allow focus to be moved to elements in any direction (such as a menu with focusable items arranged on a 4 &215; 4 tile) don’t need to loop.

  We encourage developers to have an option to enable and disable menu looping for all menus.

• Players should be able to quickly cancel/repeat narration, regardless of input type (controller, keyboard, mouse, or touch).

• If narration for the current item in focus is actively being read and focus is moved to a different UI element before the narration string has been read in its entirety, the narration for the original UI element should immediately stop, and narration for the new UI element that focus was most recently moved to should begin.

• Allow players to adjust the speaking rate and pitch of the voice used to narrate the UI.

• Context change should be player initiated. After a change in context has occurred, the player should be notified via narration of the new context.

• Players should be notified via narration of events that are relevant to user interactions (changes in component states, value, or description). This includes reoccurring/timed-based notifications such as indications of game state. (For example, loading screens, searching for player notifications, or count-down timers.) In these instances, it's acceptable to read out the state every 7-10 seconds so as not to interfere with other narration/notifications.

• When supporting external screen readers (versus implementing in-game speech synthesis), be sure to do the following:

  • Programmatically expose the language of the game. This means that if the game is in English (for example, the menus are written in English, all text and instructions are in English, or characters speak to one another in English), the game should properly assign the language attribute for English (for example, en-us), and be sure this information is exposed to external software like screen readers. This ensures that the screen reader is announcing information with the proper pronunciations and dialects.

  • If non-player character dialogue involves speaking in a language that differs from the main language attribute assigned to the game, this should also be exposed to the screen reader. For example, a game that has text, menu elements, and majority of character dialogue in English appropriately exposes the game’s language as “English – US” to external screen readers. However, there are a few circumstances in the game where a non-player character (NPC) speaks to their mother, who only speaks Spanish. The dialogue between the character and their mother is in Spanish. In this case, the game should also programmatically expose areas in the game where dialogue or other language differs. This ensures that when a screen reader reads the dialogue text aloud to the player, it also uses the proper pronunciations for the Spanish language.

    Note

    Proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediate surrounding text are exceptions to these guidelines.

    • Example: The game is primarily in English, however phrases like “hors d’oeuvers” or other common phrases that are technically in another language, are part of a fictional language, or are the proper name/technical term for something (for example, Arc de Triomphe du Carrousel) don't need additional programmatic language attributes.

  • When writing alternative text descriptions for images, graphics, icons, or diagrams, don't include the type of object in the description. (For example, if you're writing alternative text for an image of a shield, the alternative text should be “Brown shield” instead of “Image: Brown Shield”).

  • In content that's implemented by using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements don't contain duplicate attributes, and any IDs are unique. (For detailed articles on using markup languages, see the "Resources and tools" section later in this topic.)

  • For all UI components (including but not limited to form elements, links, and components generated by scripts), the name and role can be programmatically determined. States, properties, and values that can be set by the user can be programmatically set. Notification of changes to these items is available to user agents, including assistive technologies.

• Provide a text alternative that describes any time-based media (like providing an audio description for a video).

• For live content, it's enough if the text alternative provides a descriptive title for the time-based media element. (For example, for a live clock display, the screen reader reads the title as, “Clock displaying current time in Pacific Standard Time Zone,” but doesn't have to repeatedly announce the current time in real time as it changes.)

• Tables should be made fully accessible to screen narration technologies.

  • This is achieved by ensuring that column and row headers are programmatically associated with relevant cells. This supports a player’s ability to derive necessary contexts about the information provided in each individual cell. High level alternative text descriptions for tables should be avoided.

• Provide a mechanism for the player to understand how to pronounce a proper name, technical term, or word of indeterminate language.

Potential player impact

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

Resources and tools