Accessibility

Accessibility is the degree to which a product or service can be used by a customer with a particular disability. Accessible products and services allow users with disabilities to use them easily and efficiently.

Particularly, Accessibility for TV refers to the functionality features that allow all users, including those with disabilities, to navigate, interact with, and consume the content. As streaming services and smart TVs become more popular, ensuring that these platforms and their associated content/media accessible is crucial.

Accessible systems have three major components:

• Application being made accessible
• Accessibility framework
• Assistive technology

Assistive technologies help individuals with disabilities accomplish a task or use a product. Examples of assistive technologies include screen reading software for blind users, screen magnification software for users with low vision, and text banners for users with color blindness.

Assistive technologies in Kepler Fire TV

React Native for Kepler currently supports the following assistive technologies on Amazon Fire TV.

VoiceView

VoiceView enables navigation of the Fire TV user interface for visually impaired users. With VoiceView, visually impaired users are able to use the standard Fire TV navigation mechanisms — Up, Down, Left, and Right buttons on the remote — to move the input focus around the screen. When the focus changes, VoiceView automatically speaks the currently focused item.

To activate VoiceView on Amazon Fire TV:

• Hold down the Back and Menu keys on the Fire TV remote for 2 seconds.
• Go to Settings > Accessibility > VoiceView.

  • To enable Voiceview using the shell, run the following command.

    vda shell vdcm set "com.amazon.devconf/system/accessibility/VoiceViewEnabled" "ENABLED"

Screen Magnifier

The Screen Magnifier helps users with low vision zoom in on specific areas of the screen, making content more legible and easier to visualize. Users can navigate the magnified screen using standard Fire TV navigation mechanisms to change the magnification focus to different locations on the screen.

To activate Screen Magnifier on Amazon Fire TV:

• Hold down the Back and Fast Forward keys on the Fire TV remote for 2 seconds.
• Go to Settings > Accessibility > Screen Magnifier.

  • To enable the Screen Magnifier using the shell, run the following command.

    vda shell vdcm set "com.amazon.devconf/system/accessibility/ScreenMagnifierEnabled" "ENABLED"

Text Banner

Text Banner assists users with color blindness or low vision by isolating the currently selected component’s text content in a customizable high contrast box at the bottom of the screen. When a user navigates to a new component on the screen, the text description of the component is updated in the text banner.

To activate Text Banner on Amazon Fire TV:

• Holding down the Rewind and Fast Forward keys on the Fire TV remote for 2 seconds.
• Go to Settings > Accessibility > Text Banner (currently under development).

  • To enable the Text Banner using the shell, run the following command.

    vda shell vdcm set "com.amazon.devconf/system/accessibility/TextBannerEnabled" "ENABLED"

Guidance for implementing accessibility in Kepler for Fire TV

This section provides guidance on implementing accessibility features in React Native for Kepler applications. It covers brief descriptions of how to use standard React Native accessibility features, as well as React Native for Kepler specific additions. Developers should follow these best practices to marke sure their apps are usable by people with disabilities.

To make your React Native for Kepler experiences accessible, you should generally follow the guidance provided in the Standard React Native Accessibility Documentation.

Note: Some React Native features are only supported on a single target platform (Android or iOS). Generally, properties or features that are specific to iOS are not supported on Kepler.

Standard React Native accessibility best practices

Labelling a Component

Use the aria-label property to provide a localized text description for all meaningful components which do not include on-screen text. Keep the label short and simple.

Use aria-label to:

• Provide descriptions of non-decorative icons and images. (For example, Menu or Play/Pause icons)
• Describe containers which represent individual semantic items (such as an item in a list)

Don't use aria-label to:

• Duplicate on-screen text. If an item is text, it does'nt need an aria-label.
• Describe decorative components such as backgrounds or borders which don't contribute to the semantic meaning of a component or interface.

Describing the Purpose of the Component

Use the role property to describe the purpose/type of a component: button, checkbox, heading, alert, etc. for the list of currently supported roles in React Native 0.72.See the documentation for the role property for the list of currently supported roles.

