We could specify additional parameters (like "alt" or "display value" when creating the field. That would be the same in each item (eg article) where that field appears.
But I don't think that is what you want?

If you expect the user who fills the value for the field to also specify the ALT text or the display value, then that will not be possible. Simply because you expect one field to generate two fields (eg src and alt for the image). You'd have to create two fields for that and use them properly in your override, which is already possible today.

I fond this issue two years ago, but als @Bakual says, it is not possible without changing the database and the whole output of the fields.

You can say it's not possible but it must be fixed or everything said about accessibility with j4 is invalid

You would have to change the whole architecture of com_fields to allow that. And by doing that, you will break the fields as the whole code is meant to process a single input per field. I'd be strongly against that.

Those are custom fields. This has nothing to do with our accessibility promise for J4. It's user generated content and thus out of our control.

If you need a field for the ALT attribute, nothing stops you from creating that field to accompany the image field (which is in fact just an file selector field). You just need to set up everything you need yourself, it's not done automatically.

or store value as JSON {"src":"blabla/path/to-image.jpg", "alt":"random text"}
but that also not best and easy :)

For the URL field I have already written the code

@Fedik having it as json makes it harder to index and search.

1. its an image so I doubt we would ever have indexed it
2. subfields are already stored as json

@laoneo no, not really make a difference, the finder doing indexing of the "final render", will be indexed what is rendered ?

Are you sure? Anyway, simething tells me that we will run into some issues. But on the otherside it would be nice to have a display value. Un general it would be cool if we can break up fields that way.

@laoneo check the finder plugin onContentAfterSave and index(), it uses the same onContentPrepare stuff, so if the field are rendered at onContentPrepare then it will be indexed with the article text.

Anyway, simething tells me that we will run into some issues

I did not said that it is a perfect solution, just an idea

@brianteeman For the URL field I have already written the code

Did you create a PR for this?

For the media field: At the moment it is the case that no alt-tag for the media field is output in the markup.
Perhaps we could insert a text field in the custom field in which an alt-text can be inserted for all images for this Custom Fields together.

In my opinion it is usually the case that the pictures explain a certain aspect. So it is possible to formulate the text so, that is fits.

Of course, it's not that it's the best solution for adding an alt tag. But it is a compromise.In any case, the formal criteria are met.

@astridx I submitted the PR for the url field yesterday #27597

What do you think of it when we generate the alt text from the file name? For example, an image file with the name Aerial_view_of_Central_Park_in_New_York.jpg receives the alt text Aerial view of Central Park in New York.

@astridx that is not a solution. we can and must do better than that

The layout and the field are used in several places.

If you insert a text field here, this will also be shown when creating an article.
When creating an article, there is already a text field in which an alternative text can be entered.

Shall we create a new field (that inherits from the media field) and layout for the custom field?

However it is done when a user adds an image field it should include an ALT attribute input. It cannot be something they have to add as a separate field

closed as we now have a good draft pr for the media field