Steps to reproduce the issue
| Milestone 1a finding ID |
M1a-008 |
| Backlog priority |
High |
| Severity — carried from Milestone 1a |
Serious |
| Implementation effort |
Medium |
| Target milestone(s) |
MS2b — Complex Components; MS3a — Frontend Template Build; MS3b — Backend Template Build |
| WCAG 2.2 success criterion |
1.4.13 Content on Hover or Focus; 2.1.1 Keyboard; 4.1.2 Name, Role, Value |
| Responsibility tag(s) from report |
Development |
| Affected Joomla area/component |
Dashboard checkout information, article-list tooltips, MFA default indicator, and frontend editing tooltips — Milestone 1a finding #8 |
| Affected user journey(s) |
01 — Backend Template (Atum); 05 — MFA Setup — Method / Methods Views; 08 — Backend List View Pattern; 10 — Frontend User Forms |

Audit finding
Additional information presented through tooltips is not consistently available through keyboard interaction, cannot always remain open while the pointer moves onto it, or cannot be dismissed without moving focus or the pointer.
The report identifies these cases
- Popular Articles dashboard module — checkout information is attached to a lock indicator whose audited implementation is not keyboard focusable and does not expose suitable control semantics
- Articles list — the tooltip cannot be hovered or dismissed without moving the pointer or focus
- MFA Passkeys list — the “Default” tooltip on the star indicator has hover/focus interaction barriers
- Frontend editing controls — tooltips are unavailable in small viewports and cannot be dismissed without moving keyboard focus
The failures need to be checked separately because the affected views may not use identical markup or tooltip handling.
User impact
Keyboard users may be unable to discover the checkout information shown to pointer users. That information helps explain why an article is locked and who has it checked out.
People using magnification may need to move the pointer onto the tooltip to read it. If the tooltip disappears during that movement, they cannot reliably inspect the information.
A tooltip that covers other content and cannot be dismissed while focus remains on its trigger forces users to abandon their current position to clear the obstruction.
Screen reader users may also miss the information when the trigger lacks suitable semantics or the tooltip text is not programmatically associated with it.
In frontend editing, losing the tooltip at a narrow viewport can remove useful context about which item the edit action affects.
Remediation plan
Fix the specific integrations and provide a consistent way to reveal, read, and dismiss the additional information
- Identify whether each failure originates in shared tooltip behaviour or in the markup supplied by an individual module or view
- Prefer persistent text or an inline disclosure when the information is important and a tooltip adds unnecessary interaction complexity
- If retaining tooltips, make their information available through keyboard focus as well as pointer hover
- Use a suitable focusable element for the trigger
- Use a native button when the element performs an explicit disclosure or other action
- Preserve an existing link or button's primary action rather than replacing it with an unrelated tooltip action
- Give the trigger a useful accessible name and associate supplementary tooltip text appropriately, such as through
aria-describedby
- Do not rely on
aria-labelledby attached to a generic non-interactive container as the complete accessibility implementation
- Allow users to move the pointer from the trigger onto the tooltip without making it disappear
- Keep the content available while the trigger or tooltip remains hovered, or while the trigger remains focused, unless the user dismisses it or the information becomes invalid
- Provide dismissal without requiring the user to move focus or the pointer, such as Escape where appropriate
- Do not require keyboard focus to move into a non-interactive tooltip merely to read its text
- If the popup contains interactive content, use an appropriate disclosure or popup pattern rather than treating it as a simple tooltip
- At narrow viewports, preserve the information or provide an equivalent accessible presentation
- Verify each affected view after any shared change instead of assuming that one repaired instance resolves every case
Preconditions
- Use Joomla 6.2
- Use Atum for administrator testing and Cassiopeia for frontend testing
- Record the exact build, browser name and version, operating system, viewport dimensions, and any screen reader used
- Use a test installation for checkout and MFA setup
- Ensure that the Popular Articles dashboard module is displayed and contains a checked-out test article
- Use a separate test account or session to maintain the checkout state without modifying a production article
- For MFA testing, use an account with a configured passkey and a visible default indicator
- For frontend testing, use an account permitted to edit the displayed content
- Do not include MFA secrets, authentication codes, or unrelated personal information in evidence
Steps to reproduce — dashboard checkout tooltip
- Open the Joomla administrator interface at the site's base URL followed by
/administrator/
- Open the Home Dashboard
- Locate the Popular Articles module and the checked-out test article
- If the module or lock indicator is absent, establish the required test setup before continuing
- Hover over the lock indicator
- Record the tooltip text and the information it provides
- Move the pointer from the indicator onto the tooltip
- Record whether the tooltip remains visible
- Keep the pointer in place and attempt to dismiss the tooltip using the available dismissal method
- Test Escape and record whether it works
- Move the pointer away and use Tab or Shift+Tab to reach the same indicator
- Record whether it receives keyboard focus and reveals the same information
- If it is reachable, attempt dismissal without moving focus
- Inspect the trigger's element type, role, accessible name, and relationship to the tooltip
- Record the module and markup tested
- Do not assume that a different checkout indicator elsewhere uses the same implementation
Steps to reproduce — Articles list tooltip
- Open Content → Articles
- Locate the checked-out test article and its lock or checkout-information trigger
- Reveal the tooltip with the pointer
- Move the pointer onto the tooltip and check whether it remains visible
- Attempt to dismiss it without moving the pointer
- Navigate to the trigger with the keyboard
- Check whether focus reveals the information
- Attempt to dismiss it without moving keyboard focus
- Record keyboard access, hover persistence, and dismissal as separate results
Steps to reproduce — MFA Default tooltip
- Open the test account's MFA management page through the available account settings
- Open the configured Passkeys list
- Locate the star or other indicator identifying the default passkey
- Hover over it and record the “Default” tooltip
- Repeat the pointer-movement and dismissal checks
- Check whether the same information is available through keyboard navigation or another accessible presentation
- Record the exact trigger and whether it has an independent action
- Do not change the default authentication method or remove a passkey during the test
Steps to reproduce — frontend editing tooltips
- Open the site's frontend and sign in with the permitted test account
- Locate an available edit control associated with an article or module
- Record the page URL, item title, and edit control tested
- At a wide viewport, reveal its tooltip using hover and keyboard focus
- Record the information provided
- Attempt dismissal while keeping focus on the edit control
- Reduce the viewport width to 320 CSS pixels
- Record the viewport height and browser zoom
- Repeat the hover and keyboard checks
- If the tooltip is suppressed, check whether equivalent information remains available through the control's name or nearby text
- Record any information lost in the narrow layout
- Do not activate an edit or checkout action merely to test tooltip dismissal
Supplementary screen reader verification
- Enable a screen reader and record the screen reader and browser combination
- Navigate to each available trigger
- Record its announced name, role, and supplementary information
- Compare that information with the tooltip shown to pointer users
- Check whether dismissal preserves a useful focus location
- Record results separately for each module or view
Version
6.2
Expected result
Tooltip information is available through keyboard interaction and is programmatically associated with an appropriate trigger.
Where hover/focus content is retained, users can move the pointer onto it, keep it available long enough to read, and dismiss it without being forced to move focus or the pointer, subject to the applicable criterion's exceptions.
Narrow layouts do not remove information without an equivalent accessible presentation.
Actual result
The audit reports keyboard-access and semantic problems with the dashboard checkout indicator, hover and dismissal failures in the Articles list and MFA default indicator, and missing or non-dismissible tooltips on frontend editing controls.
The individual failures and their implementation sources need to be verified separately in Joomla 6.2.
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?
N/A
Additional Comments
The browser entries above are carried forward from the original issue and do not represent a new verification of every browser against Joomla 6.2.
The supplementary screen reader checks are proposed verification, not a claim that a screen reader was used in the original test.
The issue discussion disputes a universal tooltip-component diagnosis and identifies incorrect tooltip placement in a particular module as a possible cause. Verify the affected module markup before applying a global change.
The original report's affected-sample list identifies MFA Setup as journey 05. A subsection labels that example “06 – MFA Setup”, but journey 06 is Media Manager; this draft follows the affected-sample list.
Development is the responsibility tag in the original report.
MS2b is proposed only for shared tooltip-component work that investigation establishes is necessary. MS3a and MS3b cover the documented frontend and backend integrations.
cannot confirm
keyviz_RhhZVi0S14.mp4