Add alt attribute by default in Image Media Type

[deanleigh]

As part of the process of making Umbraco more accessible images should always have the alt attribute.
Therefore can we please add this by default to the options in the Image Media Type in all versions of Umbraco going forward.

Also, within the Umbraco Github Issues page please can we add Accessibility Issues so that people don't have to choose between a bug, a feature, or an open issue.

[nul800sebastiaan]

don't have to choose between a bug, a feature, or an open issue.

It's a feature request though, so that works. 😄

As part of the process of making Umbraco more accessible images should always have the alt attribute.

I think most media pickers already allow you to fill in the title attribute and as far as I understand, that one is good for screenreaders? Would it be superfluous to use both?

The reason we don't store the title/alt on the media picker is because often people want to give the media item context when picking it in your content. It could make sense to have some kind of default as specified in the media library though.

[marcemarc]

Also, whilst all images do require an alt attribute, it is not always 'appropriate' to populate that alt attribute with text, depending on the context of how the image is used - it is more nuanced than that! - https://webaim.org/techniques/alttext/ - with the rich text editor, insertion of a media item you are presented with the opportunity to provide a contextual alternative text (or not...) which seems the correct approach - but with the Media Picker or Multi Media Picker though, it's less clear on how to achieve this level of optionality and context specificity... eg if you have an alt text property on the media item it can be edited via infinite editing, but would change 'everywhere' ... feel like it could be somehow part of the picking process... but I do tend to have the fallback alt text on the media item, and then have ability to override it when it is used eg utilising Nested Content rather than a Multiple Media Picker... in those circumstances.

[deanleigh]

@marcemarc you are right that not all images require or should have content in the alt attribute.
Your comments indicate it could be 'not diosplayed' wher eit does not need to be.
For exmple:
An image is used:

1. as a large hero image in a single page
2. as a thumbnail link in an index page along with lots of others

In the second example it is perfectly complliant to use alt="".
Which of course can be done in the code that creates the thumbnails.

Therefore I would still maintain that a description of the image can be used in the Image Library and the choice to use it can be made in the context of it's implementation.

[ault]

The issue may be slightly muddied by the term "alt text". (Even though this is largely the context in which it would be used.)

I tend to name the field "Text Description". (description: Please provide a description of this image for users unable to view it.)

While users can override this, they generally do not. They realise that the description of the image need not change even if the context in which it is used does.

I think that providing this field on the default media type might encourage best practice; even if it is left up to the implementer to include it when they call the image.

[marcemarc]

yes @ault the tricky thing is making it clear it isn't best practice to always have an alt text! it's hard to override an existing default alt text value, with 'nothing' if the logic is that when nothing is provided the text isn't overriden ;-) - I mean you can implement a convention to workaround this, but was just wondering if something clever could be baked in during the picking process so the editor can decide the appropriate course of action.

Agree having a textbox on media might surface the concept of providing alt text, but then if you drag images in, to upload them, you need to handle the setting of it too...

basically it's really annoying having alt text read to you when, the surrounding text of the image explains the exact same meaning...

[deanleigh]

@marcemarc the UX patterns where the alt text is and isn't required are common repeatable patterns.
Very rarely would they be the choice of the editor and it would be up to the devolper to implement best practice.

[ault]

Do we need to address the implementation?

To keep things simple, having the field is an easy "nudge". Simple to put into Umbraco, and hopefully it will start a few conversations.

Once in place, and the conversations are ongoing, answers to complex issues may be more clear. Or not.

This seems (IMHO) to be a choice of an easy step that may encourage progress versus doing nothing and hoping.

[MMasey]

I wonder if the best course of action for this feature it to take a two pronged approach.

1. Add an umbracoAltText field to the standard Image media type, with appropriate accompanying descriptive copy for content editors.

2. Update the Media Picker & Multiple Media Picker data types to include a "use alt text" field. This could appear below the thumbnail image maybe. This would be stored as a boolean value which would then allow developer to control when to display alt text according to the content editors preference. I imagine if a multiple media picker is being used, then it will be an all or nothing for images in terms of alt text, and even if it wasn't it would most likely be something handle via the code anyway.

As for how the alt text should be used on the front end, I think maybe we could do more to help educate developers via the documentation. For example, information on how to use the new alt text field could be included alongside the Media picker documentation.

@nul800sebastiaan I don't think the title field is a good substitute for alt text. From a content editors point of view, I don't think anyone views the title field as where they should put alt text. Considering alt text could potentially be a few sentences long to describe the image, it doesn't fit into the same category as a title.

We should probably take into account it being a potentially breaking change, in case someone had added the field themselves. That being said, if it's just a schema change it could be fine.

[nul800sebastiaan]

I also think it's fine to add a description/alt/title to the media item itself, but I would still say it should not be the leading thing. You're still presenting the image in a context and that will a lot of the time make the alt/title different from what it was when you first uploaded it. So maybe it could be a suggestion that they can pick or enter a new description.

From what I understand, after a bit of reading:

