[META] Improve workflows for image alternative text

I also would recommend adding this feature as more and more we are advised that our images are decorative and hence should be left blank. Currently adding "" in the alt field returns alt="""".

Interesting proposal!

Note that this issue is against the image system component, not the editor.module component. #3 seems to be talking specifically about the "image dialog" in CKEditor. (And the "Currently …" bug remark needs its own issue with concrete steps to reproduce — please create that issue!)

I'm concerned about two aspects:

1. usability: this complicates the 99% scenario (non-decorative images) for the 1% scenario (decorative images)
2. accessibility: this makes it very easy, and very tempting to just click the checkbox to not have to enter alternative text

We carefully settled on the current pattern, at least in editor.module/CKEditor. See #2307647: [Follow-up] Allow manual override of required image alt text in the Text Editor image dialog when appropriate.

@Wim, I am referring to the image field provided by core. Many of our images are decorative and we need to leave it blank as is recommended by the standards, but we can't. So what is the solution in such cases? I highlighted adding "" in the alt field to point out that this will not work either, in case someone suggested it.

I'm not sure what other information you need, apart from providing editors an option to make an image as decorative and hence allowing them to save the page without entering anything in the alt field.

I've seen this same issue on several projects and I can understand the conundrum because I'm a staunch advocate for descriptive alt text. Having alt text on all images that require them is one of the most important aspects of the WCAG standards. However 1.1.1 Non-text Content clearly deals with decorative images as well as it doesn't want to clutter a screen reader user's experience with redundant images right next to links, icons, etc.

What about thinking of it in a different way, in that by "making" the content editor either A) add alt text to each image or B) check the decorative image checkbox, they are in fact accomplishing the "required alt text" feature in Drupal 8? I know...it's a difficult one.

-Kat

Keen to see this implemented which will help accessibility for images that is decorative.

Agree with @queenielow, I would love to see this implemented.

I think the comment

"this complicates the 99% scenario (non-decorative images) for the 1% scenario (decorative images)"

is inaccurate, many images have no purpose on a website other than decoration, and an empty alt tag if helpful in removing

"clutter a screen reader user's experience with redundant images right next to links, icons, etc."

as @katannashaw said.

I agree that this is an import feature for decorative images. Rather then having a checkbox, would it make sense to use some kind of token in the alt text field (e.g. <decorative>)? That way the required field is still receiving a value which is being outputed as a NULL alt property (i.e. alt="").

This could also somewhat address the previously raised issue of people getting lazy and just using the decorative checkbox to avoid entering alt text. If you have to still have to go through the effort of entering a value such as a token then perhaps you may be more likely to go the extra step and put in something more meaningful?

Perhaps we just need an option on the image field formatter, so we can choose at the field display level whether the alt text should be rendered or not. That means the decision is not left for editors to make on a per-image basis, which is potentially unreliable.

And then, if a particular field is never going to have its alt text rendered, you don't want to waste time collecting it... so we'd also want to have the option at the field level to decide whether the alt text is required.

Perhaps we just need an option on the image field formatter, so we can choose at the field display level whether the alt text should be rendered or not. That means the decision is not left for editors to make on a per-image basis, which is potentially unreliable.

This unfortunately would not be flexible enough. I imagine most sites are using the image field as part of the Image media bundle, which is a generic media type that can be used for any number of use cases for images. The decision on if an image is decorative or not must be made on a case-by-case basis.

I marked #3083994: Difficult for authors to embed image media with empty alt text. as related and #3056888: Allow double quotes for empty media alternative text as a dup of this one.

+1 to getting this resolved. I think having a "Decorative" checkbox beneath alt text with a simple explanation is the best approach. This would involve a new base field property for the image field and a db migration to add it.

Simpler of course is to interpret "" input as decorative but certainly a poorer user experience, especially on sites that may have many.

Well... Why not both 😅

I definitely see that there are times that it needs to be case by case.

But definitely there are scenarios when it's not case by case, every instance of that field will be decorative. Think background image fields or icons.

Perhaps something in the field config could determine whether or not a checkbox needs to show for every instance?

Moving this back to active since I think we have presented solid justification for this in core.

Updated title and issue summary.

I have many concerns about the direction of this issue (and some others like it). At the moment there are several open issues relating to the author tools for image text alternatives. There are too many issues trying different things, and I fear we'll end up with something messy. So I'd like to gather them up under a parent meta-plan, and take stock.

This issue has a wide ranging discussion already, and many participants, so let's make this one the parent plan. Some issues will end up being closed a duplicates or won't-fix. Thanks @bkosborne for finding some of them already.

I wholly agree that the current workflow(s) are frustrating for content editors, and it would be good to improve the authoring tools.

There's a recurring misunderstanding that Drupal images always require alt text. However this isn't actually true. The image FieldType configuration already provides a mechanism for making alt text optional. Comment #6 here is a good example:

What about thinking of it in a different way, in that by "making" the content editor either A) add alt text to each image or B) check the decorative image checkbox, they are in fact accomplishing the "required alt text" feature in Drupal 8? I know...it's a difficult one.

That's a flawed semantic dodge, in my view. Required means required. What you're actually describing here is a workflow for "optional alt text".

I often wonder if the Article content type in the Standard installation profile contributes to this misunderstanding. It's likely the first image field new Drupal users encounter. That image field doesn't have a very well defined purpose, and I think it's reasonable to put a decorative image there. Yet, the alt text is required. Compare this to other image field uses, which have a stricter purpose (e.g. a product with "T-shirt rear design" field, where alt text would be mandatory.)

Whatever approach we take, we must not undermine the content model of existing websites. Various proposals and patches have overlooked this, and provide a means of evading the constraints already put in place by site builders.

• Beware of conflating a site's content model (information architecture) with with the underlying database storage schema. A pair of quote marks (or some other token) might satisfy a MySQL NOT NULL constraint, but it doesn't satisfy the "alt text required" intent of the image FieldType settings. We see this mistake in Comment #9 here, and also in #3056888: Allow double quotes for empty media alternative text.
• The text-or-checkbox proposal here, if implemented carelessly, could also jeapordize the content model of existing sites. I'm not totally against this UI, but it isn't suitable for an imagefield which is configured as "alt text required".

Drupal can handle images in several ways: image fields (and media entity references) are structured content models, while CKEditor images are unstructured. One approach won't necessarily be suit both of these. Elsewhere there are issues which explore overriding media alt text on a per-reference basis.

I don't think we need to mess with the image FieldType settings. It already has a mechanism to allow optional alt text. I'm skeptical about the need to record an explicit decorative intent in a new base field. Leaving the alt text empty would suffice for that.

Fortunately, Drupal already decouples the content model (FieldType plugins) from the author UI (FieldWidget plugins). We can experiment with alternative widgets, without risking the content model of existing sites.

• A sandbox contrib project would be a good place to do this; depending on the outcome, such widget plugins could be brought into core, or promoted to full contrib projects.
• There's a really useful WidgetInterface::isApplicable() method we can use, to say a particular widget can (or can't) be used, depending on how the field is configured. We could create a text-and-checkbox widget, which can only be used on image fields which are configured for optional alt text.

I think the double-quote method is convoluted and inelegant. It amounts to a special Konami code, for editors who are in the know. Rather than adopt it for image fields, I'd prefer to see it removed from the CKEditor images dialog, and instead improve the help text in the dialog.

The textfield-and-checkbox UI seems popular, though I'm not a fan of it myself. I dislike the binary nature of it, because it doesn't reflect the many uses of images: essential, supplementary, informational, illustrative, ambience, mood-setting, decorative, and so on.

However, we could certainly build a text-and-checkbox FieldWidget plugin.

I also share @Begun's concern in #9 that the checkbox amounts to lazy shortcut. Worse, it encourages authors to mark images as decorative, when in fact they warrant a text alternative. I've had lots of conversations with authors who insist an image is "merely decorative, blind people don't need it"... until you ask them why they chose that particular image. Having said that, a non-required text field on it's own is no better or worse.

I do think there's an element of "let's copy Wordpress!" here, but ultimately, this won't be solved with configuration or cool UI widgets. Take @bajah1701's situation in comment #3...

more and more we are advised that our images are decorative and hence should be left blank

This is indeed a common problem, and making the alt text optional will solve it. But don't be surprised if your next accessibility review says there are too many images with missing alt text; you can trade one problem for another. A double-quote placeholder code or decorative checkbox are no substitute for accessibility training, and diligence.

@amoebanath's suggestion in #11 for a setting on the image field formatter is worth exploring. I can imagine valid uses for it, as part of a teaser view mode. It's a site-builder tool though, and won't help editors. To me it sounds more suitable as a contrib module.

Various other things we can could consider...

• Relax the settings for the Article image in Standard profile, to make alt text optional. This field has a very broad use case, so allow decorative images.
• Add the ability to display warning messages to editors, on all content entities where alt text is missing.
• Use different help text depending on whether an image field alt text is configured as optional or required
• Allow custom help text per image field
• Add more example use-cases in our handbook pages about when to use required vs. optional alt text.
• Make use of the new help topics module (when stable)
• Add recipes in the handbook for "needs text alternative" workflows, e.g. using content moderation module, or an admin-only taxonomy.

EDIT: I deleted this comment, I was contradicting myself :-)

Thanks for providing that great summary and outlining the various challenges.

It seems you're suggesting approaches that don't mess with the existing field plugin at all ... But without updates to the field plugin to support a boolean value for decorative or non-decorative, how is the field display plugin going to know to output alt="" vs no alt attribute at all?

We can create a new field widget plugin with a checkbox for decorative, but what does that really do when checked? It has to control something.

Short of controlling a boolean switch, it could force a value of "[decorative]" for the alt text and use that as a special value. The display plugin would then look for that special value and force output to be alt=""

how is the field display plugin going to know to output alt="" vs no alt attribute at all?

It doesn't need to know that. It should ALWAYS output an alt attribute, othereise it's not valid HTML

We can create a new field widget plugin with a checkbox for decorative, but what does that really do when checked? It has to control something.

It only affects validation when submitting the entity. It doesn't have to store anything new, or read anything new.

The widget validation would assert that altvtext is proveded, or the box is checked. If neither, it sets a form error. If both, it sets a form error.

If alt text is provided, it saves that just like it currently does.

If the user doesn't enter alt text, but ticks the box, it saves an empty string in the alt column, just as it cureently does. I don't think it needs a special value.

The formatter doesn't need any new information. It just reads the alt column. Empty means decorative image. It always has.

Ah, I was mistaken. I was thinking that if alt text was optional, and it was left blank, then not alt attribute was output at all. Instead, it gets stored as an empty string in the database and alt="" is output which is great.

Now that I have that cleared up, I agree that this can be resolved with an updated widget alone.

how is the field display plugin going to know to output alt="" vs no alt attribute at all?

It doesn't need to know that. It should ALWAYS output an alt attribute, othereise it's not valid HTML

I disagree. For allowing good accessibility and for adhering to the HTML spec, three cases are needed:

• {1} alt attribute with non-empty value
• {2} alt attribute with empty value
• {3} no alt attribute

While case {3} can be made conforming with specific use of the title attribute or the figure element (see § 4.8.4.4.11: "Images whose contents are not known"), it’s also important to allow this case even if the resulting HTML will become non-comforming.

This is intended, because it would be wrong (per the HTML spec) and misleading (for accessibility) to output an alt attribute with an empty value if the image is not decorative/redundant.

In other words: authors need to make a conscious decision to output an empty value for the alt attribute (because the image is decorative/redundant); it should not be the default fallback if no value is provided.

So, from a UX perspective, authors need three options:

• "I know that the image needs an alt value, and I can provide it." → {1}
• "I know that the image doesn’t need an alt value (because it’s decorative or redundant)." → {2}
• "I don’t know, or I can’t provide one." → {3}

Updated issue summary now that I have a better understanding.

It should be noted that the only way to have core omit the alt attribute completely is for a module or theme to set the alt value to NULL. Core sets it to an empty string if nothing is provided.

I think the case presented in #21 is an extreme edge case that probably should not be handled by core.

I've created a new contrib module Decorative Image Widget. It adds that checkbox to indicate that the image is decorative and allows users to bypass entering alt text.

Just to chime in, the module that adds the checkbox for decorative images is great!
but if I understand it correctly, when you use media library and you reuse images, it can present a problem I think?

The same image can be decorative in one place, but functional in another, and you don't want to upload two of the same images, one with, and the other without an alt text.

We instruct our users to always fill in the ALT text (it's required), and let our theme decide if the image is decorative (think of "teaser tiles" etc).

A proper way for themers to have a template suggestion to easily override certain images in certain fields would solve a lot of problems. I'm actually looking for a proper solution using responsive images now.

Indeed - this solution is really only appropriate if images in your library are only used in one place

To clarify, is having "empty" alt text (hitting the space bar in the required alt text field) rather than NULL alt text an acceptable workaround? According to this Drupal 7 documentation it sounds like it is.

https://www.drupal.org/docs/7/creating-accessible-themes/managing-images...

I should have tested this first. I see now that Drupal 8 and up gives an error when an author tries to enter a blank space.

Alternative text is required.
(Only in rare cases should this be left empty. To create empty alternative text, enter "" — two double quotes without any content).

Summarizing the easy fix from other variations & a long analysis in #3230231: image field alt help/description should distinguish between decorative & meaningful images :
Prepend 3 words: "For meaningful images," to "Short description of the image used by screen readers and displayed when the image is not loaded."

Adding related content from the We4Authors Cluster process - https://accessibilitycluster.com/main-results/text-alternative-feature-%...

Using Decorative Image Widget mentioned above with the wonderful Media Library Media Modify is pretty close to ideal. The latter module provides a "Media with contextual modifications" reference field which lets aspects of the media object be overridden from the content context where it is used. This includes the alt text and the "This image is decorative and should be hidden from screen readers" checkbox!

Note that Decorative Image Widget, if both the Decorative checkbox is checked AND there is alt text, will behave as if the checkbox was not checked— it will save as alt text. So to use an image from your media library that has an image description as a decorative image, you need to blank out the alt text and check the Decorative checkbox. But the alt text lives on in the media library, and will be available if you re-use that image!