Repository navigation
*ByRole: return only elements with implicit or explicit accessible={true} prop #1180
Description
Describe the Feature
This is a proposed tweak to *ByRole query. It can be treated as either a fix or a (breaking) change.
Currently getByRole query is based on explicit role set in accessibilityRole prop. Other props are not taken into account (at least until #1064 is merged). This behaviour while basic can be problematic as according to screen readers, elements with accessible={false} (either explicit or implicit) are not focusable by screen reader.
This manifests in relatively common RN pattern:
<Pressable accessibilityRole="button" accessible={false}>
<Text>Cell title</Text>
<Pressable accessibilityRole="button">
<Text>Action</Text>
</Pressable>
</Pressable>Under current implementation getByRole('button', { name: "Action" }) would select both outer and inner pressables. After implementing the proposed change it would select only the inner one.
Possible Implementations
- element can be matched by
getByRoleusing the same criteria as now (host component, equalaccessibilityRole) but also needs to be consideredaccessibility element(i.e. be focusable). - each host view can be made focusable by explicitly passing
accessible={true} - some host view types are considered focusable without the
accessibleprop (e.g.Text,TextInput), but can have their "focusability" disabled by settingaccessible={false} - basic host
Viewis not consider focusable - some RN built in components, e.g.
Pressable,TouchableOpacitywhich render to hostViewactually set explicitaccessible={true}prop on the view
In more practical terms we could use something like isAccessibilityElement to check for focusable state:
export function isAccessibilityElement(
element: ReactTestInstance | null
): boolean {
if (element == null) {
return false;
}
if (element.props.accessible !== undefined) {
return element.props.accessible;
}
return (
isHostElementForType(element, Text) ||
isHostElementForType(element, TextInput)
);
}Then this criteria should be added to *ByRole query.
This change should not affect other general purpose queries as *ByText or *ByTestId. It may be worth considering applying it to some other a11y-related queries, which would make only sense if selected view is accessible: *ByA11yValue, *ByA11State.
Related Issues
#1152 - initial source for issue
#1163 - related discussion
#1064 - hidden query option
Activity
MattAgn commentedon Nov 20, 2022
I'm willing to work on that :)
mdjastrzebski commentedon Nov 20, 2022
@MattAgn great! Go ahead.
I've got some initial research done on this subject:
Viewseems to default toaccessible={false}when observed under Xcode Accessibility Inspector and/or iOS/Android screen reader. But some other controls likeTextandTextInputbehave the same withoutaccessibleprop as when setaccessibile={true}. In order to implement this properly we should analyse all relevant host elements types, so besideView,Text,TextInputthis might beImage, and maybe something more. Some other views, e.g.PressableandTouchableOpacityrender to hostViewwith explicitaccessible={true}.isAccessibilityElement(element)function that would returntruewhen element either has explicitaccessible={true}or is implicit accessibility element (i.e. behaves the same withoutaccessibleprop and withaccessible={true}under Xcode Accessibility Inspector/Screen readers).*ByRolequeries. Adding it to any other a11y query should be preceeded by careful analysis of actual behaviour under Xcode Accessibility Inspector/Screen readers.MattAgn commentedon Nov 22, 2022
Alright sounds good to me!
For the the function
isAccessibilityElement, i would rather go forisElementAccessiblein terms of naming. The termaccessible elementmakes more to sense to me thanaccessibility elementwdyt?mdjastrzebski commentedon Nov 22, 2022
There seems to be a difference between "accessible element" vs "accessibility element". We already have
isInaccessiblewhich when negated would beisAccessiblebut actually conveys idea of "hidden from accessibility" rather than being accessibility element ("focusable by screen reader").RN docs uses the "accessibility element" naming so I would stick with it.
MattAgn commentedon Nov 23, 2022
Oh indeed, did not see it was the term used in the RN documentation, fine by me then 👍
MattAgn commentedon Jan 18, 2023
Closed by #1244