Alt text & captions on placed images

I’m having trouble with alt text and captions on images inserted on pages, and wondering whether any customisation or adjustment of this is possible. The various combinations are complicated, so I hope that what I’m about to say will be clear.

Let’s start with an image already installed in the same group as the page, which has no alt text or caption added when opened in the group’s image list (I’ll call this the source image).

Note that editing the source image metadata is the only way alt text can be added, therefore all uses of that image on various pages and dynamic content would have the same alt text, which may or may not be desired. I understand that there could be an argument to say that the alt text should always just be a flat description of what is in the image, but in different contexts, different things might be emphasised for an optimal alt text.

Cases (I tried all of these for completeness, but if just want the conclusions, skip down to the summary)

When inserting the image on the page, we need to have an alt text or caption, or need to mark the image as decorative. Since our current source image has no alt text already, and we cannot specify alt text in the ‘Add image’ dialogue, we have to either add a caption, or mark as decorative.

  • Although we will mostly not be marking images as decorative, for completeness, we’ll try that option first. In that case, the tag that results will have alt=“”, as expected, and data-decoration=“true”, and will not have a data-caption attribute.

  • Now, if we place the same image but this time give it a caption, and do not check the decorative box, the tag will have alt=“”, and a data-caption attribute with the caption as it’s value.

Those are the only possibilities available, and no way to get alt text on the image, which is unfortunate.

Next, let’s add some alt text to the source image metadata.

  • we can insert the source image as is, without adding anything, since the it already has alt text. The tag will have the alt text from the source image as expected but we cannot have a special alt text for this placement of the image.

  • now if we insert the image and add a caption, the tag will have the alt text in the source image as expected, as well as a data-caption attribute with the caption we entered when we place the image. This is as expected but again we cannot have a special alt text if desired.

Next, let’s go back to the source image and take away the alt text but add a caption there.

  • when we select the image to place on the page, it begins with the source caption already filled in the caption field of the ‘Add image’ dialogue, and if we just save it, the tag has alt text which is the caption text from the source and a data-caption attribute which also has the source caption as its value.

  • now, if we insert the same image and give it a new caption, the preview in page edit starts out broken, but upon saving the page, the tag has the caption of the source image as its alt text and a data-caption attribute with the new caption entered as its value.

Finally, let’s give the source image both alt text and a caption.

  • if we insert the image without changes, we get what we expect - the tag has the alt text and data-captions values from the source image.

  • if we insert the image and add a new caption, we get what we have come to expect - the tag will have the alt text from the source image and a data-caption attribute with the caption as entered when the image was place.

Summary

The behavior observed seems to be well-thought-out and consistently implemented, with one exception in my opinion (#2 below), but I am unhappy with it. It optimistically seems to be based on the idea that the source images will have good alt text entries, and perhaps good captions. In our experience most images imported into the group’s image list have neither.

The results of the testing are that alt text on placed images is entirely dependent on what is in the source image metadata, and cannot be changed:

  1. if the source has no alt and no caption, the placed image will have no alt text, whether it is has a caption or not, even if it is not marked as decorative.
  2. If the source has no alt text but does have a caption, that caption will always appear as alt text in the placed image.
  3. if the source has both an alt and a caption, the placed image will have the source image alt but the caption can be overriden in the ‘Add image’ dialogue.
  4. in all cases, if the image is marked as decorative it will have no alt text, as expected, although it may have a caption.

My unhappiness stems mostly from the fact that the alt text cannot be specified when the image is placed. Case #1 above can result in an accessibility failure, and case #2 may result in undesireable situations - someone changing the source caption to fit their situation may cause an inappropriate alt text somewhere else where the same source image is used.

Wishes

My wishes would be that there is an alt text field in the ’Add image’ dialogue, that the source caption is never used as alt text, and that if there is no alt text in either the source image or the ‘Add image’ dialogue that the ‘Add image’ caption field would be used as the alt text for the placed image. If all three - source image alt text, Add image alt text and Add image caption are blank it would be required to add one of the two in the ‘Add image’ dialogue before the image could be placed.

Finally there is one other thing that I haven’t mentioned yet - in all the cases the name field of the source image metadata is always given as the value of a ‘title’ tag in the placed tag. These values appear when the cursor is hovered over the image. I wish there was a way to turn this off. Most of the image titles in our CMS are rubbish - usually the name of the disk file that was uploaded and people don’t bother to change that to a good title. Having bad filenames pop up when people hover over an image just makes us look lame.

So finally, is there any way for us to customise this behavior in any way, or a template that we could edit? I’m afraid this is probably all in core code as the templates in /_i don’t seem to relate. If not, please consider the addition of alt to ‘Add image’ along with the suggested behavioral changes a feature request.

If these changes are not doable, at bare minimum I think we should require uploaded images to have alt text, irrespective of whether a caption is provided…

Thanks for reading this far…

2 Likes

@gccervone, were you reading my mind? You just summed up a lot of what I have been thinking about lately, too. I wanted to comment on a few of your specific points:

I was just saying this the other day. Images could require different ALT text in different contexts.

This one surprised me, and I had to test it myself to believe it. I was under the impression that, in the absence of ALT text, anything in the caption field would be used for that purpose. The fact that is leaves alt="" is, I suspect, a bug.

I second this. I would like the Add Image dialog to display the ALT text from the source image, but allow it to be edited. Caption would never be used as ALT, and would only be relevant if the user checks the box to “display caption under image”.

Agreed x100! Our image names are never relevant to visitors, and I agree that it “just makes us look lame”.

To sum up what I would like to see:

  • Uploaded images should require ALT text or that “decoration only” is checked
  • ALT text should be editable from the Add Image dialog (even if the source image was marked as decoration)
  • Separate the “decoration only” checkbox from the caption field in the Add Image dialog, as the two should not be related.
  • The “decoration only” checkbox should be paired with the ALT field as requested in the second bullet point.
  • A caption field should only appear if “display caption under image” is checked. This would display a caption from the source image if it exists, but be editable regardless.
  • Stop displaying image names as the title. Maybe never add a title, period.

I suspect there are some issues with supporting legacy behavior (from before LiveWhale had an ALT field, and captions were always used). But what better time than a pending major version release to break backwards compatibility on something like this? :wink:

2 Likes

@jwilcox - you’ve added some nice refinements to my wish list and I agree with all of it!

:memo: :memo: :memo: Noting! Thanks you two!

Hi guys!

Thank you @gccervone for your careful review and presentation. That is a @jwilcox-level attention to detail. Thanks to both of you!

As Jon notes, incorporating those ALT features into LW when there were already millions of images on LW servers took a lot of care and thought, mostly to support a variety of backwards compatibility use cases. We’ll definitely look at streamlining this in 3.0.

Jason

1 Like