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

[esmi]

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.

[karlgroves]

+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.

[esmi]

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)?

[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. This is true for Firefox and IE support in screen readers.

[GrahamArmfield]

@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.

[esmi]

@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.

[travisnorthcutt]

+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?

[DrewAPicture]

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.

[travisnorthcutt]

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?

[ericlewis]

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.

It sounds like the title attribute should not exist if the alt is an empty string. Perhaps a conditional editing of attributes can be employed as such:

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

[lewismedia]

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...

[esmi]

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.

[JoshLeeCreates]

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.

[esmi]

I seriously doubt that people would read it.

[isaackeyet]

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]

Mockup of media options Title toggle

[nacin]

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.

[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'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?

[nacin]

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

[DrewAPicture]

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.

[martythornley]

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]

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.

[martythornley]

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]

Removed title from insert from other website js in addExtImage

[nacin]

In 22409:

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

[helenyhou]

#22426 was marked as a duplicate.

[nacin]

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.

[nacin]

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].

[nacin]

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.

[nacin]

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]

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

[koopersmith]

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.

[ryan]

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

[ryan]

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

[miqrogroove]

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

1. Is this carved in stone now?

2. 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.

[nacin]

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.

[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.

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?

[SergeyBiryukov]

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.

[luciole135]

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