How should inputEnabled effect PDOM events?

[zepumph]

Currently, inputEnabled only blocks listeners added directly to a Node it doesn't block the ability to focus that Node, and move to it through tab navigation. This may be the intended behavior, but I'm unsure. I would like to discuss with designers on Thursday. Tagging @arouinfar and @kathy-phet.

[zepumph]

I remember working on inputEnabled with @jonathanolson, and for many features in scenery, it was important to not block everything. For example, PressListener is attached to the pointer so that it can stay in sync with the position of the pointer, but it doesn't move the Node. I will need to speak with @jonathanolson to refresh my memory about all constraints.

[zepumph]

@jonathanolson and I spoke about this a bit, and we decided that it is largely a design decision. It is important to have the ability to focus on a "disabled" item from a description/PDOM standpoint. We should keep in mind #1220 and potentially the same thing for description alerts (though I'm unsure if there is an issue for it).

Basically my question revolves around if it is acceptable to have the focusHighlight for inputEnabled:false because I think we will need it for other cases.

[zepumph]

Tagging @terracoda and @emily-phet because this bleeds into voicing decisions. Perhaps we should all be at a design meeting for this.

[terracoda]

A disabled control is already focusable by the keyboard and readable by screen reader technology in the PDOM.

I think the issue has been brought to the forefront specifically because Voicing is triggered through pointer input as well as focus input.

I'll say if we cannot make a disabled control voice through pointer input, the control should also not be able to get an interactive highlight.

I agree we should all be at a design meeting because the question is more about do we want to be able to Voice a disabled control through pointer input.

I can imagine for some learners it would be helpful to get a hint about why the control is disabled if they click on it when it is disabled.

For example, the Ratio Lock checkbox in RaP is disabled when hands are not at the challenge ratio. The checkbox has dynamic help text in the PDOM. It could be useful to Voice, the help text as a hint when the checkbox is disabled. When learners have hints checked in Preferences they typically get both a Name Response and Hint Response like this:

• "Ratio Lock, Enabled when hands are at challenge ratio."

If they do not have hints checked, then they would just get a Name Response:

• "Ratio Lock"

I think having access to a hint in cases like this is more important than having access to the name, but the two go hand in hand in Voicing since Name responses are on by default. I have a feeling there may be many scenarios in PhET sims where a control can be disabled and a learner might not know exactly why.

[zepumph]

• ParallelDOM.pdomEnabledListener should run on inputEnabled instead of enabled.

[zepumph]

we want to test to make sure that aria-disabled is being spoken correctly by screen readers in the case.

[zepumph]

In NVDA, aria-disabled is correctly added to inputEnabled:false nodes, and it sounds like "unavailable". It is seeming really nice here!

[zepumph]

@terracoda can you let me know what it sounds like on the range combo box or the ratio lock in ratio and proportion on VO? They are running on the same thing.

[zepumph]

Feel free to close if you'd like.

[terracoda]

On keyboard focus of the disabled Range combobox, I hear this from VoiceOver:

When I move focus to the disabled Ratio Lock check box, I hear:

[terracoda]

@zepumph, I hear nothing on the Voicing platform. Nothing with keyboard focus, nothing with mouse click.

Is this a dead issue?
It is not a dead issue from a design perspective. I think we should have the option to Voice the name and the hist for a disabled control.

[zepumph]

Not a dead issue, just not in the running for the near future. It is being tracked in #1220 and is listed in deferred rocks in the a11y-team quarter goal planning doc. If all is good from a description perspective, I believe this issue is ready to close.

[terracoda]

Yes, I think the related RaP issues are marked as deferred - we likely won't get to this for RaP.