Opened 10 months ago
Last modified 2 months ago
#63728 accepted enhancement
In WP Admin -> Posts add 'Filter by author' dropdown and add visible labels for filters
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Milestone: | Future Release | Priority: | normal |
| Severity: | normal | Version: | |
| Component: | Administration | Keywords: | has-screenshots has-patch changes-requested |
| Focuses: | accessibility, administration | Cc: |
Description
In the posts view, I think it would be an enhancement to have an ad additional 'filter by author' dropdown.
Also a visible label should be there on top of the dropdown as well as for the categories dropdown. So you can recognize better what filter the dropdown represents.
If the additional dropdown won't find any friends, still a visible label should be there for the categories.
Attachments (5)
Change History (25)
#4
@
10 months ago
I'm sorry I messed up a bit. Please if you want to try the patch also add the following line
wp_dropdown_authors_filter( $this->screen->post_type, $which );
after
do_action( 'restrict_manage_posts', $this->screen->post_type, $which );
in class-wp-posts-list-table.php
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
10 months ago
#6
@
10 months ago
- Keywords changes-requested added
I like the idea of making the labels visible. A couple things:
1) It looks strange to have two of the four select inputs have labels. We should probably either add all of them or none of them.
2) Should probably add a check to only display the author filter if there are multiple authors. For single-user sites, this would never be useful.
3) The query should also only fetch authors who have authored posts; this would help streamline the results. There's no need to have a filter that represents users who don't have posts. What you actually need is to fetch all users who have published posts in the designated post type; you can use the has_published_posts argument to get that data.
As a side note that could be looked at when this is fleshed out into a more complete patch - there is an alignment issue on the bottom of the buttons/select inputs. If it's simple to resolve, it might make sense to take care of it with this issue.
#7
@
10 months ago
I also think that adding a group to wrap the filters with a group name of 'Filters' would allow us to make the labels less repetitive, by removing the text "Filter by". The function of the group is visibly set by the button text, and having a group (fieldset or role="group") would allow us to note the function of the group of inputs.
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
8 months ago
#10
@
6 months ago
- Milestone changed from Awaiting Review to 7.0
- Owner set to joedolson
- Status changed from new to accepted
This ticket was mentioned in Slack in #accessibility by sabernhardt. View the logs.
6 months ago
This ticket was mentioned in PR #10887 on WordPress/wordpress-develop by @sheldorofazeroth.
3 months ago
#12
Trac: https://core.trac.wordpress.org/ticket/63728
## Problem
The WordPress Posts list table filter area had several usability and accessibility issues:
- No author filtering capability - Users couldn't filter posts by author directly from the list table, requiring manual URL manipulation or additional plugins
- Hidden filter labels - All filter dropdowns (date, category, format) had labels hidden with
screen-reader-textclass, making it difficult for sighted users to understand what each dropdown represented - Poor semantic structure - Filters lacked proper grouping, reducing accessibility for screen reader users
- Single-user sites showing unnecessary filters - No conditional logic to hide author filters when only one author exists
## Root Cause
The original implementation prioritized visual compactness over usability:
- Labels were intentionally hidden to save horizontal space in the admin interface
- No author filter existed because it was considered an edge case, despite being a common need for multi-author sites
- The lack of semantic HTML grouping (fieldset/legend) meant screen readers couldn't properly announce the filter group context
- No conditional rendering logic existed to optimize the UI for single vs multi-author sites
## Solution
### 1. Added Author Filter Dropdown
- Created new
authors_dropdown()method inWP_Posts_List_Tableclass - Conditionally displays only when:
- Post type supports authors
- Site has 2 or more authors with published posts
- Uses optimized query with
has_published_postsparameter to fetch only relevant authors - Includes filter hooks (
disable_authors_dropdown,posts_authors_dropdown_authors) for extensibility
### 2. Made All Filter Labels Visible
- Removed
screen-reader-textclass from date, category, and format filter labels - Labels now display inline before their corresponding dropdowns
- Improved label text: simplified "Filter by post format" to just "Format" to reduce repetition
### 3. Added Semantic Grouping
- Wrapped all filters in
<fieldset class="filters-group">element - Added
<legend class="screen-reader-text">Filters</legend>for screen reader context - This allows screen readers to announce "Filters" group when navigating the controls
### 4. Enhanced CSS Styling
- Added styles to properly align labels with dropdowns using
float: left - Set
font-weight: 600on labels for better visibility - Adjusted
line-height: 2.16666667to vertically align with select elements - Proper spacing with labels having 8px margin and selects after labels having 12px margin
### Backward Compatibility
- All existing filter hooks remain intact
- New filter hooks follow WordPress naming conventions
- CSS changes are additive, not destructive
- Existing functionality fully preserved
### Testing
Tested on:
- Single-author sites (author dropdown correctly hidden)
- Multi-author sites (author dropdown appears with correct authors)
- Custom post types with/without author support
- All filter combinations work correctly
@mukesh27 commented on PR #10887:
3 months ago
#13
@Vedanshmini26 Left some questions/suggestions
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
3 months ago
@joedolson commented on PR #10887:
3 months ago
#15
To be thorough, this should also handle visible labels in the media library. These are being added in #23652 in the modal, but the list view would be better handled in combination with this ticket.
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
3 months ago
#17
@
3 months ago
In my opinion, we should split this into two tickets. The need for visible labels is completely separate from the addition of another filter criteria, and they have very different needs.
@presskopp If you'd like to raise a second issue and update the description and title of this one to break them up, I think that would be very helpful.
#18
@
3 months ago
- Milestone changed from 7.0 to Future Release
With all of the open questions here, I'm going to move this to Future Release, hopefully to try again for 7.1.
#20
@
2 months ago
I wonder what option is the most perceivable and accessible https://core.trac.wordpress.org/attachment/ticket/63728/labels_2.png or
https://core.trac.wordpress.org/attachment/ticket/63728/labels_1.png.
I'm attaching a proof-of-concept patch