Pre-populate Image Alt Text field with IPTC Photo Metadata Standard Alt Text

[eatingrules]

The IPTC Photo Metadata Standard includes the ability to embed Alt Text with a photo.

Seems like it would be helpful if WordPress would check for this data when an image is uploaded, and, if it exists, pre-populate the Alt Text field with it.

I could see this being especially useful for site owners who purchase stock photography; if the alt text is embedded with those images, it would save the site owner time, and it would also help ensure that an Alt Text itself is added -- and is an accurate description of the image (assuming the photographer or stock photo site actually enters a good description!).

​http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata#alt-text-accessibility

[joyously]

Do you mean like this? https://core.trac.wordpress.org/browser/tags/5.9/src/wp-admin/includes/image.php#L752

[joedolson]

@joyously Yes, that's the same type of thing @eatingrules is referring to. But the alt attribute parameter in IPTC data is newly added to the specification, and is not currently handled by WordPress.

[carolinescribely]

Tired Spongebob Meme

[carolinescribely]

Thought it might help to provide an image with embedded photo metadata. This meme has the new IPTC AltTextAccessibility and ExtDescrAccessibility properties, as well as a number of other descriptive fields (Title, Headline, Description/Caption, Description Writer). Posted above.

Not sure if uploading this image will strip out the metadata so here's a Google Drive link just in case: ​https://drive.google.com/file/d/1MKSk5GZfGoxUdJxyWubS9PNKnIZCu8gS/view?usp=sharing

[SergeyBiryukov]

#55760 was marked as a duplicate.

[joedolson]

I'm not having any luck getting the new IPTC fields from the image using iptcparse, and I'm not really sure why - I don't see anything in the ​function source that looks like it would skip newly defined tags.

I verified that the provided image does contain the extended alt information by viewing the raw image data, but the function doesn't pick them up.

[larsvanrhijn]

I'm having the same problem as @joedolson, a simple var_dump does not show the new image data. It seems that getimagesize is not returning the alt text information.

[sabernhardt]

Moving to Future Release for further investigation

[carolinescribely]

@sabernhardt - I'm disappointed to see that this request has been changed from 6.1 to future release. What needs to be done to investigate / resolve this issue and get this back on track? I'm a member of the IPTC photo metadata group. Would it help to arrange a meeting to discuss further?

[joedolson]

@carolinescribely If somebody can provide a way to get the IPTC metadata out of the image using PHP, we can continue to research it; but multiple people have worked on it without successfully getting that data. If we can't get the attribute, we can't use it. See the previous comments.

[mwsat]

@joedolson not a perfect but a well working solution can be using ExifTool - ​https://exiftool.org/ - a PERL based library for reading and writing metadata. With proper parameters it returns a structured JSON object with all the metadata in the image. We from IPTC could help using ExifTool properly in terms of metadata reading - but sorry, we are no PHP experts.

[joedolson]

Going to look at this again for 6.2; need to see if we can resolve the PHP issue with iptcparse.

@mwsat I don't think I can see a way that would help resolve the issue. I can definitely extract and see the metadata, but for these purposes we need WordPress to be able to extract that data, and that's what isn't working as expected.

[brendanquinn]

