More abstraction for accessible components

[jessegreenberg]

In phetsims/john-travoltage#149 @jonathanolson said:

It may make sense long-term to think about mix-ins for specific component types.
For instance, say you have a Path that you want to be a slider in the DOM. You need:

tagName: 'input',
inputType: 'range',
ariaRole: 'slider',

set, possibly parentContainerTagName: 'div' or others, you'll want the workaround:

// Safari seems to require that a range input has a width, otherwise it will not be keyboard accessible.
this.domElement.style.width = '1px';

you'll want to handle the min/max/step attributes, etc., and maybe custom slider-related functions would be good (handles a Range and a Property{number}).

Now say you want to do that for a Text element.
It makes sense to be able to mix in this "AccessibleSlider" behavior into any Node, e.g.:

AccessibleSlider.mixin( AppendageNode ); // after the inherit

and

this.initializeAccessibleSlider( ... ); // somewhere in the constructor

where the mixin can handle hooking up all of the events (change/input/blur) into a Property{number} value and Property{boolean} dragged that clients can use.
Also I'd note that this is the typical case of mix-ins, where you need to add in behavior (acting like a slider) to any point in a normal inheritance hierarchy.

[jessegreenberg]

Is there a precedent for conditionally mixing something in? For instance, say sun/HSlider mixes in AccessibleSlider, which sets the accessible content and adds axon/Properties for clients.

But if in some context we want a sun/HSlider to look like

<div role="slider" tabindex="0></div>

with a custom set of listeners and Properties, we could have changes to the HSlider prototype or other things that we don't want.

[jessegreenberg]

@jonathanolson responded with:

HSlider as a type would either have it mixed in or not. If the flexibility is warranted, you would either:

• Not have it mix it in, and have clients do so. This may be helpful if you need customizable mixins with parameters, e.g. AccessibleSlider.mixin( HSliderSubtype, { options } ).
• Have another mixin which overrides some of AccessibleSlider's behavior.

[jessegreenberg]

I really like the first suggestion in #607 (comment). It seems useful to be able to customize the accessible component with options, so that any portion of the content can be changed, rather than overriding specific behavior with another mixin.

[jessegreenberg]

We should investigate and see how this feels, but I am wondering if this pattern would be overkill for the majority of accessible content. For instance, to create a button with the Accessibility mixin, you might do

Node.call( this, {
  // a11y options
  tagName: 'input'
  inputType: 'button'
  accessibleLabel: 'Translatable Label'
} );

this.addAccessibleInputListener( { click: clickListener } );

Sliders are more complex, but most input elements tend to be this simple.

[jessegreenberg]

With the first bullet in #607 (comment), we might have

// in the constructor
this.initializeAccessibleButton( {
  accessibleLabel: 'Translatable Label',
  listener: clickListener
} );

// outside of constructor
AccessibleButton.mixin( MyButtonNode );

[zepumph]

This relates highly to our work during this week's a11y sprint. Adding to a11y meeting.

[zepumph]

@jessegreenberg and I discussed this outdated issue today. There is nothing left here, we now have multiple mixins for a11y technology.