bug: *ByA11yState query ignores default state values of false

[mdjastrzebski]

Describe the bug

When using *ByA11yState queries they perform match given element only when given option has the exact values as passed.

Current behavior

• getByA11yState({ disabled: true }) will match <View accessibilityState={{ disabled: true }} /> (OK)
• getByA11yState({ disabled: false }) will match <View accessibilityState={{ disabled: false }} /> (OK)
• getByA11yState({ disabled: false }) will NOT match <View accessibilityState={{}} /> (NOT OK)

Expected behavior

• getByA11yState({ disabled: false }) should match <View />
• similarly for other state options we should assume the each of them has a default value of false if not specified otherwise.

Versions

11.2.0 and below

Related issues

#1161 - issue where we discovered the bug

CC: @thymikee @AugustinLF @pierrezimmermannbam

[AugustinLF]

I have one question, is state read by the screen reader if there's no role? Does it even make sense? Looking at the MDN docs, only busy works with any role. So I'd argue that querying by a11y state might not even be something we should promote, since only busy seems relevant as is (and RTL actually doesn't allow querying it).

[mdjastrzebski]

@AugustinLF this is a valid question, I guess we already have the *ByA11yState query. RTL/DTL indeed does not have it, and you can only query state when using *ByRole options. This approach makes sense, because if you are only querying state without any additional data this is very coarse query. But maybe some of our users are using it for component-level tests, and/or someone might be using it in connection to within query to narrow down the scope.

I have a couple of thoughts about this query:

1. ByA11yState matched value and *ByRole state options should have the same behavior to avoid confusion
2. We might add warning message that will redirect users to *ByRole with state options query. We could even suggest the role/or whole query inside that warning.
3. It seems that we TextInput does not have any roles from the AccessibilityRoles type, which mean you cannot look for disabled input using *ByRole query atm. One idea to solve it would be to make TextInput report default textbox role, which is not present in AccessibilityRoles and not used by RN, but is an ARIA role, for such cases. It would be a bit weird, because you would not be able to set that role directly. See relevant details here
4. I've started testing how iOS and Android accessibility treats a11y states, and curously checked: false is treated differently than omitting checked state, while disabled: false is treated the same as omitting disabled state. I will do similar investingation for other states, but this is quite a tedious work. You can check my detailed findings here

[AugustinLF]

Yeah, I agree. We can fix the current behaviour for now, and see what is the future way forward.