Make WordPress Core

Opened 9 years ago

Closed 9 years ago

#31965 closed defect (bug) (wontfix)

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

Reported by: cheffheid's profile Cheffheid Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.1
Component: Administration Keywords:
Focuses: accessibility Cc:


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.

Change History (9)

#1 @Cheffheid
9 years ago

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)

Version 2, edited 9 years ago by Cheffheid (previous) (next) (diff)

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

9 years ago

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

9 years ago

#4 @helen
9 years ago

  • Version changed from trunk to 4.1

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.

#5 @joedolson
9 years ago

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?

#6 @afercia
9 years ago

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.

#7 @joedolson
9 years ago

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?

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

9 years ago

#9 @joedolson
9 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.