Consider a "token" role for next version

[DavidMacDonald]

An example when you have a dropdown autocomplete as you select items little icons appear visually inside the input that correspond to the choice, but are actually inside spans above or below the input that were positioned ... you can see inaccessible examples here.
https://joshuajohnson.co.uk/Choices/

[slafleche]

I would also see variants to this display where the "tokens" are just added to a list above the input. Much like GitHub handles labels.

You're basically choosing a subset of items from a group with a search. This styles of input saves you from having a very long list of checkboxes.

[jnurthen]

@DavidMacDonald Can you please clarify this issue. I have no idea what it is referring to. What would a token role be used in. Can you give an example as to how this would be structured? What would it map to in accessibility APIs?

[DavidMacDonald]

A token would be a little icon that is overlaid on an input select.

<input aria-token="p1 p2 p3">
<span class="token"  role="token" id="p1>Preset-1</span>

@jnurthen

[stes-acc]

I highly second this. Plus, tokens can be individually deleted as depicted beautifully above.
In addition, they form up a typed list (list of tokens) like options in a listbox.
They can also individually being focused and selected (!) with keyboard.
A very common example are the name tokens in the "To:" field of an outlook mail message.
There are numerous examples for this in the Web, for instance here.

[jnurthen]

@cookiecrook I notice MacOS has native controls for this - https://developer.apple.com/design/human-interface-guidelines/macos/fields-and-labels/token-fields/
Is there documentation somewhere about the API mappings of a token field?

[cookiecrook]

AppKit has an NSTokenField, which provides the token UI and keyboard behavior of the surrounding text/object siblings. The behavioral difference of native tokens is that they can be buttons that are also selectable text chars (single atomic char representing the full token)... That said, I've never seen web UI that does text selection well for token views.

To answer your question directly, the mapping of the macOS UI is an AXTextAttachment inside an AXTextField, but I would not suggest ARIA map anything like that. Implementations of native tokens usually rely on an "object replacement character" inside a standard text field. I'm not certain that is currently possible in an HTML DOM context, though contenteditable images may be done similarly. In any case, I've never seen web tokens implemented this way, and I don't think most web authors would think to do it this way (descendant of a text field), so the current macOS mapping is probably irrelevant for this discussion.

For web teams trying to make token-like UI accessible, we usually recommend the token field be a single auto-complete field, and as entries are added, the "tokens" are inserted as buttons before the field.

I don't have a strong opinion whether or not a token role should be added, but IMO the tokenfield is the more useful of the two. The field defines the interesting behavior. The token is just a button inside that field...

[cookiecrook]

@stes-acc wrote:

They can also individually being focused and selected (!) with keyboard.
A very common example are the name tokens in the "To:" field of an outlook mail message.
There are numerous examples for this in the Web, for instance here.

This is one of the examples I mentioned where keyboard behavior is implemented incompletely. You can't select them as part of the same field (e.g. with shift+arrows) or move the insertion between, so these don't act like native tokens. They just act like buttons inserted before the text field.

That said, the widget author did implement some capturing of the arrows and delete keys, so hearing "token" in the role description might make it a little easier to understand why the arrow key interception and focus changes are happening.

[cookiecrook]

Inspecting both examples linked and the GitHub example @slafleche mentioned, these are all implemented as buttons before text fields. Not really the same functionality of a native token field, but probably still different enough from standard buttons to warrant a new role or two.

[jnurthen]

(if we go down this path) Alternate names I have seen used for these are "tag" and "pill" instead of "token"

[cookiecrook]

Not tag please. That's a much narrower semantic use of a similar visual UI.

[carmacleod]

Alternate names I have seen used for these are "tag" and "pill" instead of "token"

Also, "chiclet" (believe it or not).

[AmeliaBR]

Before getting too deep into a naming discussion, it's worth considering the scope of the role:

• Does it apply to the entire widget, meaning the input field, any drop-downs, and the list of currently selected values?

• Or should the role only apply to the individual value, and it's cancel button? The list box or combo-box that adds tokens would then be a separate widget.

Either way, we need to consider how to represent the relationship between the list of currently-selected tokens and the input that adds new values.

Its also worth considering other presentations of widgets with the same semantics. E.g., consider the GitHub widget for adding labels or assignees to an issue. It doesn't use a "pill" view but instead lists the currently selected values at the top of the drop-down list of other available options, after the type-ahead input field.

Regardless of the final scope, I would strongly argue for names based on semantics and not the currently fashionable visual presentation (text on a solid background with rounded corners, AKA a pill shape).

[carmacleod]

The semantics of the "widget as a whole" are wild. :)

It's almost like a "multiselectable" combobox that "controls" tokens as well as its dropdown list.
(I'm not suggesting re-using combobox! It is already overloaded. I'm just using it to compare semantics).

One complication that I have seen is that in addition to having an X to remove tokens from the selected list, they can be "activated" like a button. For example, in an email "To:" or "CC:" list, clicking on a token opens a contact info card. Or, it might turn a token back into text so that it can be edited in the input field.

[mcking65]

I'd like for us to strongly consider every possible way of resolving this without another role. Thinking as a user, I don't want to learn the meaning of one more role. As an author, do I really need another role? If my "token" has characteristics of a button or link, why not just use a button or link role? I have a hunch we can solve this with patterns that employ existing roles.

[stes-acc]

Is aria-roledescription="Token" ok? We need APG examples.

[scottaohara]

that would just overwrite the announcement of the underlying role of the element, disguising its purpose. would agree with matt here, what value does a "token" have to someone where an established role would better communicate how it would function.

[stes-acc]

I strongly disagree. Overwriting the announcement is always happening. If this is not wanted, we would need a strict limitation of use cases of aria-roledescription which is NOT specified so far in current ARIA spec.

Going forward this path we would also forbid using role="button" on a HTML anchor, something that is also in a gray zone and topic of ARIA in HTML.

But I am with you if you saying role=token is more straight here.

[scottaohara]

talking about two different things here.

changing a native anchor to be exposed as a button via role=button, and using aria-roledescription to announce a button as a "token" which has no agreed upon/universally known meaning, are quite different.

[stes-acc]

Partly correct. The speech output override is the same. The API mapping is not.

In addition, it would be wrong to give a token a base role of button since all its semantics are different. A base class of listitem with aria-roledescription="Token" in a Token list is a better mapping which also allows for token position info and acceptance of special properties like being "deletable".

It is about time that HTML input and select/combo elements reflect contemporary extensions like this one for tokens being intrinsic part of an input and not a faked add-on.

The discussion should be more biased towards this, browser vendors involved.

[scottaohara]

Partly correct. The speech output override is the same. The API mapping is not.

I wasn't indicating otherwise... "token" having no api mapping though, and being generally meaningless as it's design/ui jargon... comparing api mappings here isn't relevant.

In addition, it would be wrong to give a token a base role of button since all its semantics are different...

except for instances where it would be appropriate. there is no 100% agreed upon pattern/ux for a "token". so that statement is more opinion than fact at this point.

It is about time that HTML input and select/combo elements reflect contemporary extensions

that's why the "open ui" tag was added to this thread. next steps should be engaging with that group, and as Matt says, see if there aren't ways we can move forward with this concept without introducing roles that have no universally accepted understanding or meaning.

[aleventhal]

We have a Chrome bug filed for this as well -- at least the attempted code does not work in Chrome:
https://bugs.chromium.org/p/chromium/issues/detail?id=991203

[brennanyoung]

Material calls this a "chip". The one with the close box is called an "inputchip". I don't really like these names. Makes me think of casinos or snacks.

https://m3.material.io/components/chips/guidelines

[brennanyoung]

I notice that ebay is using <a> for these.
Can anyone suggest why they made this choice? Is it ok?

