Allow or force editors to provide alt text for Image content items

[skleinfeldt]

When creating or editing an Image content item, there should be a (new) field for entering alt text. The contents of this field should be put into the alt attribute of the image when it is viewed by itself (as an image object). The image's markup should never include a title attribute. This is considered redundant to the alt text which is the proper way to convey the image's meaning to those using screen readers. Note that when displaying the image object the Title and Description will show and will be read by screen readers; the alt text should be a non-redundant description of the image itself.

If the accessibility control panel (#2834) is set to force editors to enter alt text for images, then the alt text field will be required.

Field name: Alt Text

Help text: Briefly describe the meaning of the image for people using assistive technology like screen readers. This will be used when the image is viewed by itself. Do not duplicate the Title or Description fields, since they will also be read by screen readers. Alt text should describe what a sighted user sees when looking at the image. This might include text the image contains, or even a description of an abstract pattern. This field should never be left blank on sites that want to be compliant with accessibility standards.

[hvelarde]

The alt text attribute can be empty indeed; it has to be present, but it can be empty:

https://webaim.org/techniques/alttext/

[skleinfeldt]

@hvelarde please see #2836 which describes the situations when alt text should be empty. These situations can occur when an image is used within rich text. That is a different piece of alt text, which is filled out by the editor of the rich text when inserting the image, to convey the meaning of the image in context. The situations when alt text should be empty won't occur when an Image object is displayed on its own, thus the alt text in this case should always be present and describe the image.

Therefore @polyester and I decided the current behavior is a bug, in addition to the feature request associated with #2834.

[hvelarde]

thanks, in this case I agree with you; nevertheless an issue can't be a feature request and a bug report at the same time.

[iham]

Looks like this is still a thing: leadimage-alt

[tisto]

FYI: this is one of the issues that we are discussing in the we4authors cluster:

https://funka-my.sharepoint.com/personal/funka_funka_com/_layouts/15/onedrive.aspx?id=%2Fpersonal%2Ffunka%5Ffunka%5Fcom%2FDocuments%2FProjekt%2FCluster%2FLive%2Ddocuments%2FWe4Authors%20Cluster%20Report%20on%20selected%20accessibility%20features%2Epdf&parent=%2Fpersonal%2Ffunka%5Ffunka%5Fcom%2FDocuments%2FProjekt%2FCluster%2FLive%2Ddocuments&originalPath=aHR0cHM6Ly9mdW5rYS1teS5zaGFyZXBvaW50LmNvbS86YjovcC9mdW5rYS9FWWthMTlHZXduWk9xUFU4Q1UtWDNpUUJwMTRNaEdXTElnVDZZejRuaXd3ZXFBP3J0aW1lPXBBaEpocFF3MlVn

https://github.com/plone/Products.CMFPlone/issues/2836 is an interesting read and goes into the directions that we are discussing. I'd be happy to discuss how we can implement this in Plone 6 (Volto). We got some funding via the we4authors project on this and we could assign one of our devs to implement this when we reach an agreement on what exactly we want to accomplish.

[iham]

Can’t login … would love to read, but first I’ll need an ms-account ;)

2836 seems done to me, as tinymce (not volto - i know) allows you to add a different text alternative. Sadly for leadimages this is not possible.

I would love to see a solution in both worlds (plone classic and volto) as i see need for it no matter how the frontend is implemented. But i am happy to see its a topic in both worlds!

On 16.06.2021, at 09:04, Timo Stollenwerk @.***> wrote:

 FYI: this is one of the issues that we are discussing in the we4authors cluster:

https://funka-my.sharepoint.com/personal/funka_funka_com/_layouts/15/onedrive.aspx?id=%2Fpersonal%2Ffunka%5Ffunka%5Fcom%2FDocuments%2FProjekt%2FCluster%2FLive%2Ddocuments%2FWe4Authors%20Cluster%20Report%20on%20selected%20accessibility%20features%2Epdf&parent=%2Fpersonal%2Ffunka%5Ffunka%5Fcom%2FDocuments%2FProjekt%2FCluster%2FLive%2Ddocuments&originalPath=aHR0cHM6Ly9mdW5rYS1teS5zaGFyZXBvaW50LmNvbS86YjovcC9mdW5rYS9FWWthMTlHZXduWk9xUFU4Q1UtWDNpUUJwMTRNaEdXTElnVDZZejRuaXd3ZXFBP3J0aW1lPXBBaEpocFF3MlVn

2836 is an interesting read and goes into the directions that we are discussing. I'd be happy to discuss how we can implement this in Plone 6 (Volto). We got some funding via the we4authors project on this and we could assign one of our devs to implement this when we reach an agreement on what exactly we want to accomplish.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[tisto]

@iham Sharepoint... :/

Here you go:

We4Authors Cluster Report on selected accessibility features.pdf

I am open to improving both Plone Classic and Plone 6 if that's possible and someone is willing to put effort into it. Personally, I will just focus on Plone 6 and not put any effort into Classic since we do not do any Classic projects any longer these days.

[iham]

@tisto thank you!

„An ALT-text means Alternative text“ - imho that is semantically wrong, as it is a text alternative. I know … pretty pedantic, but imho important as this transports two different meanings. Later this is stated correct: >>WCAG 2.1 Guideline 1.1 states that a site must “provide text alternatives for any non-text content”.<<

But back to leadimage: Correct me if i am wrong, but i thought an additional field (text alternative) on the leadimage behavior is agnostic in terms of volto and classic. Both have separate approaches to output that information.

dunno about volto (for now - will change), but in classic that’s a small tweak on the leadimage.pt i could do within minutes.

My „fear“ is about adding a field to the leadimage behavior nobody wants there for reasons i am not aware of and thoughts i don‘t find in docs. Like: „why is the title of the object used as alt for the leadimage?“ (makes not much sense to me and maybe that was only a hotfix to at least have an alt value after all.

But i am happy to discuss that and help putting that into Plone. ;) (Do you know contacts to involve into this? I don‘t think this needs to become a PLIP, as this would add more time i need to invest on that)

[tisto]

@iham in the we4authors cluster we discussed this quite extensively and always providing a text alternative for all images is considered to be an anti-pattern. Some images just do not transport any meaning. Sometimes the alt tag would just re-phrase what's already in the text next to the image. If you provide an alt-tag for an image in those situations you will make the page less accessible because you have lots of repetition. It would be easy for us as CMS vendor to just always use an alt-tag and we can be sure we would pass any automated test or audit. Though, making a page really accessible means that if you read the page content (e.g. with a braille reader) it is easy to read and process for the user. I am happy to discuss this further and present the findings we got in the we4authors cluster. Though, I'd do this in the corresponding Volto ticket, since this is what we got funding for to work on by the European Commission:

https://github.com/plone/volto/issues/1503

I agree that adding a new field is a possible breaking change and would need a FWT discussion and decision. In Volto those things are a lot easier right now since we do not have a final Plone 6 release yet.