Specify keyboard focus separately from Screen Reader focus

Description

On Android keyboard focus and accessibility focus are handled separately at the system level. Often these match, as many accessibility services use the “focusable” property (which informs keyboard focus), to also inform them where to focus. In API 28 however, Android added the setScreenReaderFocusable property to View (https://developer.android.com/reference/android/view/View#setScreenReaderFocusable(boolean)) which allows you to flag a view as being focusable only for screen readers, without making that same view focusable by keyboards.

This is useful since screen readers often want to focus on views that are content only, but not actionable (so their users can hear the content), but focusing on these content elements is not useful for keyboard navigation users, who only need to be able to move between interactive elements.

Right now in React Native, the accessible prop maps to focusable on Android, making the element focusable by both screen readers and keyboard users.

There are a few different approaches we could take here. We could surface a new prop called screenReaderFocusable, that sets focusable to false but screenReaderFocusable to true, we could adjust the accessible prop to only set screenReaderFocusable to true, and add a new prop for keyboardFocusable which sets focusable to true, or we could have the accessible prop contextually set either focusable (if the element is interactive by having a click handler) or screenreaderFocusable (if it’s content only).

Version

0.66

Output of npx react-native info

see description

Steps to reproduce

see description

Snack, code example, screenshot, or link to a repository

see description

Beginne damit zu überprüfen, wie React Natives Android-Prop für Barrierefreiheit derzeit auf focusable abgebildet wird, und lies anschließend die verlinkte Android-View-API setScreenReaderFocusable. Vergleiche die vorgeschlagenen Prop-Designs und lege fest, welches Verhalten für interaktive beziehungsweise ausschließlich Inhalte anzeigende Views gelten soll. Als erledigt gilt die Festlegung einer API sowie eines getrennten Fokusverhaltens für Tastatur und Screenreader.