Hi @joedolson and all, if I can explain a bit of the detail behind IPTC Photo Metadata (more details in the spec: ​https://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-2022.1.html#history):

The "original" IPTC metadata is now referred to as IPTC/IIM. It is a binary format encoded in the Photoshop Image Resource Block (APP13 in JPEG). It was implemented by Photoshop in the 1990s. This is what is supported by PHP's native iptcparse function.

In the 2000s, IPTC and Adobe moved to the XMP format, which is stored in a different image header using the APP1 block marker (which can also used to store Exif tags). Unfortunately, PHP's iptcparse has still not been updated. It's understandable, because the parsing is more complicated - it's an XML-encoded set of RDF triples.

I'm not a PHP expert either, but here's some code to extract the XMP packet from an image and retrieve the Alt Text field (created with a bit of help from ChatGPT!)

<?php

// Read the contents of the JPEG file into a string
$jpeg_contents = file_get_contents("image.jpg");

// Find the start and end positions of the XMP metadata
$xmp_start = strpos($jpeg_contents, "<x:xmpmeta");
$xmp_end = strpos($jpeg_contents, "</x:xmpmeta>");

// Extract the XMP metadata from the JPEG contents
$xmp_data = substr($jpeg_contents, $xmp_start, $xmp_end - $xmp_start + 12);

// Parse the XMP metadata using DOMDocument
$doc = new DOMDocument();
$doc->loadXML($xmp_data);

// Get the "Iptc4xmpCore:AltTextAccessibility" element
$element = $doc->getElementsByTagName("Iptc4xmpCore:AltTextAccessibility")->item(0);

// Extract the value of the element
$alt_text = $element->nodeValue;

I hope that helps move towards a solution. I guess the best path forward would be to change the core iptcparse to support XMP metadata. But in the meantime this wouldn't be a bad step forward.

Another option would be to use a third-party tool like exiftool, as @mwsat suggests. Of course, this creates a dependency for WordPress that might cause issues.

[pbiron]

thanx @brendanquinn.

For everyone, here's the embedded XMP from Tired Spongebob Meme.jpg​ (with ... meaning that parts have been elided for clarity):

<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 7.0-c000 1.000000, 0000/00/00-00:00:00">
 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    xmlns:Iptc4xmpCore="http://iptc.org/std/Iptc4xmpCore/1.0/xmlns/"
    ...
   >
   ...
   <Iptc4xmpCore:ExtDescrAccessibility>
    <rdf:Alt>
     <rdf:li xml:lang="x-default">Spongebob leans on his hand as if to balance or stabilize himself. He's naked, not wearing his usual square pants, and he's looking off to one side with his brow pulled up, looking completely exhausted. Both of his cheeks are puffed out as he exhales from a small opening in his mouth, like he's out of breath and trying to recover. </rdf:li>
     <rdf:li xml:lang="en">Spongebob leans on his hand as if to balance or stabilize himself. He's naked, not wearing his usual square pants, and he's looking off to one side with his brow pulled up, looking completely exhausted. Both of his cheeks are puffed out as he exhales from a small opening in his mouth, like he's out of breath and trying to recover. </rdf:li>
    </rdf:Alt>
   </Iptc4xmpCore:ExtDescrAccessibility>
   <Iptc4xmpCore:AltTextAccessibility>
    <rdf:Alt>
     <rdf:li xml:lang="x-default">Meme. Spongebob Squarepants leans against the wall of an undersea cave, puffing out his cheeks with a tired and put-upon expression. Caption: Me after I put the fitted sheet on the bed by myself.</rdf:li>
     <rdf:li xml:lang="en">Meme. Spongebob Squarepants leans against the wall of an undersea cave, puffing out his cheeks with a tired and put-upon expression. Caption: Me after I put the fitted sheet on the bed by myself.</rdf:li>
    </rdf:Alt>
   </Iptc4xmpCore:AltTextAccessibility>
  </rdf:Description>
 </rdf:RDF>
</x:xmpmeta>

And here's some working code to extract the AltTextAccessibility from the XMP, which builds on what @brendanquinn posted and is more complete. I through this together pretty quickly, and I'm sure it can be improved upon.

<?php
$jpeg_contents = file_get_contents( $file );

// Find the start and end positions of the XMP metadata
$xmp_start = strpos( $jpeg_contents, '<x:xmpmeta' );
$xmp_end = strpos( $jpeg_contents, '</x:xmpmeta>');

// Extract the XMP metadata from the JPEG contents
$xmp_data = substr( $jpeg_contents, $xmp_start, $xmp_end - $xmp_start + 12 );

// Parse the XMP metadata using DOMDocument
$doc = new DOMDocument();
$doc->loadXML( $xmp_data );

// Instantiate an XPath object, used to extract portions of the XMP.
$xpath = new DOMXPath( $doc );

// Register the relevant XML namespaces.
$xpath->registerNamespace( 'x', 'adobe:ns:meta/' );
$xpath->registerNamespace( 'rdf', 'http://www.w3.org/1999/02/22-rdf-syntax-ns#' );
$xpath->registerNamespace( 'Iptc4xmpCore', 'http://iptc.org/std/Iptc4xmpCore/1.0/xmlns/' );

$node_list = $xpath->query( '/x:xmpmeta/rdf:RDF/rdf:Description/Iptc4xmpCore:AltTextAccessibility' );
if ( $node_list && $node_list->count() ) {
        // Get the alt text accessibility alternative most appropriate for the site language.

        $node = $node_list->item( 0 );

        // Get the site's locale.
        $locale = get_locale();

        // There are 3 possibilities:
        //
        // 1. there is an rdf:li with an exact match on the site locale
        // 2. there is an rdf:li with a partial match on the site locale (e.g., site locale is en_US and rdf:li has @xml:lang="en")
        // 3. there is an rdf:li with an "x-default" lang.
        //
        // we evaluate them in that order, stopping when we have a match.
        $value = $xpath->evaluate( "string( rdf:Alt/rdf:li[ @xml:lang = '{$locale}' ] )", $node );
        if ( ! $value ) {
                $value = $xpath->evaluate( 'string( rdf:Alt/rdf:li[ @xml:lang = "' . substr( $locale, 0, 2 ) . '" ] )', $node );
                if ( ! $value ) {
                        $value = $xpath->evaluate( 'string( rdf:Alt/rdf:li[ @xml:lang = "x-default" ] )', $node );
                }
        }
}

Also note that it's possible that there are multiple <x:xmpmeta> embedded with a given image, and the above code doesn't handle that case.

[pbiron]

p.s. the above code will won't "do the right thing" if the image doesn't have XMP data :-)

also, see this ​Stack Overflow post for some code that is supposed to be able to extract multiple XMP blocks...I haven't tried it.

[pbiron]

another thing to note: there is already code in core to extra image caption/description info from EXIF data within an image.

@eatingrules and @brendanquinn : is the intent of this ticket to prefer the 2 new IPTC fields for accessibility purposes?

[carolinescribely]

IPTC Caption/Description is more for the visible captions that appear below the image. Caption/Descriptions provide the "facts" about an image (who, what, when, where).

The IPTC Alt Text and Extended Description properties are for accessibility purposes specifically. Alt Text goes to the alt attribute for the image and Extended Description goes to the page reference linked from the image. More details on that here: ​https://www.w3.org/WAI/tutorials/images/complex/

So, yes, the intent of this ticket would be to import Alt Text instead of Caption/Description when Alt Text is present. We want to import / preserve the Extended Description from the image metadata in Word Press so users can add it to the web using their preferred approach from the w3c guidance.

Replying to pbiron:

another thing to note: there is already code in core to extra image caption/description info from EXIF data within an image.

@eatingrules and @brendanquinn : is the intent of this ticket to prefer the 2 new IPTC fields for accessibility purposes?

[joedolson]

So, yes, the intent of this ticket would be to import Alt Text instead of Caption/Description when Alt Text is present. We want to import / preserve the Extended Description from the image metadata in Word Press so users can add it to the web using their preferred approach from the w3c guidance.

This isn't an either/or situation - there's no reason not to import caption/description because the alt text is present. These are all separate fields in WordPress.

The ticket will add support for importing alt attribute values when provided, but make no changes to how existing captions and descriptions are handled.

[pbiron]

@brendanquinn and/or @carolinescribely : can you please add some additional images to this ticket "showcase" the variability in the way this IPTC metadata can appear in an image? For example, there can be multiple <x:xmpmeta> elements, etc. That will help with implementing this.

[carolinescribely]

@pbiron Yes, there are sample images on the IPTC site, which already have values for both of the accessibility fields as well as other IPTC metadata properties. Including a few options below. Is this what you need? If not, can you explain what you mean by "showcase the variability in multiple <x:xmpmeta> elements?"

Current IPTC Reference images:
​http://iptc.org/standards/photo-metadata/guidelines-support/
It's part way down the page, under "Reference Image with all current IPTC Photo Metadata fields filled in"

The direct link to the Standard 2021.1 file is here:
​https://www.iptc.org/std/photometadata/examples/IPTC-PhotometadataRef-Std2021.1.jpg
THe image is linked to from ​https://iptc.org/standards/photo-metadata/iptc-standard/

​https://www.iptc.org/std/photometadata/examples/IPTC-PhotometadataRef-Std2021.1-large.jpg is the link to the image at the top of the "Get IPTC Photometadata page" ​https://getpmd.iptc.org/getiptcpmd.html (which might be a better one to use, as it also shows how to view photo metadata via this service).

[audrasjb]

Hi there, I have a quick question about this proposal. It seems to me that the alt text of an image should not only describe the image alone, but should describe it in the context where the image is used.

For example, the photo of a green gourd could have different alt texts:

• On an mountain equipment ecommerce website, the alt text could be "Green steel hiking gourd" to describe the product
• On a photographer's site, the same photo might have a more technical alt text "Photo with motion blur - aperture priority mode"
• On a hiking blog where the photo would only be decorative, we would rather have an empty alt text.

Since everything depends on the context in which the photo is inserted, wouldn't it be better to avoid generating the alternative text automatically from the exif data?

