Add "Image Title Attribute" as an editable attribute on the image block

[brentswisher]

Description

Closes #11054.

Adds a title attribute to the image block, as requestions in #11054, although I think there may be some more discussion needed, I will follow up there.

How has this been tested?

Add a new image block to the page either via dropping a file of the media library
Open the settings for that block.
See that there is now a "title" attribute that is defaulted to the current title attribute in the media library
Save and view post, see that the title attribute exists on the image unless it was set to blank.

Screenshots

Types of changes

New feature (non-breaking change which adds functionality)

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[jasmussen]

This seems okay to me. We might want to put the Title text below the Image size tools, as those seem more important, but I can understand how there's an argument to keep it close to the Alt text too. This, and the fact that the sidebar is getting crowded, would be the only design considerations we need to think about. Once that's settled, it'd be nice with shorter copy for the help text — how short can we make it?

I would suggest the acessibility feedback is more important. I know that in some cases, the Title attribute can be detrimental, but would appreciate thoughts from others.

[youknowriad]

Seeing all the help texts makes me wonder if we shouldn't leverage a ⓘ icon for them. I feel the usability of the UI is starting to suffer from all these texts.

[jasmussen]

Seeing all the help texts makes me wonder if we shouldn't leverage a ⓘ icon for them. I feel the usability of the UI is starting to suffer from all these texts.

I personally am of the opinion that we should work to retire that icon entirely. I think an in between step is to merge it with the block traversal button so at least those two are one — but the more buttons we can remove from the left hand side of the top toolbar, IMO, the better.

I feel like the sidebar is the right place for it. You can toggle the sidebar off for a simple basic experience, and anything you put in the sidebar should be stuff that is advanced. The tools we have at our disposal to simplify here is to reduce text as much as is possible, simplify labels as much as possible, only add help text when it's actually necessary, and group items in panels.

[youknowriad]

@jasmussen What I meant is that instead of having help text display under each input, we'd display a ⓘ icon or similar next to the label.

[youknowriad]

Definitely something out of scope of this PR though.

[jasmussen]

Doh, sorry I thought you meant the Outline button in the top toolbar.

I don't know that adding an icon with help text would reduce that much more — but I think we can go a long way in simply reducing labels and help texts to as concise text as possible. Of course the meaning has to be conveyed, but nearly always there's a shorter phrasing.

[brentswisher]

Thanks for the feedback @jasmussen and @youknowriad. I'll bring this code up to date so it can be reviewed/merged, in the meantime, any thoughts on the concern I brought up about the default titles in my comment:

2. Since the default title is set to the file name, I am concerned that adding it here will result in a lot more titles being saved into the page's content with the default (ie: IMG_2323),

Specifically, I'm wondering about images "inheriting" defaulted titles that match their filename.
I know on my sites, that would mean a lot of images get title attributes like "IMG0024.jpg" without me really doing anything.

The only alternative I could think of would be a toggle for if the title should be displayed that is defaulted to off? Then at least the user could see the title they are adding and it's more opt-in than opt-out. The obvious trade-off being adding complexity to an already full UI.

[youknowriad]

@brentswisher I'm having trouble understanding (by reading the code) where this default title is being added. I'm assuming by default it should be undefined.

[brentswisher]

Sorry, should have made that more clear. When an image is uploaded, the media uploader sets the title attribute of that image to be the file name. This is an existing procedure for every image, so when I grab the image attributes in the block, that comes in as the title.

This is the line:
const imageProps = pick( image, [ 'alt', 'title', 'id', 'link', 'caption' ] );

Maybe that's fine and it's obvious enough that is a user wants to change it they will. My worry is that the majority of users might not notice it or understand what is does and we will populate the internet with pointless title attributes.

I'm open to leaving it as is if others think it's okay, just wanted to at least make sure it was a conscious decision.

[youknowriad]

What if we remove the "title" from this pick call? What downsides will we create? Why this "title" property was there for the first time?

[brentswisher]

I was thinking the problem would be that two different attributes for an image both called title seemed confusing. However, in looking at the classic editor it looks like this is exactly what's happening. There is a title for the media item which serves as its name. There is also an "image title attribute" that adds a title to the actual HTML output. I say we follow that example, I'll work on updating.

[mapk]

To help the help text 😉 , maybe we can change it to say something like this:

"Provide a clear name for this image."

I'm also concerned that the title's default being the image name could cause some weirdness as pointed out by @brentswisher above.

