Make WordPress Core

Opened 13 years ago

Closed 12 years ago

Last modified 9 years ago

#18984 closed defect (bug) (fixed)

Accessibility: Title attribute should not be added to image markup by media.php

Reported by: esmi's profile esmi Owned by: nacin's profile nacin
Milestone: 3.5 Priority: normal
Severity: normal Version:
Component: Media Keywords: has-patch
Focuses: Cc:

Description

Title attributes on images create issues with some assistive software (eg JAWS in verbose mode) yet are completely inaccessible to other assistive software (JAWS in non-verbose mode, VR software etc). Alt is the prescribed and 'correct' method for relaying information to non-sighted visitors or those using non-graphical browsers.

While Title is certainly needed for the media library itself, it should be removed, if possible, from the generated image markup.

Attachments (6)

media-options-title-toggle.png (130.4 KB) - added by isaackeyet 12 years ago.
Mockup of media options Title toggle
18984.diff (1.1 KB) - added by martythornley 12 years ago.
18984.2.diff (2.1 KB) - added by martythornley 12 years ago.
Removed title from insert from other website js in addExtImage
18984.3.diff (522 bytes) - added by nacin 12 years ago.
18984.4.diff (566 bytes) - added by nacin 12 years ago.
18984.5.diff (1.6 KB) - added by koopersmith 12 years ago.

Download all attachments as: .zip

Change History (51)

#1 follow-up: @karlgroves
13 years ago

+1. This is enough of an annoyance that I've written a little snippet of jQuery to work around it on sites I make with Wordpress

The only required attribute here seems to be the title. If any of these are required, it should be the alt. I disagree with removing title from generated markup. The content author may have a valid reason for providing a title attribute. However, there is a potential usability problem with the way this is currently handled.

