Steps to reproduce the issue
| Milestone 1a finding ID |
M1a-016 |
| Backlog priority |
High |
| Severity — carried from Milestone 1a |
Serious |
| Implementation effort |
Medium |
| Target milestone(s) |
MS3b — Backend Template Build |
| WCAG 2.2 success criterion |
3.2.2 On Input |
| Responsibility tag(s) from report |
Development |
| Affected Joomla area/component |
Atum — Articles list and article edit form — Milestone 1a finding #16 |
| Affected user journey(s) |
08 — Backend List View Pattern; 09 — Backend Edit Form Pattern |
Audit finding
Changing an option in a select control automatically reloads the page without first explaining that this will happen. The reload interrupts navigation and returns keyboard and screen reader users to the beginning of the page instead of allowing them to continue from the control they were using.
The Articles list provides a reproduction example through its “Sort Table By” control. The original audit also identifies the article edit form as affected, but does not specify which select control triggers the reload there.
User impact
A keyboard user changing the article sort order can lose their position in the interface when the page reloads. Instead of continuing from the sorting control, they must navigate through the page again to reach the updated article list or another control.
For a screen reader user, the unexpected reload interrupts reading and removes the immediate context of the change. They may need to locate the sorting control again, confirm that their selection was applied, and find the updated results.
This behaviour makes comparing sort options and working through a list slower and less predictable. The same interruption in an editing form can break the user's editing sequence, although loss of unsaved content has not been established by this finding.
Remediation plan
Make the effect of changing a select control predictable and preserve the user's place in the interface
- Prefer an explicit action, such as an appropriately labelled Apply button, when changing the selection would otherwise reload the page
- Allow users to choose an option without triggering navigation before they activate that action
- Alternatively, update only the affected content without reloading the entire page, keeping focus on the select control and exposing a concise update message to screen readers
- If automatic page navigation must remain, provide accessible instructions before the control explaining that changing the selection reloads the page
- After any retained automatic reload, restore focus to the corresponding control and preserve the selected value
- Do not treat focus restoration alone as sufficient to make an unannounced automatic reload predictable
- Verify that the updated results match the selected option and that repeated changes do not require users to restart navigation from the top of the page
- Identify and test the specific affected select control in the article edit form before applying an editor-specific fix
Preconditions
- Use Joomla 6.2 with the Atum administrator template
- Sign in with an account permitted to view and manage articles
- Ensure that at least two articles have visibly different titles so that a change in sorting can be checked
- Record the browser name and version, operating system, and any screen reader used
- Use a test installation for any supplementary article-editing checks
Steps to reproduce — Articles list
- Open the Joomla administrator interface at the site's base URL followed by
/administrator/
- Open Content → Articles
- Alternatively, navigate to
/administrator/index.php?option=com_content&view=articles on the same installation
- Locate the control labelled “Sort Table By”
- If its visible label differs in the tested build, record the visible label and accessible name
- Do not substitute a search filter or the number-of-items-per-page control
- Before changing the selection, check whether visible instructions explain that choosing an option will reload the page
- Record any such instructions
- Use Tab or Shift+Tab to move keyboard focus to the sorting control
- Record the currently selected sort option and the current position in the article list
- Use the keyboard to open the control and choose a different sort option
- For example, switch between ascending and descending title order if those options are available
- Use the selection method supported by the browser and operating system
- Record whether the reload begins while moving between options or only after confirming a selection
- Do not activate a separate Apply, Search, Save, or other action button
- Observe whether changing the selection reloads the entire page
- Distinguish a full-page reload from an update limited to the article list
- If necessary, use the browser's Network panel to check whether a new document request occurs
- After the update finishes, check the selected sort option and the order of the articles
- Press Tab once and record where keyboard focus moves
- Determine whether navigation continues from the sorting control or starts again near the beginning of the page
- Repeat with another sort option to check whether the interruption happens consistently
Supplementary screen reader test
- Enable a screen reader and record the screen reader and browser combination
- Return to Content → Articles
- Navigate to the “Sort Table By” control
- Listen for its name, selected value, and any instructions explaining an automatic reload
- Change the selected sort option without activating a separate action button
- Observe whether the screen reader announces a page load or otherwise interrupts the current interaction
- Check both keyboard focus and the screen reader's reading position after the update
- Record whether the user can identify the new sort order and continue to the results without navigating from the beginning of the page
Article edit form — reproduction detail to confirm
The original audit includes the backend edit form in the affected samples, but does not identify the triggering select control.
- Open an existing test article from Content → Articles
- Record the article-editing tab and the label of any select control found to trigger an automatic reload
- Check whether instructions explain the reload before the control is changed
- Record the original value, select a different value, and observe whether the whole page reloads without a separate action
- Check the selected value, keyboard focus, screen reader reading position, and any existing unsaved edits after the reload
- Add the exact tab, control label, and selected values to this issue once the affected control is confirmed
- Close the test article without saving unintended changes
Version
6.2
Expected result
Changing a select option does not cause an unexpected change of context.
The user can select a value and apply it through an explicit action, or the affected content updates without a full-page reload and without losing the user's position.
If changing the selection must automatically reload the page, that behaviour is explained before the user operates the control, and the selected value and focus are preserved after the reload.
Actual result
The audit reports that changing a select option reloads the entire page and requires keyboard and screen reader users to restart navigation from the beginning.
The existing reproduction example identifies the “Sort Table By” control in the Articles list. The affected control in the article edit form still needs to be identified.
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?
VoiceOver, JAWS, NVDA
Additional Comments
The browser and assistive-technology entries above are carried forward from the original issue and do not represent a new verification of every combination against Joomla 6.2.
The original report contains no screenshot for this finding.
The report identifies both the backend list view and backend edit form as affected, but provides no field-level reproduction details for the edit form.
Hey @mbeganyi-a11y @brianteeman can I get assigned this issue