Chip tags should be compatible with .prefix and labels, as with regular inputs

[netthier]

Reposting this issue from the old repo: Dogfalo#3462
Seems to still exist, as chips cannot be properly labeled in v1.0.0.

[medeaoblongata]

Just want to add some other notes about "chip". I don't know materialize very well, but I am looking at implementations for chips 'in the wild' and finding wide variation in accessibility.

I know that there is no such thing as <input type="chip"> and ARIA does not (yet) have role="chip" (although something like it is being discussed). If you have strong opinions about how these things should behave, you might give that issue a browse, and maybe offer an opinion.

Markup choices are pretty strange in the Materialize chip. We have <div tabindex="0"> but no role. This violates WCAG SC 1.3.1 Name, Role, Value. and will behave unpredictably on assistive tech. The close box is currently implemented as <i> which just seems wrong, semantically. (A close box is not "idiomatic text").

<div> without role does not support naming.
With current specs, a 'correct' implementation should address:
Grouping / Wrapping - Chips rarely appear alone, or at least we can expect to find them in groups of more than one.
So what's the grouping semantic? Could be ARIA role="group" - this supports naming.

Another option is to use a list.
Sometimes a UI permits re-ordering of chips, which indicates <ol> rather than <ul>, then each chip would need to be a <li>.

Should chips be tab stops? They are operable elements, but unlike most other operable elements, they tend to disappear when you interact with them.
If the chip is a tab stop, the close box should not be an additional tab stop. Should the entire chip act as a keyboard event target (listening for "Delete" perhaps?), with the mouse-clickable closebox hidden from the accessibility tree?

How should keyboard operation work otherwise? How to re-order chips without drag-and-drop? What about touchscreen?
For accessibility, it might be wise to make an announcement when a chip was successfully deleted. aria-live="polite" and aria-relevant="removals" on the container/wrapper?

I notice that if you tab to a chip and press Delete, the last chip in the parent container gets deleted, which is not necessarily the one that is in focus. This is a bug. "Delete" should delete the currently focused chip.

Certainly some design challenges here, I dare say this will take a few iterations (and possibly some standards changes) to be nailed.

[gselderslaghs]

@brennanyoung thanks for the heads up and my excuses for the late reply, this issue is related to #543 so I'll add it as a subtask to the queue

Just want to add some other notes about "chip". I don't know materialize very well, but I am looking at implementations for chips 'in the wild' and finding wide variation in accessibility.

I know that there is no such thing as <input type="chip"> and ARIA does not (yet) have role="chip" (although something like it is being discussed). If you have strong opinions about how these things should behave, you might give that issue a browse, and maybe offer an opinion.

🚫 This idea was not planned in W3C specs

Markup choices are pretty strange in the Materialize chip. We have <div tabindex="0"> but no role. This violates WCAG SC 1.3.1 Name, Role, Value. and will behave unpredictably on assistive tech. The close box is currently implemented as <i> which just seems wrong, semantically. (A close box is not "idiomatic text").

Correct, this should be refactored accordingly to a interactive button element

<div> without role does not support naming. With current specs, a 'correct' implementation should address: Grouping / Wrapping - Chips rarely appear alone, or at least we can expect to find them in groups of more than one. So what's the grouping semantic? Could be ARIA role="group" - this supports naming.

I like the idea of adding a group role for accessibility

Another option is to use a list. Sometimes a UI permits re-ordering of chips, which indicates <ol> rather than <ul>, then each chip would need to be a <li>.

I notice it's possible to implement the chips as unordered list items without losing its initial styling, perhaps the docs should be updated

Should chips be tab stops? They are operable elements, but unlike most other operable elements, they tend to disappear when you interact with them. If the chip is a tab stop, the close box should not be an additional tab stop. Should the entire chip act as a keyboard event target (listening for "Delete" perhaps?), with the mouse-clickable closebox hidden from the accessibility tree?

Good point, from my opinion chips should only be tabbable when the chip element contains underlying interactive functionality, highlighting the interactive button that would activate when the element is going to be triggered

How should keyboard operation work otherwise? How to re-order chips without drag-and-drop? What about touchscreen? For accessibility, it might be wise to make an announcement when a chip was successfully deleted. aria-live="polite" and aria-relevant="removals" on the container/wrapper?

Currently there is no implementation for sorting out the order of chip elements, it would be a great idea to implement, not sure how to handle this with only keyboard interaction, maybe the addition of a re-arrange icon near to the close icon would be sufficient, when activated the user could use the arrow keys followed by a return key press to confirm the changes? Not sure if this has to do with accessibility or should be addressed as a new feature request

I notice that if you tab to a chip and press Delete, the last chip in the parent container gets deleted, which is not necessarily the one that is in focus. This is a bug. "Delete" should delete the currently focused chip.

✅ This does not seem the case in current version, marking as fixed

Certainly some design challenges here, I dare say this will take a few iterations (and possibly some standards changes) to be nailed.