byRole queries don't find element that don't have an explicitly set accessibilityRole prop
See original GitHub issueDescribe the bug
react-native
built-in elements are not queriable with byRole
queries if you don’t set the accessibilityRole
prop.
Expected behaviour
byRole
queries should be able to match some elements without accessibilityRole
.
We however need to be conscious of what roles should be used to match what elements. My suggestion is checking each element with a voice-over and see what matches:
- should
<Pressable />
bebutton
by default? <TextInput />
will readInput
on ios voiceover, but that is not anAccessibilityRole
as exported byreact-native
.
We might need to think about types. The point raised in https://github.com/callstack/react-native-testing-library/pull/1127#discussion_r974160967 that suggests using TextMatch
for the role will make it harder to discover those cases.
Steps to Reproduce
Unable to find an element with accessibilityRole: image
140 | const { getByRole } = render(<Image />);
141 |
> 142 | getByRole('image');
| ^
143 | });
144 | });
145 |
Versions
Latest.
Issue Analytics
- State:
- Created a year ago
- Comments:10 (8 by maintainers)
Top Results From Across the Web
Release: coordination of recent `A11y` and element tree ...
byRole queries don't find element that don't have an explicitly set accessibilityRole prop #1130 default roles for some elements based on observed ...
Read more >ByRole | Testing Library
Default roles are taken into consideration e.g. <button /> has the button role without explicitly setting the role attribute. Here you can see...
Read more >No suggestions on getByRole, queryByRole, etc
The error is suggesting to try using the hidden option, not the suggest option, to locate a DOM element that may not be...
Read more >Making sure you're using the correct query - Tim Deschryver
One query in particular pops out, the (get|find|query)ByRole query. ... can't find elements that are broken into multiple elements.
Read more >React Testing Library Tutorial - Robin Wieruch
In modern React, developers will not get around Jest for testing, ... test cases and a test case doesn't have to be in...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
In order to have more concrete information about iOS/Android behaviour, I’ve stared doing experiments how different a11y props combinations affects behaviour of assistive tech on iOS and Android. I share initial findings in newly created wiki page. If you have time, please contribute your research for other component types (
TextInput
,Image
,Pressable/TouchableXx
,View
, etc) there.I think we need to build some playground repos for native, so that we have easier job when examining these roles. For native we could build a sample Expo app and the test it using VoiceOver on iOS and TalkBack on Android. If I understand correctly these screen readers should announce roles for the elements.
It also seems that there are difference between RN Accessiblity Roles, ARIA roles, UIKit Accessibility Traits and Android where I could not find anything in the API resembling roles.
E.g. ARIA does not have a role for static text, iOS has
staticText
trait, and RN hastext
.We should follow recent RN activity https://github.com/facebook/react-native/pull/34538, and base most of our decisions on ARIA roles, but also taking into account how screen readers act on iOS/Android.
This RN PR has mapping between ARIA and RN roles.