![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 5 years ago
Last modified 7 days ago
#52399 accepted enhancement
Remove widget accessibility mode
| Reported by: | joedolson | Owned by: | joedolson |
|---|---|---|---|
| Priority: | normal | Milestone: | Future Release |
| Component: | Widgets | Version: | |
| Severity: | normal | Keywords: | needs-patch needs-design |
| Cc: | Focuses: | ui, accessibility, administration |
Description
With the introduction of the new block editing experience for widgets management, WordPress will have four separate interfaces for managing widgets: block editing, customizer, classic widgets, and accessbility mode.
The accessibility team would like to explore merging the characteristics that accessibility mode uses for better accessibility into the classic widget screen, to cut down to only three modes of operation for widgets.
This will require identifying the characteristics of accessibility mode and finding ways to reproduce those characteristics within the existing widget UI.
The key differences that are obvious are:
1) Use of a text link to 'Add' or 'Edit'
2) Links target each widget via a URL to manage independently.
3) Selection options to choose which sidebar and position will be used for a widget.
These characteristics allow a single widget to be edited in isolation, the ability to assign a location without drag and drop, and visible text tools for handling widgets.
One possibility to explore is having an add/edit option that opens a given widget in a modal that includes the location selection tools provided in accessibility mode.
Change History (18)
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
5 years ago
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
5 years ago
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
5 years ago
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
5 years ago
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
5 years ago
This ticket was mentioned in Slack in #accessibility by ryokuhi. View the logs.
5 years ago
#11
@
5 years ago
- Milestone 5.9 → Future Release
I'm setting this to Future Release. If we can solve any specific problems in the classic widget screen for 5.9, that could be addressed in a new ticket.
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
2 years ago
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
7 months ago
#16
@
3 months ago
I spent some time doing a thorough code audit for this.
How accessibility mode works today (code-level)
The toggle lives in wp-admin/widgets-form.php. When widgets_access = 'on' is stored via set_user_setting(), it adds the widgets_access body class and — critically — skips enqueuing admin-widgets entirely, so drag-and-drop JS is never loaded. The accessible single-widget edit experience lives at widgets.php?editwidget=<id>, rendered by wp-admin/includes/widgets.php, and is fully server-side.
The .widget-control-edit a (Edit/Add link) is already rendered in the markup for every widget in both modes; it is hidden in standard mode only by the hide-if-js class on that element.
Proposed approach (phased)
Phase 1 — Immediate, low risk: Remove hide-if-js from .widget-control-edit a in wp_widget_control(). This makes the Edit/Add text link permanently visible alongside the JS expand button. Keyboard and AT users get a plain-text path to the accessible single-widget edit page without needing to enable a mode. No JS changes required.
Phase 2 — Address standard screen a11y gaps: Two gaps exist in admin-widgets JS that accessibility mode currently sidesteps by not loading JS at all:
- No
wp.a11y.speak()call after AJAX save or delete (only "Add" has one, at line ~706 ofwidgets.js). - Focus is dropped to
<body>after widget delete — no focus restore logic exists in that code path.
Both should be fixed before the mode toggle is removed, so the standard screen is actually equivalent.
Phase 3 — Remove the toggle: Once Phases 1–2 land, wp_widgets_access_body_class() becomes unused. It should be deprecated with _deprecated_function() and kept as a no-op for one major version — third-party plugins may target that body class in their CSS.
Two smaller issues found along the way
The help tab text reads: "Enabling Accessibility Mode, via Screen Options" — the toggle has never been in Screen Options, it is a link under the page heading. Independent doc bug.
$_GET['editwidget'] in widgets-form.php (~line 228) is used unsanitized as an array key. No injection vector today since it only does a $wp_registered_widget_controls[$widget_id] lookup, but sanitize_key() would be consistent with how $_POST['widget-id'] is handled elsewhere.
Testing note
Since 5.8 the classic widget screen only appears with the Classic Widgets plugin active or remove_theme_support('widgets-block-editor'), so any test setup needs to account for that.
Happy to put together a patch starting with Phase 1 if that direction looks good to the accessibility team.
We reviewed this ticket today during the accessibility team's bug scrub.
To sum up the discussion, the team agreed that the final goal for this ticket is to have a single classic widget screen which is accessible by default. This will need work in two directions:
This ticket will probably be better addressed if split into smaller chunks, to make progress little by little. But first, it's better to list all accessibility issues that can be found in the classic widget screen. To do so, testing the classic widget screen with and without assistive technologies would help in finding existing bugs.
Since WordPress 5.8, the new Block Widget screen is the default, so to test the old classic widget screen you'll have to install the Classic Widgets plugin, which is available in the plugin repository and can be installed using your preferred method (either by downolading and uploading it or by installing it directly from the admin screen).