[joedolson]

Alternative text provided by the source (photo owner and or photographer, for example) can provide details that aren't necessarily available to the user at the time they use the photo. Retaining that information is helpful.

The alt text field in WordPress should never be considered the source of the optimal alt text, because WP only supports a single field for that use, and alt text needs to be context-sensitive, anyway.

The value to this is to retain valuable information that could be provided by the photo creator.

See #47456

[carolinescribely]

Thanks, Joe. I thought I had responded and looks like the comment didnt post.

Good question @audrasjb. Yes, alt text does depend on the surrounding context. The ideal use case is to show the embedded alt text and allow WP users to accept/edit the description. There are a few good reasons for doing this. First, it gives users a place to start their descriptions from - always easier to adapt than create from scratch. Second, the alt text may come from the original creator or source provider and provide helpful information about how to accurately describe the image. Third, the alt text can be imported from an outside source/database managed by the host of the website. The idea with this ticket is to put the plumbing in place to preserve and pass any existing descriptive text through, and then allow users to adapt the alt text as needed. Let me know if there are any additional questions or comments on contextual descriptive text.

[oglekler]

This is an enhancement, and we are in 12 days until Beta 1 after which we will not add new enhancement to the release, so, because there is no patch, I am moving this ticket to 6.4.

[oglekler]

I think alongside with @audrasjb, if information will be uploaded automatically, and it is actually invisible to user who is uploading it, the user can miss it and land with something unwanted or unexpected. If a picture was bought, there can be a lot of keywords to optimize search visibility of this image where it was purchased and also authors attributes and links to buy more.

Article in addition: ​https://yoast.com/developer-blog/why-we-dont-set-the-og-image-alt-tag/

[carolinescribely]

Why wouldn't WordPress make the embedded alt text visible to users? Is there a way to have an actual conversation with stakeholders about this ticket? It has been pushed back last minute for several releases at this point and I think we would benefit from having a discussion about the best way forward.

Replying to oglekler:

I think alongside with @audrasjb, if information will be uploaded automatically, and it is actually invisible to user who is uploading it, the user can miss it and land with something unwanted or unexpected. If a picture was bought, there can be a lot of keywords to optimize search visibility of this image where it was purchased and also authors attributes and links to buy more.

Article in addition: ​https://yoast.com/developer-blog/why-we-dont-set-the-og-image-alt-tag/

[joedolson]

@oglekler I'm not sure in what sense you mean "would be invisible to user who is uploading it" - the alt text would be visible exactly like any other alt text would be visible.

I'll also note that in the case where the author doesn't notice the alt text, then they were never going to have appropriate alt text in the first place - they were going to have no alt text. So it's somewhat a wash there; just a different default.

@carolinescribely This has been pushed back largely because there's no consensus on what to do and PHP doesn't have good support for extracting the data in the first place, so it's fairly labor intensive to make this happen.

There is a larger question here which is about how WordPress is going to handle alt text. Historically, WordPress has only stored a single canonical alt text, and that leads to a number of problems in usage. However, due to the many different ways of using this data, it's difficult to make significant changes to how it's stored. I've had a number of conversations about that with other contributors, but we don't have a clear path yet.

[carolinescribely]

I didn't realize this was part of a larger conversation and that it has a higher LOE. Thanks for sharing that. Let me know if I can help weigh in with contributors and decide on a go-forward alt text strategy. I work with clients and partners on this sort of thing all the time and I would be happy to contribute to moving this conversation forward.

Here are initial thoughts in case they are helpful...

Ideally there's a way to store multiple versions of alt text within a media library and have users control which one works best and whether or not to adapt / write a new description. It would be good to be able to categorize an alt text description as "primary / default" in the media library, as well as include other categories that might be helpful to users like "IPTC / embedded" or "custom."

From there, users could set controls for images on the actual webpage to pull let's say the "primary" alt text from the media library or write a new description that's just for that page. This addresses the context concern brought up on this thread. WebFlow has a similar process of pulling descriptions from the asset library to make if you want a reference for this but I don't believe they allow you to store and select from multiple versions of alt text in the media library which is really what's needed for accessibility workflows.

Putting my ideas down here but happy to talk through any of them with you / others if it's helpful.

[joedolson]

@carolinescribely Do you know of any image sources who are actively using this field? For example, stock imagery providers, photography studios, etc. - a place where we could look at a wide variety of images to examine.

