mirror of
https://github.com/zhigang1992/react-native.git
synced 2026-04-26 13:25:51 +08:00
Release React Native for Android
This is an early release and there are several things that are known not to work if you're porting your iOS app to Android. See the Known Issues guide on the website. We will work with the community to reach platform parity with iOS.
This commit is contained in:
Martin Konicek
@@ -1,23 +1,40 @@
|
||||
---
|
||||
id: accessibility
|
||||
title: Accessibility (iOS)
|
||||
title: Accessibility
|
||||
layout: docs
|
||||
category: Guides
|
||||
permalink: docs/accessibility.html
|
||||
next: native-modules-ios
|
||||
---
|
||||
|
||||
## iOS
|
||||
Accessibility on iOS encompasses many topics, but for many, accessibility is synonymous with VoiceOver, a technology available since iOS 3.0. It acts as a screen reader, allowing people with visual impairments to use their iOS devices. Click [here](https://developer.apple.com/accessibility/ios/) to learn more.
|
||||
|
||||
## Android
|
||||
Accessibility on Android involves many diverse topics, one of which is enabling people with vision loss to use your application. For this community, Google provides a built-in screen reader service with Android called TalkBack. With TalkBack, you can use touch exploration and gestures to navigate a mobile device and application. TalkBack will read back the content on screen using text-to-speech and alert users to important notifications within your application. Click [here](https://support.google.com/accessibility/android) to learn more about Android accessibility features and [here](https://developer.android.com/guide/topics/ui/accessibility) to learn more about making your native applications accessible.
|
||||
|
||||
## Making Accessible Apps
|
||||
|
||||
### Coding Accessibly
|
||||
### Accessibility properties
|
||||
|
||||
#### accessible
|
||||
#### accessible (iOS, Android)
|
||||
|
||||
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 elements are accessible.
|
||||
|
||||
#### accessibilityLabel
|
||||
On Android, ‘accessible={true}’ property for a react-native View will be translated into native ‘focusable={true}’.
|
||||
|
||||
```javascript
|
||||
<View accessible={true}>
|
||||
<Text>text one</Text>
|
||||
<Text >text two</Text>
|
||||
</View>
|
||||
```
|
||||
|
||||
In the above example, we can't get accessibility focus separately on 'text one' and 'text two'. Instead we get focus on a parent view with 'accessible' property.
|
||||
|
||||
|
||||
|
||||
#### accessibilityLabel (iOS, Android)
|
||||
|
||||
When a view is marked as accessible, it is a good practice to set an accessibilityLabel on the view, so that people who use VoiceOver know what element they have selected. VoiceOver will read this string when a user selects the associated element.
|
||||
|
||||
@@ -33,7 +50,7 @@ To use, set the `accessibilityLabel` property to a custom string on your View:
|
||||
|
||||
In the above example, the `accessibilityLabel` on the TouchableOpacity element would default to "Press me!". The label is constructed by concatenating all Text node children separated by spaces.
|
||||
|
||||
#### accessibilityTraits
|
||||
#### accessibilityTraits (iOS)
|
||||
|
||||
Accessibility traits tell a person using VoiceOver what kind of element they have selected. Is this element a label? A button? A header? These questions are answered by `accessibilityTraits`.
|
||||
|
||||
@@ -57,15 +74,95 @@ To use, set the `accessibilityTraits` property to one of (or an array of) access
|
||||
* **allowsDirectInteraction** Used when an element allows direct touch interaction for VoiceOver users (for example, a view representing a piano keyboard).
|
||||
* **pageTurn** Informs VoiceOver that it should scroll to the next page when it finishes reading the contents of the element.
|
||||
|
||||
#### onAccessibilityTap
|
||||
#### onAccessibilityTap (iOS)
|
||||
|
||||
Use this property to assign a custom function to be called when someone activates an accessible element by double tapping on it while it's selected.
|
||||
|
||||
#### onMagicTap
|
||||
#### onMagicTap (iOS)
|
||||
|
||||
Assign this property to a custom function which will be called when someone performs the "magic tap" gesture, which is a double-tap with two fingers. A magic tap function should perform the most relevant action a user could take on a component. In the Phone app on iPhone, a magic tap answers a phone call, or ends the current one. If the selected element does not have an `onMagicTap` function, the system will traverse up the view hierarchy until it finds a view that does.
|
||||
|
||||
### Testing VoiceOver Support
|
||||
#### accessibilityComponentType (Android)
|
||||
|
||||
In some cases, we also want to alert the end user of the type of selected component (ie, that it is a “button”). If we were using native buttons, this would work automatically. Since we are using javascript, we need to provide a bit more context for TalkBack. To do so, you must specify the ‘accessibilityComponentType’ property for any UI component. For instances, we support ‘button’, ‘radiobutton_checked’ and ‘radiobutton_unchecked’ and so on.
|
||||
|
||||
```javascript
|
||||
<TouchableWithoutFeedback accessibilityComponentType=”button”
|
||||
onPress={this._onPress}>
|
||||
<View style={styles.button}>
|
||||
<Text style={styles.buttonText}>Press me!</Text>
|
||||
</View>
|
||||
</TouchableWithoutFeedback>
|
||||
```
|
||||
|
||||
In the above example, the TouchableWithoutFeedback is being announced by TalkBack as a native Button.
|
||||
|
||||
#### accessibilityLiveRegion (Android)
|
||||
|
||||
When components dynamically change, we want TalkBack to alert the end user. This is made possible by the ‘accessibilityLiveRegion’ property. It can be set to ‘none’, ‘polite’ and ‘assertive’:
|
||||
|
||||
* **none** Accessibility services should not announce changes to this view.
|
||||
* **polite** Accessibility services should announce changes to this view.
|
||||
* **assertive** Accessibility services should interrupt ongoing speech to immediately announce changes to this view.
|
||||
|
||||
```javascript
|
||||
<TouchableWithoutFeedback onPress={this._addOne}>
|
||||
<View style={styles.embedded}>
|
||||
<Text>Click me</Text>
|
||||
</View>
|
||||
</TouchableWithoutFeedback>
|
||||
<Text accessibilityLiveRegion="polite">
|
||||
Clicked {this.state.count} times
|
||||
</Text>
|
||||
```
|
||||
|
||||
In the above example method _addOne changes the state.count variable. As soon as an end user clicks the TouchableWithoutFeedback, TalkBack reads text in the Text view because of its 'accessibilityLiveRegion=”polite”' property.
|
||||
|
||||
#### importantForAccessibility (Android)
|
||||
|
||||
In the case of two overlapping UI components with the same parent, default accessibility focus can have unpredictable behavior. The ‘importantForAccessibility’ property will resolve this by controlling if a view fires accessibility events and if it is reported to accessibility services. It can be set to ‘auto’, ‘yes’, ‘no’ and ‘no-hide-descendants’ (the last value will force accessibility services to ignore the component and all of its children).
|
||||
|
||||
```javascript
|
||||
<View style={styles.container}>
|
||||
<View style={{position: 'absolute', left: 10, top: 10, right: 10, height: 100,
|
||||
backgroundColor: 'green'}} importantForAccessibility=”yes”>
|
||||
<Text> First layout </Text>
|
||||
</View>
|
||||
<View style={{position: 'absolute', left: 10, top: 10, right: 10, height: 100,
|
||||
backgroundColor: 'yellow'}} importantForAccessibility=”no-hide-descendant”>
|
||||
<Text> Second layout </Text>
|
||||
</View>
|
||||
</View>
|
||||
```
|
||||
|
||||
In the above example, the yellow layout and its descendants are completely invisible to TalkBack and all other accessibility services. So we can easily use overlapping views with the same parent without confusing TalkBack.
|
||||
|
||||
|
||||
|
||||
### Sending Accessibility Events (Android)
|
||||
|
||||
Sometimes it is useful to trigger an accessibility event on a UI component (i.e. when a custom view appears on a screen or a custom radio button has been selected). Native UIManager module exposes a method ‘sendAccessibilityEvent’ for this purpose. It takes two arguments: view tag and a type of an event.
|
||||
|
||||
```javascript
|
||||
_onPress: function() {
|
||||
this.state.radioButton = this.state.radioButton === “radiobutton_checked” ?
|
||||
“radiobutton_unchecked” : “radiobutton_checked”;
|
||||
if (this.state.radioButton === “radiobutton_checked”) {
|
||||
RCTUIManager.sendAccessibilityEvent(
|
||||
React.findNodeHandle(this),
|
||||
RCTUIManager.AccessibilityEventTypes.typeViewClicked);
|
||||
}
|
||||
}
|
||||
|
||||
<CustomRadioButton
|
||||
accessibleComponentType={this.state.radioButton}
|
||||
onPress={this._onPress}/>
|
||||
```
|
||||
|
||||
In the above example we've created a custom radio button that now behaves like a native one. More specifically, TalkBack now correctly announces changes to the radio button selection.
|
||||
|
||||
|
||||
## Testing VoiceOver Support (iOS)
|
||||
|
||||
To enable VoiceOver, go to the Settings app on your iOS device. Tap General, then Accessibility. There you will find many tools that people use to use to make their devices more usable, such as bolder text, increased contrast, and VoiceOver.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user