backdrop-issues icon indicating copy to clipboard operation
backdrop-issues copied to clipboard

[D7] Add alt and title fields for the image file type?

Open jenlampton opened this issue 5 years ago • 28 comments

This is a follow-up to https://github.com/backdrop/backdrop-issues/issues/2632.

In Drupal 7's file entity module, there were Alt and Title fields added to the image file type, but these were never closely integrated. Should we add them back, for feature parity with D7?

(Anyone upgrading from Drupal 7 will have their old fields upgraded, so the question here is only about new installs of Backdrop.)

If so, we should integrate these fields more closely with the Alt and Title fields on Image fields, or in the Rich Text Editor.

Agreed functional specification is detailed here: https://github.com/backdrop/backdrop-issues/issues/4007#issuecomment-1302475861

Here is an attempt to summarise the agreed approach; this is from the user perspective and does not determine any technical direction (added here on request from @jenlampton :

1. Image added to site via node edit

As a site editor I want to add an image globally when I add to a node So that my workflow for adding images is the same as now

AC1.1 Given that I have added an image to a node And I have added alt text and/or a title to the image When I view the image under 'Manage Files' Then I can see the alt text and/or title that I added at the node

AC1.2 Given that I have added a new image via node edit When I edit that node in future Then the checkbox "Use default alt and title text" is checked and the text fields are disabled.

2. Image added to site via manage files

As a site editor or site architect I want to add some images globally from the manage files dialog and add alt text and/or titles at this location So that I can add common images that can be used by multiple editors and have them use consistent text

AC2.1 Given that I am adding an image from Manage Files > Add a file When I've uploaded the image Then I am presented with Alt text and title fields

AC2.2 Given that I have added an image with alt and title text at Manage Files > Add a file When I view the image in the files listing and click on it to view the record Then I can also see the alt and title fields

3. Reusing an image on another node

As a site editor I want to be able to reuse the alt and title image from an existing image and be able to override the text if necessary So that I can save time when re-using an image and ensure consistent text where necessary.

AC3.1 Given that I have selected to add an image from the library When the library opens Then I can choose to search using the alt text and/or image title

AC3.2 Given that I have selected an image from the library When I return to the node screen Then I am presented with:

  • A checked checkbox with the label "Use default alt and title text"
  • The text box for alt text should be populated with the default alt text and should be disabled
  • The text box for image title should be populated with the default image title and should be disabled

AC3.3 Given that I have selected an image from the library And returned to the node screen And chosen not to override the default alt and title text When I save the node Then the image is presented with the default alt and title text

AC3.4 Given that I have selected an image from the library And returned to the node screen When I uncheck the "Use default alt and title text" checkbox Then the alt text and title text boxes are enabled And the default alt text and title text remains in place And I can override all or part of the default text in the usual way

AC3.5 Given that I have selected an image from the library And I have selected not to use default alt text and title text And overridden all or part of the default text When I save the node Then the image is presented with the overriden alt and title text

AC3.6 Given that I have selected an image from the library And I have selected not to use default alt text and title text And overridden all or part of the default text When I re-check the checkbox to use default alt text and title text Then the alt text and title text boxes are re-populated with the default text And the text boxes are disabled.

4. Amend global alt and title text for image

As a site architect or editor I want to edit the alt text and title text for an image and have it apply to all nodes using that image with the default text So that I can reflect changes quickly and avoid repetitive editing

AC4.1 Given that I found opened the file record from Manage Files When I edit the alt text and/or title text And save the file record Then the record is updated And all instances of the image where the default is used are updated to use the new alt and title text And any cached versions of those instances are updated And all instances of the image where the default is not used are unchanged.

AC4.2 Given that I am editing a node that includes an image that uses the default alt text and title text And I have permissions to manage files When I view the image field Then I can see a link (e.g. "Update the default information for this image") And the link takes me directly to the edit form for that file

5. User upgrades site with existing images

As a site owner I want to update Backdrop to the version that includes this feature and have it use existing information to populate the global list So that I can use the functionality on existing images without lots of additional work

AC5.1 Given that I have updated to the Backdrop version with this feature in When I view images that are only used once Then the global alt and title text are taken from the node where they are used.

AC5.2 Given that I have updated to the Backdrop version with this feature in When I view images that are used more than once Then the global alt and title text are taken from the node where they were first entered

jenlampton avatar Sep 01 '19 22:09 jenlampton

In my quest to figure out what the difference is between the D7 file_entity module 2.x vs 3.x version, I came across this: https://www.drupal.org/project/file_entity/issues/2974604 ...which points to Sync alt and title text between file entity and standard image field. That last issue is against 3.x and marked as postponed, but it seems that this has fixed the issue in 2.x: https://www.drupal.org/project/file_entity/issues/2665960

Thought I'd mention all that here.

klonos avatar Sep 05 '19 02:09 klonos

Are you talking about the same issue that was raised in the forum today?

I've been using the file entity fields for a while now. I've got alt and title fields on all of my image files when viewing them under manage files. It's unfortunate that when I add an image in an image field and associate alt text with it that it doesn't automatically populate the field on the image file like it does for me in Drupal. When reusing the image elsewhere in the site I need to enter the alt text a second time rather than it being remembered. Is this how it's supposed to work?

https://forum.backdropcms.org/comment/1402#comment-1402

stpaultim avatar Oct 31 '19 03:10 stpaultim

Are you talking about the same issue that was raised in the forum today?

Yup 🙂

klonos avatar Oct 31 '19 04:10 klonos

I was just watching the keynote from the recent DrupalCon, and this bit of video shows what's coming with Drupal 8.8.0: https://youtu.be/Apqd4ff0NRI?t=1398

Transcript (emphasis mine):

If you happened to see the Media demo in Seattle, you remember that starting in Drupal 8.7, Drupal shipped with a media library, that enables editors to create reusable media. Drupal 8.8 take that a step further, and allows you to embed media in a text field. In this animation, we are browsing the media in our library, selecting an image, end embedding it in text. By default, the alternative text description for the image is inherited from the Media Library; but we can override it, if it doesn't make sense in this context. And of course, just like when uploading images the old way, without Media Library, it is possible to align and caption media - no matter if it is an image, a video, or something else.

klonos avatar Nov 09 '19 20:11 klonos

If we were to provide values of alt and title for each managed image file independently of the field in which the image is used (and additionally), where in the data tables should these values be stored? Is there a suitable table for supplementary data about each managed file?

Graham-72 avatar Dec 29 '19 17:12 Graham-72

I'd like to add my voice of support for this feature. It would be great to be able to add the title and alt anywhere and have them re-used whenever the image is re-used; this would help site builders and editors to avoid repeating their effort. Is this likely to be very complex technically or is it more a case of agreeing how we should do it?

yorkshire-pudding avatar Aug 12 '22 13:08 yorkshire-pudding

If we were to provide values of alt and title for each managed image file independently of the field in which the image is used (and additionally), where in the data tables should these values be stored? Is there a suitable table for supplementary data about each managed file?

file_metadata looks the right place. It has fid, name and value so could be flexible about what information is held without causing unnecessary overhead for other files. It currently stores height and width though these are stored as BLOB. Alternatively, a dedicated table (e.g. file_image_data) with text fields? I'm not a DB expert so not sure, which way would be best.

yorkshire-pudding avatar Aug 12 '22 13:08 yorkshire-pudding

I have a client looking for this functionality. Using the file_entity_inline module, we can easily add data to custom fields on files that is stored in the files table and accessible for all uses of the file. https://github.com/backdrop/backdrop-issues/issues/5738

However, we are not able to do that with the image alt and title field. This seems really weird that I am automatically able to add alt text to a file, but that info is not attached to the file and not available the next time I use the file.

I'm ready to Advocate for this issue, unless @yorkshire-pudding wants to advocate for this so I can advocate for something else?

First step as advocate may be to confirm that this is a good feature for core. I am pretty confident that it is and believe that it would greatly improve accessibility, by making it much easier for site editors to manage alt text.

As (temporary?) advocate, I've added this to the 1.24.0 milestone for now.

stpaultim avatar Sep 14 '22 02:09 stpaultim

@stpaultim - I'm happy to advocate for this so you can advocate for something else.

yorkshire-pudding avatar Sep 14 '22 08:09 yorkshire-pudding

First step as advocate may be to confirm that this is a good feature for core.

I find this to be a good feature 👍🏼 ...it will basically allow specifying the alt/title once, and then these values would be (re)used each time the same file entity* is added elsewhere on the site. Saves time, so it makes sense from a UX perspective.

The question is whether we should have it so that if these values are changed in one instance of the media asset, should the defaults be updated (hence applied to every other instance of the same asset on the site), or should it only update these values for the current instance and leave all other instances intact? I see valid use cases for both, but the UI would get too complex if we attempted to accommodate both, so it seems that we'd need to make a decision re that 🤔

*I would like us to actually start referring to these as "media assets" or "file assets" instead - the term "entity" is hard to explain to non-technical people

klonos avatar Sep 14 '22 09:09 klonos

The question is whether we should have it so that if these values are changed in one instance of the media asset, should the defaults be updated (hence applied to every other instance of the same asset on the site), or should it only update these values for the current instance and leave all other instances intact? I see valid use cases for both, but the UI would get too complex if we attempted to accommodate both, so it seems that we'd need to make a decision re that

I think we should update everywhere as trying to have an override could be complex and I imagine the use cases for overriding are very limited.

*I would like us to actually start referring to these as "media assets" or "file assets" instead - the term "entity" is hard to explain to non-technical people

I agree

yorkshire-pudding avatar Sep 14 '22 14:09 yorkshire-pudding

I think we should update everywhere as trying to have an override could be complex and I imagine the use cases for overriding are very limited.

I'd prefer an approach where the default values of the image file could be changed in single instances without affecting existing ones – as concept similar to field default values.

olafgrabienski avatar Sep 14 '22 15:09 olafgrabienski

If it comes to alt and title attribute, I agree with @olafgrabienski - updating the value in one field/node should not update it everywhere.

Background to this: alt and title may relate to content, so both should be per node. An image in one node might have a different meaning in another node. A title might be preferable in one node but not in another...

Another concern: currently the alt and title are per node - changing that behavior could baffle users. They might not expect that.

indigoxela avatar Sep 15 '22 06:09 indigoxela

If alt is being used correctly, it shouldn't change per node as it is meant to be a factual description of the image for accessibility purposes. That said, if we should allow title to be per node, then we should treat both fields the same.

I'm starting to think about possible user journeys here. These are initial thoughts for discussion.

Adding image initially

User uploads image and adds alt and title Image is stored and added to global list alt and title are stored both against the global list and against the node

Reusing the image on another node

User selects image (possibly using alt and/or title to help filter) Image sub-form is populated with alt and title from global list but fields are disabled User is shown checkbox that is already checked saying "Use default alt and title text" (a bit like the "Generate automatic URL alias" checkbox) User can leave it at that, or uncheck the checkbox which will enable the fields User can edit fields If the node is saved with the checkbox unselected then node is saved with overridden alt and title text.

Amend global alt and title text for image

User goes to manage files User selects file User can edit the alt and title text for image When saved, all nodes where use default is true will be updated; all nodes where use default is false will not be updated. There should be a link from nodes to the manage files form for that image (e.g. "Update the default information for this image")

User upgrades site with existing images

For images that are only used once, global list should be populated from that image and use default set to true For images that are used across multiple nodes, the global list should be populated from the node that used it first

yorkshire-pudding avatar Sep 15 '22 07:09 yorkshire-pudding

@yorkshire-pudding Thanks for the well-thought-out user journeys – a good concept, in my opinion.

Given your approach to treat 'alt' and 'title' the same, it might not matter practically here, but I'd like to disagree with the assumption of a "factual" image description in 'alt' texts. Context matters. Take e.g. an article about books and their authors and another article about book design. Both articles show book covers. While in the first article the 'alt' text of book covers could mention author and book title, in the second article it could mention the color of the cover and which font was used.

olafgrabienski avatar Sep 16 '22 13:09 olafgrabienski

Given your approach to treat 'alt' and 'title' the same, it might not matter practically here, but I'd like to disagree with the assumption of a "factual" image description in 'alt' texts. Context matters. Take e.g. an article about books and their authors and another article about book design. Both articles show book covers. While in the first article the 'alt' text of book covers could mention author and book title, in the second article it could mention the color of the cover and which font was used.

Thanks @olafgrabienski - I hadn't thought of it from that angle before

yorkshire-pudding avatar Sep 16 '22 13:09 yorkshire-pudding

@indigoxela @stpaultim @klonos @Graham-72 @jenlampton - any further feedback on the draft user journeys at https://github.com/backdrop/backdrop-issues/issues/4007#issuecomment-1247722046

Have I missed any considerations? Are we getting close to agreement about how this should work?

yorkshire-pudding avatar Sep 21 '22 18:09 yorkshire-pudding

I've added this to the forum post for discussion at an upcoming dev meeting, maybe this week. https://forum.backdropcms.org/comment/4463#comment-4463

I think a discussion in DEV meeting is the next best step.

stpaultim avatar Sep 21 '22 18:09 stpaultim

Discussion at 2022-09-22 Design meeting. General agreement that is a good idea. Need to consider caching; @hosef recommends that cache tags would be useful. Would need to implement a hierarchy so look at where its being used for alt and title before looking at entity.

yorkshire-pudding avatar Sep 22 '22 20:09 yorkshire-pudding

@yorkshire-pudding this looks fantastic. Thank you for taking the time to think through it so clearly. I'd recommend we copy that into the issue description so that everyone can refer to it easily in the future. I also expect that with this many changes we should break these up into separate subtasks, since many of these things could happen in parallel, and almost all of them are improvements individually, as well as together :)

jenlampton avatar Nov 03 '22 20:11 jenlampton

Specification at https://github.com/backdrop/backdrop-issues/issues/4007#issue-487939218

@jenlampton - while I imagine these could be split up and done as separate tasks by different developers, I'm not sure, other than story 5, that any of them would work without the others.

yorkshire-pudding avatar Nov 03 '22 20:11 yorkshire-pudding

The scope of changes is so large that it's hard to know where to start. If we could break this down into smaller more concrete action oriented steps, it might be easier for developers to jump in. Something like:

  1. allow alt/title to be stored with files (this would include the add/edit forms for files, database schema, etc)
  2. allow alt/title to be stored in place B
  3. allow alt/title to be copied from place A to place B
  4. allow alt/title to be copied from place A to place C
  5. etc

Maybe we can discuss this in one of the developer or UX meetings and see if we can help get this unblocked for the next milestone :) I would love to improve our image situation in Backdrop :)

jenlampton avatar Jan 03 '23 02:01 jenlampton

@jenlampton - I'm happy to look at splitting this out. Any ideas why I can no longer edit the description at the top (where it would make most sense to do a meta list of separate tasks)?

yorkshire-pudding avatar Jan 03 '23 09:01 yorkshire-pudding

The contrib module, Extended Image Module (EIM) implements adding options to enable the Alt and Title field to image fields. This is only for when image fields are added to content types it does not address this issue. However, it includes the following description: "The title attribute is used as a tooltip when the mouse hovers over the image. Enabling this field is not recommended, as it can cause problems with screen readers." The warning might be important to this discussion.

izmeez avatar Sep 30 '23 16:09 izmeez

Starting to think a bit about how to implement this...

where in the data tables should these values be stored?

file_metadata looks the right place. It has fid, name and value so could be flexible about what information is held without causing unnecessary overhead for other files. It currently stores height and width though these are stored as BLOB. Alternatively, a dedicated table (e.g. file_image_data) with text fields? I'm not a DB expert so not sure, which way would be best.

The disadvantage of storing this in file_metadata as pairs of key/value with value being a BLOB is that querying this table for specific title or alt values becomes a bit tricky (but it can be done, I think). Since it was mentioned that site builders should be able to search images by their alt or title values, it's probably more convenient to create a new table like @yorkshire-pudding suggested, file_image_data with individual columns for alt and title. The problem with this is, of course, you end up with two different tables to store image metadata.

argiepiano avatar Sep 30 '23 16:09 argiepiano