Steps to reproduce the issue

Audit finding

The tag selector is difficult to use with a keyboard and with a screen reader.

The report identifies the following problems

1. Existing selected tags appear before the “Type or select some tags” field, so keyboard users must move past them before reaching the input
2. Screen-reader users encounter repeated “Remove item” buttons and may only be able to review selected tags by hearing that label repeatedly
3. The visual “Tags” label communicates the purpose of the following controls, but this context is not programmatically available
4. Focused but unselected options in the combobox are announced as selected
5. Removing a tag moves focus to the top of the page
6. The “Remove item” buttons are smaller than 24 by 24 CSS pixels

The report recommends showing selected tags after the selector, referring to them with aria-describedby, marking selected options in the dropdown, not marking merely focused options as selected, and using a <fieldset> or role="group" to identify the tag interaction.

User impact

Keyboard users must navigate through every existing tag and its remove button before they can type or select a new tag. With several tags selected, this makes adding another tag slow and cumbersome.

Screen-reader users hear “Remove item” repeatedly without enough context to know which tag each button removes. They may need to navigate back and forth to understand the current selection.

Because the “Tags” label is not programmatically associated with the control group, users may not understand what they are selecting or removing.

Announcing a focused but unselected option as selected can cause users to believe they have already chosen it. Focus jumping to the top of the page after removal forces users to find their place again.

Small remove targets are difficult to activate with a pointer or touch, particularly for people with reduced dexterity.

Remediation plan

Improve the tag selector as one coherent component

• Place the tag-selection input before the list of selected tags, or otherwise ensure users can reach the input without traversing every selected tag
• Give the tag-selector group an accessible name that identifies it as tags
• Use a <fieldset> with a legend or a container with role="group" and an accessible name
• Associate the visible “Tags” label with the group or input programmatically
• Refer to the selected tags from the input using aria-describedby where appropriate
• Mark selected options as selected in the dropdown
• Do not mark an option as selected merely because it has keyboard focus
• Ensure each remove control identifies the tag it removes, such as “Remove tag: [tag name]”
• After removing a tag, return focus to a logical nearby location, such as the remaining tag, the input, or the removed tag's former position
• Do not move focus to the top of the page after removal
• Ensure each remove target meets the applicable target-size requirement, including through an adequately sized hit area
• Preserve keyboard operation, visible focus, and predictable focus order
• Verify searching, selecting, reviewing, and removing tags separately
• Apply the corrected component consistently across backend edit forms, frontend user forms, and Global Configuration

Preconditions

• Use Joomla 6.2 with Atum for backend testing and Cassiopeia for frontend testing
• Sign in with an account permitted to access the relevant forms
• For the Global Configuration example, open the Logging section and locate Log Priorities
• For the article example, use a test article with at least two tags selected
• For the frontend example, use a form that renders the same tag selector
• Record the exact Joomla build, browser name and version, operating system, viewport dimensions, and browser zoom
• Record the screen reader and browser combination if testing announcements
• Start at 100% browser zoom
• Use disposable test content and do not save unintended configuration changes

Steps to reproduce — Global Configuration Log Priorities

1. Open the Joomla administrator interface at the site's base URL followed by /administrator/
2. Open System → Global Configuration
   • Alternatively, navigate to /administrator/index.php?option=com_config on the same installation
3. Open the Logging section
4. Locate the Log Priorities tag selector
5. Record the currently selected tags before changing them
6. Move keyboard focus to the start of the tag-selector group
7. Press Tab repeatedly and record the order of the remove buttons, tag names, and selection input
8. Confirm whether the remove buttons precede the “Type or select some tags” field
9. Inspect the group using Developer Tools
10. Record whether it has an accessible name, <fieldset> legend, or role="group"
11. Record whether the visible “Tags” label is programmatically associated with the group or input
12. Open the combobox and navigate its options using the keyboard
13. Record whether a focused but unselected option is announced as selected
14. Select a test tag
15. Confirm that it is marked as selected in the dropdown and reflected in the selected-tags area
16. Remove a tag using its remove control
17. Record where keyboard focus moves after removal
18. Inspect a remove button and record its rendered size and hit area
19. Capture the focus order, announcements, group structure, removal behaviour, and target dimensions
20. Restore the original Log Priorities selection if appropriate

Steps to reproduce — article tags

1. Open Content → Articles
2. Open a test article for editing
3. Locate the Tags field
4. Repeat the focus-order, group-labelling, combobox-announcement, removal-focus, and target-size checks
5. Record any differences from the Log Priorities example
6. Do not save unintended article changes

Steps to reproduce — frontend user form

1. Open a frontend form that renders the same tag selector
2. Record the exact page URL and form
3. Repeat the keyboard, screen-reader, focus, and target-size checks
4. Record whether the frontend implementation differs from the backend component
5. Do not submit the form unless using a disposable test environment

Screen-reader verification

1. Use a screen reader with the browser combination being tested
2. Navigate to the tag-selector group
3. Record the announced group name, if any
4. Navigate through the selected tags and remove buttons
5. Record whether each remove button identifies its tag
6. Navigate to the selection input and record its announced label and description
7. Open the combobox and navigate its options
8. Record whether focused unselected options are announced as selected
9. Select and remove a test tag
10. Record the announcement and the location of focus after removal
11. Repeat with at least one additional screen reader if available
12. Record the screen-reader name, version, browser, and operating system

Verification after remediation

1. Open an affected tag selector
2. Confirm that the selection input can be reached without traversing every selected tag
3. Confirm that the group is identified as tags to assistive technology
4. Confirm that selected options are marked selected and focused unselected options are not
5. Confirm that each remove control identifies its tag
6. Remove a tag and confirm that focus remains in a logical location
7. Confirm that each remove target meets the applicable target-size requirement
8. Repeat in the backend edit form, frontend user form, and Global Configuration contexts
9. Record the final focus order, announcements, group structure, and target dimensions

Version

6.2

Expected result

The tag-selection input is reachable without first traversing every selected tag.

The tag-selector group is programmatically identified as tags, and its visible label is available to assistive technology.

Selected dropdown options are marked as selected; focused but unselected options are not announced as selected.

Each remove control identifies the tag it removes, returns focus to a logical location after activation, and provides an adequately sized target.

Actual result

Selected tags and their remove buttons precede the “Type or select some tags” field in the keyboard focus order.

Screen-reader users encounter repeated “Remove item” announcements without sufficient context.

The visible “Tags” label is not programmatically available to assistive technology.

Focused but unselected combobox options are announced as selected.

Removing a tag moves focus to the top of the page.

The remove buttons are smaller than 24 by 24 CSS pixels.

The current Joomla 6.2 build needs to be checked to establish which behaviours persist across the affected views.

What device were you using? (eg, phone, laptop)

Desktop web

What web browser were you using? (eg, Chrome, Safari)

Chrome, Firefox, Edge, Safari

Assistive Technology?

VoiceOver, JAWS, NVDA

Additional Comments

The browser and assistive-technology entries above are carried forward from the original issue and do not represent a new verification of every combination against Joomla 6.2.

Development is the responsibility tag in the original report.

The report's suggested aria-describedby, <fieldset>, and role="group" approaches are recommendations, not the only possible implementation. Verify the chosen approach with assistive technology.

The target-size requirement has exceptions and depends on the final implementation, including any expanded hit area. Measure the actual target and record the applicable result.

This issue concerns the tag-selector component. It is distinct from #48394, which concerns the accessible context of displayed article tag links.

MS2b is proposed for the shared tag-selector component, with MS3b and MS5b covering the documented backend and frontend integrations.