Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Role: taglist #2304

Open
MarioBatusic opened this issue Aug 6, 2024 · 5 comments
Open

New Role: taglist #2304

MarioBatusic opened this issue Aug 6, 2024 · 5 comments
Labels
feature may add new concept(s) to ARIA which will require implementations or APG changes

Comments

@MarioBatusic
Copy link
Contributor

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:

  1. toolbar, which should be restrected so that it contains only button and combobox as accessible children, or

  2. 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.

@MarioBatusic MarioBatusic added feature may add new concept(s) to ARIA which will require implementations or APG changes aria-live labels Aug 6, 2024
@JAWS-test
Copy link
Contributor

Related: #689

@JAWS-test
Copy link
Contributor

@MarioBatusic
Copy link
Contributor Author

@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
Copy link
Contributor

@MarioBatusic I agree with you. But I wanted to refer to the old discussions. role=grid is not a good way to implement tags: w3c/aria-practices#1233 (comment)

@spectranaut
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature may add new concept(s) to ARIA which will require implementations or APG changes
Projects
None yet
Development

No branches or pull requests

4 participants