WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#26270 closed enhancement (invalid)

TITLE attribute valued over ALT attribute in Edit Media

Reported by: yaelkmiller Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.7.1
Component: Accessibility Keywords:
Focuses: Cc:

Description

In WCAG 2.0, Guideline 1.1 is "Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need."

You do this with the ALT tag.

However, when you go to edit the metadata of an image in Media Library, the large field at the top is the TITLE tag and the much smaller field further down the page is the ALT tag.

Since the ALT tag is vital in terms of accessibility, I suggest that the positions of the ALT tag and the TITLE tag be reversed.

Change History (12)

#1 @yaelkmiller
4 years ago

  • Summary changed from TITLE tag valued over ALT tag in Edit Media to TITLE attribute valued over ALT attribute in Edit Media

#2 in reply to: ↑ description @yaelkmiller
4 years ago

When I used "tag", I meant "attribute."

#3 follow-up: @helen
4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

I think this is a little misleading because of the existing post_title field that is being used here - if you don't specify different alt text, it will use the title for the alt text and does not output a title attribute by default. If you specify a different value for alt text, it will get used instead and is actually stored as post meta instead of post_title.

#4 @yaelkmiller
4 years ago

@helen I had no idea it would use title for alt until you mentioned it.

Still, I think because alt is so important, I would like it to be given pride of place.

In any case, I was pointed to this ticket which discusses the value of all title attributes.

#5 @dimadin
4 years ago

Note that title is also used as a page title for single attachment pages for all type of files not just for images.

Single attachments pages are those that you can see when you click "View" at Media Library screen, and links to those pages can exist in posts if user choses "Link to attachment page" in media modal.

#6 in reply to: ↑ 3 ; follow-up: @grahamarmfield
4 years ago

Replying to helen:

I think this is a little misleading because of the existing post_title field that is being used here - if you don't specify different alt text, it will use the title for the alt text and does not output a title attribute by default. If you specify a different value for alt text, it will get used instead and is actually stored as post meta instead of post_title.

Helen, can I ask why that is, as it doesn't seem sensible to me.

That means you could end up with nonsense strings getting into the alt attribute - and thus to screen readers. If someone is not putting alternate text in they either don't understand what the field is for or they are purposefully leaving it blank. If then the title - which may be the default filename initially gets put into the alt I think that's not good.

#7 @grahamarmfield
4 years ago

  • Cc graham.armfield@… added

#8 in reply to: ↑ 6 @SergeyBiryukov
4 years ago

Replying to grahamarmfield:

If then the title - which may be the default filename initially gets put into the alt I think that's not good.

Related: #18984 (specifically ticket:18984:32).

#9 follow-ups: @helen
4 years ago

I don't really know the history behind why this behavior is in place. However, I would suggest shifting the thought process a little bit - we are using "title" in the UI not as the title attribute, but rather a human-friendly title that is used in a variety of places that doesn't actually include the title attribute. Since alt attributes are required (and for good reason), it makes sense to fall back to something that's likely to be populated. If somebody knows what alt text is for, they have the ability to make it different if so desired. I understand that it's potentially harmful to have less-than-awesome alt text, but I think in looking at the balance between adding complexity to the UI and making things "just work", the behavior makes sense to me. If a user can't be bothered to change the title, they're not going to specify the alt text, either.

#10 in reply to: ↑ 9 ; follow-up: @grahamarmfield
4 years ago

Replying to helen:

I don't really know the history behind why this behavior is in place. However, I would suggest shifting the thought process a little bit - we are using "title" in the UI not as the title attribute, but rather a human-friendly title that is used in a variety of places that doesn't actually include the title attribute.

I appreciate that now. Can I suggest therefore that we use a less ambiguous input field label - like 'Image name' perhaps.

This would remove the confusion at a stroke if this is the way that WordPress is to behave.

Since alt attributes are required (and for good reason), it makes sense to fall back to something that's likely to be populated.

It's the presence of the alt attribute that is important, but the contents of the alt attribute need to be appropriate. My current view is that it would be better to have an empty alt attribute (ignored by screen readers) than one with potentially meaningless text in it - example 'IMAG0015'. But that is just my view.

If somebody knows what alt text is for, they have the ability to make it different if so desired.

That's a key point Helen - the alt attribute is also useful where the image doesn't get downloaded, or people browse with images switched off.

Perhaps we need a small redesign of the user interface to clarify and to help the users. Maybe:

  • Call the Title field Image Name instead.
  • Have an Alternate Test field next that has some help attached to it (in the label or elsewhere?) that prompts the user to describe image for screen readers or if image doesn't show on page.
  • The caption field.
  • Remove description field altogether - what is it for?

#11 in reply to: ↑ 9 @SergeyBiryukov
4 years ago

Replying to helen:

Since alt attributes are required (and for good reason), it makes sense to fall back to something that's likely to be populated.

Perhaps we could only fall back to title if it's not the same as the file name?

#12 in reply to: ↑ 10 @sharonaustin
4 years ago

Replying to grahamarmfield:

Perhaps we need a small redesign of the user interface to clarify and to help the users. Maybe:

  • Call the Title field Image Name instead.
  • Have an Alternate Test field next that has some help attached to it (in the label or elsewhere?) that prompts the user to describe image for screen readers or if image doesn't show on page.
  • The caption field.
  • Remove description field altogether - what is it for?

From a sheer, user-interface standpoint, I think implementing these recommendations would go a LONG way to improving how users would implement the data associated with images.

I spent many a month trying to get the "Title" attribute to work in the context of our site for our screen-reader users; it was a long, long time before I realized that "Title" did not mean "HTML attribute". My coworkers had it worse; they went through multiple layers of confusion as to "which" title was the title in question, as they had no coding skills. I think changing the name from "title" to image name would be a simple fix that would go a long way towards eliminating much of the confusion (and frustration) associated with the use of the term.

I also agree, strongly, with some sort of "helper" text associated with alt tags. I think there is a real and true movement to try to accommodate accessibility issues, but a general lack of knowledge on what to do and how to do it. Helper text would be welcome to those trying to get on board with accessibility issues.

Note: See TracTickets for help on using tickets.