Steps to reproduce the issue

Audit finding

The image editor presents rotation angles as radio-button choices, but applies a rotation immediately whenever the selected choice changes.

Keyboard users moving through the choices with the arrow keys therefore apply intermediate rotations even when they are only trying to reach another angle. Each rotation is added to the image's current orientation rather than calculated from its starting orientation.

For example, moving from 0° to 90° rotates the image by 90°. Moving next to 180° adds another 180°, leaving the image rotated by a total of 270° from its starting orientation, even though 180° is selected.

The control mixes two different interaction models: choosing a final angle and issuing repeated rotation commands.

User impact

A keyboard user cannot move through the angle choices without changing the image at each intermediate choice. Reaching 180° by passing through 90° can produce a different result from selecting 180° directly with a pointer.

This makes the result depend on the route taken through the controls, rather than simply on the selected angle. Users may need to restart the edit or work out additional rotations to recover the orientation they intended.

People who find spatial reasoning or tracking a sequence of changes difficult must also keep a running total of the rotations. The selected angle does not reliably communicate the image's resulting orientation.

Remediation plan

Choose one clear interaction model and make the controls behave consistently with it

• Preferred option: retain angle choices, allow users to select an angle without changing the image, and provide a separate Apply rotation button
  • Explain whether the chosen angle is applied relative to the current image or to a defined starting orientation
  • Apply the selected rotation once when the user activates the button
  • Do not rotate the image while users move between the angle choices
• Alternative option: replace the radio-button choices with independent action buttons
  • Use labels that describe the action, such as “Rotate 90° clockwise”
  • Apply a rotation only when a button is deliberately activated, not when it receives focus
  • Allow keyboard users to move past unwanted actions without applying them
  • Remove a 0° action if it has no useful effect, or provide a clearly labelled reset action if restoring the starting orientation is intended
• If the interface instead represents an absolute orientation, calculate each selected angle from a stable reference image rather than repeatedly rotating the current preview
• Explain the rotation direction and whether rotations are cumulative
• Provide concise feedback confirming the applied rotation and resulting orientation where that information can be calculated reliably
• Keep keyboard focus on the control used to apply the rotation
• Verify that equivalent keyboard and pointer actions produce the same result from the same starting image
• Keep rotation of the editing preview distinct from saving changes to the image file

Preconditions

• Use Joomla 6.2 with the Atum administrator template
• Sign in with an account permitted to access Media Manager and edit images
• Use a test installation and a disposable copy of an editable image
• Choose an image with an obvious top edge and an asymmetric feature, such as an upright arrow with a marker in one corner
• Record the browser name and version and the operating system
• Do not save or overwrite the original image during the test

Steps to reproduce — keyboard interaction

1. Open the Joomla administrator interface at the site's base URL followed by /administrator/
2. Open Content → Media
   • Alternatively, navigate to /administrator/index.php?option=com_media on the same installation
3. Locate the disposable test image
4. Open the image's item actions and activate Edit
   • Record the action label if it differs in the tested build
   • Ensure that the image editor opens rather than only an image preview
5. Open the Rotate section of the image editor
   • Record the section label if it differs in the tested build
6. Locate the angle choices for 0°, 90°, 180°, and 270°
7. Record the image's starting orientation and the initially selected angle
   • Capture a screenshot showing the image and angle controls together
8. Use Tab or Shift+Tab to move focus into the angle-choice group
   • If the initial selected angle is not 0°, reopen the test image without saving to establish a consistent starting state
9. Press the arrow key that moves the selected choice from 0° to 90°
   • Do not activate Save or any separate Apply control
10. Observe whether the image rotates immediately
    • Record the selected angle and the image's orientation relative to the starting image
11. Press the arrow key again to move from 90° to 180°
12. Observe whether the image is now rotated 180° from its starting orientation or whether another 180° has been added to the existing 90° rotation
    • The reported behaviour produces a total rotation equivalent to 270° from the starting orientation
13. Move to the 270° choice
14. Observe whether another 270° rotation is added
    • Record the resulting orientation rather than assuming that the selected label represents it
15. Capture the selected angle and resulting image orientation at each stage
16. Close the editor without saving changes to the test image

Comparison test — direct pointer selection

1. Reopen the same test image in its unchanged starting orientation
2. Open the rotation controls
3. Select 180° directly with a mouse or another pointer device without first selecting 90°
4. Record the resulting image orientation
5. Compare this result with the keyboard sequence that reached 180° by passing through 90°
6. Check whether the same selected angle produces different image orientations depending on the route used to select it
7. Close the editor without saving changes

Supplementary implementation check

1. Inspect the angle controls using the browser's Developer Tools or accessibility inspector
2. Record whether the controls are exposed as radio buttons, buttons, or another control type
3. Check whether image rotation occurs when focus arrives, when the selected value changes, or only after explicit activation
4. Record whether any instructions explain cumulative rotation before the controls are operated
5. Record whether the interface exposes the resulting orientation or only the most recently selected rotation amount

Version

6.2

Expected result

Users can navigate to the desired rotation control without unintentionally applying intermediate rotations.

If the interface offers angle choices and an Apply rotation button, changing the selected angle alone does not rotate the image.

If the interface offers rotation action buttons, each rotation occurs only when the corresponding button is activated, and its label explains the amount and direction of rotation.

If the interface represents an absolute orientation, the selected value corresponds to the image's orientation relative to a defined starting point.

Equivalent keyboard and pointer actions produce the same result from the same starting image.

Actual result

The audit reports that using the arrow keys to move between the angle choices immediately applies each selected rotation to the image.

The rotations accumulate: selecting 90° rotates the image by 90°, and then selecting 180° adds a further 180° instead of producing an image oriented at 180° from its starting position.

The selected angle therefore does not reliably describe the resulting orientation, and keyboard navigation through intermediate choices changes the result.

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 original audit assigns this finding to WCAG 2.2 Success Criterion 3.2.1 On Focus. Verification should distinguish receiving focus from changing a radio button's selected value and determine whether a qualifying change of context occurs, rather than treating every preview update as a failure of that criterion.

The report identifies Development as the responsibility tag. This draft uses that original classification rather than the broader Design, Development combination in the existing GitHub issue.

The original audit includes a demonstration video: Rotation interaction demonstration

An existing discussion links this related issue: #29943

MS3b is the proposed primary implementation milestone because the documented defect concerns the administrator image-editing interface. Assignment to a shared component milestone or a transversal-feature phase requires confirmation of that implementation scope.