search

googlearchive / core-selector

Manages a list of elements that can be selected
9 stars 14 forks source link

Accessibility: core-selector is missing semantics #28

Open marcysutton opened 9 years ago

marcysutton commented 9 years ago

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.

Core-selector with missing ARIA attributes

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

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 commented 9 years ago

@azakus is there anyone working on this?

addyosmani commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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?