kylefang/react-native-web
1
0
Fork 0
mirror of https://github.com/zhigang1992/react-native-web.git synced 2026-04-24 04:25:27 +08:00
Code Issues Packages Projects Releases Wiki Activity

[change] a11y and layout: button role and DOM props

Browse Source 
Problems:

HTML's native <button> tag doesn't support flex styling in all browsers,
causing layout bugs. And buttons or links created by "createDOMElement"
(without an accessibility role) do not have the correct props.

Solution:

The "button" role is rendered to a "div[role=button]" that is focusable
and responds to the same keyboard events as a native button. A native
button can still be rendered using "createDOMElement".

Make "createDOMProps" aware of the component context to ensure style
resets and other props are correctly applied when an accessibility role
is not defined.

Additionally:

This patch also adds a new "label" role to support accessible forms.
It maps to a native label element.

Close #241
This commit is contained in:
Nicolas Gallagher
2017-07-07 23:34:40 -07:00
parent 1a0a40d9be
commit ad3dee0204
24 changed files with 425 additions and 378 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
docs/guides/accessibility.md
View File

@@ -40,35 +40,40 @@ using `aria-label`.
In some cases, we also want to alert the end user of the type of selected
component (i.e., that it is a “button”). To provide more context to screen
readers, you should specify the `accessibilityRole` property. (Note that React
Native for Web provides a compatibility mapping of equivalent
Native for Web also provides a compatibility mapping of equivalent
`accessibilityTraits` and `accessibilityComponentType` values to
`accessibilityRole`).
The `accessibilityRole` prop is used to infer an [analogous HTML
element][html-aria-url] to use in addition to the resulting ARIA `role`, where
possible. While this may contradict some ARIA recommendations, it also helps
avoid certain HTML5 conformance errors and accessibility anti-patterns (e.g.,
giving a `heading` role to a `button` element).
element][html-aria-url] and ARIA `role`, where possible. In most cases, both
the element and ARIA `role` are rendered. While this may contradict some ARIA
recommendations, it also helps avoid certain HTML5 conformance errors and
accessibility anti-patterns (e.g., giving a `heading` role to a `button`
element) and browser bugs.
For example:
* `<View accessibilityRole='article' />` => `<article role='article' />`.
* `<View accessibilityRole='banner' />` => `<header role='banner' />`.
* `<View accessibilityRole='button' />` => `<button type='button' role='button' />`.
* `<View accessibilityRole='button' />` => `<div role='button' tabIndex='0' />`.
* `<Text accessibilityRole='label' />` => `<label />`.
* `<Text accessibilityRole='link' href='/' />` => `<a role='link' href='/' />`.
* `<View accessibilityRole='main' />` => `<main role='main' />`.
In the example below, the `TouchableWithoutFeedback` is announced by screen
readers as a native Button.
In the example below, the `TouchableHighlight` is announced by screen
readers as a button.
```
<TouchableWithoutFeedback accessibilityRole="button" onPress={this._onPress}>
```js
<TouchableHighlight accessibilityRole="button" onPress={this._handlePress}>
<View style={styles.button}>
<Text style={styles.buttonText}>Press me!</Text>
</View>
</TouchableWithoutFeedback>
</TouchableHighlight>
```
Note: The `button` role is not implemented using the native `button` element
due to browsers limiting the use of flexbox layout on its children.
Note: Avoid changing `accessibilityRole` values over time or after user
actions. Generally, accessibility APIs do not provide a means of notifying
assistive technologies of a `role` value change.