#20373 closed enhancement (fixed)
Dashboard links aren't being properly read by screenreaders.
Reported by: |
|
Owned by: |
|
---|---|---|---|
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)
Change History (29)
#4
follow-up:
↓ 5
@
13 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.
#5
in reply to:
↑ 4
;
follow-up:
↓ 7
@
13 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?
#7
in reply to:
↑ 5
;
follow-up:
↓ 9
@
13 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.
#9
in reply to:
↑ 7
;
follow-up:
↓ 10
@
13 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.
#10
in reply to:
↑ 9
@
13 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.
#11
follow-up:
↓ 13
@
13 years ago
To label the links but not show browser tooltips, seems we can use aria-label
, W3C reference.
#12
@
13 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
.
#13
in reply to:
↑ 11
;
follow-up:
↓ 14
@
13 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.
#14
in reply to:
↑ 13
@
13 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.
#15
follow-up:
↓ 16
@
13 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.
#16
in reply to:
↑ 15
@
13 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.
#17
@
13 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.
#18
@
13 years ago
- Owner set to azaozz
- Resolution set to fixed
- Status changed from new to closed
In [20680]:
#19
@
13 years ago
- Milestone changed from Awaiting Review to 3.4
Going with the first patch for now.
#20
follow-up:
↓ 23
@
13 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
Reopening to review the escaping here.
#21
@
13 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.
#22
follow-up:
↓ 24
@
13 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.
#23
in reply to:
↑ 20
@
13 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.
#24
in reply to:
↑ 22
@
13 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.
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.