Note: In previous React Native versions the accessibilityRole property was used. The current reccomendation is to use the role property instead.

Describing the State of the Component

React Native provides several ARIA-style properties to describe a component's state:

• aria-checked: Describes the state of a checkable component (such as a checkbox or radio button). The value can be true, false, or "mixed".
• aria-disabled: Indicates that a component is temporarily disabled.
• aria-expanded: Describes the state of an expandable component such as a node in a tree view.
• aria-selected: Dndicates the present selected state which takes value of true , false or undefined (for not selectable components). Some of the selectable components are gridcell, tab, listbox.

Note: Whenever there is a change in the state of a component, the underlying assistive technologies is advised of the above change thereby alerting the users with the updated state.

Providing accessibility value-related Information

Use the aria-valuemin , aria-valuenow , aria-valuemax , and aria-valuetext properties to describe the value of a component. Use aria-valuemin , aria-valuenow , and aria-valuemax to describe a range-based value. The aria-valuetext property provides a textual description of a component's value if the range-based properties are inappropriate. For example, to describe the value of a color contrast or audio balance control.

Providing Usage Hints

For users without visual impairment, the layout of a screen provides visual cues as to how to navigate and interact with that screen. For example, if item A is located above item B on a screen, the user intuitively knows to press the Down button to navigate from A to B. However, an 'assistive technology' user may require additional hints to aid their interactions with a screen. To help with this issue, the Accessibility Hint property helps provide this navigation context.

The following example shows how to set the accessibilityHint property to a custom string on your view.

<TouchableOpacity
  accessible={true}
  accessibilityLabel="Next Page Button"
  accessibilityHint="Navigates to the next page"
  onPress={onPress}>
  <View style={styles.button}>
    <Text style={styles.buttonText}>Next</Text>
  </View>
</TouchableOpacity>

Exposing dynamic content changes in live regions

You can use the aria-live property to marke sure assistive technologies, such as VoiceView, communicates the updates (such as text content) of a component effectively to the users.

Note: Users might not able to perceive the updates in live regions immediately. Based on the priority and significance of the update in live region, developers can set one of the following three values for the aria-live property.

• Assertive: Indicates that the screen reader should interrupt anything currently being spoken to speak the update. This will not move the focus to the live region in which the change has occurred.
• Polite: Indicates that the screen reader should finish speaking any current text before reading the update. Similar to the “Assertive” value the focus will not be shifted to the live region in which the change has occurred.
• off: Indicates that the changes should be reflected to the user only if the user is focused on the current item otherwise the changes won’t be intimated to the user.

Avoid making accessibility announcements whenever possible

announceForAccessibility - This method allows applications to explicitly force the screen reader to speak something. However, making direct accessibility announcement is generally not a good practice especially when that user is using a non-speech modality such as Braille.

Note: - This method is currently available but will be removed in future releases.

Suggested methods to make accessibility announcements - Instead of using the announceForAccessibility API, using semantic roles, live regions and accessible property is highly advised to convey information naturally to the users.

• Use ARIA roles (role) - Using semantic roles such as header, summary is recommended to notify users of the update.
• Making it a live region (aria-live) - Alternatively, setting aria-live property helps developers to notify users of the dynamic changes in a component.
• Accessible elements with labels (aria-label or aria-labelledby) - Making an element accessible by setting accessible property as true with the associated accessibility texts ( such as aria-label or aria-labelledby ), will enable assistive technologies to make announcements when a user selects the element.

React Native for Kepler Specific Accessibility Properties

This section describes properties which are not standard to React Native but are supported in React Native for Kepler.

Orienting the Blind User to a Screen

In some cases, the way in which the user navigates elements within a screen is related to their visual layout. For example, pressing down to navigate to content below the current item. In these cases, it is useful to provide an initial orientation to a screen and the visual orientation of its components to help blind users navigate it. To provide such a description, set the accessibilityOrientationText property on the screen or container to be described. accessibilityOrientationText property should include a localized string describing how the blind user should navigate components in the screen or container. Note that orientation text is only read the first time the screen or component is encountered. After that, the user can request the orientation text to be re-read, but it will not be read automatically. Note that this is different from accessibilityHint as this is read only the first time the screen or component is encountered.

