Slider does not generate a useful ARIA label

[marcysutton]

When using $materialAria.expect() to handle labeling of the material-slider component, unless developers provide a custom aria-label attribute themselves (and few will), no useful label is generated nor is a warning logged to alert the developer. For example: because material-slider injects a model value like 70 as text, $materialAria.expect() copies that text into an aria-label, but that is not a useful label for a slider.

See aria-label="70" and the highlighted span (child node):

Expected behavior:

• Developer omits aria-label, so a warning is logged telling them to do so.
• Developer includes aria-label and the purpose of the component is clearly communicated to AT users. Useful labels would be "Volume" or "Rating 2/5"

Related PR: #344

[marcysutton]

@ThomasBurleson @ajoslin any input on how to handle this slider labeling issue? Should we require developers to include a label?

[ThomasBurleson]

Here is a snippet of slider used in our own demos:

<h3> Rating: {{rating}}/5 </h3>
<material-slider 
    discrete 
    aria-label="rating"
    ng-model="rating" step="1" min="1" max="5" >

</material-slider>

Personally, adding a label attribute/value seems at odds with the slider itself, since we do not inject a label DOM element. And the only reason we are considering one here is to prepare a clear aria-label value.

If we offered a label attribute, it would confuse the developer because they would think

<h3> Rating: {{rating}}/5 </h3> 

was not needed. I wonder if we simply [and only] warn of a missing aria-label value here. The developer could then easily do this:

<h3> Rating: {{rating}}/5 </h3>

<material-slider discrete 
    aria-label="Rating {{rating}} of 5"
    ng-model="rating" step="1" min="1" max="5" >
</material-slider>

[marcysutton]

So, depending on the component, we don't copy $element.text() into aria-label and just warn if the attribute is missing? That is a good idea! 💡

[ThomasBurleson]

Well for slider we would not have text() body nor a label attribute, so we warn only. I think for other components [where these two sources are confusing] we would also warn.