Accessibility: core-selector is missing semantics

[marcysutton]

To be accessible, <core-selector> needs to communicate its role and state to assistive technologies. It also needs to be accessible from the keyboard, but this issue is focused on semantics.

I don't see this component extending a native <select> under the hood and there are no ARIA attributes being added dynamically. Can you elaborate on the lack of accessibility in the current version of <core-selector> and if we can expect an update to it? I'm willing to work on a PR, but I don't want to overlap existing efforts.

A more accessible version built on-top of core-selector, uses roles, aria-activedescendant and child IDs (PR forthcoming):

If accessibility is meant to be "layered on" as a plugin, it is highly likely developers will forget it...making this component less useful. It really should be built into the core component. Just wondering if that's already on your radar, since I don't see any open issues for it.

[robdodson]

@azakus is there anyone working on this?

[addyosmani]

I'm +1 for this being baked in to the element (if feasible). There are likely to be historical constrains around just extending <select>, but we could possibly add in core-a11y-keys support and start to look at the ARIA attributes too.

Thanks for working on a PR @marcysutton!

[robdodson]

Just quoting @azakus here:

I think I asked about this myself before, and the team came to the conclusion that core-selector is a base class for many things, so baking accessibility into that element might be a mistake. Instead, subclasses should work out how accessibility functions for them.

For instance, core-menu and core-tabs extend core-selector, and it may be better for those elements to handle a11y.

I'm personally unsure what is the best approach since core-selector can be used standalone inside a custom element.

cc @frankiefu @morethanreal

[marcysutton]

I highly recommend accessibility be included if possible, for a few reasons:

1. core-selector can be used by itself (if it isn't supposed to be, then it shouldn't be in a demo).
2. core-selector is likely to be used as a base for custom elements, exposing 3rd-party developers to accessibility issues (example: basic-list-box).
3. Good examples of accessibility in Web Components are desperately needed to teach people how they should be coding.

Also: core-menu and core-tabs will likely have different accessibility requirements, so they could override anything they have inherited.

Any input, @alice?