Make WordPress Core

Opened 10 years ago

Closed 10 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:

Description

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

http://i.imgur.com/tUEsTbD.png

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
10 years ago

For tracking, affected screens/files are:

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

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

Version 0, edited 10 years ago by Cheffheid (next)

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


10 years ago

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


10 years ago

#4 @helen
10 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
10 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
10 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
10 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.


10 years ago

#9 @joedolson
10 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.