Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Voicing needs listeners to fire on disabled Nodes #1220

Open
zepumph opened this issue May 10, 2021 · 13 comments
Open

Voicing needs listeners to fire on disabled Nodes #1220

zepumph opened this issue May 10, 2021 · 13 comments

Comments

@zepumph
Copy link
Member

zepumph commented May 10, 2021

From a voicing meeting today with @jessegreenberg and others, we discussed the need for listeners to fire on disabled components. Like if you click on a disabled checkbox, it may voice "show force values, disabled." Currently inputEnabled (which enabled runs on) won't let this happen. It would be good to discuss this with @jonathanolson to see what could be done. Do you have any ideas?

@zepumph zepumph changed the title Voicing needs listeners to fire on disabled elements Voicing needs listeners to fire on disabled Nodes May 10, 2021
@terracoda
Copy link

terracoda commented May 10, 2021

I'll just add that at the bare minimum we would want to voice the name of the interaction and potentially some help text that would indicate why the interaction is disabled. In many cases, though perhaps not all, the interaction's name will be text that is displayed on the screen, and it would be useful for learners to be able to voice that text out loud.

Two real-life examples exist on screen 2, the Create Screen, of Ratio and Proportion.
Screen Shot 2021-05-10 at 3 14 48 PM

The Range combobox is only enabled when using Tick Marks or numbered Tick Marks, and the Lock Ratio checkbox is only enabled when the Hands are at challenge ratio.

@jonathanolson
Copy link
Contributor

It would probably be good to discuss exactly in what cases we'd generally want that type of input, to determine how to best handle it.

@zepumph
Copy link
Member Author

zepumph commented May 10, 2021

Thus far, this type of voicing would occur when you focus on the element (which is already supported), as well as when you try to select it (like on down with a mouse).

@jonathanolson
Copy link
Contributor

as well as when you try to select it (like on down with a mouse).

This is partially what I'm curious about. Most clicks activate on the "up", I don't know how we'd handle touch-snag, and we'd truly want to be able to support all of the custom input listeners.

@jessegreenberg
Copy link
Contributor

The down is just an example, the main point is that we have a case where we need some input listeners on the Node to fire when the Node is disabled. Even for disabled Nodes, we would like to add a highlight around the Node when a mouse is over it and to describe the Node with speech when it gets clicked.

The inputEnabled property doesn't impact picking, so we are are still detecting hits just preventing listeners from being fired. What if we had a separate list of input listeners that could still get called when inputEnabled is false?

@jonathanolson
Copy link
Contributor

What if we had a separate list of input listeners that could still get called when inputEnabled is false?

This is specifically something that was considered when @zepumph and I were discussing approaches. We considered a flag on listeners where they would still have events fired even when inputDisabled, AND the listeners then would need to be very aware of when they were called when inputDisabled.

That sounds like a reasonable approach to me, however it might be good to brainstorm and meet about this, since this effectively changes our general needs from what I was aware of.

@zepumph
Copy link
Member Author

zepumph commented Sep 29, 2021

We will need this for the "lock ratio" checkbox in Ratio and Proportion. Marking for meeting to initially discuss with @jessegreenberg. We can pull in @jonathanolson with what our findings are, and more brainstorming.

@terracoda
Copy link

We also need it for the Range combo box in Ratio and Proportion.

@zepumph
Copy link
Member Author

zepumph commented Nov 11, 2021

@jessegreenberg, is this similar to the issue about voicing invisible Nodes? Should it be part of that design while we are working in scenery? Let's talk at our meeting tomorrow.

@zepumph
Copy link
Member Author

zepumph commented Jan 24, 2022

@terracoda, can you note here whether or not you feel like this is blocking the publication of Ratio and Proportion with voicing. If so, we can get some of @jonathanolson's time on the books (likely for early Q2) to get this supported.

@zepumph
Copy link
Member Author

zepumph commented Mar 11, 2022

@terracoda had a fun idea about this today. Let's refocus this issue into our actual case, which is that disabled nodes that support voicing would look like a mouse-only reading block (not available with keyboard), and it would say the name response and "unavailble" (mimicing aria-disabled in NVDA). Basically we could somehow wrap the node in a reading block, only when disabled though. We wouldn't want any content in the PDOM (text content or button).

I'll see how it could go!

Then we talked about design differences between ReadingBlocks, and disabled content. For example, would we always want them to both have black hover highlight. I think this may be enough to try it out.

@terracoda also mentioned that it would be good to talk this through with @jessegreenberg, because they may have spoken about this before.

@zepumph
Copy link
Member Author

zepumph commented Mar 11, 2022

@jessegreenberg and I discussed this a bit further today, and the conclusion we came to really was that this needs to be a scenery-level change. We have 3 paths forward:

  1. The "real" solution. @jessegreenberg and I found that over in Add PhET-iO support for Node.inputEnabledProperty #1116 (comment) we almost supported disabledInputOptIn on the inputListener interface, and doing that here would be the best path forward to letting these readingBlock listeners fire when clicking on a disabled Node. After a bit of poking, it seems like a pretty huge change:
  • We would need to change Input.ts to not just ignore Nodes after an inputDisabled: false
  • We would need to investigate why/how some PDOM events like focus/blur are listening to pickable still instead of inputEnabled, and try to align that, perhaps with this feature, or using the dispatchEvent.fireOnInputDisabled option.
  • We would need to really change Voicing/ReadingBlock/InteractiveHighlighting to support listening to inputEnabled, and doing the right thing on disabled Nodes. We most likely want this feature for all voicing Nodes, and perhaps for all InteractiveHighlighting ones, so that would require messing with the responsibilities of each of those traits.
  1. We can workaround this with DisabledReadingBlockParent.ts (a name I just made up) that can surround the Nodes we need to immediately support this with. It may be worth some investigation. This would automatically work well for mouse/touch, but for keyboard, we would need to somehow disable the ability to navigate to the actual Node in the PDOM. This would be in conflict with accessing these disabled Nodes for Interactive Description in the PDOM.
  2. We can continue to do nothing, and not support this.

@zepumph
Copy link
Member Author

zepumph commented Mar 21, 2022

Last Friday, @terracoda and I brainstormed what (2) may look like above, and we came to the conclusion that it would be more trouble than it was worth. The primary reason is because we would need to make sure to support the parent with keyboard interaction with voicing while also keeping the actual element focusable with keyboard (but disabled) for description.

From this, as well as further discussion during the quarterly team planning meeting today, we aren't going to devote time to this at least until Q3 2022. Makring on hold.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants