- Application being made accessible
- Accessibility framework
- Assistive technology
Assistive technologies in Vega Fire TV
React Native for Vega 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:-
Run the following command.
vega exec vda shell -
In the shell, enable VoiceView with the following key combination (hold Back + Menu for 3 seconds).
{ echo -e button_hold KEY_BACK; echo -e button_hold KEY_MENU; sleep 3; echo -e button_release KEY_BACK; echo -e button_release KEY_MENU; echo exit; } | inputd-cli start
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:-
Run the following command.
vega exec vda shell -
In the shell, enable Screen Magnifier with the following key combination (hold Back + Menu for 3 seconds).
{ echo -e button_hold KEY_FASTFORWARD; echo -e button_hold KEY_BACK; sleep 3; echo -e button_release KEY_FASTFORWARD; echo -e button_release KEY_BACK; echo exit; } | inputd-cli start
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:-
Run the following command.
vega exec vda shell -
In the shell, enable Text Banner with the following key combination (hold Back + Menu for 3 seconds).
{ echo -e button_hold KEY_FASTFORWARD; echo -e button_hold KEY_REWIND; sleep 3; echo -e button_release KEY_FASTFORWARD; echo -e button_release KEY_REWIND; echo exit; } | inputd-cli start
Guidance for implementing accessibility in Vega for Fire TV
This section provides guidance on implementing accessibility features in React Native for Vega applications. It covers brief descriptions of how to use standard React Native accessibility features, as well as React Native for Vega specific additions. Developers should follow these best practices to make sure their apps are usable by people with disabilities. To make your React Native for Vega 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 Vega.Standard React Native accessibility best practices
Labelling a Component
Use thearia-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)
- 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 therole 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,falseorundefined(for not selectable components). Some of the selectable components aregridcell,tab,listbox.
Providing accessibility value-related Information
Use thearia-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 theaccessibilityHint property to a custom string on your view.
Exposing dynamic content changes in live regions
You can use thearia-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 heading, summary is recommended to notify users of the update.
- Making it a live region (aria-live) - Alternatively, setting
aria-liveproperty 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
accessibleproperty astruewith the associated accessibility texts ( such asaria-labeloraria-labelledby), will enable assistive technologies to make announcements when a user selects the element.
React Native for Vega specific accessibility properties
This section describes properties which are not standard to React Native but are supported in React Native for Vega.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 theaccessibilityOrientationText 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.
Describing the focused item
One of the challenges with the React Native for Vega 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 calledaccessibilityDescribedBy. 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.
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
heading - Set the role of any components containing text that provides a summary of the window content to
summary
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, Vega 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 Vega, 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 Vega in a future release. Therefore, relying solely on the accessible property to indicate focusable elements isn’t recommended.
Accepted values
Example usage
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
role
The role property communicates the purpose of a component to the user of an assistive technology. Has precedence over the accessibilityRole property.
Supported role values:
Example usage
transportControls
This property indicates that the element contains transport controls.
Accepted values
Example usage
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
accessibilityLabel
This property has same behavior as aria-label , which has a precedence over this property.
Example usage
accessibilityLabelledBy
This property has same behavior as aria-labelledby, which has a precedence over this property.
Example usage
accessibilityLiveRegion
This property has same behavior as aria-live , which has a precedence over this property.
Example usage
accessibilityRole
This property has the same behavior as role, which takes precedence over this property.
The accessibilityRole propert can be one of the following:
Example usage
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
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
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
accessibilityActionsproperty. - Implement an
onAccessibilityActionfunction to handle action requests.
accessibilityActions property should contain a list of action objects. Each action object should contain the following fields:
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.

