Add screen-reader-text to list "filter" links

[Cheffheid]

This is specifically for links like these on the "Posts" page:

Currently, when tabbing through the page, these links will simply announce "All (x)", "Published (x)", "Draft (x)", and so on. It's absolutely not clear what these links will do when activated.

Suggestion is (to keep it simple, code wise) to change this to the following:

<span class="screen-reader-text">Show</span>
[status] (x)
<span class="screen-reader-text">[post_type]</span>

Where [status] is the status (All, Published, Draft, whatever) and [post_type] is whatever the post type is (or Comments, or Plugins).

To make it easier to review patches, will probably need to make these changes on a per-file basis and create patches based on that.

[Cheffheid]

For tracking, affected screens/files are:

All Posts (wp-admin/includes/class-wp-posts-list-table.php, wp-includes/post.php)
All Pages (wp-admin/includes/class-wp-posts-list-table.php)
Comments (wp-admin/includes/class-wp-comments-list-table.php)
Installed Plugins (wp-admin/includes/class-wp-plugin-list-table.php)
All Users (wp-admin/includes/class-wp-users-list-table.php)

(Network) All Users (wp-admin/includes/class-wp-ms-users-list-table.php)
(Network) Installed Themes (wp-admin/includes/class-wp-ms-themes-list-table.php)
(Network) Installed Plugins (wp-admin/includes/class-wp-ms-plugins-list-table.php)

[helen]

Moving version back to clear trunk report - it can be set further back if somebody really wants to trace the history, or if it was introduced in trunk, please comment to that effect.

[joedolson]

I'm uncertain whether this is really necessary, or whether we'd just be creating additional noise on the page. These links are not duplicates on any given screen, so the existing text is unique for that screen. I think it's reasonable to assume that somebody should know their current post type context when using those links.

While adding context can be very valuable, for confirmation, I'm not sure it's necessary in this case. Considering a normal workflow, I can see only one likely path to reach these links.

The use case I see is that the user has activated a link such as 'All Posts' from the left menu, landed on the page, and selected "Published". They've intentionally gone to the "All Posts" page, so should be expecting posts.

If there's another context that may be relevant, let me know. I could certainly be overlooking something.

This is kind of an overarching question for the entire admin: when is there enough context already? Should we assume that users with screen readers never know their current context, and need confirmation at all stages?

[afercia]

Adding some headings as proposed in #32147 would probably add some useful context for these links and maybe won't require other changes. Also, there are issues here in order to have fully translatable strings.

[joedolson]

I think we're better off with the headings for context (since they will be read less frequently).

Think we should close this as wontfix?

[joedolson]

Closing this in favor of the solutions proposed in #32147.