Selectable: Add ARIA semantics and keyboard handling

[davidb]

For accessibility, we should add an attribute to elements that are selectable. Using WAI-ARIA we can do the following:

1. If an element is selectable, specify attribute aria-selected=false
2. If an element is selectable, and selected, aria-selected=true
3. If an element is not selectable, provide no aria-selected attribute

So in codespeak something like:

this.element.addClass("ui-selectable");

would be:

this.element.addClass("ui-selectable").ariaState("selected",false);

I wonder if we should first refactor (extract-method) such that there are one or two places where selection related classes are added or removed?

[Scott González]

From #3481 (duplicate):

The "Selectable" interaction might be a good place to auto-expose the following ARIA semantics: aria-selected aria-multiselectable

The aria-multiselectable = true|false would apply to the container element. The aria-selected = true|false would apply to the selectable items. There is no aria-selectable, but if aria-selected is not undefined, selectability is assumed (by browser, and exposed to platform accessibility layer).

[tj.vantoll]

#9634 is a duplicate of this ticket.

[tj.vantoll]

Per #9634 the widget should be focusable with the keyboard.

[dylanb]

This will require more than simply implementing these attributes. Will require role="option" and role="listbox" as well as potentially aria-multiselectable.