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.

[brennanyoung]

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.