RFC/feat: default accessibility roles

[mdjastrzebski]

Summary

Resolves #1130

This PR improves accessibility role handling by supporting default following default roles:

• text role for Text elements
• textbox* role for TextInput elements
• none role for all other elements

Note: textbox is not an official RN role, you cannot set it explicitly on elements. However, returning none role for TextInput elements does not feel correct as they have significantly different default accessibility behavior that default accessible Views. Therefore, I propose to use official "textbox" ARIA role, which despite not being supported by RN, better describes the characteristics of TextInput elements.

Removed textbox role, reducing the scope of this PR to just none and text default roles.

Details

View

Experiments results

Default view View has the same a11y characteristics (iOS traits, etc) as View with explicit none role. Moreover, assigning none role to Text elements changes it's iOS traits to be the same ("(empty") as both View cases above.

Therefore, it seems reasonable that the default role of View is none.

Text

Experiment results

Default view Text has the same a11y characteristics (iOS traits, etc) as Text with explicit text role. Moreover, assigning text role to View elements changes it's iOS traits to be the same ("Static Text") as both Text cases above.

Therefore, it seems reasonable that the default role of Text is text.

TextInput

Experiment results
TextInout does not seem to react to explict roles being passed, expect of search role.

Test plan

Updated *ByRole tests to check for default role.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (ab679c9) 98.17% compared to head (d4eabf2) 98.18%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1490   +/-   ##
=======================================
  Coverage   98.17%   98.18%           
=======================================
  Files          99       99           
  Lines        5868     5888   +20     
  Branches      909      913    +4     
=======================================
+ Hits         5761     5781   +20     
  Misses        107      107           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[MattAgn]

I'm not sure what to think of the textbox role. I find it a bit misleading to have an API that 99% of the time returns React Native roles but for one case does not, and instead returns a role based on web standards.
I'm not sure being able to do expect(screen.getByRole('textbox').props.testID).toBe('text-input-default') is so important that we need to introduce web behavior in our RN library.
however i understand your point that "none" is not that great either for text box 😅

[pierrezimmermannbam]

I agree with @MattAgn, I'd find it surprising that users try to find text inputs using the textbox role. By the way for now role can be any string but it could be nice to narrow it to RN supported roles, namely because it would bring autocompletion.

It's not clear for me either what is the value in being able to query texts by role or any element by a none role. @mdjastrzebski how would you use it?

From a more general perspective, I don't think RNTL should add default roles and stick to the real behavior of RN. This makes our code simpler, easier to maintain and closer to the reality

[mdjastrzebski]

@pierrezimmermannbam, @MattAgn thanks for your feedback, I'll plan to explain my reasoning properly after RNEU. I share your some of concerns, and at the same time doing experiments with iOS Accessibility Inspector & learning more about web ARIA gave me a new perspective on the topic.

[mdjastrzebski]

@pierrezimmermannbam, @MattAgn Let me answer the easier part of your feedback first: do we need default roles for View and Text and why not just require explicit roles.

I've done a11y experiments on both iOS and Android and verified that:

1. View with none role behaves the same as View without explicit role. Moreover, assigning explicit none role to Text also makes it behave the same.
2. Text with text role behaves the same as Text without explicit role. Moreover, assigning explicit text role to View also makes it behave the same (+ adding accessibilityLabel as a mean of passing "text" to a View)

I'll do some more experiments for TextInputs next and post the results and thoughs in this PR.

[deansimcox]

Appreciate your work on this 🙏

[mdjastrzebski]

@pierrezimmermannbam @MattAgn I've reduced the scope of this PR to default text role for Text component, and none role for all other components without explicit role. Pls review.