<View
  accessibilityOrientationText="This is a complex screen-- A localized description of how to navigate it goes here">
  <Text>This is a complex screen</Text>
</View>

Describing the Focused Item

One of the challenges with the React Native for Kepler app is that the screen reader focus follows input focus. As such, there are many items on-screen (such as static text describing the currently focused item) which can never receive screen reader focus. To solve this, we added a React Native property called accessibilityDescribedBy. The value of this property is a list containing the native IDs of the components which describe this component. For example, each tile in a row might include the native ID of the mini details view in its accessibilityDescribedBy property, or alternatively, all the bits of static text which are related to the tile.

<View nativeID="miniDetails">
  <Text nativeID="rating">PG-13</Text>
  <Text nativeID="runtime">42 minutes</Text>
  ...
</View>

<View
  accessibilityDescribedBy={["rating", "runtime"]}>
    <Text>Content Tile Text</Text>
</View>

If instead we set the accessibilityDescribedBy property to "miniDetails", then all the items inside the mini details container would be spoken in tree order. Specifying the individual items allows the component to exclude some items and/or control the order in which they are spoken.

Providing Proper Roles for static text

Assistive technologies, such as VoiceView and Text Banner, do not automatically present text when it appears, as doing so will create an overly verbose experience for the user.

However, in some cases, it is desirable for assistive technologies to present the content when it appears. For example, it maybe useful if assistive technologies announce the title and caption text of new windows when they appear. To enable such behavior, do the following:

• Set the role of the component containing the window title to header
• Set the role of any components containing text that provides a summary of the window content to summary

In most cases, forcing the screen reader to read something using this method is the wrong thing to do and you should use it sparingly or consult the accessibility team for guidance on the optimal approach.

Accessibility Properties Changes in 0.72

ARIA-style props were introduced in React Native 0.71 as aliases to existing React Native accessibility props. Each "aria-*" prop has precedence over any existing equivalents. Use their ARIA-style counterparts for the following accessibility properties:

• accessibilityLabel - use aria-label instead
• accessibilityLabelledBy - use aria-labelledby instead
• accessibilityLiveRegion - use aria-live instead
• accessibilityRole - use role instead
• accessibilityState - use aria-checked, aria-disabled, aria-expanded instead
• accessibilityValue - use aria-valuemin, aria-valuemax, aria-valuenow, and aria-valuetext instead
• accessibilityElementsHidden - use aria-hidden instead

API Reference

Accessibility properties

Like Android and iOS, Kepler provides methods for integrating apps with assistive technologies. React Native provides complementary method that let your app accommodate all users.

Currently active and supported properties

The following properties are the currently supported and recommended for the use. These properties have precedence over the removed counterparts.

accessible

When true , indicates that the view is an accessibility element. When a view is an accessibility element, it groups its children into a single selectable component. By default, all touchable or navigable (using DPAD) elements are accessible.

On Kepler, accessible={true} property for a React Native View and Image component will be translated into native focusable={true} . Note that this behavior might be de-linked on Kepler in future release. Therefore, relying solely on the accessible property to indicate focusable elements is not recommended.

Accepted values

Example usage

// setting accessible as true for the View here makes it as a single selectable component and its children Text components cannot be selected as a standalone component.

<View accessible={true}>
  <Text>Text one</Text>
  <Text>Text two</Text>
</View>

In the previous example, we can't get accessibility focus separately on 'text one' and 'text two'. Instead we get focus on a parent View with 'accessible' property.

accessibilityDescribedBy

This property receives a list of nativeID of elements which describe this element. It can be used in the context of TV to link an individual content tile with the details view or other on-screen elements which describe it.

Accepted values

Example usage

