Suggestion about accessibility improvements roadmap

[mika-lindell]

Accessibility is in demand right now, and this is my attempt to make a draft of accessibility roadmap for react-native-date-picker.
IosClone and AndroidVariant are fundamentally so different, that I've found they require separate solutions to fix similar problems (event though the API looks the same).

Principles

• IosClone should implement accessibility similar to the wheel picker used in iOS
• AndroidNative should implement accessibility of the vanilla NumberPicker
• Each wheel should be treated as a single control from the perspective of accessibility: One can change focus to read the value of the other wheels, if one so wishes
  • Best practice is to avoid long readouts, so interacting is faster when you rely on spoken feedback
  • When wheel is focused, only the state of that wheel should be considered when creating accessibility
• All controls should be compatible with a keyboard

IosPicker

When element is accessibility focused

• EXPECTED
  • Should read display value, content description and role of the control
    • For example Tuesday second of March, set date, slider
    • feat: improved spoken feedback #390
  • Should function like a slider
    • Volume keys (< android 11) or flick up/down (>= android 11) should increase / decrease value
    • feat: improved spoken feedback #390
  • Additionally, should explain how to use the control. This might be automagically done by TalkBack if everything is set up correctly
    • feat: improved spoken feedback #390
• ACTUAL
  • Reads only content description: Set date

When scrolling

• EXPECTED
  • Should read out loud new display value when it changes during scroll
    • fix: talkback read display value on scroll value change #373

When value is selected

• EXPECTED
  • Should only read the display value of the wheel currently active
    • For example: Tuesday second of March
    • feat: improved spoken feedback #390
• ACTUAL
  • Reads content of all wheels
    • For example: Selected value: Tuesday second of March 2021, 12:15 pm

When using with keyboard

• EXPECTED
  • Should be able to increment / decrement value using keyboard
    • feat: improved spoken feedback #390
• ACTUAL
  • It's not possible to increment / decrement value using volume buttons --> This is how sliders (android.widget.seekBar) work w/ keyboard, you can experiment with system volume or brightness sliders for example.

AndroidNative

When element is accessibility focused

• EXPECTED
  • Should read display value and role of the control

When selected value is accessibilityFocused

• EXPECTED
  • Should read display value, state and role of the control
    • For example 3rd of May, selected, button
• ACTUAL
  • Reads 3rd of May, editbox, but you can't use it like you would use editbox (==native input field)

When scrolling

• EXPECTED
  • Should read out loud new display value when it changes during scroll
• ACTUAL
  • Interrupts the reading of selected value to read values from other wheels

When value is selected

• EXPECTED
  • Should only read the display value of the wheel currently active

When using with keyboard

• EXPECTED
  • Should be able to increment / decrement value using keyboard

Resources

• Accessibility-related code at React Native repository:
  • https://github.com/facebook/react-native/blob/cbec66ef9250319258bf4c917518c08c34b0d3cd/ReactAndroid/src/main/java/com/facebook/react/uimanager/ReactAccessibilityDelegate.java
  • https://github.com/facebook/react-native/blob/1465c8f3874cdee8c325ab4a4916fda0b3e43bdb/ReactAndroid/src/main/java/com/facebook/react/modules/accessibilityinfo/AccessibilityInfoModule.java
• performAccessibilityAction could be used to create the scroll up/down with keyboard -feature
  • https://developer.android.com/reference/android/view/View.AccessibilityDelegate

[henninghall]

Great summary! Just let me know if you get stuck somewhere or have questions about the codebase, and I'll try to help out!

[mika-lindell]

For any random person reading this issue just want to say following: I might not have the chance to fix everything in the list above. So if you find you're in need of some accessibility improvements, I hope you can use this as inspiration and chip in :)

[andriikovall]

Hi, we have encountered a transparent component that is focusable by talkback on Android.

I have found a place where it is located and can be easily fixed by adding importantForAccessibility="no" to the images

Should I create a new issue or what?

Package version 4.1.1
RN 0.66.0
Android 9

[henninghall]

@ziovio Great catch, thanks for the PR!

[hcbreedl]

Any updates here by chance? The Android variant still doesn't read interaction instructions correctly. It reads "edit box, double tap to edit text, double and hold to apply, button, double tap to activate". The above and below options read "button, double tap to activate, double and hold to long apply, button, double tap to activate". This package is almost ideal for our use case but may not be selectable due to this a11y limitation.