Conversation
This allows interfaces (including accessible ones) to indicate to the user that the command may toggle state.
|
Looks like the test failure is from Travis, not from this PR. |
| dataset: asFunc(options.dataset, emptyDatasetFunc), | ||
| isEnabled: options.isEnabled || trueFunc, | ||
| isToggled: options.isToggled || falseFunc, | ||
| isToggleable: options.isToggleable || !!options.isToggled, |
There was a problem hiding this comment.
Is this correct? It seems like it should only be !!options.isToggled and never use the options.isToggleable.
The primary UX hint we had in mind was something that was toggleable should be represented in a menu as a checkbox (rather than just a UI element that visually was a check) so that screenreaders could recognized the toggled status. It sounds like you are basically saying that isToggleable should distinguish between the default isToggled and a user-supplied isToggled. I think you are also implying that there never is a case where the user supplies an isToggled function, but explicitly wants to say that the element is not toggleable.
I think your suggestion makes sense. If isToggleable really is just asking if the user supplied an isToggled function vs using the default function, there may be a better way to do it once we can break backwards compatibility.
1 participant
This allows interfaces (including accessible ones) to indicate to the user that the command may toggle state.