As I said above, the only field marked as required is currently the title. This may lead content authors to believe that all they need to do is provide the title (afterall, the alt isn't required). It would be preferable to have the alt be the required field here. Any logic necessary for labeling the file in the media library can come from the alt.

#2 in reply to: ↑ 1 @esmi
13 years ago

Replying to karlgroves:

If any of these are required, it should be the alt.

No! The alt attribute should not be used for purely decorative images. As this cannot be determined by software, it must remain an author decision

I disagree with removing title from generated markup. The content author may have a valid reason for providing a title attribute.

Can you provide a reason - given that it can only be guaranteed accessible to a limited sub-set of users (ie sighted mouse users)?

#3 @MarcoZ
13 years ago

Using alt is indeed THE method to accessibly name images for screen readers and other assistive technologies. the title attribute is ALWAYS suplemental information that is only then referred to if alt is not available and not "". So if alt is "", title will ALWAYS be ignored. This is true for Firefox and IE support in screen readers.

#4 @DrewAPicture
13 years ago

  • Cc xoodrew@… added

#5 @GrahamArmfield
13 years ago

@esmi I'm afraid I have to disagree with your assertion that the alt attribute should not be used for purely decorative images.

When an image is presented in a web page the alt attribute should always be present. But for decorative images it should be set to an empty string - ie:

alt=""

When screen readers encounter an image without any alt attribute the screen reader is likely to read the full path and filename of the image to the user - not always meaningful or useful. Using alt="" signals to assistive technology that the image should be ignored.

Agree with you that setting of the alt attribute value should be down to the discretion of the author and judged on what the image represents or the meaning it conveys or where clicking on the image takes you.

#6 @esmi
13 years ago

@Graham: My bad. I phrased my response poorly. Yes - of course a null alt attribute is the correct way to handle decorative images. And WordPress does handle that correctly right now. It's the enforced title attribute that's the issue here. At best, it's superfluous and annoying. At worst, it could create a barrier for some users - either by creating unwanted noise on the page or by encouraging web authors to rely on it instead of using the alt attribute appropriately.

From an educational standpoint, I think we should be trying to point web authors in the right direction with regard to the alt attribute instead of giving them the wrong crutch.

#7 @SergeyBiryukov
13 years ago

  • Component changed from General to Accessibility

#8 follow-up: @travisnorthcutt
13 years ago

  • Cc travis@… added
  • Keywords needs-patch added

+1 to this. The title field should be available, but not required. One problem is that WordPress uses the value of the title field for both front-end output and for organizing uploaded files on /wp-admin/media.php. Any ideas for an unambiguous way to solve that problem?

#9 in reply to: ↑ 8 ; follow-up: @DrewAPicture
13 years ago

Replying to travisnorthcutt:

One problem is that WordPress uses the value of the title field for both front-end output and for organizing uploaded files on /wp-admin/media.php.

Well, that is the rub of not requiring the title. I suggest we continue to require the title but not necessarily output it in markup, which is what this ticket suggests.

Last edited 13 years ago by DrewAPicture (previous) (diff)

#10 @DrewAPicture
13 years ago

  • Keywords ux-feedback added

#11 in reply to: ↑ 9 ; follow-up: @travisnorthcutt
13 years ago

Replying to DrewAPicture:

Well, that is the rub of not requiring the title. I suggest we continue to require the title but not necessarily output it in markup, which is what this ticket suggests.

So, perhaps a "display on site" checkbox?

#12 in reply to: ↑ 11 @ericlewis
13 years ago

Replying to travisnorthcutt:

So, perhaps a "display on site" checkbox?

IMHO a lot of end users would be confused at the existence of a checkbox "display title of image in HTML element on site," or however it ended up being phrased.

Replying to MarcoZ:

Using alt is indeed THE method to accessibly name images for screen readers and other assistive technologies. the title attribute is ALWAYS suplemental information that is only then referred to if alt is not available and not "". So if alt is "", title will ALWAYS be ignored.

It sounds like there is user error in filling out the Media Upload / Edit screen, filling out the Title only. Perhaps a conditional editing of attributes can be employed to deal with this:

if ( ! alt && title ) {
    alt = title; title = "";
}

and then output in the <img> tag alt, whether or not it is an empty string, and title only if it is not an empty string.

Last edited 13 years ago by ericlewis (previous) (diff)

#13 @toscho
13 years ago

  • Cc info@… added

#14 @Joe Lewis
13 years ago

  • Cc bjoe_lewis@… added

#15 @lewismedia
13 years ago

Is this not a simple fix, for the minority of users (myself included), who prefer NOT to have the title tag inserted automatically:

function remove_attachment_title_attr( $attr ) {
	unset($attr['title']);
 
	return $attr;
}
add_action('wp_get_attachment_image_attributes', 'remove_attachment_title_attr');

Definitely digging the idea of offering users the option to display or not display with a checkbox or dropdown, though I am in agreement that this would be confusing for your average Joe Schmoe end user who doesn't even know what a title tag IS...

#16 @esmi
12 years ago

The average Joe Schmoe end user might understand "tootip". That seems to be the most common way of describing the browser rendering of title attributes amongst non-technical users.

#17 @JoshLeeCreates
12 years ago

Would it not be best to explain in the form how these fields will be used by assistive technology? I think that even intermediate users may not understand how vital it is to fill out the alt field.

#18 @esmi
12 years ago

I seriously doubt that people would read it.

#19 @isaackeyet
12 years ago

Agreed that title is not really the preferred field to have users fill out or automate if we get to pick which field is pre-populated. Mostly because many images will then have the title "IMG_0021" or similar, which is not useful for anybody.

WP should use another way of indexing the files or rely on other meta data.

Personally I think the resolution should just be to

  1. Implement function to not output title fields in the actual rendered mark up (but keep it internally for indexing).
  2. Change Title field in Media Options to be a non-editable looking greyed out string (not textfield), with an Edit.
  3. Edit enables the text field, the "required field" asterisk, hides the original string, shows help about the field (editing will enable the Title HTML attribute).
  4. If edited, title is now output in the rendered post.

I'm a visual guy so I'll be posting a quick and dirty mockup of what this could look like shortly.

@isaackeyet
12 years ago

Mockup of media options Title toggle

#20 @isaackeyet
12 years ago

  • Cc isaackeyet added

#21 @nacin
12 years ago

  • Component changed from Accessibility to Media
  • Keywords needs-patch ux-feedback removed
  • Milestone changed from Awaiting Review to 3.5

I know this was reported as an accessibility issue, but it's much more than that. I'm moving this to the Media component as I want to track this as one of the media 3.5 tickets.

#22 @martythornley
12 years ago

  • Cc marty@… added

It sounds like the title attribute should be removed altogether and just use the "title" aspect of the image as a naming device in the back end? Why not just change title to "Name", so as we edit an image, we can give it a "Name" and edit the ALT attribute?

I'd be happy to jump on a patch for this but there doesn't seem to be a consensus about what needs to be done?

#23 @nacin
12 years ago

"Title" is used on attachment pages as well. #21390 will result in some changes on how these fields are presented.

#24 follow-up: @DrewAPicture
12 years ago

Replying to martythornley:

It sounds like the title attribute should be removed altogether and just use the "title" aspect of the image as a naming device in the back end? Why not just change title to "Name", so as we edit an image, we can give it a "Name" and edit the ALT attribute?

I think from an administration standpoint, an image title is necessary and important and should be fed via the image's EXIF data as it is now. This is not really an issue of contention and falls outside this ticket's scope.

Really we just want to use the alt value instead of the title value in markup.

Replying to nacin:

#21390 will result in some changes on how these fields are presented

Thanks for the heads up.

#25 in reply to: ↑ 24 @martythornley
12 years ago

Replying to DrewAPicture:

Really we just want to use the alt value instead of the title value in markup.

So if that is the consensus for this ticket and leave the rest to another time, I can take a look at fixing the markup to use alt instead of title.

@martythornley
12 years ago

#26 @martythornley
12 years ago

  • Keywords has-patch added

Added a patch that removes the title attribute. Looks like it was in two places, both wp_get_attachment_image() and get_image_tag(). i couldn't find it anywhere else.

#27 @martythornley
12 years ago

Looking into image captions and gallery shotcodes as well...

The following just take existing $html of an img tag and don't mess with the attributes, just wrap in the caption:
image_add_caption()
img_caption_shortcode()

Gallery shortcode uses
wp_get_attachment_link() which uses wp_get_attachment_image() which is fixed in this patch.

None of the filters surrounding these functions seem to have anything in core hooked in that would effect the title attribute.

@martythornley
12 years ago

Removed title from insert from other website js in addExtImage

#28 @nacin
12 years ago

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

In 22409:

Stop adding title attributes to images (in the old media uploader). props martythornley. fixes #18984.

#29 @helenyhou
12 years ago

#22426 was marked as a duplicate.

#30 @nacin
12 years ago

I think a piece of [22409] was in the wrong place. get_image_tag() is a generic (if old, crufty) function and should not be touched. Its caller, get_image_send_to_editor(), should be modified.

#31 @nacin
12 years ago

In 22747:

Stop inserting title attributes for images inserted into the editor by modifying get_image_send_to_editor(), not the generic get_image_tag().

see #18984, [22409].

#32 @nacin
12 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Re-opening this again.

What we currently do is use the caption for alt if alt is empty. We should subsequently fall back to title for alt.

Many people are using titles and possibly not captions. We should not punish them.

#33 @nacin
12 years ago

Oh. We already do this.

if ( empty($default_attr['alt']) )
	$default_attr['alt'] = trim(strip_tags( $attachment->post_excerpt )); // If not, Use the Caption
if ( empty($default_attr['alt']) )
	$default_attr['alt'] = trim(strip_tags( $attachment->post_title )); // Finally, use the title

@nacin
12 years ago

#34 @nacin
12 years ago

Patch tries to implement the alt-caption-title fallback when sending to editor.

@nacin
12 years ago

@koopersmith
12 years ago

#35 @koopersmith
12 years ago

attachment:18984.5.diff​ implements the fallbacks in JS instead of PHP, so strings created in JS and "from URL" output both benefit from the fallbacks as well.

If we were to go with a PHP solution, attachment:18984.4.diff needs to prevent the $title var from being cleared before it's sent to the filter, and also ensure the title var would be sent over from the JS.

#36 @ryan
12 years ago

.5.diff looks good. Tested alt falling back to caption and title.

#37 @ryan
12 years ago

In 22937:

In the add media modal, fallback back to caption if alt is not set. Falback to title if neither caption nor alt are set.

Props koopersmith
see #18984

#38 @ryan
12 years ago

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

#39 @miqrogroove
12 years ago

So the image tooltips are missing on new images. :( Two questions:

  1. Is this carved in stone now?
  1. Since this change does nothing to old posts, does it really help assistive software users in any way?

I'm looking at my front page in RC5 and thinking, if I need to get rid of image titles for the sake of blind visitors, this hasn't accomplished that.

As a sighted webmaster, I'm concerned that the case hasn't been made for this being a WordPress bug rather than a browser bug.

#40 @nacin
12 years ago

This is a WordPress bug. I'm sorry (but not actually sorry) that the tooltip community has felt slighted by this one, but we won't need to make a change. We made a choice, and this choice on the whole benefits all users and readers, not just those using screenreaders. How often have you moused over an image on a WordPress site and saw "IMG_1234"? One of the lamest things ever. Never again.

Tooltips can still be added by opening the Edit Image modal and inserting something into the title attribute box. The only change is that the "Title" field — which is the name of an image's attachment page — does not populate the title attribute.

#41 follow-up: @TLWH
12 years ago

Just wondering when you try to add an image via "insert from URL" you get a field to enter the url and a field to enter the title. If you fill up the title then ass the url, then the title vanishes.

I though originally that it was auto saved. But true enough after inserting the image then clicking on it you see that the title field is now blank. i.e. it never saved.

Surely this is bug? If you are going to do away with titles why add a title field that doesn't save anything?

#42 in reply to: ↑ 41 @SergeyBiryukov
12 years ago

Replying to TLWH:

Just wondering when you try to add an image via "insert from URL" you get a field to enter the url and a field to enter the title. If you fill up the title then ass the url, then the title vanishes.

Confirmed. This ticket was closed on a completed milestone, feel free to create a new one.

#43 @luciole135
11 years ago

This is the most stupid change i never seen, if you make the change i propose in these track there is no probleme for everyone : #22854

Last edited 11 years ago by SergeyBiryukov (previous) (diff)

This ticket was mentioned in Slack in #design by ocean90. View the logs.


9 years ago

This ticket was mentioned in Slack in #core by boren. View the logs.


9 years ago

Note: See TracTickets for help on using tickets.