Consider a high level API for Voicing to match the high level API of ParallelDOM

[jessegreenberg]

We are considering a "Tier 1" feature set for description features, which includes the "high level" API from ParallelDOM (accessibleName, helpText, possibly others).

There is significant overlap between accessibleName and voicingNameResponse, and helpText and voicingHintResponse. We want to consider an API that makes it simple to set both of these at the same time. It should be possible to set both Voicing and Interactive Description content from a single option. We will need to keep the ability to customize so that Voicing and Interactive Description can deviate. But this issue is to consider a uniform API.

My initial thought is that we should lean into accessibleName and helpText. For example, when you set the accessibleName on a component, it is automatically used as the voicingNameResponse. Maybe the default AccessibleNameBehavior could be changed to do this for us. But this needs more thought.

[terracoda]

@jessegreenberg, I would support this approach. It is ideal that the accessibleName and voicingNameResponse be the same unless absolutely necessary to be different.

I would also support the same for helpText and voicingHintReponse, but I know from my experience, that there tends to be more differences between the 2 features when it comes to helpText and voicingHintResponse. In the case of helpText, I tend to be more verbose in order to allow more details for the non-visual experience. Whereas, for Voicing, the theVoicingHintResponse is directly concatenated with the voicingNameResponse, so I have often made the voicingHintResponse shorter than the corresponding helpText. I still think that starting with helpText is good approach, and is how I think about it as a designer.

Can the sharing go both ways, like in the case of Quadrilateral where we did the description for Voicing first?