[wp-trac] [WordPress Trac] #52399: Remove widget accessibility mode

Thu Apr 23 09:03:33 UTC 2026

#52399: Remove widget accessibility mode
-------------------------------------+-------------------------------------
 Reporter:  joedolson                |       Owner:  rcreators
     Type:  enhancement              |      Status:  assigned
 Priority:  normal                   |   Milestone:  Future Release
Component:  Widgets                  |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  needs-patch needs-       |     Focuses:  ui, accessibility,
  design                             |  administration
-------------------------------------+-------------------------------------

Comment (by sanket.parmar):

 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 of `widgets.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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/52399#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform