Steps to reproduce the issue

Audit finding

The TinyMCE editing area can be resized by dragging its resize handle, and the audit recognizes that keyboard resizing is also available. However, it identifies no equivalent way to adjust the editor's size using clicks or taps without dragging.

A keyboard shortcut does not provide the missing pointer interaction for someone who cannot perform a dragging movement and is not using a keyboard.

This finding concerns the custom editor's resize functionality, not browser zoom or resizing the browser window.

User impact

People who can click or tap but cannot reliably hold a pointer down while moving it may be unable to adjust the editing area's size.

This can affect people with hand tremors, limited dexterity, or difficulty maintaining pressure on a mouse button or touch screen. A keyboard workaround may not be available to someone editing on a touch device or using a pointer-based input method.

They must continue working with the existing editor size rather than adjust it to show more content or leave more room for the surrounding form. Keyboard resizing does not remove this barrier for pointer-only users.

Remediation plan

Preserve the existing resize functionality and add an equivalent way to adjust the editor's size through clicks or taps without dragging

• Provide clearly labelled controls such as “Increase editor height” and “Decrease editor height”
• If the configured editor supports horizontal resizing, provide an equivalent non-dragging way to adjust its width
• Alternatively, provide an accessible size selector with useful size options or editable dimensions
• Allow repeated clicks or taps to make useful adjustments without requiring the user to hold down the pointer
• Make the available range sufficient for the resizing functionality offered by the drag handle
• Keep the existing keyboard resizing functionality available
• Make any added controls keyboard operable and give them visible focus indicators
• Preserve the article content, text selection where feasible, and a useful focus position when the editor is resized
• Prevent resizing beyond limits that make the editor or surrounding form unusable
• Apply the solution consistently wherever the affected TinyMCE configuration appears in frontend and backend forms
• Do not treat a keyboard shortcut alone as the pointer alternative
• Assess any fullscreen option against the actual resizing functionality rather than assuming that switching between normal and fullscreen sizes provides an equivalent adjustment

Preconditions

• Use Joomla 6.2 with the TinyMCE editor enabled for the test account
• Use Atum for administrator testing and Cassiopeia for frontend testing
• Use an account permitted to edit an article in the interface being tested
• Use a test article containing enough text to make changes in the editing area's visible size easy to observe
• Confirm that the active TinyMCE configuration exposes a resize handle
• Record the browser name and version, operating system, viewport dimensions, and pointer device used
• Record any customized TinyMCE toolbar or resize settings
• Do not save unintended changes to the article

Steps to reproduce — backend article editor

1. Open the Joomla administrator interface at the site's base URL followed by /administrator/
2. Open Content → Articles
3. Open a test article for editing
4. Locate the Article Text field and confirm that TinyMCE is active
   • The field should display a rich-text editing interface rather than only a plain text area
   • Record the field label if it differs in the tested build
5. Locate the resize handle at the edge of the editor
   • In the audited configuration, the handle is at the lower-right corner
6. Record the editing area's initial size
7. Use a mouse, trackpad, or other pointer to drag the resize handle
8. Confirm that dragging changes the editing area's size
   • Record whether height, width, or both can be changed
9. Release the pointer
10. Attempt to resize the editing area without dragging
    • Click or tap the resize handle without moving the pointer while it is pressed
    • Inspect the available editor controls and menus for size buttons, size presets, or editable dimensions
    • Do not use keyboard shortcuts during this part of the test
11. Record whether any available control provides a useful equivalent to the resizing demonstrated in step 8
12. If a fullscreen control is available, record what it does
    • Distinguish switching to fullscreen from adjusting the editor's size within the form
    • Record the available size choices rather than assuming that fullscreen is equivalent
13. Record whether dragging remains the only pointer-based way to make the tested size adjustment
14. Capture the editor, resize handle, and relevant toolbar or menu options
15. Close the article without saving unintended changes

Steps to reproduce — frontend editing form

1. Open the site's frontend and sign in with an account permitted to edit the test article
2. Navigate to the test article
3. Activate its frontend editing action
   • Record the article URL and the editing action used
   • If frontend editing is unavailable, record that the required test setup is absent rather than reporting a resize failure
4. Locate the TinyMCE editing area and its resize handle
5. Repeat the dragging and non-dragging pointer checks from the backend test
6. Record whether the frontend configuration provides different resize controls or options
7. Close the form without saving unintended changes

Supplementary touch test

1. Open the affected editing form on a touch device or with an available touch-input setup
2. Record the device, browser, and whether the editor exposes its resize handle
3. Check whether the editing area can be resized by dragging the handle
4. Look for an equivalent way to adjust its size using taps without dragging
5. Record the available controls and the result
   • Do not rely on a connected keyboard as the pointer alternative

Supplementary keyboard verification

1. Place keyboard focus in the TinyMCE editing area
2. Use the toolbar-focus shortcut supported by the tested editor and platform
   • The issue discussion identifies Alt+F10 as a working route in the configuration demonstrated there
   • Record the shortcut used and any operating-system or browser conflict
3. Navigate through the editor controls to the resize handle if it is available
4. Test the arrow keys and record whether they change the editing area's size
5. Record the keyboard result separately from the pointer-only result
   • Successful keyboard resizing does not establish that a non-dragging pointer alternative exists

Version

6.2

Expected result

Users can adjust the editing area's size using clicks or taps without performing a dragging movement.

The alternative provides a useful equivalent to the resizing functionality available through the handle.

Existing dragging and keyboard resizing remain available.

Actual result

The audit reports that the editing area can be resized through dragging or keyboard interaction, but provides no equivalent way to resize it through clicks or taps without dragging.

The absence of this pointer alternative is the reported barrier. The issue should not describe keyboard resizing as unavailable without separate evidence from the tested configuration.

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 explicitly recognizes keyboard resizing and assigns this finding to WCAG 2.2 Success Criterion 2.5.7 Dragging Movements.

The issue discussion also identifies a keyboard route through the editor toolbar to the resize handle. That functionality should be preserved, but it is separate from the missing non-dragging pointer interaction.

TinyMCE controls can vary with the active plugin configuration and user settings. Record the configuration being tested, including whether resizing and fullscreen controls are available.

Development is the responsibility tag in the original report.

MS3a and MS3b are proposed integration milestones because the audit identifies both frontend and backend editing forms. The precise implementation may require coordination with the bundled TinyMCE integration or its upstream project.