Closed switherwax closed 5 years ago
There are two ways to solve this problem:
Switch
or ToggleButton
classes. The benefit of ensuring you control is an instance of a Switch
or ToggleButton
is that you get a lot of stuff for free.
Basically, in order to implement this all you need to do is take whatever custom control you have, and ensure it is a subclass of ToggleButton
. Why ToggleButton
? ToggleButtons
inherently track state. They come with announcements and all of the other things that a control needs to share the state of something being On or Off, but they do so in a way that is more naturally announced for an Assistive Technology user in the case of a "Favorites" button.
This is deceptively difficult to get correct. There are a lot of different properties involved. We may build out this solution as an example in Deque University application, but if you want to look into the various APIs that matter while we're implementing this:
AccessibilityNodeInfo
Effecting all of these properties directly is actually quite cumbersome, especially if you are not used to working directly with AccessibilityDelegates. It is much easier to just use Inheritance! Not only that, but by utilizing Inheritance you are much more Past/Future proof.
One thing that developers tend to do THAT IS NOT a solution is to append the information to the content description for the thing.
favoriteStar.setContentDescription("Favorites, selected")
This is a non solution for one very important reason: Programmatic Determinability.
There are too many words that mean "selected" for Assistive Technologies to do anything but announce the word. Sharing the state of "Selected" or "Unselected" is only one job that this state information does. The programmatic determinability is very important and can't be ignored.
For example
Accessible Behavior
I would expect that in step 2 it announces as "Favorite, selected" or "Favorites, unselected"