• title is not useful for screen readers and not even super useful in all browsers, recommendation is to not use it
• alt is not just useful for screen readers but also shows the text on the screen if the image can't load
• alt is not required: "if a non-visual user would not miss the image, don’t describe it."

Finally: how do we make this clear to content editors? From an editor's point of view they don't know what the alt attribute is exactly. So I am not sure what to present to them "describe this image in the shortest way possible, but only if it adds context"?

Considering alt text could potentially be a few sentences long to describe the image, it doesn't fit into the same category as a title.

As far as I understand, it really shouldn't be whole sentences... that would be better done in the actual text surrounding the image.

We should probably take into account it being a potentially breaking change, in case someone had added the field themselves.

Not necessarily, in a migration we can check if a property with that alias is already there and then not do anything, right? Maybe I'm missing something.

[MMasey]

Yeah I agree that it the alt text shouldn't be the leading field, maybe it sits under the thumbnail? There is nothing in you're feedback I don't disagree with 👍 I was pretty tired when I wrote the part about alt text being whole sentences, you're certainly right on that part.

For some a potential idea, here's an example of how we set it up in our projects.

If it's built in then we could take advantage of the translations for the descriptive text for the field too. Maybe we could provide a link to https://webaim.org/techniques/alttext/ for anyone wanting to learn more about it?

In regards to breaking change, if you're able to check for the property then it shouldn't be an issue. There may end up with some installations having multiple alt text fields, but I can't imaging that being a major issue.

[marcemarc]

Pretty much, agree with everything in this thread,

We all want editors and developers to be more aware of the notion of providing alternative text descriptions for images when they are used on a website, and adding a permanent field in the media type for alternative text description, is largely what we all do on sites at the moment to try to facilitate this.

Having this field as part of default Umbraco MediaType for an image will help 'surface' this consideration for others, instead of people using the media 'Name' by default... which can lead to the horrible experience of alt="2345343.jpg" if the image has been dragged into the uploader.

The complication is this move doesn't necessarily lead to better accessibility, as it is all about the context that the image is used in, the particular site, and the text around it. It is easy for people to mis-grasp that 'all images must have an alt attribute' means 'all images must have an alt text description' - but I'm not sure how the CMS can educate that? eg does having the default Alternative Text Description as part of the Media Type, endorse the 'all images should have alt text' mantra?

Long term having the CMS actions support the good practice of allowing editors to set the appropriate alternative text (or not include it), depending on the context the image is used in should probably be the aspirational goal...

... but for now, this step would probably improve the current situation and so has merit in its own right.

It's all about whether you want your site to be more accessible for real people, or pass automated accessibility tests!

In terms of editors, it is their responsibility to understand how to write content for the web, and how alternative text descriptions for images work - it is the job of the developers and CMS tools to support them in those endeavours. So yes calling things 'Alt' might be less helpful than 'Alternative Text Description (AltText)' if they are unaware of the HTML attribute name... but the notion of screen readers consuming the content being edited should be a familiar one.

@MMasey crazy probably unachievable 'spin off idea', how about Umbraco 'Preview' has an option to 'read the page'? or a 'text only browser' preview of the content?

[deanleigh]

Sorry for starting this and not responding for a bit but you have all been saying almost everything I would have!
I would like to clarify a few things:

alt attribute

Let's start with best practice and call this by it's correct name "alt attribute", an attribute of the image element that provide a description of the image when it is not visible - i.e. either for technical reasons or human ones.

alt text

This is most commonly used to refer to the text that is displayed on the page when the image is not or is read by assistive technologies.

title attribute

The title attribute is a global attribute and as @nul800sebastiaan has correctly pointed out has fallen out of favour for accessibility purposes. I personally don't think we should be conflating alt and title in this issue at all.

Use in the back office

Before we even consider the use of the alt attributes for the front end user I believe we should be considering Accessibility for the back office user. To this end I propose that's all images should have a description within the media library.
I personally would make it mandatory but I can see that would be a lot of objection to this.

By having a description for every image a partially sighted or blind user would have much greater accessibility within the media library.

Use in the code

As developers we have an incredible amount of control over how and where the text can be used.
Previous comments have highlighted there are most certainly situations where an image is being used for decorative purpose and therefore a Null alt text should be used.

If for example this was a grid of products, as in the Umbraco demo site, then the accompanying text would act as a good description for the images and a 'Null' value could be coded into that feature.

I can see issue with RTE's but I think many of us are restricting them to text only in favour of Image features in new block editors.

Use in the front end

Lastly, but most importantly, front end users adding images should get the description by default. Again developers can offer the choice to overwrite it or even make it 'Null' but I can guarantee most will be left in.

It is great to see this being taken seriously, it will be something that gains respect for Umbraco within the industry for sure.
Do we have any blind or partially sighted users within the community who would we can consult?

[deanleigh]

This initiative was announced yesterday which may prove useful for this issue:
https://www.a11yproject.com/checklist/#images

[nul800sebastiaan]

Hey all! Thanks again for your input! We had a good chat about this at HQ and of course came to the conclusion that I was coming up with a lot of challenges, but forgot to ask the one simple question: is adding an alt text property to each media item better than what we have now? Obviously: yes, yes it is. Baby steps make things incrementally better.

