React-native: Accessibility with NavigationCardStack speaks accessibilityLabels of previous pages's views on iOS

Created on 3 Sep 2016  路  19Comments  路  Source: facebook/react-native

Issue Description

Let's say we have two pages in our app: Page A and Page B. NavigatorExperimental is used to navigate between them.

Page A's accessibility is working great. But when moving two Page B, VoiceOver still recognises and speaks Page A's accessible elements, even though they are now hidden.

Steps to Reproduce / Code Snippets

Create 2 pages: Page A and Page B, and use NavigationExperimental to navigate between them. Both pages should contain some accessible elements.

Turn on VoiceOver on the iOS device and start the app. Navigate to Page B and try VoiceOver.

Expected Results

Page A's accessible elements should not appear in Page B.

Additional Information

  • React Native version: 0.32.0
  • Platform(s) (iOS, Android, or both?): iOS
  • Operating System (macOS, Linux, or Windows?): macOS
iOS Locked

Most helpful comment

@hramos It shouldn't need extra information to open this back up, this should be a pre-requisite to react-navigation and should surely remain open until it's resolved.

All 19 comments

@alongubkin this is happening to me as well. Did you find any workarounds?

@danieladias Not really a solution, but I found out that if I use NavigationStateUtils.reset instead of NavigationStateUtils.push it doesn't happen

@alongubkin thanks for your reply. Yes in that case we loose the navigation animation right?

@danieladias and history, yes.

As of v0.35.0-rc.0 this is still not fixed 馃槩

@alongubkin thank you.

I can reproduce this on Android using v0.35.0 as well. Prior to seeing this issue I had asked the question on stack overflow. I'm also unaware of any workarounds short of making the current scene the only rendered one.

We have the same problem and while the necessary Native APIs for Android is available to fix this issue in _user application_, for iOS the accessibilityElementsHidden property needs to be exported by UIViewManager .

I have created a pull request to expose said property and relevant changes for NavigationCardStack to fix this issue.

On Android, Navigator doesn't have this problem because Navigator will set the alpha of the covered/outside view to zero. Navigation Experimental should set the alpha of the covered/outside view to zero instead of 0.3

@lightboys22 The reason it works in Android is because the default value of importantForAccessibility is auto which does some magic to detect what elements are not important, for example when opacity is 0, when the element is more than one layer deep, and I think when height and/or width is 0, and so forth.

@alongubkin Can you check if #10918 address your problem too?

I believe I'm seeing the same issue when using react-navigation. However, I did notice an interesting result and would be curious if others can reproduce this in their own examples:

  • Reproduce the above described issue on IOS.
  • Press the home button to place the app in the background.
  • reopen the app.
  • verify whether the hidden screen is still visible with VoiceOver.

If others are seeing this, and not just me, then I wonder if firing a UIAccessibilityScreenChangeNotification would make a difference?

Is anyone using the accessibility inspector for this, or strictly using VoiceOver & TalkBack to identify the overlap? I have not created a sample, but it goes three layers deep for me. As in you can see page A & B elements when on page C with the AI. Will try integrating native language into the code base and see what happens.

@cannona I am seeing this in react-navigation and @jeffbum I am seeing the same behavior as you. While there may be several solutions I have one approach working in my project. First I need something like #11788 merged into react-native to expose iOS's accessibilityElementsHidden property. While waiting on that PR I've been maintaining my own fork. Then I fork react-navigation and set importantForAccessibility to no-hide-descendants on all but the active view (what the user sees) in react-navigation's Card on this view.

Hi there! This issue is being closed because it has been inactive for a while. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. Either way, we're automatically closing issues after a period of inactivity. Please do not take it personally!

If you think this issue should definitely remain open, please let us know. The following information is helpful when it comes to determining if the issue should be re-opened:

  • Does the issue still reproduce on the latest release candidate? Post a comment with the version you tested.
  • If so, is there any information missing from the bug report? Post a comment with all the information required by the issue template.
  • Is there a pull request that addresses this issue? Post a comment with the PR number so we can follow up.

If you would like to work on a patch to fix the issue, contributions are very welcome! Read through the contribution guide, and feel free to hop into #react-native if you need help planning your contribution.

Was there any resolution to this issue?

@jonolock91 not yet - it's a real shame this ones been closed @hramos even more so as it's preventing us from having an accessible app right now.

@lprhodes we've talked about this before. Please see my issue closing message for more information on next steps.

@hramos It shouldn't need extra information to open this back up, this should be a pre-requisite to react-navigation and should surely remain open until it's resolved.

Solution for this issue is to set "accessibilityViewIsModal" property to "true" for the Parent "View" component for each Container.

"...a window that contains sibling views A and B, setting accessibilityViewIsModal to true on view B causes VoiceOver to ignore the elements in the view A. "
Ref: https://facebook.github.io/react-native/docs/accessibility.html

Eg:

render() {
return (
{/* some code. */}

);
}

Was this page helpful?
0 / 5 - 0 ratings

Related issues

josev55 picture josev55  路  3Comments

anchetaWern picture anchetaWern  路  3Comments

madwed picture madwed  路  3Comments

ghost picture ghost  路  3Comments

jlongster picture jlongster  路  3Comments