-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[4.0] fields accessibility #27571
Comments
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. 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. This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/27571. |
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 |
For the URL field I have already written the code |
@Fedik having it as json makes it harder to index and search. |
|
@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.
I did not said that it is a perfect solution, just an idea |
Did you create a PR for this? |
For the media field: At the moment it is the case that no 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. |
What do you think of it when we generate the alt text from the file name? For example, an image file with the name |
@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. 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 |
This is to aggregate two separate issues that have the same base
1. Image field
This field needs the ability to set an ALT attribute. This is essential for accessibility
2. Url field
This field needs the ability to set the value to be displayed for the link. For example it would be better to display a url as joomla news than
https://www.joomla.org/announcements/release-news/5781-joomla-3-9-14.html
The text was updated successfully, but these errors were encountered: