-
Notifications
You must be signed in to change notification settings - Fork 248
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
accessibility #138
Comments
hi there, |
we could try passing accessibility props all the way, for a start:
|
those accessibility props should go to the In theory you can create your own "accessible" touchable (with |
since using optionTouchable I end up having error on Android (at least) |
sorry @GuillotJessica , I somehow miss your problem with |
Hi @sodik82 - I have run into a similar issue (screen reader can traverse elements below the menu). I wanted to take a crack at fixing it but quickly ran into a problem with the MenuPlaceholder, so I am wondering if you can advise on the best approach. In order to avoid having the screen reader "see" content beneath the menu, there are several props we can use:
So the first pass at a fix is in the MenuProvider, I tried something like this: // New props on the View containing { this.props.children }
accessibilityElementsHidden={isMenuOpen}
importantForAccessibility={isMenuOpen ? 'no-hide-descendants' : 'auto'}>
// New props on the SafeAreaView containing the MenuPlaceholder
accessibilityViewIsModal={isMenuOpen}
importantForAccessibility={isMenuOpen ? 'yes' : 'no-hide-descendants'} However, this falls over when a menu gets opened because the MenuProvider doesn't actually re-render. Only the MenuPlaceholder does, which doesn't provide a way for me to toggle the accessibility props on the app content. It's easy enough to work around with setState or forceUpdate, but it appears that that would bypass the intent of MenuPlaceholder? It seems that it was created for exactly this reason (to avoid re-rendering the rest of the tree), so I'm not sure how to address this properly. Note - there are several other accessibility tweaks we can investigate for the library, but this one (screen reader traversing underneath the menus) is the most urgently needed for the package to be screen reader friendly. Other low hanging fruit:
|
Any update on this issue? I tried to use accessibilityLabel on MenuOption with no success. |
Any update on allowing the accessibilityLabel ??? Or other Menu Lib for React Native that allow the use of it??? |
This is causing problems for us as well. |
hi guys.... as I understand the topic is also important, we are lacking accessibility expertise and time to dive into the problem. |
Hello, I recently encountered an issue while using this component. I'm automating React Native with Appium, and I can't locate the children elements of MenuTrigger using Appium Inspector because they are wrapped. I understand some reasons for this. When we use pressable components (components with onPress method, such as Touchable components), their accessible property defaults to true. If we don't set it to false, it wraps the child elements below it. Therefore, when we try to detect its elements using automation tools, we can only see one element and not the elements wrapped below it. @sodik82 I'd like to suggest opening up the option to set the accessible property so that we can pass in the accessible property. You can apply this property to the following pressable components. This may be helpful for products with automation needs. |
Thanks for the library, easy to use.
I must use accessibility all over the app, and I have some issue regarding your component, accessibility reads content hide by pop menu Item that I'm pressing, the behaviour only happened with the library.
Any workaround?
Thanks for the response
The text was updated successfully, but these errors were encountered: