MarioBatusic commented 3 months ago

Description of bug or feature request

There are several desktop and web applications that use similar GUI constructs for creating and selecting tags as found in the “To” fields of MS Outlook and Gmail. These widgets are often known as “tagging” or “chips” components.

Although with similar visual design and the same functionality, these components are not standardized. There is neither an HTML element nor an ARIA role to express their semantics.

The tagging pattern has been in use already for a long time - both on the web and in desktop applications. The most representative example is the To field in email programs such as Outlook and GMail. Other software programs use it to create or select tags.

Different Implementations

Here are some examples:

To field in Microsoft Outlook (desktop app)

It is a combined control consisting of an input field/combo box and entered email addresses, each with a separator behind it if several are entered. UIA presents the control as a document that, in addition to the text for separators, spaces and input strings, also contains buttons with the entered email addresses. This flexibility allows you to enter an email address in any sequence position.

Outlook to-field with accessibiliy tree Outlook to-field-popup with accessibility tree

GMail

"To" field in GMail uses a complete different, non-valid ARIA: In a listbox options represent already entered mail adresses. On the end as a last child of the listbox there is a combobox to select / create a mail adress.

GMail to-field

GMail to-field accessibility tree

Select2 - JQuery Library

Select2 - JQuery screenshot

Select2 - JQuery accessibility tree

Example for tagging with JQuery multi-value select boxes: https://select2.org/tagging

Jira

Jira offers extensive tagging options for issues. Users can enter labels and choose from suggestions.

Jira Screenshot

Jira accessibility tree

Example: https://react-select.com/home#custom-styles

Component Discussion

Regardless of whether ARIA roles are chosen differently or are completely absent in these widgets, they always consist of

a horizontal arrangement of entered tags
followed by a combo box for selecting or creating further tag.

Both visualization and the use of mouse and keyboard differ from implementation to implementation.

The widget is sometimes in the tab order. After entering the widget, the cursor is either in the empty input field / combo box or at the end of an element with the role of document (MS Outlook).
After the creation / selection of a tag is complete, the tag is entered as an option or a button and visually inserted to the left of the input field. The input field is emptied and the cursor remains mostly within it.
If the cursor is in the first position of the input field, the left arrow command focuses the previous entry as a whole.
In some cases it is possible to move between entries using horizontal arrow keys.
Mostly the tags have a context menu.

Accessibility Issues

Screen reader users in particular have problems with all implementations of tagging:

Without a correct role, it is impossible to understand what is going on here:
- Where to disappear entered tags?
- Why does the focus remain on the emptied input field after an entered tag disappears?
- If I success to find the entered tag afterwards, it is no longer a text but a button or a listbox option. And the list is arranged horizontally.

ARIA Suggestion

Name

I would suggest tagbox or taglist as a working name. There may be of course a more suitable name.

ARIA for the Widget

The new role must be noted on the common container for the combobox and for entered entries in order to clearly indicate the semantics of the entire construct.

There are two possible starting roles that can be renamed and adapted for the purpose:

toolbar, which should be restrected so that it contains only button and combobox as accessible children, or
listbox, which could be allowed to contain a combobox in addition to option children.

Will this require a change to CORE-AAM?

If unknown, leave blank. If relevant, link bug.

Will this require a change to the ARIA authoring guide?

Yes.

JAWS-test commented 3 months ago

See APG example using role=grid: https://www.w3.org/WAI/ARIA/apg/patterns/grid/examples/layout-grids/#ex2_label

MarioBatusic commented 3 months ago

@JAWS-test Thanks for calling the previous issue - that was similar but not completely explained.

The APG example is also only yet another implementation of the tagging widget and not at least clearer and intuitive for SR users. Using a grid in this peculiar way - adding new columns on each recipint input is not easy to understand.

I think the tagging pattern is so often used and so different implemented that an ARIA role can be a big help for SR users.

JAWS-test commented 3 months ago

@MarioBatusic I agree with you. But I wanted to refer to the old discussions. role=grid is not a good way to implement tags: https://github.com/w3c/aria-practices/issues/1233#issuecomment-547256458

spectranaut commented 3 months ago

Discussed briefly in new issue triage: https://www.w3.org/2024/08/08-aria-minutes#t01

MarioBatusic commented 3 weeks ago

There is a "tag" widget in the openUI project and it should be tried to get this widget accessible as much as possible.

w3c / aria

New Role: taglist #2304