The accessibility team's preferred approach to this is to add a media data panel that can expose this and other important metadata without automatically assigning it to fields that will be output on the front end, so that the user can choose to use this information, but it isn't automatic.

[oglekler]

There is no patch and no time before Beta 1 to finish and test it, so, I am moving this ticket into the 6.5 milestone.

[sergueifomine]

Replying to joedolson:

@carolinescribely Do you know of any image sources who are actively using this field? For example, stock imagery providers, photography studios, etc. - a place where we could look at a wide variety of images to examine.

The accessibility team's preferred approach to this is to add a media data panel that can expose this and other important metadata without automatically assigning it to fields that will be output on the front end, so that the user can choose to use this information, but it isn't automatic.

We implemented ALT-TEXT properities in DAM Picvario (picvario.com) and actively promote the feature to our users. Here is a link to sample WordPress page with the embedded image containing ALT-TEXT: ​https://picvario.com/embedding/

[mmzeroexpcom]

Replying to joedolson:

@carolinescribely Do you know of any image sources who are actively using this field? For example, stock imagery providers, photography studios, etc. - a place where we could look at a wide variety of images to examine.

The accessibility team's preferred approach to this is to add a media data panel that can expose this and other important metadata without automatically assigning it to fields that will be output on the front end, so that the user can choose to use this information, but it isn't automatic.

Hello
@joedolson and @carolinescribely (cc @sergueifomine and @brendanquinn ) ! I have been following this thread off and on and working with Caroline and have finally had a chance to chime in.

The website: ​https://imagesnippets.com makes use of the embedded alt-text field extensively and has done so since it was introduced as part of the iptc standard.

While I cannot guarantee that every search on the ImageSnippets site will return images in which a user has included alt-text, you can perform a search on the front page of that site for a variety of topics and may find it in any number of images. We have over 80,000 images in ImageSnippets. You can also create an account and experiment with uploading/downloading/searching for images and their metadata.

However, what might be easier is if you take a look at this page: ​https://margaretwarren.us --- the images on this page are pulled into a word press block editor plug-in gallery that pulls image links from ImageSnippets and thus all included, embedded metadata is included in the linked file. A user can log into ImageSnippets and add or modify alt-text at any time and it will be updated in the file and the link hosted at ImageSnippets.

One of the reasons we have created the block editor that works this way, is because of the historic lack of good word press support for iptc-metadata in the media library even when imagemagick is also installed for other metadata plug-ins. It would be really nice if the exif/iptc metadata were natively handled better in the wp media library for sure.

We additionally copy the alt-text field from the image into the html alt-tag attribute in the block editor, but to access lots of embedded metadata in these files, you can click on each image and and right-click download each image. Most of the images on that site are populated with alt-text data as well as many other iptc-xmp fields.

Additionally, I list below about 10 other images from my own account linked here that are populated. We have many other users who use alt-text extensively through our interface.

Below, each html link matches each .jpg (or .jpeg) link. If you click on the html link, you can flip the image and read the difference between the description and the alt-text field. You can also download each image from this link to examine and you can also just use the URL for the image itself... i.e. all the same and all images contain embedded metadata. For one image, I intentionally used an image that has alt-text, but not a 'description' if that helps in your examination.

​https://imagesnippets.com/imgtag/images/info@margaretwarren.us/fletcher_flair_glenmoor.html
​https://imagesnippets.com/imgtag/images/info@margaretwarren.us/fletcher_flair_glenmoor.jpg

​https://imagesnippets.com/imgtag/images/info@margaretwarren.us/metadata.html
​https://imagesnippets.com/imgtag/images/info@margaretwarren.us/metadata.jpg

​https://imagesnippets.com/imgtag/images/info@margaretwarren.us/P1070330.html
​https://imagesnippets.com/imgtag/images/info@margaretwarren.us/P1070330.jpg

​https://imagesnippets.com/imgtag/images/info@margaretwarren.us/j_loom.html
​https://imagesnippets.com/imgtag/images/info@margaretwarren.us/j_loom.jpg

​https://imagesnippets.com/imgtag/images/info@margaretwarren.us/P1010140.html
​https://imagesnippets.com/imgtag/images/info@margaretwarren.us/P1010140.JPG

​https://imagesnippets.com/imgtag/images/info@margaretwarren.us/gg_circa78.html
​https://imagesnippets.com/imgtag/images/info@margaretwarren.us/gg_circa78.jpg

​https://imagesnippets.com/imgtag/images/info@margaretwarren.us/fletcher%20072.html
​https://imagesnippets.com/imgtag/images/info@margaretwarren.us/fletcher%20072.jpg

