#35136 closed defect (bug) (fixed)
Remove title attributes: the Media Library screen
Reported by: | afercia | Owned by: | afercia |
---|---|---|---|
Milestone: | 4.5 | Priority: | normal |
Severity: | normal | Version: | 4.4 |
Component: | Media | Keywords: | has-screenshots, has-patch, title-attribute |
Focuses: | ui, accessibility | Cc: |
Description (last modified by )
See related #24766 and all the following tickets about title attributes.
Please refer to the screenshot below:
The title attribute on the "Comments" table header
I'd suggest to simply remove it, the link already has a hidden text.
The title attributes on the row action links
there are a couple of things to notice:
- the only link with a title attribute is the "View" link, this is a bit inconsistent (also visually)
- the title attribute is different depending on the attachment being attached or not attached to a post
When it's attached, the attachment permalink will contain also the parent post title but it still points to the attachment page so the title attribute saying "View {post parent title}" doesn't look 100% accurate to me. I'd propose to simplify and just say "View {attachment title}".
The attachment main "Edit" link and all the row action links should have some hidden text or aria-label
to give more context or to reference the attachment title. See for example the Plugins screen.
The "Attach" link
it opens the "Find Posts or Pages" modal, should inform that is going to open a modal dialog.
The link to the post parent in the "Uploaded to" column
it points to the "Edit" screen. It's not clear at first sight if it's a link to "View" or "Edit", by the way this is out of the scope of this ticket and should go in a separate one.
Working on a patch but would like to have some feedback from the accessibility team before.
Attachments (2)
Change History (16)
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
9 years ago
#4
@
9 years ago
Hi @diddledan, thanks for your feedback. I kindly disagree :)
As noted in a similar ticket (see #35050) somehow that has been a common UI expectation till now but just for mouse/trackpad/alternate pointing devices users. Not for mobile and tablet users as well as assistive technologies users.
The web is evolving and title attributes are more and more the best way to hide content from users :)
Basically, we're providing a small piece of information that's available just for some users while we should make it available for all users.
At WordCamp US 2015 it was pointed out that when using title attributes there's something lacking in your interface to begin with :) https://videopress.com/v/YYVkXSx7?at=1269 and I totally second that. If the speech-bubble icon makes people unsure about what it means, then I'd say the icon should be improved a bit or not used at all.
Also, I wouldn't recommend to rely on HTML features which usage is currently discouraged.
#5
@
9 years ago
@afercia, thanks for the explanation and links, I see your point of view now and can only agree with your statements :-) Now to go watch that video....
#6
@
9 years ago
Having a :hover condition that provides feedback about what an icon link represents is very important for users with cognitive disabilities or to disambiguate between unrecognized icons.
However, using the title attribute to perform that task is a highly problematic technique.
I strongly feel that information like this does need to be disclosed to the user in a text format; it's just a matter of creating a method to do this which is effective both in a :hover and a :focus situation and making the information mobile-friendly.
I'm aware that isn't a small thing, but I don't think it's wise to dismiss the value of the information because the technique in use isn't effective.
No icon will ever be 100% communicative on its own; we can "improve" the icon all we want, but it won't magically become universal. Providing text-based support is the only way to make that truly effective. However, removing the icon is not a solution either, since a fully text-only interface is overwhelming for users with cognitive disabilities, dyslexia, etc., among other issues.
#7
@
9 years ago
I agree. On everything :) Need a pragmatic solution though. There are ways to use data-attributes or, better, aria-labels to generate "tooltips" see for example:
tooltips in Gmail: data-tooltip="Refresh" aria-label="Refresh" (uses JavaScript) tooltips in GitHub: aria-label="You have no unread notifications" (pure CSS on hover/focus, JavaScript for positioning)
And we should find a way to reveal them also on a "longpress" event. By the way I think this is a topic for a separate ticket and proposal. If it was my personal site, I would go with simple, plain text. It's not my personal site though :) It wouldn't look so bad:
#8
@
9 years ago
- Keywords has-patch added; needs-patch removed
First pass. Pending issues:
- the "Comments" table header
- should the "Attach" link inform users that it's going to open a modal dialog?
#10
@
9 years ago
The refreshed patch strips out changes to the Comments "bubble". It was correctly pointed out that icon links need a way to clarify what they represent. The title attribute is a problematic technique for that and probably there's the need to find a new, modern, method to disclose this kind of information to users. By the way, this issue is related to all icon links used in the admin so it should probably go in a separate ticket.
About the "Attach" modal dialog, thinking there's no need to inform users the link is going to open a modal but the modal itself should be accessible. Will open a specific ticket for this.
#11
@
9 years ago
Example of the the aria-label
attributes with the patch applied:
“My image” (Edit) Edit “My image” Move “My image” to the Trash Restore “My image” from the Trash Delete “My image” permanently View “My image” Attach “My image” to existing content Detach from “My post”
Regarding the "Comments" table header title attribute, I would suggest to leave that in-place: Even though the speech-bubble is recognisable, it can be helpful for people who are unsure what the icon means to have the hover-state label appear to clarify. Personally I have no accessibility issues, but I expect icon-only links and actions to have a label when I hover over them to disambiguate what it symbolises.