Skip to content
This repository has been archived by the owner on Jan 13, 2025. It is now read-only.

[Chips] Don't force aria-checked attribute on choice/filter chips #4910

Closed
vanessanschmitt opened this issue Jul 16, 2019 · 4 comments
Closed
Assignees
Labels
backlog feature-request Unresolved (Archived) Open and unresolved issues and PRs that were closed due to archiving the repository.

Comments

@vanessanschmitt
Copy link

Angular Material is experimenting with MDC-backed chips. We are using a custom adapter, and we recently implemented the setAttr method that was added to the adapter interface in #4736.

I saw that setAttr is being used by the chip foundation here to toggle the aria-checked attribute for choice and filter chips. The MDC specs were updated so that choice chips now have role="radio" and filter chips have role="checkbox".

aria-checked makes sense in these contexts, but we are not using these roles for our own choice/filter chips. Ours have role="option" (the container chip set has role="listbox"). We therefore toggle aria-selected, and aria-checked doesn't make sense. Right now we are working around this with a check in setAttr to no-op if the attribute is aria-checked. angular/components#16530

We may consider in the future adding radio and checkbox interaction patterns, but we would still be keeping our current option/listbox pattern alongside them. Since aria-checked assumes certain roles, could you consider not managing aria-checked in MDC and instead leaving it up to the developer?

@jelbourn
Copy link
Collaborator

Chiming in to confirm that I agree aria-checked is too specific here, since the "Filter chips" part of the spec is very much a listbox pattern.

@patrickrodee
Copy link
Contributor

Thanks for filing this issue. I'm open to any suggestions on how to achieve this.

@patrickrodee
Copy link
Contributor

FYI the a11y spec for chips lists selectable chips (like filter) as being role="checkbox"

https://docs.google.com/document/d/1b0A08XkeRfKojc-6dccEXYPaUTy7ALHYg8D0-kAU_hU/edit#heading=h.g6fqgtabqq5g (link is only accessible to Googlers)

@vanessanschmitt
Copy link
Author

@stevenyxu

@asyncLiz asyncLiz added the Unresolved (Archived) Open and unresolved issues and PRs that were closed due to archiving the repository. label Jan 13, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
backlog feature-request Unresolved (Archived) Open and unresolved issues and PRs that were closed due to archiving the repository.
Projects
None yet
Development

No branches or pull requests

5 participants