Opened 3 weeks ago
Last modified 6 days ago
#65683 new defect (bug)
Visually expose the labels of the Media Library 'List view' and 'Grid view' links
| Reported by: | afercia | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Awaiting Review |
| Component: | Media | Version: | |
| Severity: | normal | Keywords: | a11y-visible-labels has-patch |
| Cc: | Focuses: | accessibility |
Description
Now that accessible tooltips and toggle tips are in Core, see [62741], I think that's a great opportunity to reconsider those parts of the admin UI that we are most accustomed to and that at first glance we do not consider problematic but in fact may be problematic for some users.
One of the most evident cases is about the 'List view' and 'Grid view' links in the Media Library.
Those two icon-only links do contain visually hidden screen reader text but that's not sufficient. There should be a _visible_ label for them.
Visible label text should always be preferred.
Some users don't understand icons. Some users need to know the accessible name of a control to be able to issue a voice command. The most accessible web and desktop applications use a combination of icon + visble label to take into account the needs of users with diverse abilities.
When there's a really, really, really good reason to use only an icon, e.g. because of design constraints that can't be solved otherwise, then exposing the accessible name of such a link by the means of an accessible tooltip is an acceptable compromise. Still, it's a compromise. Always prefer visible text.
In this specific case there are two options:
- Change the design and add visible label text below the icons.
- Use the new WordPress accessible tooltips.
It is worth noting that in their first implementation the new WordPress tooltips only supported button eloments. They are going to be extended to support also links but only for the 'tooltip' pattern, not for the 'toggletip' pattern.
For links, as agreed on the discussion starting at https://github.com/WordPress/wordpress-develop/pull/12528#issuecomment-5025167415, the only implementation we'd want to have is the 'tooltip' case. As in: an icon-only link that already has an accessible name and needs to visually expose it by the meqans of a tooltip.
For these two links, the PHP part in the List view is pretty simple to address. However, the JS part in the Grid view may be a little more comples. Still, visible text is the preferred option so I would like to suggest a design change to start with.
Attachments (4)
Change History (15)
This ticket was mentioned in PR #12617 on WordPress/wordpress-develop by @afercia.
3 weeks ago
#1
- Keywords has-patch has-unit-tests added
Track ticket: https://core.trac.wordpress.org/ticket/65683
This is a proof of concept pull request to add the accessible WP tooltips on _links_. Still, in the case of the media library 'views' links, the preferred option would be using visible label text.
See also https://github.com/WordPress/wordpress-develop/pull/12528
## Use of AI Tools
#2
@
3 weeks ago
- Keywords has-patch has-unit-tests removed
- Summary Visually expose the labels of the Media Library 'List view' and 'Grid view' link → Visually expose the labels of the Media Library 'List view' and 'Grid view' links
#3
@
3 weeks ago
Thanks for the ticket.
I have another request, but maybe I should open a dedicated ticket for this…
In your screenshot I noticed the "List View" / "Grid View" labels, and given these labels are on a button (or an action link), I thought it should rather use a verb to describe the action, like "Switch to list view" or "Switch to grid view". In some other contexts, we're good, like in the "Move Up" / "Move Down" labels.
But I'm globally wondering whether we should make it a general rule for buttons/action links labelling.
And yeah, I believe I definitely should open a specific ticket for this…
#4
@
3 weeks ago
+1 for this enhancement. Adding visible labels would improve discoverability and accessibility for a wider range of users. If design constraints prevent that, accessible tooltips seem like a reasonable alternative.
#6
@
3 weeks ago
Besides the Media 'List view' page, there are two more cases where the list table classes use the view_switcher() method from the parent class:
- Network Sites: switching view adds to the table:
- The
blognameandblogdescriptionto the cells in the URL column. Note that when there's no blogdescription, the added row shows a stray en dash. - The time for the Last updated and Registered dates.
- The
- Network Users: switching view adds to the table:
- The time for the Registered date.
These are minimal differences. See attached screenshots.
I'd like to propose to entirely remove the switch view functionality from these two admin pages because it adds little value. The additional info could be shown by default.
It is worth reminding that the view mode switcher for posts was moved to the Screen options 11 years ago in [35357]. Later, the 'Excerpt' view was expanded to become an 'Extended' view in
#49715. These views are now called "Compact view" and "Extended view" and serve a slightly different purpose, including making the row actions links always visible.
#7
@
3 weeks ago
I thought it should rather use a verb to describe the action, like "Switch to list view" or "Switch to grid view". In some other contexts, we're good, like in the "Move Up" / "Move Down" labels.
@audrasjb thank you, good point. There's some inconsistency between verbs / action names across the UI. However, if we are going to make these label visible, they should be as short as possible. We should make sure they are short also when translated. Also, what we have now in the Screen options are names: View mode > Compact view / Extended view.
This ticket was mentioned in PR #12662 on WordPress/wordpress-develop by @afercia.
3 weeks ago
#8
- Keywords has-patch added
@afercia commented on PR #12662:
11 days ago
#9
I'mm going to mark this PR as a draft so it is clear it's a Work In Progress.
@afercia commented on PR #12617:
10 days ago
#10
Closing as this was just a proof of concept.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
The view links in the media library