Disabled TouchableOpacity buttons are not narrator-focusable

[kim-allison]

Problem Description

Disabled buttons are focusable using UWP navigation controls but are not focusable using the narrator. Users should still be able to access disabled buttons with the narrator (ex. the narrator should read the button as 'disabled [button label] button').

Steps To Reproduce

1. Create a button with 'disabled' set to true.
2. Run the narrator over the button to check if it's focusable.

Expected Results

Disabled 'Button 1' only has a white box around it (missing blue box) := no narrator focus.

'Button 2' has both boxes. Disabled 'Button 1' is expected to follow similar patterns.

CLI version

5.0.1

Environment

System:
    OS: Windows 10 10.0.19043
    CPU: (8) x64 Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz
    Memory: 13.91 GB / 31.59 GB
  Binaries:
    Node: 14.17.4 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.5 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 6.14.14 - C:\Program Files\nodejs\npm.CMD
    Watchman: Not Found
  SDKs:
    Android SDK:
      API Levels: 28
      Build Tools: 28.0.3, 31.0.0
      System Images: android-28 | Android TV Intel x86 Atom, android-28 | China version of Wear OS Intel x86 Atom, android-28 | Wear OS Intel x86 Atom, android-28 | Intel x86 Atom, android-28 | Intel x86 Atom_64, android-28 | Google APIs Intel x86 Atom, android-28 | Google APIs Intel x86 Atom_64, android-28 | Google Play Intel x86 Atom, android-28 | Google Play Intel x86 Atom_64
      Android NDK: 22.1.7171670
    Windows SDK:
      AllowDevelopmentWithoutDevLicense: Enabled
      AllowAllTrustedApps: Enabled
      Versions: 10.0.18362.0, 10.0.19041.0
  IDEs:
    Android Studio: Version     2020.3.0.0 AI-203.7717.56.2031.7678000
    Visual Studio: 16.11.31702.278 (Visual Studio Enterprise 2019)
  Languages:
    Java: 11.0.1 - C:\android\jdk-11.0.1\bin\javac.EXE
  npmPackages:
    @react-native-community/cli: Not Found
    react: 17.0.1 => 17.0.1
    react-native: ^0.64.2 => 0.64.2
    react-native-windows: 0.64.9 => 0.64.9
  npmGlobalPackages:
    *react-native*: Not Found

Target Platform Version

No response

Target Device(s)

Desktop

Visual Studio Version

Visual Studio 2019

Build Configuration

Debug

Snack, code example, screenshot, or link to a repository

No response

[NickGerleman]

@kim-allison what component are you using for your button?

[kim-allison]

@kim-allison what component are you using for your button?

I'm using 'BasicButton'.
<BasicButton buttonType={ButtonType.Brand} label="Button 1" style={(globalStyles.baseButton, { backgroundColor: 'red' })} disabled />

[NickGerleman]

I don't think BasicButton is a built-in component. Is this imported from a library that you are using?

[kim-allison]

Ah, my bad. TouchableOpacity is the built-in component I'm using to create BasicButtons. But yes, I'm setting TouchableOpacity as disabled and have encountered this accessibility issue.

[NickGerleman]

@kim-allison one other bit is that Touchable has some internal logic which only defaults the view to be focusable if an onPress handler is present. Is one set on the button where you are seeing the issue?

[kim-allison]

@NickGerleman Yes, I can confirm that the button has an onPress handler.

[chrisglein]

Item should show up to Narrator in some way, but not be tabbable (disabled items shouldn't get keyboard focusable). @AgneLukoseviciute to check on the expected behavior here.

[AgneLukoseviciute]

I think that when an element is not visible, trying to retrieve it's automation peer will return null. My best guess is that Narrator focus requires an automation peer for focus and this might be the expected behavior. I'll check with some a11y folks offline to confirm.

Also if the white box signifies keyboard focus is that the behavior we want? @rectified95 -- should a disabled Touchable receive keyboard focus?

[rectified95]

AFAIK disabled controls don't typically receive keyboard focus, not sure if they should. I don't know how that relates to Narrator, though

[AgneLukoseviciute]

I think narrator focus is behaving as expected here and it's actually the keyboard focus that isn't. Filed a separate issue to address that.