Images alt attribute in an editing context

[afercia]

Splitting this out from #1309

One interesting thing we've recently discussed in the accessibility team, during the review of the new media widgets, is the different purpose the alt text has in the front-end and in an editing context (ie. when editing a post).

As a general rule, we all know that (I'll simplify a bit):

• purely decorative images should have an empty alt text alt=""
• images that convey relevant information, should use a meaningful alt text

However, when in an editing context, things are slightly different. Will try to do my best to explain. While editing a post, users need to know what the image they've added is.
When users add an alt text to the image because they want to communicate the image purpose in the front-end, that also serves the purpose to make the image recognizable in the editor.
However, when the image is purely decorative, users will set an empty alt text. That's perfectly correct for the front-end but it will also make the image not recognizable for screen reader users because images with an alt="" are just ignored.

Ideally, when in the editor, also images intended to use an empty alt="" should have something to make them perceivable and announced by screen readers. Not sure about the best option, but maybe this is something worth considering as a nice improvement Gutenberg could bring in.

As a reference, the solution implemented for the image widget was to remove the empty alt attribute in the editor when there's no alt value, so at least the filename gets announced. Not sure that's the best available option and maybe we could consider an improved solution.
xwp/wp-core-media-widgets#47
xwp/wp-core-media-widgets#50

[mtias]

One of the reasons we split edit and save methods is precisely because it makes this trivial. We can add whatever we need to the image in the editor without affecting what will be saved for the front-end.

[joedolson]

It would definitely be great for non-visual editing. We'll need some verbiage to make sure that it's clear when an in the editor is not what would appear on the front-end.

[afercia]

See also point 6. in the initial accessibility recommendations: #297

You may want to explore a method for making the alt text for an image visible while editing, plus an easy way to edit it. While the alt text may come in from the media library, context means it might need to change on a per-use basis. Showing it is a good reminder.

[jeffpaul]

This ticket was mentioned in Slack in #core-editor by jeffpaul. View the logs.

[youknowriad]

Closing as no actionable items here like mentioned in the bugscrub. Let's open specific issues if needed.

[afercia]

Not sure why this issue was closed, seems to me it's perfectly actionable and it's also part of the initial accessibility recommendation from #297. Considered also the comment from @mtias

One of the reasons we split edit and save methods is precisely because it makes this trivial. We can add whatever we need to the image in the editor without affecting what will be saved for the front-end.

To recap:

• images with an empty alt="" are always ignored by assistive technologies
• in the editor, we need to add something to images with an empty alt attribute because that's the only way they will be exposed to assistive technologies
• something like This image has an empty alt attribute, the file name is blablabla.jpg could work; better wording welcome

[afercia]

Discussed during today's accessibility bug-scrub, this could be a good first issue. In an editing context, Gutenberg should try to give some feedback about the selected image even if it has an empty alt attribute. for example:

• The selected image is {silence}

wouldn't be so useful while:

• Image block: the selected image is DSC_234829347.jpg

would give, at least, some context.

[antpb]

Hi @tofumatt , I just noticed this was self assigned to yourself. If you don’t have any work already in progress, I have the bandwidth to get this one finished today.

[tofumatt]

I don't think I do, or if I do it's probably ancient. Go for it, thanks! (Feel free to assign me to review it!)

[antpb]

I've created a PR that should fix this right up. :)

The current string from the PR defaults to 'This image has an empty alt attribute, the file name is ' + filename

Are all in favor for this to be the message? I am open to others! @afercia what do you think?

[antpb]

For the sake of time on my end, I made a new PR that factors in all the recent changes to the image block.

Would love a review on #10960

We are still pending on e2e testing for the image block alt attributes, I'd like to propose moving those tests to a separate issue as I am not confident in learning/making tests with my current workload ahead of me. If someone would like to jump on making those tests, I'd really appreciate it. If not, lets try and get this in asap as this is a must have for 5.0 readiness. I've updated the inline-image tests in the PR so those should validate the alt values. The remaining e2e test needed would be for the image block as a whole.