List table: Lists of items should inform users about the "current view" being displayed

[afercia]

See related #32147

Several screens in the admin present items in a list and you can filter these lists choosing which "view" you want, whether they're Posts in a List Table or lists generated by other components (see Themes and Plugins), they all have some "views" links.

When you select a view, there's no clear, semantic, indication in the markup about the current view being displayed. There's just some bold text.

Users, especially the ones who use assistive technologies, would need some feedback about which kind of "view" they're currently in. For example, something like you're currently viewing the Scheduled Posts. Of course this is the semantics that should be conveyed, not the best possible phrasing.

There are ways to do this but the main issue would be about translatable strings, as pointed out in #32147.

Any thoughts and patches more than welcome :)

Screenshot for reference:

[joedolson]

It seems to me like the data should be pushed into the heading for the page. E.g., click 'Scheduled', heading changes from 'Posts' to 'Scheduled Posts'. That would be simple, uncluttered, and semantic.

[joedolson]

Attached patch only applies to post & post types, as an example of getting that data into the heading.

It also shows up an issue with the language used for post statuses; they aren't consistent - e.g. "Scheduled" vs. "Trash". This is evident when used in a construction: Scheduled Posts is totally logical, but "Trash Posts" doesn't make so much sense.

[joedolson]

Adds context to heading for view and page in post views.

[afercia]

Replying to joedolson:

It seems to me like the data should be pushed into the heading for the page.

That would be ideal. Especially now that the main heading is going to be changed in a H1 see #31650
For Posts (Custom Post Types, Pages) we could simply extend the labels provided by register_post_status() in order to have fully translatable strings e.g.:

register_post_status( 'publish', array(
	'label'       => _x( 'Published', 'post' ),
	'h1'          => __( 'Published Posts' ),
	...

Other screens, e.g. Users, Themes, Plugins, would require something different but definitely worth considering this and I'd highly recommend contextual, descriptive, headings.

[joedolson]

I don't think we want to push complex strings into the strings registered in a post type; I'd rather see linguistic ur-types, such as:

register_post_status( 'publish', array(
	'label'     => _x( 'Published', 'post' ),
	'adjective' => __( 'Published' ),
	'verb'      => __( 'Publish' ),
	...

This allows us to create any needed string combination, rather than making something that's *only* usable in specific contexts.

[joedolson]

We might be able to make a case for adding this information to the status messages block.

[johnbillion]

Adding stand-alone adjectives/verbs/etc as individual labels is a non-starter because it's impossible to localise these.

We can get around it by using phrases which aren't specific to the post type, such as "Status: Published" instead of "Published Posts". This is also more inline with the sort of phrases you'd expect to see when filtering lists of records.

[afercia]

Yup or see an alternate approach suggested by @ocean90 here:
​https://wordpress.slack.com/archives/accessibility/p1433185516000481

[obenland]

Beta is going to hit in two weeks. Does this ticket have a realistic chance to get in until then?

[obenland]

Not a lot of movement recently, let's look at it again in a future release.

[jbpaul17]

Punting to 4.8.1 as there doesn't appear to be a patch coming shortly. If one is ready, then we can pull back into 4.8.

[joedolson]

Note for reference: use aria-current to indicate active view.

[afercia]

32399.diff​ is a first pass to add aria-current="page" to all the "views" link in the list tables and in the theme.js "views" link. Some testing would be nice :)

[flixos90]

32399.diff​ looks good to me.

I'm a little worried about the code there getting more and more complex with more of these (necessary) changes going in. I wonder whether we should introduce a general function to deal with creating the arrays of links that are so commonly used in the backend.
It could be a function get_admin_status_links( $link_data ) (let's find a better name though) where $link_data is an associative array where each key is the link identifier and each value is an array containing data for the actual link element (href and label at least). The logic to transform that data into a link element string could be handled in that function, and changes like those from this ticket would be much simpler as they'd only need to be changed in one place.

Such a function should be introduced in a separate ticket though. Depending on how urgent this fix here is, we could do it one or the other way. It would be a bit easier to have the function first, but it's more initial work to set this up, so if we need to have this here in 4.9, we can always still create the function later.

[afercia]

a general function to deal with creating the arrays of links that are so commonly used in the backend ... The logic to transform that data into a link element string could be handled in that function

@flixos90 thanks. I'd agree that decoupling what get_views() does (which needs to be different depending on the table, since it checks for post status, or user role, or current tab, etc...) with the generation of the links markup could help making the code a bit more clean. The users list table is a special case though, my concern is it would require some refactoring.

I'd agree the propose function should be evaluated in a separate ticket.

Note: maybe 32399.diff​ could be simplified a bit to avoid some ternarys but at the cost of a reduced code readability.

[afercia]

32399.2.diff​ simplifies things a bit. Also, in the Posts list table, there's the need to exlude other edit links used for example for the post formats.

[flixos90]

@afercia I like 32399.2.diff​ better, since the current class and the aria-current attribute really need to always be set at the same time anyway, so I think the new patch has less code churn.

Feel free to open another ticket for the outsourcing part later and ping me, I'd be happy to work on that.

[afercia]

In 41683:

Accessibility: List Tables: use aria-current for the views current link.

The aria-current attribute is a simple, effective way to help assistive
technologies users orientate themselves within a list of items. Continues the
introduction in core of the aria-current attribute after [41359] and [41371].

Props joedolson, flixos90, afercia.
Fixes #32399.