Having alt and title information as a part of the image field itself is a conceptual failure. Alt and title information is related to display, hence they should be options in a field formatter. Ideally we get support for fields that can be attached to files which can provide per-file metadata like alt and title, which the formatter can the specify the alt text should be [file:field_alt_text] or the title should be [file:field_title].

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

quicksketch’s picture

Ideally we get support for fields that can be attached to files which can provide per-file metadata like alt and title, which the formatter can the specify the alt text should be [file:field_alt_text] or the title should be [file:field_title].

I'm all for this, but it sounds like a situation that is almost certainly going to add confusion to the configuration of Image fields. I always said that having alt and title as part of the same field made sense because it was all generating a single HTML element:

<img src="http://example.com/files/sample.png" alt="Alt text" title="Title text" />

Because things like Link URL (if you wanted the image linked) or Caption were not part of the HTML tag, they were not available in the same field and therefor not a part of Image field. Those sorts of things make sense as separate fields.

Everett Zufelt’s picture

Interesting, and I definitely need to give this more thought.

My initial thought is that "alt" (alternative), is definitely part of the image. It is not meta data, but the replacement value for the image when it is not available. That being said, this is handled on the display level.

On the other hand, the alt attribute for an image is * not * meant to be a description of an image. The alt attribute is a textual replacement, based on the context of usage, and therefore it really needs to be decoupled from the image itself (likely not possible in our use-cases).

Users should be able to upload, store, re-use images. However, alt should not be re-used, unless the user chooses this intentionally.

An image of a cat, in a family newsletter, could be "Our new cat fluffy.". The same image, used in a child's school report about animals, may just be "A cat.". This might not be the clearest example, but I hope that it drives home the point that alt should be determined based on context, and is not the same as the image itself.

Everett Zufelt’s picture

Issue tags: +Accessibility
dqd’s picture

I agree with Everett Zufelt. That's what I sad over here http://drupal.org/node/1343022. I don't think that having stuck these attributes only once and tight to the image would be the best decision, because from there, you can't use the images with other alt="" and title="" values no more again. What wouldn't be a good idea, because these image attributes often also rather depend on other relations than the image itself, like the topic they are used in, for example, or when placed in a node-inline-gallery with a series of depending alt values. I actually didn't saw a big problem on how it was solved in D7 image module, because when I upload an image by creating a node, I certainly would like to enter the contextual alt and title attribute data in the same time there. That it isn't actually really DRY, would be the only point where I can think of optimization from my point. I don't know what other problem should be discussed maybe, because I didn't took any deeper look onto database design or other spots here.

I had a longer chat with DaveReid on IRC yesterday about it and we agreed, that it isn't that simple to decide than it may appears from the first look. Since we actually are discussing entities these days, not nodes and content types holding image fields (or any other file) no more, it should be common for all conceptual decisions to think of node entities and file entities on the same level instead of images nested in nodes as fields. And from this point, we should try to look at this both attributes and think from there, where is the best to implement them.

The awesome field injector module from DaveReid (which saved my day on another issue) inspired me thinking about the option to inject any text field from the node as alt="" or title="" for any use case like images, links and files. This would be really DRY, flexible, and would be rather stuck on the node entity id than on the file entity id. A decision which I would prefer.

I am not scared to provide patches, even for big contrib packages like media, or for a field which can be injected as attribute like single-line text-fields. But before that, we need a decision.

kmadel’s picture

What about the use case where you have a multi-valued Media field (multiple File entities) on a Node entity (content type) and you would like to have a unique title attribute value for the current node only and that the values would different for each File entity item?

An example may be a gallery of pictures that represents different steps in a recipe. Each picture would have a title attribute for a certain step and would possibly be unique to that particular recipe node. Creating a set of text fields that would be injected for each File entity associated to the multi-valued Media field would become fairly clumsy to work with, or am I missing the point?

It seems like, in the case of the Media module, an advanced Media field widget is needed that would allow:

  1. Free-form, node specific tittle and alt attribute values - that would be stored on a node by node basis via the field api - nice for a multi-valued Media field
  2. The ability to specify another field on the same node to use as the title and/or alt values; could get a little bit unwieldy with a multi-valued Media field
  3. The ability to use token based values for the title and alt attributes, would only set once in this case and my be different across a mutli-valued Media field depending on what tokens were selected

And I am sure there may be other scenarios.

Dave Reid’s picture

You will have this same problem if you had a node reference field on two different items, wanted to reference the same node, but have a different title for each one. You can't do that. I would like us to work on a solution that would work for all entity reference fields, not just specific ones.

kmadel’s picture

Then it seems a good approach would be built on something like the Relation module. Giving us the ability to have field able relationships. So, don't use the Media field, or the node or user reference field. If you need to relate another entity to another entity (the same or different) create a Relation with whatever field(s) may be unique to the given relationship.

Dave Reid’s picture

torotil’s picture

@kmadel: using the relation module just to insert alt and title attributes for images seems pretty much like overkill. Instead of a field that has a 1:1 relation to a file we're getting a relation which has a 1:1 to an entity which has a two 1:n relations to the text fields holding the attributes.
Such a complex data structure may be the way to go for for user_references/node_references in the rare cases where it's needed, but not for alt and title attributes for images which are (and should be) the common case.

ericclaeren’s picture

A good approach seems to me, that the alt and title is the same for every image file, since the description of the image stays the same but can be overridden per entity if needed. In this way, there's always an fallback and the freedom to overwrite it on specific places where you need it for SEO. Or does this sounds stupid?

stephen Piscura’s picture

dreamlabs,

I wholly agree the idea of adding default data to each file with the option to override wherever needed.

mgifford’s picture

One of the challenges of using tokens here is that it may indeed encourage sloppy behaviour.

There are lots of tools that simply insert the file name if no alt text is provided for instance. That's bad for accessibility & usability as it really provides nothing useful for the visitor. Often a useless, random distraction.

Likewise, if the token were based on the title of the node or the author, would it do more than duplicate the content which is already being displayed to the page?

How will tokens get us to provide more meaning to our non-text media?
http://www.gawds.org/show.php?contentid=28
http://www.ssa.gov/accessibility/bpl/default.htm?category=images

John Pitcairn’s picture

Agree with dreamlabs - I wouldn't want a requirement that alt/title be added per-use. I can see many situations where authors can't be trusted to do a halfway decent job (of the alt attribute in particular), so editors may want to just set those globally, once. I can see a need for any option to override to be controlled by a corresponding permission...

RobW’s picture

Alt and title should absolutely be attached per display instance / context, but I can see file name or file entity title being a reasonable safety net for careless content editors. Maybe as a pseudo placeholder text to encourage users to enter something more descriptive.

Everett Zufelt’s picture

Agreed that alt and title are contextual, and should be at the field instance.

John Pitcairn’s picture

@RobW:

I can see file name or file entity title being a reasonable safety net for careless content editors. Maybe as a pseudo placeholder text to encourage users to enter something more descriptive.

Haha, you haven't met my editors. If there's a "reasonable" (on their terms) default supplied in a field, they won't bother to change it, and it will validate if the field is required.

RobW’s picture

@John: Well I started my post ranting about how client laziness isn't the CMS's responsibility to fix, but then thought I'd tone it down and try to see it from both sides. I'm in favor of no default alt text, and requiring users to input their own on a case by case basis.

But I might try file entity title as an actual HTML5 input placeholder on a client project, see how it turns out.

tsvenson’s picture

Hopefully there wont be a dedicated image field in Drupal 8. Especially if the File Entity module makes it into core.

Anyways, we had a little Media Initiative sprint in Gothenburg last Sunday and we came up with a very nice solution for solving the alt/title (and name as well) issue for files. Including a first patch too. See #1553094: Alt and Title support for Images for more about that.

Do note that the patch does not contain the whole solution. We plan to have an out-of-the-box solution once #1292382: Make it possible to create any number of custom File Types is finished. That solution will automatically detect when the file is an image and thus be able to then display the alt field in the form, and optionally also the title field.

leenwebb’s picture

Good alt tags are good for accessibility! Beyond that this is not so much a core accessibility issue as a we'll-review-it-when-it's-ready issue.

(via Montreal Accessibility Sprint)

mgifford’s picture

Issue summary: View changes

This has been quiet for 2 years. Might need to be bumped to D9. However, just looking at D8 now. There's a token available to protect an image style derivative, seems odd that there wouldn't be one for alt & title.

I assume that the token for the image is generated in core/modules/image/lib/Drupal/image/Entity/ImageStyle.php but couldn't find it easily. Any ideas?

mgifford’s picture

Version: 8.x-dev » 9.x-dev
Issue tags: -Needs accessibility review +Accessibility

Bumping this to D9 and moving it to accessibility rather than needs accessibility review.

This would be a big plus to make it easier to add alt text.

dqd’s picture

*unsubscribe* -- in favour of file_entity ...

catch’s picture

Version: 9.x-dev » 8.1.x-dev
Status: Active » Postponed
Dave Reid’s picture

Issue tags: +D8Media
mgifford’s picture

Status: Postponed » Active

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

nsputnik’s picture

Bump. I would appreciate some sort of solution to this. I seems unbelievable that there is not one after 5 years. I don't care if it is on a per file or per node context case.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

geek-merlin’s picture

mgifford’s picture

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Peter Törnstrand’s picture

I did a solution for this that fits my use case (Drupal 8). If anybody is interested I made the module available as sandbox module, https://www.drupal.org/sandbox/blixxxa/2916732

From the description:

Enhanced version of the Drupal\image\Plugin\Field\FieldFormatter\ImageFormatter with support for tokenized Alt, Title and Custom link fields.

demonde’s picture

@Peter Törnstrand: Works also very nice for core media module if you rename the dependency.

This exactly solves this comments request:

https://www.drupal.org/project/media_entity_image/issues/2850169#comment...

Works also in conjunction with inline field formatter:

https://www.drupal.org/project/field_formatter

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

amaisano’s picture

#33 (the sandbox module) does not work with core Media (8.5.x) + Entity Embed 8.x. There is still no ability to add ALT text during the embed (see image).

no alt option

Note that adding a FILE media type does allow title, alt and other meta fields during embed - straight out of the box w/o patches or additional modules. But an IMAGE media type embed gives us zero options, besides which File Bundle View Mode to choose.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

preksha’s picture

Agree as per the comment in #36. It doesn't allow any alt and title text during embed. so can't use Media with entity embed for accessibility reason.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

mgifford’s picture

Issue tags: +atag

I think this will tie into ATAG 2.0. But largely just bumping this issue to see if there is still value in the concept.

John Pitcairn’s picture

Still valid IMO.

We use a "default" alt, title and caption entered at upload, with a custom override option available when using the media. Implemented via various horrible hacks over the years ;-)

It would be great to be able to handle this using core media embed and field widgets.