<View>
  <Text nativeID='usernameText'>Enter a username</Text>
  <TextInput 
    placeholder='Name'
    aria-label='Username'
    accessibilityDescribedBy={['usernameText']} />
</View>

accessibilityHint

accessibilityHint helps users understand what happens when they perform an action on the accessibility element when that result is not clear from the accessibility label.

Accepted values

<TouchableOpacity
  accessible={true}
  aria-label="Go back"
  accessibilityHint="Navigates to the previous screen"
  onPress={onPress}>
  <View style={styles.button}>
    <Text style={styles.buttonText}>Back</Text>
  </View>
</TouchableOpacity>

In the previous example, VoiceView reads the hint after the label.

accessibilityOrientationText

This optional string property describes how a user should interact with content inside this pane. It should only be included when the understanding of the visual layout of content is essential to navigating it successfully.

Accepted values

Example usage

// here orientation is a state that change based on the screen orientation ['portrait' or 'landscape']

<View
    accessible={true}
    role="text"
    aria-label="Screen Orientation Text"
    accessibilityOrientationText={`Screen is in ${orientation} mode`}>
    <Text>{orientation==='landscape' ? "Horizontal" : "Vertical"}</Text>
</View>

aria-checked

Indicates the state of a checkable element. This field accepts a boolean value (true/false) or a "mixed" string to represent partially checked checkboxes. It has the same behavior as accessibilityState.checked which will be removed in the future.

Accepted values

Example usage

// here isChecked is a boolean state variable.

<Pressable 
    onPress={handlePress}
    aria-checked={isChecked}
    role="checkbox"/>

aria-disabled

Indicates that the element is perceivable but disabled, so it is not editable or otherwise operable. It has the same behavior as accessibilityState.disabled which will be removed in the future.

Accepted values

Example usage

// handleValueChange is an event handler for onValueChange event. isMuted is a state variable that is modified by handleValueChange event handler.

<Switch
    onValueChange={handleValueChange}
    value={isMuted}
    aria-label="Mute Switch"
    aria-disabled={false}
    role="switch"
/>

aria-expanded

Indicates whether an expandable element is currently expanded or collapsed. It has the same behavior as accessibilityState.expanded which will be removed in the future.

Accepted values

Example usage

// here expanded is a state variable that change when we press the TouchableOpacity button and the state changes are handled by handlePress eventHandler. 

<View style={styles.container}>
    <TouchableOpacity
        onPress={handlePress}
        aria-expanded={expanded}
        role="button">
        <Text>{expanded ? "Collapse" : "Expand"} Section</Text>
    </TouchableOpacity>
</View>

aria-hidden

Indicates whether the current element and its children are not exposed to the assistive technologies like screen readers.

For example, when the aria-hidden property is set to true, UI Components such as View or TouchableOpacity hide the component and its children from the assistive technologies, thereby not reflecting or announcing the changes to the user.

Accepted values

Example usage

<View aria-hidden={true} aria-label="Product Container">
  <Text aria-label="Product Name">Smartphone</Text>
  <Text aria-label="Manufacturing Month">July</Text>
</View>

In the previous example the aria-hidden is set to true. This causes assistive technologies such as screen readers to ignore the announcement of the aria-label values of the View as well as its child components (both Text components).

aria-label

It is generally advised to set an aria-label on the UI component which are targeted by assistive technologies, so that people who use VoiceView know what element they have selected. VoiceView reads this string when a user selects the associated element.

Accepted values

Example usage

<TouchableOpacity
  accessible={true}
  aria-label="Tap me!"
  onPress={onPress}>
  <View style={styles.button}>
    <Text style={styles.buttonText}>Press me!</Text>
  </View>
</TouchableOpacity>

In the previous example, the aria-label on the TouchableOpacity element defaults to "Press me!". The default value is formed by concatenating all child Text nodes separated by spaces. However, since we have explicitly set the value for aria-label , the value of TouchableOpacity element would be '"Tap me!".

aria-labelledby

This property takes a reference to nativeID of another element that labels the element it is applied to. This property is useful in building complex forms.

Accepted values

Example usage