The HTML5 spec for <a> (like ARIA's "link" role) forbids interactive descendents, which means that a separate 'close box' inside the chip is going to cause trouble. These are common. What do we do here?
The HTML5 spec for <a> without href forbids naming.

Seems to me that <a> is no more suitable than checkbox or button.

[brennanyoung]

Important note: Some implementations of "token" support re-ordering by drag-and-drop. I've never seen this with button/checkbox/radiobutton/link.

[brennanyoung]

that's why the "open ui" tag was added to this thread. next steps should be engaging with that group, and as Matt says, see if there aren't ways we can move forward with this concept without introducing roles that have no universally accepted understanding or meaning.

open ui has marked the issue as "stale".
How can we move this along?

[pkra]

How can we move this along?

The issue is on the aria 1.4 milestone and aria 1.3 does not have a first public working draft yet.

@scottaohara is this topic something for #1832 perhaps?

[brennanyoung]

All the suggested names have flaws, but I agree with @AmeliaBR :

I would strongly argue for names based on semantics and not the currently fashionable visual presentation.

Also there are several different kinds of "token" or "chip". (I'm gonna use "chip" here). They don't all behave the same way, and their behavior may depend on a the higher-level widget that contains them (often some kind of option list, or input field). Without getting distracted by the similarities or differences of their appearance, it would be valuable to determine whether these different kinds of chip are actually distinct types of element or whether they are a 'family' of component types with some taxonomical relationship.

Common Use Cases

• In editable email/messaging recipient lists. (Reorder, remove)
• As lightweight wrappers for hashtags and similar under a post. Often, these function as hyperlink searches.
• As removable filters for search results (e.g. ebay)
• As booleans included in a form submission. (Pseudo checkboxes).

any more?

Questions/Comments

• Are chips "phrasing content"? I think so. AFAICT Chips are invariably "inline". Any exceptions?
• Should there be any rules, constraints or guidelines about the semantic context where chips are permitted? For example, should a filter chip be required to be a child of (or have some semantic association with) a container with role="search"?
• Some chips have something that looks like a close box, but semantically it is "remove" rather than "close".
• Should chips be tab stops? Or should focus be managed by the the containing widget?
• How does the close box (more correctly, the "remove" button) fit into the tab sequence, ideally?
• If a chip is in focus and you press "Delete" on the keyboard, I think it should behave as if the "remove" button has been clicked. (If there is a one). Any dissenting opinions on this?
• Quite a few of the implementations "in the wild" support reordering of chips/tokens (typically by drag-and-drop). Suggest viable keyboard interface for this? What about touchscreens? How to distinguish reordering from deleting?
• If not via role (or aria-roledescription) What cues may be offered to indicate that chips may be deleted, reordered, deselected?
• Consider aria live regions and aria-relevant="removals" - to provide AT cues that the deletion actually occurred.
• Some chips behave more like toggle buttons or checkboxes (can't be removed, but can be 'unchecked'). These may be implemented today as <button> with a value for aria-pressed, or even as role="switch". Which is better? APG?
• I've seen chip-like elements which are basically radio button groups. Existing ARIA can handle these cases. APG?

If a chip/token is implemented as <a> (as ebay does):

• What's the "href"? Is it null? In which case naming is prohibited!
• For both <a> and role="link", focusable child elements (e.g. the closebox) are forbidden.
• <a> might yet be appropriate in some cases (e.g. tag cloud under a post, where each tag is a search url)

Possible implementations (APG?) with today's specs:

• Wrapper <ol> with Chips as <li>, with <button> "remove" inside - <ol> might support the notion of re-ordering but <ol> and <li> are non-operable roles. (Missing aria attribute to indicate that a collection is ordered).
• Wrapper role="group" seems viable in some cases. For more elaborate implementations I'm looking at role="application".
• chips as <a>. visible "remove" button is excluded from the a11y tree. Chip itself responds to "Delete" key when in focus
• chips as <input type="checkbox">

[stes-acc]

We need an APG proposal for this. Still role=button with aria-roledescription="token button" would be my favorite.

[brennanyoung]

Given that so much of the complexity of tokens/chips comes from their "secondary actions" (delete/reorder) I'm wondering if this might be approached as part of #1440

[slafleche]

Given that so much of the complexity of tokens/chips comes from their "secondary actions" (delete/reorder) I'm wondering if this might be approached as part of #1440

I agree 100% that this fits into a broader need for a way to describe secondary actions. Custom implementations need to be described as such. However, I believe they are common enough to merit their own label. It will be easier and quicker for the user to understand what the input is.

[cookiecrook]

@brennanyoung Delete/remove obviously useful, but does anyone know of a real-world example where the reordering of tokens is useful or critical? I don’t recall seeing that as a UI pattern.

For example, you can reorder email tokens in a To: field, but practically speaking, the order doesn’t matter.

[slafleche]

@brennanyoung Delete/remove obviously useful, but does anyone know of a real-world example where the reordering of tokens is useful or critical? I don’t recall seeing that as a UI at term.

Although tokens may often be "flat", there are cases where there's a hierarchy.

Say you're on a forum, and users can have multiple roles. The user may want to chose the order their roles appear on their profiles, putting the most important roles to them first.

[jnurthen]

closing - this should be in HTML before ARIA. If HTML creates this then we should revisit.