https://discord.umbraco.com logo
Powered by
Alt Text Support in Umbraco
# umbraco-chat
l
Currently Umbraco still does not support adding alt texts on images by default, right? And I mean alt-text that are specific to where the image is used, so I'm not talking about an alt-text on the media item itself. I was positive that there were at least some discussions or issues on github about this, but I can't seem to find them. I want to do a proposal on how we can do this, but I wanted to read past discussions before I do. I also want to do a PR if the idea is OK. Any of you have an idea?
j
The problem is crops. When you crop an image, you change what's in the image. So you will likely need different alt text for certain crops.
l
Sure, I understand that there are certain challenges. But simply NOT having alt texts in a CMS is just plain weird to me
j
Oh, totally. There's just no nice way of doing it, just a less bad way.
m
https://our.umbraco.com/forum/using-umbraco-and-getting-started/101782-inserting-media-images-into-rich-text-editor-v8 back in v8... (alt text and I think caption on mediapicker v1) and if you have crops (aliases) specified local or global can we not just have altext set for each crop you choose to edit? or a fallback to the default if nothing specific for the crop.. I know we then have issues with manually created crops..
j
Yeah, so thinking along those lines you'd need: 1. Global alt text 2. Alt text field for each crop, falls back to global. 3. Local/contextual alt-text override 4. Local/contextual alt-text override for each crop.
m
and vary by culture 🙂
j
And this would need to live inside the image cropper UI.
Exactly
Which causes a problem, as you may not want to vary the image itself, or its crops by nature.
m
I guess you could hack something together.. where you know your crop aliases.. and add alt texts for each crop editor into the media properties? as a more simple starting point?
j
Yeah, which some people do.
m
I seem to remeber an imagecrop alias picker that could be used as a starting point for a ((crops alias alt text property editor))? for use on a media item.
j
The problem is what will and wont work changes depending on how a given implementation chooses to do things, e.g. mulit-lang.
You can't vary by lang inside a property editor value.
And you can't really force properties to be dependant on/controlled by each other.
Umbraco's content model just isn't geared up for this given the way that media works.
m
but you can enumerate the langs and have a tabbed interface?
j
You can but that' svery different to anything umbraco currently does. Also, what if you do want to vary images by culture too... it's messy.
m
if you vary image by lang.. it simply takes the relevant media item lang/crop text?
r
I’ve been in the room and had this conversation a few times .. it’s weird to see it playing out in text..
j
Basically, there's a reason this feature doesn't exist. And that's because its really very hard to do given how Umbraco works.
m
So we admit defeat and nothing even the simple no context alt text isn't surfaced?
just alt="medainode.Name" 🙂
j
No. People already do alt text just fine in Umbraco, but they all do it different ways depeding on their content models.
Because that's what actually determiens what will/wont make sense
r
I think the basic idea is valid . It’s the actual implementation that’s tricky , how much to hide from a user, and how much to do as work around. Unless there is contextual way we can determine if some thing is a crop And see if it has an alt we can fall back and then display an alt field for filing on change .. I’m with Jason. It’s not we are admitting defeats , we just need someone to crack, or help us crack the paradigm.
j
And people can (and will) implement all kind of weird and wacky content models that we can't account for in core or a nice all-in-one package.
r
But maybe there is a conversation needed to see if we can try and standardise it..
j
Global blocks might make that easier... where there's scope to link properties together for re-use. Have an "image" global block that contains both the picker (with or without local crops) and a separate alt text property editor.
r
Ooh that’s a “nice idea”
j
Alt text property editor can be configured to "target" the image property and provide relevant text boxes that match the picker's crops.
(just an idea)
m
ps the docs are advocating just a simple alttext on a media item (in one sample).. that doens't exist.. 🙂
Copy code
@using Umbraco.Cms.Core.Models
@{
    var typedMediaPickerSingle = Model.Value<MediaWithCrops>("media");
    if (typedMediaPickerSingle != null)
    {
        <img src="@typedMediaPickerSingle.MediaUrl()" style="width:200px" alt="@typedMediaPickerSingle.Value("alt")" />
    }
}
j
Then there's a nice distinction between the media library (files that exist for general sharing/resuse) and "images" that exist for rendering in a web context.
r
Actually that may be an answer, have them as two separate properties.. it’s a dirty way and a way I have used. .. Actually I like the contextual crops and alt text idea
That’s sounds like a query for the docs team, and or a pull request for Mike chambers. To get a change made
m
I thought I might have already done it.. must be loosing/lost my marbles.
s
Umbraco also doesn't have pages by default either.
r
As a member of marbles I have lost many club.. it’s fine .. fine.. just fine
m
sorted a pr now before I forget my own name.
r
It does make me think this is big idea that needs a bit of thinking and a fix maybe in mentality .. or maybe an extrenal opinion .. how would you do it with no constraints and then work in some bits and bobs .. give people a better starting point rather than lots of different ways to do the thing.. ..
s
But you could say that about content and pages too.
Having a default built in way would imply that as the only option, and then people would start hacking away. Much better to leave open for implementation.
m
Isn't that where all this started though.. with nothing there, there's a why does this CMS not handle the simplest of alt text additions? or are we saying that 
<img src="@image.Url()" alt="@image.Name" />
is acceptable as that simplest option? which fails as soon as editors bulk upload images from a camera and umbraco tries to use all the wild and wacky image naming conventions of cameras/phones... not sure adding an alttext property to the media element, so at least there is something there, is such a bad first step.. you don't have to use it, or would use it as the root fallback, and can easily remove it too?
l
I personally think that when I use a media picker, it should give me the option to set an alt per selected image. This way it already supports variants (because it's part of the property editor's value. A default fallback would be nice, but then again, an alt text is very dependent on usage of the image, so I'm not sure if a fallback is really a good thing. It's ugly, but if you were to display a alt textbox below each selected image, you already cover a lot of scenario's, right? (Albeit ugly :P)
m
I like the fallback on the media asset itself, for the pure reason it might not need any contextual alteration it has one element and crops only focus on that element, or I use it full native size in all scenarios, and it's only a single language site. I also don't as an editor want to have to go and find all instances of the use of that image and update the contextual alts, if I happen to change the image? but get that that's the jist of contextual too different alt.. Media library being the single source of truth, I guess..
d
it's my intention to reinstate or perhaps recreate a package that we It sounds really useful for allowing us to have alternative text in the media library on an item but override it when it gets used in the page. However, @Jason makes a good point regarding crops although to be fair in most of our projects the crops were tightly defined in the templates. https://our.umbraco.com/packages/website-utilities/wholething-fallback-text-property/
l
From an editor perspective you are right, but from a SEO perspective, an image alt is just very dependent on where it's used. I feel like if you set a fallback, the user will just use the fallback because it's easy. And ofcourse media is no variant by culture
m
is the fallback better than nothing though?
l
It depends, SEO-wise, an empty alt can tell that an image is not relevant for the page
m
at some level it must describe the image.. even if the context might require a slightly different alt.
l
Our current ugly approach is to use a block with an image picker and a textbox. I hate that approach The second approach is to create a property editor that use the media picker component set to only one image and also adds a textbox for the alt. But I'd much rather have the full support of the media picker where you can specify an alt for each selected image. I think that would cover variants, crops, everything
d
Just to be all modern and trendy can I throw AI into the mix In a current project I am using Umbraco AI to generate the alternative text for me and also descriptions of images to be used as overlays in slide shows for example and I'm finding yet is working really well for this particular project. However this morning I ran into an issue where the image was too large for Claude to process which made me think why am I sending such large images to Claude in the first place so in the last hour purely by chance I've been investigating does the syntax support crops and yes it does so in theory we could generate descriptions for each crop. https://cdn.discordapp.com/attachments/1493169827647459449/1493220590859845673/image.png?ex=69de2d8b&is=69dcdc0b&hm=0ca2d9515d7fea602e2d674c281576754e7737048b93f427399f8c8830ad19c5&
l
Yes, I always thought that as well, but I've learned that the alt can vary wildly based on how it's used. I don't have an example at the moment, but I'll check if I can find something. But my idea was also: why not store it at the media node itself. But that's not good practice.
m
Are we also maybe advocating that a block in a grid, or rte is where this context happens? And not necessarily if this is just a media picker in a doctype? (again back to how this was implemented in v8?) 🤷‍♂️
d
Hmm I may have misunderstood what @Matt Brailsford means by > The property value is read from the entity (supporting media picker JSON, image cropper JSON, GUIDs, and file paths) I was hoping I could add {{image:umbracoFile.content3Col}} to {{image:umbracoFile}} but this does not work
r
That my solution
Cat and dog
Dog
Cat pic
Some source but diff crops
m
If only that simple.. as the context of the page content around the image could change it again... even the simple "Describe the information, not the picture"
d
I'm confident we will be able to address this shortly @Mike Chambers By adding alternative text in the media library, we are describing the image in isolation. However, as you say, we may need to add a small amount of context to the alternative text whilst "in page". Therefore all we need to do is be able to override the default alternative text being provided by the media library when we place the image. Whilst in the past doing this manually was quite a chore I think this is the kind of thing AI can handle successfully on our behalf. @Matt Brailsford Very kindly added the ability to create prompts for different crops yesterday so hopefully that will be released very soon. So shortly we will have the ability to create different alternative text that will address @Ravi example above then all we need to do is overrides to whatever solutions we provide for adding images to pages.
l
And I think if you actually want to do it right, you should ALWAYS write the alt text in the context and not only when it deviates from the generic description. This way you are forced to think about it. I think that if you provide a default alt, editors will just always take that.
r
Thi is a fair point and maybe that is the base interaction we have to solve it for
d
I agree the context should always be correct however the generic alternative text in the Image library should be suitable in 99% of cases and the change of context would very much be an edge case. So what we could possibly do is prompt the user to read the default text so they have to approve it e.g. Please review the alternative text provided by the Image library does this fit the context of the current content? How does that sound?
l
I like the idea and I think that's a good compromise. But to be completely honest (and maybe that's unfair), but I don't think editors in most cases won't really care all that much and have no idea how to write good alt-texts. I think they are just gonna click 'approve' the same way most people treat cookie banners 😄
d
> I think they are just gonna click 'approve' Most will if they have to rewrite it but… If we make it very easy so that AI suggests it for them: 📎 I see you're about to add an image using the generic alternative text Have you read it properly first I can rewrite it for you for the context of the page just by clicking "…"
m
It's almost an anti pattern then to have a centralised media asset in the library, and should be just an upload image property to the content (as image + crop + alttext becomes unique to the single content location)? Changing the media asset in the library could mean all the alt texts then need revisiting, with no existing mechanism to easily do that?
Not sure that we should have a dependency on AI integration for image alt tags though 🙂
d
I have been investigating rewriting the alt text on upload but as you cam imagine it starts getting very complicated very quickly.
In my heart I agree but unfortunately users will expect this as it will be the case in every other CMS. Also, it won't be long before AI can write much better ALT text than most humans. Therefore, for Umbraco we just need to make it work as good as it can be.
m
to turn it on it's head... will it be the responsibility of the CMS then... when AI in the browser could probably do a much better job (or screen readers) 🤔 🤖
d
That is a conversation I am seeing happening right now and the browser vendors are very much involved so I guess watch this space.
r
I was in the midst of writing this response and the. Work ..but you have gone sort of down the route I was thinking This was my very simple opener to start a conversations, so that we can have. .. but may be that the thing to focus on .. how do we encourage user to fill in the information correctly.. (either through a generative ai mechanism ) or editor notes that are designed to help How do we make it easier for. Ow in til such time as ai, or browser tech improves so that we get the desired help… I like the ai suggestions or help, but its user focussed and they have an opt in action.. so they commit to it
d
Hey @Ravi - you know you were talking about a community project that could get everyone on board I think this would be a perfect example. What do you think?
r
Possibly .. it had occurred to me
l
Another problem for a 'default alt text' is that you can't just set it on the image. Images don't have culture variants, so you can't set multiple languages if needed. I used to create a property per language on boot for some project, but that's not ideal
d
I thought cultures were on the To do list when the media library gets a revisit? Then again I am very old and I may have just dreamt this 😂
l
Media items are just nodes in the end, you should be able to do everything with them like content. So set permissions, variants etc. Hope we'll see that someday
m
allowing versions/roll back would be expensive if you are anticipating keeping all versions of the linked physical assets. 🙁 There is something semantically different about a content repository over a media repository... So not entirely convinced that the media aka assets store should be seen just as a content repository. But if you want it like that then why not just recreate the media types as content types and have them as content (with a media libary that is just a name+asset)? 🤔
l
well, maybe you are right. Although multiple versions could have the same file ofcourse. In Sitecore (eeew), everyting was an Item (node). So media, content, templates (document types). So for instance, all permissions could be applied to everything. So if I denied you read rights on a certain template/document type, you could not see it in the list of document types that you could add as new content.
m
We do have media start nodes for a user... and looking for that when did granular permissions on documents and doc prop values arrive for user groups.. could be nice to have that for media too... (you can't edit the company logo for instance....) https://cdn.discordapp.com/attachments/1493169827647459449/1493980070501417101/image.png?ex=69e0f0dd&is=69df9f5d&hm=d17028d2abbbfed2ba52b4ebaa453715b070d0b0f4ddd4dc28bc81747d80e8a2& https://cdn.discordapp.com/attachments/1493169827647459449/1493980070845485247/image.png?ex=69e0f0dd&is=69df9f5d&hm=e638a78635a0cd890c8ba40760f18094ee757178d99efb1ea809bbce341bd6a8&
m
Hey folks 😄 ust wanted to let you know i'm working on some improvements to the image cropper in a PR i'm hoping to get ready for review soon. From what I've seen in this chat, I think i've been able to solve a lot of the issues raised i this discussion (and my other of the others i've had with people over the years). It'll likely not be perfect, and I plan to include a detail video going through all the changes I have made. My aim has been to do his in a way that is "Umbraco" and friendly as possible. I'm hoping this will help to maybe get the ball rolling, even if it just helps to give some direction for a final, viable improvement. Once its ready, i'll drop the link here
d
Well done @Mike Masey - long overdue
m
Just in case you don't use media in the RTE... that's missing crops but does have contextual alt text (and a caption)! Just in case you feel the need to give that some love too and bring parity and shared ui 🙂 https://cdn.discordapp.com/attachments/1493169827647459449/1517454964304117931/image.png?ex=6a365790&is=6a350610&hm=bd15c734fee990afeeda94599f65358bd4c91ba81de2e144a82ea24b4ee20941&
m
I’ll see what I can do ☺️, although that editor works based on a different configuration I think due to being TipTap extension. It’s also going to be a big code change too so might have to look at it after as it is kind of separate. At least it already has some form of alt text haha
I imagine it would be a more complex update thinking about it, especially if we tried to add crops, we we’d then need to way to determine how they are used when the RTE code is rendered
m
I think the functionally is already there.. just rte use rmode=max and the w/h settings.. 
<img src="https://localhost:44392/media/rt3lonr2/seafront-15.jpg?rmode=max&width=200&height=133" alt="Bincombe Park seafront 3" width="200" height="133" data-udi="umb://media/36b7fa8a303c48fc9d3621d0ff16c2f1">
https://github.com/umbraco/Umbraco-CMS/blob/main/src/Umbraco.Infrastructure/PropertyEditors/ValueConverters/RteBlockRenderingValueConverter.cs 
sourceString = _imageSourceParser.EnsureImageSources(sourceString);
https://github.com/umbraco/Umbraco-CMS/blob/main/src/Umbraco.Core/Templates/HtmlImageSourceParser.cs just tack on the crop height/width attributes instead...
m
Cool, would also need to handle how to decide which crop to use, if there are multiple ones available. Could end up being an extra bit of UI just for the rte, adding more flexibility
m
global crops might be easier first.. rather than local crops to the rte image.. and probably make more sense for the editor experience?
m
I do think it'll be possible to do, but probably best left as a separate project as this will be a big enough merge as it is haha (if by some miracle is gets to that point)
And it depends on what you mean by global crops, as we can already do that can't we?
It's more how to get the rte image to use the ones you want, rather than the only options it currently has
r
Ooh fancy and the video is too
13 Views
PreviousNext
Powered by