So we wholeheartedly invite you to help make Umbraco better please and thank you for the discussion, super interesting! 🙏

[umbrabot]

Hi @deanleigh,

We're writing to let you know that we would love some help with this issue. We feel that this issue is ideal to flag for a community member to work on it. Once flagged here, folk looking for issues to work on will know to look at yours. Of course, please feel free work on this yourself ;-). If there are any changes to this status, we'll be sure to let you know.

For more information about issues and states, have a look at this blog post

Thanks muchly, from your friendly Umbraco GitHub bot :-)

[deanleigh]

One thing I have since realised is Media includes things like PDF as downloads which do not meet the same criteria. In our old classic ASP CMS we had an Image Library and separate Document Library (we faithfully recreate this in Umbraco). We also had a Link Library to store and manage external links.
If we are to review images then perhaps the Media Library could be reviewed as well for different 'types' ?
For example it could be renamed Libraries and include all three types?

I know this would need to become a separate issue but how do you all feel about this?

[dawoe]

How will this be handled in multi language sites. Media items can not be made culture variant. I have a property editor lying around somewhere that I used on multilanguage project.

[deanleigh]

@dawoe I think that is another issue that needs addressing.
@ault how are we handling the multi-language PDFs btw ?

[ault]

How will this be handled in multi language sites. Media items can not be made culture variant. I have a property editor lying around somewhere that I used on multilanguage project.

Messy... either a separate image for each language (many of them repeats, a clear nightmare when a file needs replacing) or an "Image Library" in the root with multicultural doctypes that include an image picker. One would essentially duplicate the alt-text field at this level and ignore the one in the media. Users would then choose images using a MNTP to select content nodes that would then corelate back to the media record.

@deanleigh the 'library' option is how we manage the pdf's in multi-language sites at the moment.

[nul800sebastiaan]

@deanleigh I am not sure what you mean with the libraries but that's a whole different feature request. On our long-term wishlist is a complete overhaul for the media library.

We have to accept right now that the media library does not support multilingual features. For things like adding an image to the rich text editor this is not a problem, we imagine that the alt text travels to the media picker and there you can edit it before you insert it in the rich text editor.

Make sure to watch out for super scope creep on this one, I know it's very easy to do and we did this while talking about it, but let's start with the simplest thing that works and than take the next simplest thing that will work then, and so on.

[dawoe]

How will this be handled in multi language sites. Media items can not be made culture variant. I have a property editor lying around somewhere that I used on multilanguage project.

Messy... either a separate image for each language (many of them repeats, a clear nightmare when a file needs replacing) or an "Image Library" in the root with multicultural doctypes that include an image picker. One would essentially duplicate the alt-text field at this level and ignore the one in the media. Users would then choose images using a MNTP to select content nodes that would then corelate back to the media record.

@ault I created a property editor that shows a textbox for each language configured in the backoffice for editing the alt text. Through a property value converter I get the alt text for the current language the site is displayed in.

Will see if I have time to package it up

[janjulius]

@dawoe Have you got around to packaging it up?

[leekelleher]

@dawoe Have you got around to packaging it up?

@janjulius I know it's over a year later, but I was just reading this thread and remembered that @dawoe did release the package: https://our.umbraco.com/packages/backoffice-extensions/multilanguage-textbox/

[elit0451]

We are currently converting our feature requests to discussions, so even though this one has stalled, I would do the transfer to keep the good ideas.

[deanleigh]

I am glad this issue has not disappeared from the agenda!
It seems the first issue to resolve would be making the Media Library Multi Language.
@nul800sebastiaan Does that require a new Feature Request?

[iOvergaard]

Yes, the media library has to support variants before we can add an alt text field to media in a meaningful way. This feature is currently something we are tracking internally with no fixed date set yet.

[JasonElkin]

In a site that allows crops, there's a chance that the alt text will be wrong.

e.g. depending on how I crop this it's either a photo of a dog, a cat, or both.

Really, I think the cropper needs to store the alt text, with the ability to modify it per crop. If it's set on the cropper itself then the alt text could also be applied when looking at the image in the backoffice via media pickers etc.

[deanleigh]

Agreed - we already have a Fallback Text Editor package and would invisage the user would be presented with the option to the Alt text from the library or create a new one.
We invisage where alt text is not required can be handled in the code.

[iOvergaard]

Also agreed - it makes sense to have alt texts stored on each crop. Would probably be possible to implement in a meaningful way even before the media library starts supporting variants. If we eventually get to add alt texts on media items, we would then have an implicit fallback if the alt text is not overwritten on a crop per se.

[iOvergaard]

I just want to provide an HQ update.

As of writing, there is a prerequisite before adding alt texts on media items: We need the media library to support variants. This is something we are currently tracking internally and unfortunately, something that has no fixed date set yet.

Adding alt texts on the image cropper is probably something that can be done either way, where we then later let the alt text on the media item act as a fallback.

This feature will continue being marked up-for-grabs if anyone wants to give a take on the image cropper.