Should Accessibility Providers Be Implemented Conditionally on Role Type?

[chiaramooney]

Creating an issue to continue the discussion from #13892.

Pasting in previous thread:

Jon: I know we do this pattern elsewhere, but do we really need to gate on accessibilityRole if expandable is set? Is there an actual limitation in UIA where a JS component author can't define say, a switch with expandable?

Chiara: UIA would not stop us. We would be able to specify a Switch control type that implements the ExpandCollapse provider, but that would have the wrong accessibility conventions. i.e. a control like that would not meet "correct" accessibility rules. The role checks here were mostly added as "guard rails" for JS developers who aren't as familiar with UIA accessibility expectations. They help prevent JS developers from building apps with wonky accessibility implementations.

Andrew: Is this a case where we are potentially blocking something, which while unusual, might be desired.
What if I have a switch which expands/collapses a bunch of UI based on its state. Maybe I want it to report both expand state and the rest of the switch state.

I always worry about these kinds of restrictive policies. What if I'm designing some completely new kind of control type, where expandable very much makes sense, but I dont want UIA reporting that I'm a combobox (or any of these other options). If I set accessibilityState.expanded - I'd expect that to report to the accessibility tools. It would be completely non-obvious that actually for that to work I need to set the role to one of several special values.

[jonthysell]

@chiaramooney Can you open an issue for upstream optional (i.e. three state) accessibility states values so we could implement this properly, and also mention this bug in that new one?