Feature Request: "Sanitise, Not Strip" – Native support for XMP/IPTC Accessibility Metadata

[kinderauk]

Currently, Craft CMS strips all image metadata by default during upload unless preserveExifData is set to true. While this is great for privacy (stripping GPS and camera serial numbers), it creates a "last-mile" accessibility gap.

Valuable accessibility data — such as ALT text and descriptions stored in IPTC or XMP (AltTextAccessibility) fields — is lost. This forces authors to manually re-enter descriptions that may have already been embedded at the point of capture (by hardware) or licensed (from image libraries).

The proposed solution

I’m advocating for a "Sanitise, Not Strip" approach to image handling:

1. Selective Preservation by Default: Instead of an all-or-nothing approach, Craft could allow specific, non-sensitive accessibility tags (like Iptc.Application2.Caption, XMP-dc:Description, or the newer IPTC AltTextAccessibility) through the metadata stripping process by default.
2. Native ALT Mapping: In Craft 5, we now have a native alt field for Assets. It would be a huge win for inclusion if Craft could automatically map these incoming XMP/IPTC fields to the native alt field on upload, populating it as a baseline for the author to then review/edit.
3. Default Field Layout: Why is the native alt field not automatically added to the Asset Volume field layout when a volume is created? Making it a default part of the UI would signal that accessibility is a core requirement, not an "optional extra."

Why I am advocating this functionality is added to Craft’s core

Currently, we can use the preserveExifData => true config setting, but this is a security risk as it retains sensitive GPS data. Alternatively, we have to build or install custom plugins to "reach back" into the file before Craft processes it, which adds unnecessary overhead to what should be a native inclusive workflow.

Additional context

We are pushing a wider campaign called #AltAtSource. The goal is to connect the dots from capture to publish. If hardware vendors (Apple/Google) and image libraries start embedding this data, CMS platforms like Craft are the vital bridge to getting that data to the end-user.

By making this a native, "no-plugin-required" feature, Craft can lead the way in making digital inclusion the default.

[brandonkelly]

Thanks for the suggestion! This is now implemented for Craft 5.10 (#18744).

[kinderauk]

@brandonkelly I am genuinely impressed that you turned this feature request around so quickly. Thank you for your ongoing commitment to digital accessibility. I am hopeful that this feature and the #AltAtSource campaign will really help reduce the number of images without alt text.

[brandonkelly]

Craft 5.10.0 is out with that change. Thanks again!

[kinderauk]

I just gave this new feature a spin and it is amazing to see this working — thank you!

I have noticed that it works when uploading a new file, but not when replacing an existing file. As a typical workflow might include replacing existing images after adding metadata in an application like Adobe Bridge, it would be great if a future release could support this too.

[brandonkelly]

It should also work with Replace File. Just tested locally with mixed results. It works for assets where Alternative Text had never been set before; but not if it had been set and then cleared out.

Just fixed that for the next release (e6149bb). There are a couple caveats though:

• It will only happen if the alt text is blank. If there’s an existing Alt Text value, Craft will leave it alone.
• The new alt text is not immediately shown in the field, until you reload the page. If you were to submit the form with the value still blank, then it will get reset back to empty.

[brandonkelly]

Craft 5.10.1 is out with that fix.

[kinderauk]

Brilliant! Thanks @brandonkelly