Steps to reproduce the issue

Audit finding

Some interactive controls do not visibly indicate when they have keyboard focus. Other controls rely on a faint browser-provided indicator that is difficult to distinguish from the surrounding background.

A focus indicator is the visible outline, border, or other treatment that shows which control will respond to the next keyboard action.

The report documents these examples

• Atum's “Toggle Menu” control looks the same in its focused and unfocused states
• The “Post Installation Messages” control has a faint blue focus outline in Safari that is difficult to distinguish against the dark background
• A Media Manager toolbar control has no visible focus indicator when focused

The report lists the wider set of audited journeys as affected, but does not identify an individual failing control for every journey.

User impact

Sighted keyboard users cannot reliably tell which control will respond when they press Enter, Space, or another action key.

In the administrator navigation, a user can lose track of whether focus is on the menu toggle, another navigation item, or a page control. They may activate the wrong action or repeatedly move backwards and forwards to recover their position.

Faint indicators are particularly difficult for people with low vision to follow against dark backgrounds. A control becoming brighter on mouse hover does not help someone navigating without a pointer.

The same problem in Media Manager makes it difficult to identify the currently focused toolbar action before activating it.

Remediation plan

Define a consistent, clearly visible keyboard-focus treatment and apply it to the affected controls across frontend and backend interfaces

• Establish shared focus tokens for the indicator's colour, thickness, offset, and treatment on different backgrounds
• Apply the focus treatment to links, buttons, inputs, selectors, and custom interactive controls
• Use keyboard-focus styling such as :focus-visible where appropriate
• Retain a visible fallback wherever the chosen styling approach requires one
• Do not remove the browser's focus outline unless a clearly visible replacement is provided
• Do not rely on a subtle hover colour change as the only keyboard-focus treatment
• Ensure that the indicator remains distinguishable on light, dark, selected, and expanded control states
• Consider a two-colour indicator where one colour cannot remain visible against all surrounding backgrounds
• Check that containers, overflow rules, and adjacent controls do not clip or cover the indicator
• Keep keyboard focus visually distinct from persistent states such as the current page or selected item
• Verify the actual rendered result in supported browsers rather than assuming that browser-default indicators look the same everywhere
• Check the three documented controls first, then review the remaining affected journeys for instances of the same styling problem

Preconditions

• Use Joomla 6.2
• Use the Atum administrator template and Cassiopeia frontend template
• Sign in with an account permitted to access the administrator interface and Media Manager
• Use a keyboard or an input method that produces keyboard navigation
• Enable the browser or operating-system setting that allows keyboard navigation to all relevant controls
• Record the browser name and version, operating system, viewport dimensions, and active light or dark appearance
• Include Safari when available because the report identifies a browser-specific example there
• Start at 100% browser zoom
• Avoid changing focus styles through browser extensions or custom CSS during the initial check

Steps to reproduce — Atum Toggle Menu control

1. Open the Joomla administrator interface at the site's base URL followed by /administrator/
2. Locate the sidebar's “Toggle Menu” control
   • Record its visible label or accessible name if it differs in the tested build
3. Move the mouse pointer away from the control so that its hover appearance does not mask the keyboard-focus result
4. Use Tab or Shift+Tab to move keyboard focus to the control
   • Do not click it to establish focus
5. Compare its focused appearance with its unfocused appearance
6. Check whether an outline, border, background treatment, or other visible change identifies it as the currently focused control
7. Press Tab to move to the next control, then Shift+Tab to return
8. Record whether the location of focus is visually apparent in both directions
9. Capture the focused and unfocused states for comparison
10. If the focus location is uncertain, confirm the active element using Developer Tools after recording the visible result
    • Do not use a forced CSS state as a substitute for the keyboard-navigation test

Steps to reproduce — Post Installation Messages control

1. Remain in the administrator interface
2. Locate the “Post Installation Messages” control in the header area
   • If it is absent in the current configuration, record that the documented example is unavailable rather than substituting a different control without identifying it
3. Move the mouse pointer away from the control
4. Use Tab or Shift+Tab to focus it
5. Observe the indicator against the surrounding header background
6. Compare the focused and unfocused states
7. In Safari, check the blue outline described in the audit
   • Record whether it remains clearly distinguishable in the tested version
8. Repeat in the other available browsers and record differences
9. Capture the focused state with enough surrounding background visible to assess the indicator

Steps to reproduce — Media Manager toolbar control

1. Open Content → Media
   • Alternatively, navigate to /administrator/index.php?option=com_media on the same installation
2. Locate the Media Manager toolbar area
3. Use keyboard navigation to reach its controls
   • Use Tab and Shift+Tab between controls or groups
   • If a toolbar group uses arrow-key navigation, record that interaction and use it to move between its controls
4. Check the control corresponding to the toolbar example in the report screenshot
   • Record its visible label, accessible name, or identifying icon
   • If the layout has changed, identify the tested control rather than assuming that another toolbar button is the same example
5. Move the mouse pointer away from the toolbar
6. Observe whether the focused control has a visible focus indicator
7. Move to the next control and then return
8. Record whether the visual indicator follows focus and clearly identifies the active control
9. Capture the focused control and its surrounding background

Broader verification across affected journeys

1. Repeat the keyboard-focus check on available pages representing the journeys listed in the metadata table
2. For each failing control, record its page URL, label or accessible name, and the steps needed to reach it
3. Classify the observed problem
   • No visible change when focused
   • Indicator difficult to distinguish from the background
   • Indicator clipped or covered
   • Indicator visible only while the mouse pointer is also hovering
4. Repeat relevant checks in light and dark appearances where supported
5. Repeat at 200% browser zoom and any higher zoom level used in the test protocol
6. Check responsive layouts where controls move into collapsed menus or compact toolbars
7. Record any unavailable journey or missing test setup separately
   • Use a separate test installation for the installation wizard
   • Do not initiate an installation or update merely to check a focus style

Version

6.2

Expected result

Users can visually identify the currently focused interactive control while navigating with the keyboard.

The focus indicator remains visible against the control and surrounding background in the supported appearances, layouts, and browsers.

A mouse hover is not required to reveal keyboard focus.

Actual result

The audit reports that Atum's “Toggle Menu” control has no visible distinction between its focused and unfocused states.

It also identifies a faint blue focus outline on the “Post Installation Messages” control in Safari and a Media Manager toolbar control with no visible focus indicator.

The report lists all 13 audited journeys as affected, but individual failing controls in the remaining journeys need to be recorded during verification.

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.

Design is the responsibility tag in the original report.

The absence of a custom focus rule is not, by itself, evidence of failure. Assess whether the actual indicator is visible during keyboard use, including any indicator supplied by the browser.

This issue concerns visible keyboard focus. General text contrast, current-page indicators, and other control states should not be reported as failures here unless they directly affect the visibility of keyboard focus.

MS2a is proposed for the shared focus tokens and foundational styling, with MS3a and MS3b covering frontend and backend integration. These are scope-based recommendations rather than confirmed project assignments.