[#48767] - [6.2] Fix split button focus order and accessible name (#48397)
- Pending
- Medium
- Build: 6.2-dev
- # 48767
- Diff
- Nikhil-sinhaa:fix/48397
User tests: Successful: Unsuccessful:
Pull Request resolves #48397
- I read the Generative AI policy and my contribution is either not created with the help of AI or is compatible with the policy and GNU/GPL 2 or later.
Summary of Changes
The Save & Close split button rendered its dropdown toggle before the primary button in the HTML. A CSS order: 1 rule then moved the toggle to the right, so it looked correct but keyboard focus went to the toggle first. The toggle was also named only "Toggle Dropdown".
layouts/joomla/toolbar/dropdown.php: render the primary button first, then the toggle. The DOM order now matches the visual order. The hidden label uses a new$toggleTextvariable and falls back to the old string.libraries/src/Toolbar/Button/DropdownButton.php: buildtoggleTextfrom the primary button's text, for example "Save & Close options".administrator/language/en-GB/joomla.ini: addJTOOLBAR_SPLIT_TOGGLE_OPTIONS="%s options".- Atum and Cassiopeia
_toolbar.scss: remove theorder: 1workaround. The look is unchanged.
The fix is in the shared toolbar layout, so every edit form that uses the Save & Close group gets it. The "Toggle Dropdown" label is still used by two hand-written buttons, in the Users list and the Module assignment tab. I left those alone because they don't use this layout.
Testing Instructions
- Apply the patch and compile the CSS with
npm run build. If you use a pull-request test tool, it does this for you. - Log in to the administrator and open Content → Articles → New.
- Click in the Title field, then press Shift+Tab until the Save button has focus.
- Press Tab and note which control gets focus.
- Inspect the toggle arrow and note its accessible name (browser dev tools, Accessibility panel).
- Press Enter on the arrow to open the menu, then Escape to close it. Note where focus ends up.
- Repeat on other edit forms, for example Users → New, Categories → New, Banners → New, Menus → Items → New.
Actual result BEFORE applying this Pull Request
- Tab from Save moves focus to the arrow, which is on the right of Save & Close, and skips Save & Close. Another Tab is needed to reach it.
- In the HTML, the toggle
<button>comes before Save & Close. - The arrow's accessible name is "Toggle Dropdown".
- The accessibility tree reads: Save, Toggle Dropdown (menu popup), Save & Close.
48397before.mp4
Expected result AFTER applying this Pull Request
- Tab from Save moves focus to Save & Close, then to the arrow, which matches the left-to-right order.
- In the HTML, Save & Close comes before the toggle.
- The arrow's accessible name is "Save & Close options".
- The accessibility tree reads: Save, Save & Close, Save & Close options (menu popup).
- The toolbar looks the same as before. The menu still opens with the same items. Escape closes it and focus stays on the arrow.
48397after.mp4
Link to documentations
Please select:
-
Documentation link for guide.joomla.org:
-
No documentation changes for guide.joomla.org needed
-
Pull Request link for manual.joomla.org:
-
No documentation changes for manual.joomla.org needed
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration Language & Strings Layout Libraries NPM Change |
I agree that the accessible name needs improving. "Toggle Dropdown" is too generic and doesn't explain what the dropdown relates to.
However, I am not convinced that changing the DOM order is necessarily the right solution.
The current implementation has a visual ordering that is achieved using CSS, and I would like to understand whether there is a reason the DOM was originally structured this way before changing it. Matching the DOM order to the visual order is not, in itself, an accessibility requirement. What matters is that the resulting focus order and screen-reader experience are logical and meaningful. There is nothing inherently wrong with a DOM order differing from visual order, provided the resulting keyboard and assistive-technology experience remains logical and understandable. WCAG 2.4.3 requires a meaningful focus order, not necessarily identical DOM and visual ordering in every situation.
I would also like to see this tested against all the other uses of this shared dropdown layout, rather than just the Save & Close example, to ensure that changing the order does not introduce unexpected behaviour elsewhere.
I support making the accessible name more descriptive, but I think we should consider whether that name should be explicitly configurable rather than automatically derived from the primary button's text. That would give us more flexibility for other uses of the component.
I would therefore separate the two changes and establish that the DOM-order change is actually necessary before adopting it.
Thanks @brianeteeman for the review. Taking your points in turn:
- Is the DOM-order change necessary? #48397's expected result is that the primary button receives focus before the toggle, with DOM order matching visual order. Its remediation says to do that "unless a deliberate, accessible reading order requires otherwise". CSS order changes only the visual order, not the Tab order, so on the current code Tab goes Save → toggle → Save & Close.
- Why was the DOM structured this way? I checked git:
- The 2018 layout (9e3bd1a) rendered the primary button first
- [4.0][WIP] BS5 JS #31990 (88c498b) moved the toggle first, with the comment "Reverse order solves a console err for dropdown", an @todo to
replace the inline style, and flex-direction: row-reverse - [4.0] Correct btn-group radius in atum subhead #32440 (338800d) turned that inline style into order: 1, as a border-radius fix for [4.0b7]
Save & Close Split button borders wrong #32433. - [5.0] resolve toolbar TODO #41881 (3a4c9e6) removed the @todo ("The issue referred to in the TODO was done in #32440").
I found no discussion of reading order or focus order in #32440 (all 10 comments, no inline comments) or in #31990 (keyword search of its
comments and inline review comments). If you know of another reason, please tell me.
3. Testing some other uses.
Test 1: keyboard open and close
With focus on the caret, Enter opens the menu (aria-expanded="true"). Esc closes it and focus stays on the caret.
https://github.com/user-attachments/assets/d64a4421-3599-4436-a37d-e39eb4ea242f
Test 2: accessible name
The Firefox Accessibility panel shows the caret as role button with the name "Save & Close options". The name was "Toggle Dropdown" before.
Test 3: mouse
Clicking the caret opens the menu. Clicking outside closes it. The main Save button saves the article. "Save & New" from the menu works too.
https://github.com/user-attachments/assets/f290de2d-9b9a-4ba8-bc7d-ec25fd988d8d
Test 4: RTL
With dir="rtl" the caret mirrors to the left of Save & Close and stays attached to it.
https://github.com/user-attachments/assets/2a21f95d-2da2-4c16-9502-4632f59a2573
it remain identical in both before and after
Test 5:
Before-
https://github.com/user-attachments/assets/9deb2fa1-cf40-4fa8-8557-f5d20c103c26
After-
after3.mp4
Test 6:
under Banner
Before
before4.mp4
After:
after4.mp4
Same behaviour under Menu page, tags page
- Your suggested changes. separate the accessible-name change from the DOM-order and SCSS change, and make the name configurable through an explicit toggleText option.
I do not agree with the change in order