[brentswisher]

I worked on this some more and not defaulting the title was quite confusing to me. There were two things called title for an image. One which was edited in the media modal and one which was in the block, but were unrelated to each other. I expected them to act the same as the alt attribute when uploading or replacing an image.

What about a toggle? This way we can keep it with only one title, but make sure it is intended to be displayed?

Something like this (Copy/design is rough, just a proof of concept)

[brentswisher]

I've updated the help text to be a link as suggested by @afercia and the text to "Provide an optional description for this image." @mapk "optional, non-essential" seemed a little repetitive without adding any additional information, but if there are strong feelings it should be that I'm not opposed to updating. Love to get this wrapped up and merged if everyone is good with it?

[afercia]

@brentswisher thanks for the ping! Maybe it's a language thing (not an native English speaker here) but as a user, if the whole sentence is linked:

[link]Provide an optional description for this image.[/link]

I would expect the link to point to a resource that explains what an optional description is. Instead, we'd want the message to inform users they shouldn't rely on the title attribute for important information.

Today, title attributes are only available to a minority of users. I'd tend to think we can contribute to the progress of the Web as a whole if we strive a bit to find some better wording :)

Also, the part: description for this image is not 100% accurate because this is about the purpose of the image, not necessarily the image content (same as for the alt attribute).

What about something along the lines of:

Optional description. [link]Consider to not rely on the title attribute for important information.[/link]

(I'm trying to avoid don't and negative sentences)

/Cc @mapk

[brentswisher]

@afercia Yes, I like it not all being a link better, I reworded the second part a little bit:

[michelleweber]

I find it a little odd to only include language about how not to use this field, and no language about what the field actually is. Am thinking of something along the lines of:

Describe the role of this image on the page. (Note: many devices and browsers do not display this text.)

This explains what it is, and by explaining that it's not always used the "don't put key info here" idea is strongly implied.

[afercia]

I'd tend to agree, see my previous comment where I was trying to avoid negative sentences.

[brentswisher]

Happy to update that, would it all be the link text, or just a part of it @michelleweber?

[mapk]

Let's try @michelleweber's idea there. It's worded pretty good!

[michelleweber]

I'd only link the second sentence.

[brentswisher]

Updated to the latest text:

[mapk]

One more suggestion from:

Note: many devices and browsers do not display this text.

to:

Note: this text is not always displayed.

or simpler:

Not always displayed.

I think the link defines the reasons about devices, etc.

[michelleweber]

My two cents -- whenever possible, text should make sense and answer people's questions as much as possible without requiring them to click on a link. In this case, "Not always displayed" doesn't answer questions, it raises them -- why? when? where? -- and that requires clicking. (You could lighten the line visually by only linking "do not display" instead of the whole sentence, tho.)

(I know the longer version doesn't answer every question either, but it does clarify that if its not displayed, it's because of the browser or device and not because your website/something you did.)

[mapk]

In this case, "Not always displayed" doesn't answer questions, it raises them -- why? when? where? -- and that requires clicking.

This is fair, but for what it's worth, "Many devices and browsers do not display this text." probably raises the same questions too.

I'm good either way here. I'd love it if there was a way to trim it down, but not opposed to longer text if it helps the user.

[brentswisher]

This has been held up for quite a while with differing opinions on text, but nobody seems strongly opposed to what is there now. Am I reading that correctly? If so feel free to speak up, otherwise, I am going to try to get this moving forward as is.

[brentswisher]

This PR has been going on for a while so a summary may be in order:

• This PR adds a field for "Image Title Attribute" to the Advanced options of the image block.
• This is different from the "Attachment Title" which is never displayed publicly.
• This lines up with how the classic editor handles the title attribute (which is currently unavailable in Gutenberg)
• While adding this to add compatibility to the classic editor, help text and a link to the w3c page explaining that it should not be used for critical information was added as title has historically been abused for accessibility purposes.

[mkaz]

The code change looks good, however I think the extra text and link is confusing. Especially since we have almost the same text above in the Alt Text field above it. It is hard as a user to parse and figure out what I'm supposed to do. See this screenshot.

This is what the fields look like in the Media Uploader, and there is no extra contextual info around title there.

I thinking remove the extra text around the Title field will make it easier for the user, also gets the feature in so the users can set the title which is an accessibility win. We can solve the contextual help by addressing @youknowriad comment about using a (i) icon in a separate isuse.