WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 21 months ago

#20373 closed enhancement (fixed)

Dashboard links aren't being properly read by screenreaders.

Reported by: quanin Owned by: azaozz
Milestone: 3.4 Priority: normal
Severity: normal Version: 3.3
Component: Accessibility Keywords:
Focuses: Cc:

Description

The top level menu links in the dashboard menus use either very few alt tags in their images, or none at all. As such, screenreaders--at least those that I've tested with--read the links as, for example, wp-admin/plugins or wp-admin/edit-comments as opposed to what they should read. In *most* cases, it's not a major issue, however it reduces the ability to navigate the various screens quickly unless you *really* know what you're doing, and are very familiar with both the capabilities of your screenreader and the underlying layout of Wordpress (for example: knowing you need to access wp-admin/post-new.php instead of clicking on the link that, according to your screenreader, just says wp-admin/edit and hoping it gets you to the right screen). I could make the changes myself and just submit a patch, if that would be helpful, but I'm still not entirely sure yet where everything's located in wordpress's code--I'm learning, just slowly--and as such, am not yet sure how to best go about telling Wordpress to accept a proper alt tag for the various menu images.

Note: this is only a problem for the top level menus--submenus underneath behave as advertized. In fact, if the top level menus were designed the same as their children, this wouldn't even be an issue that needed fixing. However, since that's not necessarily the direction WP's heading in, adding alt tags to these image links would be the next best way to fix that issue so far as accessibility is concerned. I appreciate any attention that can be given to this matter.

Attachments (2)

20373.patch (2.5 KB) - added by azaozz 2 years ago.
20373-2.patch (3.0 KB) - added by azaozz 2 years ago.

Download all attachments as: .zip

Change History (29)

comment:1 SergeyBiryukov2 years ago

  • Component changed from Menus to Accessibility

comment:2 azaozz2 years ago

That would be nice to have. The problem is these aren't "real" images, they are backgrounds for <div> tags that have <a> tags inside. So alt attributes cannot be added on them as they are not valid.

Adding title attributes on the links would trigger the browsers to display "tooltips" on hover which look out of place there. Perhaps aria attributes can be used instead.

Last edited 2 years ago by azaozz (previous) (diff)

comment:3 DrewAPicture2 years ago

  • Cc xoodrew@… added

comment:4 follow-up: quanin2 years ago

  • Summary changed from Graphical links in Dashboard need alt tags. to Dashboard links aren't being properly read by screenreaders.
  • Version set to 3.3

Having a look at the code, yeah, they're not actually graphical links. That makes it a bit more tricky. I'll play with it a bit on this side and see if I can tweek things a bit. Screenreaders *should* be reading these links correctly by default, though--they're valid HTML, whether or not Aria is involved, so far as I'm aware. This has only been a problem since version 3.3, so it's definitely related to one of the changes implemented there. However, verifying on wordpress.com which still runs 3.2.1 still, yes the screenreader still reads those links as, for instance, wp-admin/index, but it *also* reads the Dashboard links etc. And, in that version, they behave more as expected--the menus are available as needed, without guess work/screen manipulation on an extensive scale. Not sure how much help that is, but you'll have that.

Scratch my ticket reference from earlier. That'll teach me to look before I type. That ticket actually isn't related.

Last edited 2 years ago by quanin (previous) (diff)

comment:5 in reply to: ↑ 4 ; follow-up: helenyhou2 years ago

Replying to quanin:

However, verifying on wordpress.com which still runs 3.2.1 still

WordPress.com essentially runs on trunk, and definitely not an old version. Interesting that it works there, then - are you able to test using trunk or the 3.4 beta?

comment:7 in reply to: ↑ 5 ; follow-up: quanin2 years ago

Replying to helenyhou:

Replying to quanin:

However, verifying on wordpress.com which still runs 3.2.1 still

WordPress.com essentially runs on trunk, and definitely not an old version. Interesting that it works there, then - are you able to test using trunk or the 3.4 beta?

It says it's running 3.2.1 when you stare at your dashboard. And, I'm running the 3.4 beta now. Issue still persists.

comment:8 stickbear2 years ago

  • Cc stickbear added

comment:9 in reply to: ↑ 7 ; follow-up: nacin2 years ago

Replying to quanin:

It says it's running 3.2.1 when you stare at your dashboard. And, I'm running the 3.4 beta now. Issue still persists.

Nope — you might be looking at an old WordPress.org install somewhere, as WP.com is currently running 3.4-beta1.

comment:10 in reply to: ↑ 9 quanin2 years ago

Replying to nacin:

Replying to quanin:

It says it's running 3.2.1 when you stare at your dashboard. And, I'm running the 3.4 beta now. Issue still persists.

Nope — you might be looking at an old WordPress.org install somewhere, as WP.com is currently running 3.4-beta1.

Ah, yes, my mistake. I was staring at more than one window. Still, I can confirm wordpress.com is not giving me the same issue, even running its current version. The beta is a clean install in this system, and is giving me this issue. As is any blog that gets upgraded from 3.2.1. No idea what breaks, but I've tested multiple times with same results.

comment:11 follow-up: azaozz2 years ago

To label the links but not show browser tooltips, seems we can use aria-label, W3C reference.

azaozz2 years ago

comment:12 azaozz2 years ago

Alternatively HTML IDs will have to be added to the second links (that contain the visible text), then aria-labelledby can be used in place of aria-label.

comment:13 in reply to: ↑ 11 ; follow-up: quanin2 years ago

Replying to azaozz:

To label the links but not show browser tooltips, seems we can use aria-label, W3C reference.

This patch looks like it works, mostly. Now, it says things like Dashboard wp-admin/index, as opposed to wp-admin/index. Progress, if small. I'll take it, for the time being. If we can improve it though, I won't say no.

comment:14 in reply to: ↑ 13 azaozz2 years ago

Replying to quanin:

This patch looks like it works, mostly...

So it reads both the aria-label and the link href? Strange, the label should have priority over the href. Not sure if using aria-labelledby will be any better. The specs say they are supposed to behave in exactly the same way, worth a try though.

Could you test the next patch to see if it works better.

azaozz2 years ago

comment:15 follow-up: azaozz2 years ago

If not, seems the only alternative would be to remove the link from div.wp-menu-image and handle clicks there with JS. Then screen readers would disregard this div and continue on to the "real" link that has text.

Last edited 2 years ago by azaozz (previous) (diff)

comment:16 in reply to: ↑ 15 quanin2 years ago

Replying to azaozz:

If not, seems the only alternative would be to remove the link from div.wp-menu-image and handle clicks there with JS. Then screen readers would disregard this div and continue on to the "real" link that has text.

This patch doesn't actually do anything screenreader-wise. Functionality is same as without patching at all.

comment:17 quanin2 years ago

Just giving this a nudge. I'd like to see the dashboard interface improved preferably prior to 3.4's release, if possible.

comment:18 azaozz2 years ago

  • Owner set to azaozz
  • Resolution set to fixed
  • Status changed from new to closed

In [20680]:

Admin menu: add aria-label attributes to the links around menu images for the sake of screen readers, fixes #20373

comment:19 azaozz2 years ago

  • Milestone changed from Awaiting Review to 3.4

Going with the first patch for now.

comment:20 follow-up: nacin2 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening to review the escaping here.

comment:21 quanin2 years ago

I don't think you're using the first patch. If you are, then something didn't do what it was supposed to. It reads the same with a screenreader as without patching.

comment:22 follow-up: quanin2 years ago

Okay, nevermind. I just fail at SVN. It's doing what it should. Not perfect, but uh... it's readable.

As said, now, it looks like this.
Dashboard wp-admin/index

Not perfect, but... workable-ish. If we can improve it, though, I'd love to.

comment:23 in reply to: ↑ 20 azaozz2 years ago

Replying to nacin:

Reopening to review the escaping here.

SInce this is an html attribute, escaping is done with esc_attr() after all html tags and line breaks are removed.

Version 0, edited 2 years ago by azaozz (next)

comment:24 in reply to: ↑ 22 azaozz2 years ago

Replying to quanin:

...Not perfect, but uh... it's readable.

The only other option seems to be to remove the link from there completely. A bit hesitant to do that now, will revisit for 3.5.

comment:25 azaozz2 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In [20698]:

Admin menu: change to strip_tags() for the aria-label attributes as it's faster, fixes #20373

comment:26 quanin2 years ago

I'd be interested in seeing a possible patch or something for how that would work, or some general pointers as to how I might do it myself. If it works, I'd love to see it in 3.4 or 3.5, whichever would be easier.

Note: See TracTickets for help on using tickets.