Summary:
Assistive technologies use the accessibility role of a component to tell the disabled user what the component is, and provide hints about how to use it. Many important roles do not have analog AccessibilityTraits on iOS. This PR adds many critical roles, such as editabletext, checkbox, menu, and switch to name a few.
Accessibility states are used to convey the current state of a component. This PR adds several critical states such as checked, unchecked, on and off.
[general] [change] - Adds critical accessibility roles and states.
Pull Request resolved: https://github.com/facebook/react-native/pull/24095
Differential Revision: D15079245
Pulled By: cpojer
fbshipit-source-id: 941b30eb8f5d565597e5ea3a04687d9809cbe372
Summary:
In order to meet our accessibility requirements we need to have full support for keyboard navigation. The Touchable components works with press/tap with a finger, but doesn't respond to 'enter' when using a keyboard. Navigation works fine. This PR adds an onClick listener to touchable views that have the onPress prop defined.
[Android] [Added] - Add View.OnClickListener to Touchable components when onPress is defined
Pull Request resolved: https://github.com/facebook/react-native/pull/24359
Differential Revision: D14971230
Pulled By: cpojer
fbshipit-source-id: ca5559ca1308ee6c338532a00dcea4d00fa57f42
Summary:
Closes: https://github.com/facebook/react-native/issues/24016
React Native 0.57 introduced cross-platform `accessibilityRole` and `accessibilityStates` props in order to replace `accessibilityComponentType` (for android) and `accessibilityTraits` (for iOS). With #24095 `accessibilityRole` and `accessibilityStates` will increase, receiving more options, which seems to be a good moment to remove deprecated props.
Remove deprecated `accessibilityComponentType` and `accessibilityTraits` props.
[General] [Removed] - Remove accessibilityComponentType and accessibilityTraits props
Pull Request resolved: https://github.com/facebook/react-native/pull/24344
Reviewed By: rickhanlonii
Differential Revision: D14842214
Pulled By: cpojer
fbshipit-source-id: 279945e503d8a23bfee7a49d42f5db490c5f6069
Summary:
Potential breaking change: The signature of ReactShadowNode's onBeforeLayout method was changed
- Before: public void onBeforeLayout()
- After: public void onBeforeLayout(NativeViewHierarchyOptimizer nativeViewHierarchyOptimizer)
Implements same feature as this iOS PR: https://github.com/facebook/react-native/pull/7304
Previously, only Text and Image could be nested within Text. Now, any view can be nested within Text. One restriction of this feature is that developers must give inline views a width and a height via the style prop.
Previously, inline Images were supported via FrescoBasedReactTextInlineImageSpan. To get support for nesting views within Text, we create one special kind of span per inline view. This span is called TextInlineViewPlaceholderSpan. It is the same size as the inline view. Its job is just to occupy space -- it doesn't render any visual. After the text is rendered, we query the Android Layout object associated with the TextView to find out where it has positioned each TextInlineViewPlaceholderSpan. We then position the views to be at those locations.
One tricky aspect of the implementation is that the Text component needs to be able to render native children (the inline views) but the Android TextView cannot have children. This is solved by having the native parent of the ReactTextView also host the inline views. Implementation-wise, this was accomplished by extending the NativeViewHierarchyOptimizer to handle this case. The optimizer now handles these cases:
- Node is not in the native tree. An ancestor must host its children.
- Node is in the native tree and it can host its own children.
- (new) Node is in the native tree but it cannot host its own children. An ancestor must host both this node and its children.
I added the `onInlineViewLayout` event which is useful for writing tests for verifying that the inline views are positioned properly.
Limitation: Clipping
----------
If Text's height/width is small such that an inline view doesn't completely fit, the inline view may still be fully visible due to hoisting (the inline view isn't actually parented to the Text which has the limited size. It is parented to an ancestor which may have a different clipping rectangle.). Prior to this change, layout-only views had a similar limitation.
Pull Request resolved: https://github.com/facebook/react-native/pull/23195
Differential Revision: D14014668
Pulled By: shergin
fbshipit-source-id: d46130f3d19cc83ac7ddf423adcc9e23988245d3
Summary: This was added in [this PR](https://github.com/facebook/react-native/pull/22047) with a non strict type
Reviewed By: yungsters
Differential Revision: D13617894
fbshipit-source-id: 849f83203556e2830ac725570c9053503377f4be
Summary:
Related to #22100
Enhance ViewPropTypes flow types.
- I had some troubles with a TODO left for `onResponderGrant` hence the return type.
- I wasn't able to properly type `nativeBackgroundAndroid` and `nativeForegroundAndroid` at the moment.
Pull Request resolved: https://github.com/facebook/react-native/pull/22504
Reviewed By: cpojer
Differential Revision: D13334024
Pulled By: TheSavior
fbshipit-source-id: cada236e0d716ae78cb663172e5315cf11c6406a
Summary: This is one more step to remove `fbjs` from `react-native-github`. This changes both the internal and external code to use `invariant` from zertosh instead of the copy in fbjs.
Reviewed By: yungsters
Differential Revision: D13195941
fbshipit-source-id: 73564ca1715110e7da9c7ef56dc57374d61377e0
Summary:
Adds the displayName prop to `View` and `Text` components. Because these now use `React.forwardRef`, they were showing as `Component` instead of their actual names.
Thanks to ljharb for helping to pinpoint the source of the issue!
Fixes#21937
Pull Request resolved: https://github.com/facebook/react-native/pull/21950
Differential Revision: D12827060
Pulled By: TheSavior
fbshipit-source-id: d812cae14d53ad821ab5873e737db63ad1a989e3
Summary:
This PR splits and renames all references of ViewAccessibility to DeprecatedViewAccessibility
Related to #21342
Pull Request resolved: https://github.com/facebook/react-native/pull/21422
Reviewed By: yungsters
Differential Revision: D10132659
Pulled By: RSNara
fbshipit-source-id: 68c371230c69ed37c3e44bf8a36043adb04afc78
Summary: Fixes the runtime value of `ReactNativeStyleAttributes` to correctly map to `true` instead of strings (as returned by `keyMirror`).
Reviewed By: TheSavior
Differential Revision: D10057235
fbshipit-source-id: dc855cff3a114761098ed5176b2e6e25412481dc
Summary: D10013265 introduces flow types for `PanResponder`. This diff fixes the facebook-internal flow errors that surface as a result.
Reviewed By: TheSavior
Differential Revision: D10035046
fbshipit-source-id: fbba3d61e68851dda2da4f8e98238e0fdb35a27e
Summary:
This PR moves `DeprecatedViewPropTypes` to a new `DeprecatedViewProps` folder, and copies all documentation comments to the relevant Flow types file.
Pull Request resolved: https://github.com/facebook/react-native/pull/21349
Differential Revision: D10080802
Pulled By: TheSavior
fbshipit-source-id: af4881f3b12e8a1e675b849e0fcf0cc57a68e57f
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary:
D8842691 split AccessibilityTraits into multiple RN properties. However, the accessor code did not support REMOVING traits.
This results in buttons that were disabled (AccessibilityTraits & NotEnabled === true) never being enabled.
Fix the issue by making the split accessors properly mask in the bits, allowing you unset them without disturbing bits managed by the other accessor.
NOTE: setting AccessibilityTraits and AccessibilityRole or AccessibilityStates will still result in bugs.
Reviewed By: shergin
Differential Revision: D9661970
fbshipit-source-id: 77d70dd0754f2eaf8cbf895bfc13757c697a76d8
Summary:
Makes a couple improvements to `ViewPropTypes`.
- Remove deprecated transform props. We are now using exact object types, so they are already disallowed.
- Remove garbage types for `accessibilityLabel`.
Reviewed By: TheSavior
Differential Revision: D9542088
fbshipit-source-id: f9128353e19cff22caf52c896c9c137f01aea276
Summary: Apparently different apps have different implementations of view managers that support different props. This is a problem that we will need to address. Unfortunately, this means we can't have a static config defined in JS. We will need to find another approach to this problem.
Reviewed By: sahrens
Differential Revision: D9500178
fbshipit-source-id: b591559164fcf29f5fd43e13a0f2da15011491c6
Summary:
Changes the Flow prop types for `Image`, `Text`, and `View` to be nullable and optional.
This makes these components easier to compose.
Reviewed By: sahrens
Differential Revision: D9494285
fbshipit-source-id: c3f17147f063b31217b239a3abc085d1850f8df9
Summary: As we move these configs to JS from native, until we have codegen that ensures everything stays up to date, this adds a dev mode check to ensure they are consistent.
Reviewed By: yungsters
Differential Revision: D9475011
fbshipit-source-id: 9d6f7b6c649229cae569d840eda3d5f7b7aa7cb2
Summary: Reverting due to problems with prepack.
Reviewed By: gaearon
Differential Revision: D9482931
fbshipit-source-id: 0ec5d0fb80dab32a07521a465dd2a501e6bb4d30
Summary: This diff moves the prop-type definitions for View out into it's own file. We will be able to do this with a bunch of the prop-type definitions and then move them out into a deprecated npm package.
Reviewed By: yungsters
Differential Revision: D9444394
fbshipit-source-id: 4fd0a78533211b598ba2da4eb5015ffcc20bb675
Summary: When running a trace, reduce the noise from the `__DEV__`-only `ForwardRef(View)` elements.
Reviewed By: ejanzer
Differential Revision: D9445865
fbshipit-source-id: 7cfe87bab6dd62d3800d2ca239724b5063c55c89
Summary: This caught a few flow types that weren't defined for attributes that Android exposes. Ensuring that these stay in sync will be necessary for codegen in the future.
Reviewed By: sahrens
Differential Revision: D9444165
fbshipit-source-id: 8ee00af7b732c35d7f6befcdf79f77b73eac6a1b
Summary: Moving this config to native for android so we skip the native lookup for the config.
Reviewed By: yungsters
Differential Revision: D9415726
fbshipit-source-id: 84cac3f0dfa4f6ea8800de77676f1e2896ee463d
Summary:
Description:
------------
While creating a custom component I added a prop `style: ?ViewStyleProp`. When I tried to pass the following object
```
style={{
opacity: new Animated.Value(0),
}}
```
to this `style` prop I received a yellow box with the warning:
```
Warning: Failed prop type: Invalid prop `opacity` of type `object` supplied to `MyComponent`, expected `number`.
```
Then I browsed through the source code and found an inconsistency in types checks. Namely,
https://github.com/facebook/react-native/blob/master/Libraries/StyleSheet/StyleSheetTypes.js#L158 has the following declaration `opacity?: number | AnimatedNode`, whereas https://github.com/facebook/react-native/blob/master/Libraries/Components/View/ViewStylePropTypes.js#L50 is willing to accept **only** a `number`: `opacity: ReactPropTypes.number`.
Pull Request resolved: https://github.com/facebook/react-native/pull/20773
Differential Revision: D9464634
Pulled By: TheSavior
fbshipit-source-id: fa21f706cb890dbeec136f1c4fab468904cd284b
Summary: Locking down view style so that invalid styles can't be passed into View.
Reviewed By: yungsters
Differential Revision: D9309097
fbshipit-source-id: 69e7e3c5626609cfd47c167027a55470c42228c8
Summary:
ag -L --ignore __snapshots__ 'flow strict|noflow|generated|The controller you requested could not be found.' | ag '\.js$' | xargs ag -l 'flow' | sort > ~/temp
cat ~/temp | xargs ag -L 'flow strict' | xargs sed -i '' 's/flow$/flow strict-local/'
until flow check; do flow check --json | jq -r '.errors[].message[0].path' | sort | uniq | xargs hg revert; done
allow_many_files
The controller you requested could not be found.
The controller you requested could not be found.
Reviewed By: TheSavior
Differential Revision: D9004573
fbshipit-source-id: 936bd5741706b781be06bf08b6ad805a69407dfd
Summary: Moving out the requireNativeComponent call into a new file. We want this long term for all of our view managers to support codegen of the native side and so we can move the viewConfigs into JS.
Reviewed By: yungsters
Differential Revision: D9231619
fbshipit-source-id: 7c89587cc6a76e92b309c4941577291e56af8c7c
Summary:
Changed documentation for accessibility Hint so that its no longer only available on iOS
Also added full description of documentation for accessibility Role as it was missing earlier
Reviewed By: PeteTheHeat
Differential Revision: D9072572
fbshipit-source-id: c8d20f30df588717d9ec37721c2aa3c86a0664c6
Summary:
This adds the accessibilityHint for View, Text and Touchable* on iOS.
The accessibilityHint provides some more information about an element
when the accessibilityLabel is not enough.
The accessibilityHint is a core accessibility property on iOS.
From https://developer.apple.com/documentation/objectivec/nsobject/1615093-accessibilityhint:
> An accessibility hint helps users understand what will happen when they perform an action on the accessibility element when that result is not obvious from the accessibility label.
Related issue: https://github.com/facebook/react-native/issues/14706
The npm scripts `test`, `flow`, `lint` and `prettier` are satisfied.
I added a couple of examples to the RNTester app. The Accessibility Inspector on Mac helps debugging accessibility stuff on a simulator, but it does not show the accessibilityHint. Therefore I tested the RNTester app on an iPhone 8 device using VoiceOver to verify the hint functionality. It works fine, and I've tested disabling and enabling "read hints" in the VoiceOver settings on the phone.
https://github.com/facebook/react-native-website/pull/222
[IOS][FEATURE][Accessibility] - Add accessibilityHint for View, Text, Touchable* on iOS
Closes https://github.com/facebook/react-native/pull/18093
Reviewed By: hramos
Differential Revision: D7230780
Pulled By: ziqichen6
fbshipit-source-id: 172ad28dc9ae2b67ea256100f6acb939f2466d0b
Summary:
Previously, I exposed the "accessibilityIgnoresInvertColors" API on iOS to react native views.
In this diff, I added this property to the `module.exports` in `ViewPropTypes` so that the property can be accessed by other files.
Reviewed By: PeteTheHeat
Differential Revision: D8977515
fbshipit-source-id: d0aba5eac3bc1528e18b6027f3f055e5f4a1147a
Summary:
Previously, I added accessibilityRole and accessibilityStates as View Properties.
In this diff, I added accessibilityRole and accessibilityStates to ReactNativeViewAttributes.UIView, which is used for viewconfig in some components.
The NativeMethodsMixing uses the set view config when invoking `setNativeProps`, and it's used to make those components look like an actual native component class.
Reviewed By: PeteTheHeat
Differential Revision: D8976524
fbshipit-source-id: 16a5ba7d91ee9cfb6488c2d94f7f23b9093e5b81
Summary:
Context:
After discussing with @[1038750002:yungsters], `currentViewStates` is a very ambiguous name for a prop, especially because there are only two possible values. From a developer's perspective, it makes more sense to just call them `accessibilityStates` because the main use for them is to add states to Talkback and Voiceover.
Also, the actual implementation of what we're changing under the hood in Native Code is abstracted away from developers using React Native, so as long as behavior is as they would expect, it makes more sense to change the name into a clear one.
Changes in this Diff:
Changed the prop name `currentViewStates` to `accessibilityStates` in js files
Reviewed By: PeteTheHeat
Differential Revision: D8896223
fbshipit-source-id: dfdb48dce69303a347dfccd194af2fef9beb776c
Summary:
Added in a prop for CurrentViewState that is used to set the state of the current view for both accessibility and regular view settings..
Ex:
AccessibilityRole = "button"
CurrentViewState = ['selected']
This will trigger talk back/voiceover to announce both the role and the state.
Unlike Accessibility Role, Accessibility States can take on more than one form, and are passed in an array.
Ex: AccessibilityState = ['selected', 'disabled']
Currently, two options are available: selected and disabled
Reviewed By: PeteTheHeat
Differential Revision: D8837848
fbshipit-source-id: ca30c950a2aa713813be8577ea4fa9ba9bfc698a
Summary:
Because we're now separating accessibilityTraits into accessibilityRole and accessibilityState, we're going to only allow one role to be set, and allow one preset combinations of roles that make sense.
This diff adds image button as a role.
Reviewed By: PeteTheHeat
Differential Revision: D8846958
fbshipit-source-id: dad3783654b20abeb29767cdad7450d1896058c2
Summary:
Added in props for three more roles:
link, search, and adjustable
Reviewed By: blavalla
Differential Revision: D8788186
fbshipit-source-id: acd1d667a43bea753964d128bd4525ece90d06b3
Summary: Removed Accessibility Trait TabBar for iOS compatibility Issues, since tabbar is only available on iOS 10+
Reviewed By: PeteTheHeat
Differential Revision: D8822469
fbshipit-source-id: 34bf00eb930f631a5a4effa0a4159da07c1573f6
Marc Mulcahy
Sam Mathias Weggersen
Estevão Lucas
Adam Comella
Grégoire Rit
danibonilha
Eli White
glevi@fb.com
Doug Russell
Thomas BARRAS
Christoph Nakazawa
Rajiv Shah
danibonilha
Thomas Carlson
nd-02110114
Tim Yung
Guilherme Varandas
Ramanpreet Nara
Julio Xavier
empyrical
Héctor Ramos
Zack Gomez
Alexander Perepelitsyn
Wayne Cheng
Ziqi Chen
Mats Byrkeland