A11Y: Improve image ALT tag handling (we4authors cluster)

[tisto]

Status Quo

Current behavior when adding an image via the Volto editor:

1. Add new page
2. Add image block to the page
3. ALT tag is filled out automatically with the generated ID of the image

Screenshot

Current behavior when adding an image manually (to a page or stand-alone):

1. Add a new image content object
   -> no ALT tag can be specified

Screenshot

Improvement

We should make sure we have consistent handling of the ALT tag. Even though we technically make sure there is always an ALT tag filled out we might fool an automated a11y checker but this is not what we should optimize for. In most cases, the ALT tag will end up with the same as the image ID which is not helpful at all. A screen reader will read the image ID ("my-image-3234.gif") to the reader and this is not ideal.

See the w3c image decision tree for details about a11y recommendations:

https://www.w3.org/WAI/tutorials/images/decision-tree/

Key takeaways:

• Some images might not require an ALT tag ("decorative images")
• Therefore we can not make the ALT tag required
• An ALT tag with the ID of the image is rather worse than improving real accessibility
• We currently handle embedded image (has ALT field) differently from uploaded image (has no ALT field)

The main design decision we have to make is if an ALT tag belongs to the image object and stays the same when an image is embedded multiple times or if the ALT tag belongs to the image that is embedded. With the latter the same image can have multiple different ALT tags.

Sidenote: Using ALT tags should be consistent with image caption and image copyright information.

[nileshgulia1]

@tisto What I found on this is, If we add image manually(not using blocks), we get image alt tag as Title of the content. Whearas, adding through the blocks we have to manually edit it unless we want to use the image ID, which intern causes two alt tags for same image.

[tisto]

@nileshgulia1 good catch. I guess we want to use the image object alt tag as fallback in case the block-based alt tag has not been filled out. PR to fix this would be welcome. :)

[tisto]

This issue has been discussed for Plone Classic:

plone/Products.CMFPlone#2837
plone/Products.CMFPlone#2836
plone/Products.CMFPlone#2834

[tisto]

WordPress leaves the alt-tag field empty and adds a note below the alt-tag field:

Describe the purpose of the image(opens in a new tab)Leave empty if the image is purely decorative.

Link to: https://www.w3.org/WAI/tutorials/images/decision-tree/

That's in sync with one of the recommendations from the we4authors cluster results on the ALT-tag:

by providing clear instruction on when and how to write ALT-texts;

Source: https://accessibilitycluster.com/main-results/text-alternative-feature-%E2%80%93-presentation

[tisto]

@sneridagh I think as a first step we should:

1. Add a description to the alt-tag:

Describe the purpose of the image(opens in a new tab)Leave empty if the image is purely decorative.

Link to: https://www.w3.org/WAI/tutorials/images/decision-tree/

2. Remove the auto-fill of the alt-tag

What do you think?

@iRohitSingh could you imagine working on this next week?