Accessibility

Accessibility in React Native for Web combines several separate web APIs into a cohesive system. Assistive technologies (e.g., VoiceOver, TalkBack screen readers) derive useful information about the structure, purpose, and interactivity of web apps from their HTML elements, attributes, and ARIA in HTML.

Accessibility Props API

React Native for Web includes APIs for making accessible apps. The most common and well supported accessibility features of the Web are exposed as platform-agnostic accessibility* props.

Accessibility patterns

Links

The Text and View components can be rendered as links. If the href prop is set, the element will render <a> tags without altering the presentation of the element.

<Text href="/" />
// <a href="/" ></a>

The hrefAttrs prop sets link-related attributes.

const hrefAttrs = { download: true, rel: "nofollow", target: "blank" };

<Text
  href="/document.pdf"
  hrefAttrs={hrefAttrs}
/>
// <a download href="/document.pdf" rel="nofollow" target="_blank"></a>

Keyboard focus

The focusable prop determines whether a component is user-focusable and appears in the keyboard tab flow. This prop should be used instead of the accessible prop found in React Native for Android/iOS, which is not implemented by React Native for Web/Windows/macOS.

<View focusable={true} />
// <div tabindex="0"></div>

<Text focusable={false} href="/" />
// <a href="/" tabindex="-1"></a>

Accessible HTML

React Native for Web components express semantics exclusively via the accessibility* props which are equivalent to aria-* attributes. For example, accessibilityRole is equivalent to the HTML role attribute, accessibilityLabel is equivalent to aria-label, etc. (Additional compatibility with React Native accessibility props is also included.)

<View
  accessibilityLabel="..."
  accessibilityPressed={false}
  accessibilityRole="menuitem"
  nativeID="abc"
/>
/*
<div
  aria-label="..."
  aria-pressed="false"
  id="abc"
  role="menuitem"
/>
*/

Semantic HTML

The value of the accessibilityRole prop is used to infer an analogous HTML element where appropriate. This is done to rely on well-supported native mechanisms for encoding semantics and accessibility information.

<View accessibilityRole="article">
  <Text accessibilityRole="paragraph">This is an article</Text>
</View>
/*
<article>
  <div role="paragraph">This is an article</div>
</article>
*/

The "paragraph" role isn’t mapped to a <p> tag because it’s an HTML conformance error to include block-level children within the element; both Text and View support block-level children.

If the "heading" role is combined with an accessibilityLevel, the equivalent HTML heading element is rendered. Otherwise, it is rendered as <h1>.

<Text accessibilityRole="heading" /> /* <h1> */
<Text accessibilityRole="heading" accessibilityLevel={2} /> /* <h2> */

Note: Avoid changing accessibilityRole values over time or after user actions. Generally, accessibility APIs do not provide a means of notifying assistive technologies if a role changes.