<View>
  <Text nativeID="formLabel">Label for Input Field</Text>
  <TextInput
    aria-labelledby="formLabel"
  />
</View>

In the previous example, the screen reader announces '“Input Edit Box for Label for Input Field” when focusing on the TextInput component.

aria-live

When components dynamically change, we want VoiceView to notify the update to the end user. This is made possible by the aria-live property. The aria-live property takes one of the three below mentioned values.

• off - Accessibility services will not announce changes to this view.
• polite - Accessibility services will announce changes to this view.
• assertive - Accessibility services will interrupt ongoing speech to immediately announce changes to this view.

Accepted values

Example usage

// here addOne is an event handler that adds increments value of count state variable by 1. 

<TouchableWithoutFeedback onPress={addOne}>
  <View style={styles.embedded}>
    <Text>Click me</Text>
  </View>
</TouchableWithoutFeedback>
<Text aria-live="polite">
  Clicked {count} times
</Text>

In the previous example, the method addOne changes the state variable count . As soon as an end user clicks the TouchableWithoutFeedback component, VoiceView reads text in the Text view because of its accessibilityLiveRegion="polite" property.

aria-selected

Indicates whether a selectable element is currently selected or not. It has the same behavior as accessibilityState.selected which will be removed in the future.

Accepted values

Example usage

// here addOne is an event handler that adds increments value of count state variable by 1. 

<View>
  <Text aria-selected={true}>
     This component is set with the property aria-selected as true
  </Text>   
</View>

aria-valuemax

Represents the maximum value for range-based components, such as sliders and progress bars. It has the same behavior as accessibilityValue.max which will be removed in the future.

Accepted values

Example usage

// here styles is an stylesheet object which has progress object that has styles for the progress bar.

<View
    accessible={true}
    aria-label="Progress Bar"
    role="progressbar"
    aria-valuemax={100}
    style={styles.progress}/>

aria-valuemin

Represents the minimum value for range-based components, such as sliders and progress bars. It has the same behavior as accessibilityValue.min which will be removed in the future.

Accepted values

Example usage

// here styles is a stylesheet object which has progress object that has styles for the progress bar.

<View
    accessible={true}
    aria-label="Progress Bar"
    role="progressbar"
    aria-valuemin={0}
    style={styles.progress}/>

aria-valuenow

Represents the current value for range-based components, such as sliders and progress bars. It has the same behavior as accessibilityValue.now which will be removed in the future.

Accepted values

Example usage

// here styles is an stylesheet object which has progress object that has styles for the progress bar. 

<View
    accessible={true}
    aria-label="Progress Bar"
    role="progressbar"
    aria-valuenow={25}
    style={styles.progress}/>

aria-valuetext

Represents the textual description of the component for which the numeric values mentioned above are not meaningful. It has the same behavior as accessibilityValue.text which will be removed in the future.

Accepted values

Example usage

// here styles is an stylesheet object which has progress object that has styles for the progress bar.

<View
    accessible={true}
    aria-label="Progress Bar"
    role="progressbar"
    aria-valuetext={'Low'}
    style={styles.progress}/>

role

The role property communicates the purpose of a component to the user of an assistive technology. Has precedence over the accessibilityRole property.

role can be one of the following:

Example usage

<View
    accessible={true}
    role="header"
    style={styles.container}>
    <Text> Header Element </Text>
</View>

transportControls

This property indicates that the element contains transport controls.

Accepted values

Example usage

 
<View
    style={styles.container}
    transportControls={{
        play:'playButton',
        forward:'forwardButton'
    }}>
    <TouchableOpacity 
        nativeID={'playButton'}>
        <Text>Play Button</Text>
    </TouchableOpacity>
    <TouchableOpacity 
        nativeID={'forwardButton'}>
        <Text>Forward Button</Text>
    </TouchableOpacity>
</View>

Properties that will be removed

These properties will eventually be removed in future releases. You should use the respective ARIA properties instead. Note that ARIA properties have precedence over the removed accessibility properties.

accessibilityElementsHidden

