|
| 1 | +--- |
| 2 | +title: Improvements to accessibilityRole and accessibilityStates |
| 3 | +author: |
| 4 | +- Marc Mulcahy |
| 5 | +date: 2019-02-06 |
| 6 | +--- |
| 7 | + |
| 8 | +## Summary |
| 9 | + |
| 10 | +Some brilliant work was begun to add cross platform support for accessibility roles and states to React Native. We propose to add some additional roles and states, as well as extend the implementation on Android and Fire OS. |
| 11 | + |
| 12 | +## Basic example |
| 13 | + |
| 14 | +With the current set of roles, it is not possible to describe a checkbox. These changes would enable this scenario, among other things: |
| 15 | + |
| 16 | + <View |
| 17 | + accessibilityRole="checkbox" |
| 18 | + accessibilityStates={['unchecked']}> |
| 19 | + <Text>Show Password</Text> |
| 20 | + </View> |
| 21 | + |
| 22 | +## Motivation |
| 23 | + |
| 24 | +When developers build components in JavaScript, they need the ability to express the role and current state(s) of the component to assistive technologies running on the platform. |
| 25 | + |
| 26 | +## Detailed design |
| 27 | + |
| 28 | +### New Roles |
| 29 | + |
| 30 | +This proposal adds the following roles: |
| 31 | + |
| 32 | +- alert |
| 33 | +- checkbox |
| 34 | +- combobox |
| 35 | +- editabletext |
| 36 | +- menu |
| 37 | +- menubar |
| 38 | +- menuitem |
| 39 | +- progressbar |
| 40 | +- radiobutton |
| 41 | +- radiogroup |
| 42 | +- scrollbar |
| 43 | +- spinbutton |
| 44 | +- switch |
| 45 | +- tab |
| 46 | +- tablist |
| 47 | +- timer |
| 48 | +- toolbar |
| 49 | + |
| 50 | +### New States |
| 51 | + |
| 52 | +This proposal adds the following states: |
| 53 | + |
| 54 | +- on |
| 55 | +- off |
| 56 | +- checked |
| 57 | +- unchecked |
| 58 | +- busy |
| 59 | +- expanded |
| 60 | +- collapsed |
| 61 | +- hasPopup |
| 62 | + |
| 63 | +### Fallback Mechanism for Roles |
| 64 | + |
| 65 | +There are several roles which don't have native analogs on a given platform. For such roles, a fallback mechanism will be used. |
| 66 | + |
| 67 | +#### Android |
| 68 | + |
| 69 | +The fallback mechanism is already in place on Android. For roles which don't have standard Android view analogs, the class name of the AccessibilityNodeInfo is set to the class name of the closest native Android view type, and the roleDescription extra is set to a localized textual description of the role. |
| 70 | + |
| 71 | +### Fire OS |
| 72 | + |
| 73 | +For Fire OS, we will always embed the role as a key/value pair in the AccessibilityNodeInfo's extra bundle. |
| 74 | + |
| 75 | +key: com.amazon.accessibility.role |
| 76 | +value: the role string |
| 77 | + |
| 78 | +The role string should not be localized-- it should be one of the constants defined above, or in the existing documentation. This will allow assistive technologies on Fire OS to consume the role directly. |
| 79 | + |
| 80 | +#### iOS |
| 81 | + |
| 82 | +For roles which don't have a corresponding iOS accessibilityTrait, we recommend appending a localized version of the role description to the accessibilityValue of the component. |
| 83 | + |
| 84 | +### Additional States Implementation Notes |
| 85 | + |
| 86 | +Android has slightly more robust state support than does iOS. The following states can be represented with Android'd standard accessibility API: |
| 87 | + |
| 88 | +- checked |
| 89 | +- unchecked |
| 90 | +- expanded |
| 91 | +- collapsed |
| 92 | +- hasPopup |
| 93 | + |
| 94 | +We will append a localized description of other states to the component's content description. |
| 95 | + |
| 96 | +on iOS, a localized description of states which do not have corresponding accessibilityTraits will be appended to the component's accessibilityValue. |
| 97 | + |
| 98 | +## Drawbacks |
| 99 | + |
| 100 | +Supporting these additional roles and states will necessarily make the platform accessibility implementations a bit more complex, especially when supporting roles and states which have no native analog on a given platform. |
| 101 | + |
| 102 | +We do not see this impacting any existing code. Developers who choose to use the new roles and states will get improved accessibility functionality. Those who choose not to will see no change in the behavior of their existing code. |
| 103 | + |
| 104 | +## Alternatives |
| 105 | + |
| 106 | +The only alternative is to recommend that developers append the role and state information to the text of the accessibility label. This does not allow a disabled user to control how much, and in what order, they hear information about a component. It also does not support compact rendering of role and state information in braille. It also requires localization effort in each component which employs it. |
| 107 | + |
| 108 | +## Adoption strategy |
| 109 | + |
| 110 | +We should document the additional roles and states as part of the official accessibility API documentation. Developers can then start using them if they choose. |
| 111 | + |
| 112 | +## How we teach this |
| 113 | + |
| 114 | +The attempt with this proposal is to bring React Native accessibility support one step closer to generally accepted accessibility idioms and practices as specified by standards such as ARIA. As such, we believe this will make it easier for developers familiar with accessibility on the web or other platforms to relate React Native's accessibility support to what they already know. |
| 115 | + |
| 116 | +## Unresolved questions |
| 117 | + |
| 118 | +- Roles imply supported states and behaviors. For example, checkboxes imply the checked state, and the ability to be toggled. Radio groups typically only allow one child to be selected, etc. When a component specifies its role, should this programmatically require the developer to implement certain behaviors? Alternatively, what mechanisms exist to present warnings during compile time for missing behaviors? |
0 commit comments