​https://imagesnippets.com/imgtag/images/info@margaretwarren.us/FOOu91MXoAAIguo.html
​https://imagesnippets.com/imgtag/images/info@margaretwarren.us/FOOu91MXoAAIguo.jpeg

​https://imagesnippets.com/imgtag/images/info@margaretwarren.us/20220322_190336.html (intentionally without 'description' but has alt-text embedded)
​https://imagesnippets.com/imgtag/images/info@margaretwarren.us/20220322_190336.jpg

​https://imagesnippets.com/imgtag/images/info@margaretwarren.us/20160911_183452.html
​https://imagesnippets.com/imgtag/images/info@margaretwarren.us/20160911_183452.jpg

You can also use the iptc tool: ​https://getpmd.iptc.org/getiptcpmd.html
or the call this tool using a Firefox or Chrome extension from the .jpg or .jpeg links and explore the difference between the descriptions and the alt-text.

I can't guarantee that every alt-text description written in images in ImageSnippets is to the same standards @carolinescribely describes, but in general you can see that the description used to describe the image for blind, low-vision or cognitively-disabled users is different from the general description and is in many cases less sensitive to context (i.e. it is just a description of the visual elements).

In our case, we also duplicate the 'description field' (​https://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata#description) into the Extended description field as well however for additional coverage with screen readers.)

While I do understand why context is important and considered - and I defer to @carolinescribely on her interpretation of this, I do also feel there would simply be a great benefit to just getting the main one field working presently.

To help the workflow of users working with alt-text,it would be great if just this primary field could be retained in the image and read into the media library and if edited in the media library interface, could be resaved back into the image.

There will always be forward/backward/read/write compatibility concerns - but right now, anything would be better than nothing I think. I will ask our developer if he has .php expertise around the embedded metadata that would be helpful here.

I can also see the value to having a media panel however and having better support for all EXIF/IPTC metadata fields in general, but to further emphasize the need for the alt-text in particular, this news just came out 3 days ago:

​https://www.usatoday.com/story/news/politics/2023/10/04/url-supreme-court-disability-rights-case-hotel-booking/71037464007/

WASHINGTON − The Supreme Court wrestled Wednesday with whether Americans with disabilities may sue hotels for failing to disclose accessibility information on their websites even if they don't intend to stay there − a dispute that advocates say could have broad implications for the enforcement of disability laws.

please contact me if you have more questions, I'm happy to help.

[audrasjb]

As per today's bug scrub, we decided to move this ticket to Future Release to give it more time to get a patch / more discussion.

[joedolson]

Re-assigning to @rcreators to explore.

[Jesterman]

As @mmzeroexpcom points out there needs to be some improvement to how creators and publishers can ensure accessibility features in WordPress are displayed and utilized by the public. I've been part of the WordPress community for a very long time and I still cannot understand why core image metadata has not been fully incorporated into the media upload and filing tool.

I'm a professional photojournalist and photo editor and have encouraged several newspapers, stations and magazines to switch to WordPress and yet, I have never understood why I've had to apologize for WordPress' poor adoption of pulling Alt text, Headlines, (True) Description/Caption, Creator and Copyright into the correct WordPress image fields. Every publisher is forced to copy their info around from field to field or from software to website on each photo. It's really poor data filing for the WP database and awful for a professional workflow.

Every professional photographer I know files clear photo information in many of the built-in IPTC fields after photo shoots or assignments. That info is further edited by other staff when archiving, editing and publishing. This professional filing process is as old as the EXIF and IPTC format at newsrooms and photography houses.

My question to @joedolson and @rcreators is:

When will the WordPress fields "Alternative Text", "Caption" and "Description" use the internationally recognized (AND USED) IPTC fields "Headline" or "Keywords" (in the WP Caption field) "Description/Capton" (in the WP Description field) and the "Alt Text" (in the WP Alternative Text field).

Please take a look how most professional photographers log their raw photo shoots, either in Lightroom, Photo Mechanic, and so many other filing tools that follow the IPTC fields.
Here's an example from Photo Mechanic:

​https://camerabits.freshdesk.com/support/solutions/articles/48001252566-using-the-metadata-iptc-template

I implore the WordPress Core developers to fix this longstanding issue where the work and effort photographers and publishers face whenever they upload an image into WordPress. It's as if WordPress has determined all of that work is worthless and they must copy/paste meta data for every single image when using WordPress. Thank you.
-TJ