This property has same behavior as aria-hidden, which has a precedence over this property.

Example usage

<View 
    accessible={true}
    accessibilityElementsHidden={true}
    style={styles.container}>
    <Text>This section cannot be seen by assistive technologies</Text>
</View>

accessibilityLabel

This property has same behavior as aria-label , which has a precedence over this property.

Example usage

<TouchableOpacity 
    accessibilityLabel="Close Menu Bar">
    <Text>Close Menu</Text>
</TouchableOpacity>

accessibilityLabelledBy

This property has same behavior as aria-labelledby, which has a precedence over this property.

Example usage

<View>
  <Text nativeID="formLabel">Label for Input Field</Text>
  <TextInput accessibilityLabel="input" accessibilityLabelledBy="formLabel" />
</View>

accessibilityLiveRegion

This property has same behavior as aria-live , which has a precedence over this property.

Example usage

// In this example hours is a state that gets updated on every hour.
 
<View
    style={styles.container}>
    <Text
        accessibilityLiveRegion="assertive"
        style={styles.text}>
        Time in hours is {hours}
    </Text>    
</View>

accessibilityRole

This property has same behavior as role, which has a precedence over this property.

Example usage

<View 
    accessibilityRole="button"
    accessible={true}
    onPress={handlePress}>
    <Text>Move to Home Page</Text>  
</View>

accessibilityState

Describes the current state of a component to the user of an assistive technology. It is a combination of aria-checked , aria-disabled , aria-expanded , aria-selected properties.

Accepted values

Example usage

<View>
   <Text> Simple Switch</Text>
   <Switch
        accessibilityLabel="simple_switch"
        accessibilityRole="switch"
        accessibilityState={{ disabled: false}}
        onChange={handleChange}/>
</View>

accessibilityValue

Represents the current value of a component. It can be a textual description of a component's value, or for range-based components, such as sliders and progress bars, it contains range information (minimum, current, and maximum). It is a combination of aria-valuemin, aria-valuemax, aria-valuenow, aria-valuetext properties.

Accepted values

Example usage

// here value is a numeric constant and convertToMeaningText is a method that
// takes value and convert it to textual description of the value.

<View>
   <Text> Download Progress Bar</Text>
   <View
        accessible={true}
        accessibilityLabel="Progress Bar"
        accessibilityRole="progressbar"
        accessibilityValue={{min: 0, 
                             max: 100, 
                             now: value,
                             text:convertToMeaningfulText(value)}}
        style={styles.progress}/>
</View>

Accessibility Actions

Accessibility actions allow an assistive technology to programmatically invoke the actions of a component. In order to support accessibility actions, a component must do two things:

• Define the list of actions it supports via the accessibilityActions property.
• Implement an onAccessibilityAction function to handle action requests.

The accessibilityActions property should contain a list of action objects. Each action object should contain the following fields:

Actions either represent standard actions, such as clicking a button or adjusting a slider, or custom actions specific to a given component such as deleting an email message. The name field is required for both standard and custom actions, but label is optional for standard actions.

The label field is optional for standard actions, and is often unused by assistive technologies. For custom actions, it is a localized string containing a description of the action to be presented to the user.

To handle action requests, a component must implement an onAccessibilityAction() method. The only argument to this method is an event containing the name of the action to perform. The below example shows how to create a component which defines and handles several custom actions.

<View
  accessible={true}
  accessibilityActions={[
    {name: 'cut', label: 'cut'},
    {name: 'copy', label: 'copy'},
    {name: 'paste', label: 'paste'},
  ]}
  onAccessibilityAction={(event) => {
    switch (event.nativeEvent.actionName) {
      case 'cut':
        Alert.alert('Alert', 'cut action success');
        break;
      case 'copy':
        Alert.alert('Alert', 'copy action success');
        break;
      case 'paste':
        Alert.alert('Alert', 'paste action success');
        break;
    }
  }}
/>

Related topics

• AccessibilityInfo
• Making React Native Apps Accessible

Last updated: Sep 30, 2025