Make WordPress Core

Opened 5 months ago

Closed 3 months ago

#63971 closed defect (bug) (duplicate)

Multiple select elements associated with tables in the admin (filters, user role changes) lack visible, persistent labels

Reported by: alh0319's profile alh0319 Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: General Keywords: a11y-task
Focuses: ui, accessibility Cc:

Description

Throughout the admin, there are select elements that have labels hidden with screen reader text and that rely on the default or first option in the select to provide a visible label.

Here is an example, filters for the posts table:

<div class="alignleft actions">
				<label for="filter-by-date" class="screen-reader-text">Filter by date</label>
		<select name="m" id="filter-by-date">
			<option selected="selected" value="0">All dates</option>
		<option value="202508">August 2025</option>
		</select>
		<label class="screen-reader-text" for="cat">Filter by category</label><select name="cat" id="cat" class="postform">
	<option value="0">All Categories</option>
	<option class="level-0" value="1">Uncategorized</option>
</select>
<input type="submit" name="filter_action" id="post-query-submit" class="button" value="Filter">		</div>

See image of post filters missing visible lables.

Other places that this technique has been used include:

  • Bulk actions select
  • Change user role select
  • Media filters
  • Comment filters

WCAG 3.3.2: Labels or Instructions (Level A) requires that labels or instructions be provided when content requires user input. This is generally interpreted to require visible and persistent labels.

In the current implementation, once a user has selected an option in the select, there is no longer a visible label for the select. It is posisble for users to link directly to filtered versions of these tables which would pre-fill the select with a date or category, for example, in which case any user following that link would not have access to the label for the select.

It is worth noting that to receive the accessibility-ready tag for a theme, we require all inputs and form fields to have visible and persistent labels. This technique in the admin would fail an accessibility ready review were it followed in a theme.

In addition, these fields also fail 2.5.3: Label in Name (Level A), as the visible text for the first option (or any selected option) does not match the label.

Example: The hidden accessible name for the date filter select is "Filter by date" and the visible text is "All dates" or any selected date, such as "August 2025".

This mismatch between the visible text and the label would make it difficult for users who rely on voice control to interact with these fields.

The admin UI should be reworked so that selects have visible labels that don't rely on the default option in the select.

Change History (6)

#1 @joedolson
5 months ago

  • Keywords a11y-task added

This is an existing task that's been getting very slowly worked through across the admin. But there's a lot of these, and it's slow going.

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


5 months ago

#3 @joedolson
5 months ago

This is significantly overlapping, though not a 100% duplicate of #63728. I think it would be better to make these tickets more focused, and refer specifically to a particular set of issues.

Probably makes sense for this to be considered a task with associated issues; can you open new tickets for the user role filters and comment filters?

Media filters are already covered by #47137.

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.


3 months ago

#5 @joedolson
3 months ago

  • Milestone changed from Awaiting Review to 7.0

Also related: #47359

#6 @joedolson
3 months ago

  • Milestone 7.0 deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #63728.

Note: See TracTickets for help on using tickets.