Feature request: alt tag field for assets by default

[JayBox325]

Description

At the moment assets have title and filename fields by default.

Adding an Alt text field out the box will improve Craft's accessibility standards out the box for a lot of devs that may not remember to add this field for every project.

[carl-evans]

I was about to request this. I feel it's a wonderful enhancement which I would love to see.

[mattstein]

I add an Alt Text field to Asset field layouts intended for images—which is most of them—but there are cases like PDFs and .zip archives where it's not relevant.

I think this would be a healthy default as long as it could be turned off/removed for special cases.

[JayBox325]

I add an Alt Text field to Asset field layouts intended for images—which is most of them—but there are cases like PDFs and .zip archives where it's not relevant.

I think this would be a healthy default as long as it could be turned off/removed for special cases.

Hi @mattstein, came to log this ticket again and I was correct in remembering I already logged it some time ago 😂. I usually add an 'alt text' field to my assets, but it would be great if it was added by default in the image config:

Hoping this eventually makes it's way into Craft 4 or even a version of 3.5!

[mattstein]

I think it’s a great idea to promote accessibility considerations for content editors @JayBox325, I was just arguing for cases where it wouldn’t make sense to expose an Alt Text field by default since Craft purposefully doesn’t make assumptions about the front end. alt and role might make sense for img tags, but the asset could be a non-image or used in a CSS background or something. Though the title would be moot at that point too, so maybe it’s already a self-defeating argument.

Ultimately I don’t know whether it’d be best handled by Craft core or an opinionated plugin focused on accessibility tools—but luckily for both of us it’s not up to me! :)

[brandonkelly]

I would say that alt text is part of the content of the image, not really file metadata, so it makes the most sense as a custom field that lives alongside other content. And we can’t add custom fields to assets by default in an installation because they are added via the volume’s field layout, and there aren’t any volumes in a default Craft install.

[brandonkelly]

Went ahead and added this for Craft 4, since it gives Craft a way to add alt text to asset thumbnails and <img> tags returned by craft\elements\Asset::getImg(). Also helps with WCAG compliance.

I also added a “Has alternative text” condition rule for assets, which could be used to find assets that do/don’t have alt text added yet.

PR: #10304

[MoritzLost]

@brandonkelly Will the new native alt text field be optional? What about assets that are not images and don't require alt texts – is the native field only shown for images?
Will there be an upgrade path for Craft 3 projects moving to Craft 4 that want to replace an existing custom field for alt texts with the new native field?

[brandonkelly]

Yeah it’s optional. You have to drag it into the field layout if you want it. And thanks to field conditions (#10300) you can even have it only show up for certain file types.

Will there be an upgrade path for Craft 3 projects moving to Craft 4 that want to replace an existing custom field for alt texts with the new native field?

Good question. I just added new --set and --to options to resave commands for the next Craft 3 release (#10356), so you could use those to populate asset alt text from your old custom field:

php craft resave/assets --set alt --to myAltTextField --if-empty

[MoritzLost]

@brandonkelly We're having a bit of trouble planning the migration to the new alt field in the context of automated deployments. The upgrade guide says we should add the new native field to the asset volume's field layout, then use the resave/assets command with --set and --to to copy the value of the old custom field to the native field and then remove the old native field. But in a deployment on the live site, the two fields are added and removed at the same time during project-config/apply, so there's no chance of running the resave command in between. Running it before project-config/apply is not possible because the native alt field isn't present in the field layout at this point, and running it afterwards doesn't work because at this point, the old custom field is gone.

The only way I can think of is to either do this step manually on the server (not great) or splitting this into two deployments: The first to add the native field and rename the old custom alt field to something like alt_old and to migrate the content from the custom field to the native field. Then after that's done, a second deployment that removes the old field. Both of those feel wrong and have downsides – in particular, having to split the update into two commits and making sure they're not deployed at the same time in every environment.

Is there a better solution to this?

[brandonkelly]

Yeah I think it needs to be a phased approach. Get the site upgraded first, then migrate off of your existing Alt Text field to the native one later on, after you’ve had a chance to migrate the data.