Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Images alt attribute in an editing context #1520

Closed
afercia opened this issue Jun 27, 2017 · 11 comments

Comments

Projects
None yet
8 participants
@afercia
Copy link
Contributor

commented Jun 27, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Jun 27, 2017

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

This comment has been minimized.

Copy link

commented Jun 27, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Jul 12, 2017

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 comment has been minimized.

Copy link
Member

commented Feb 15, 2018

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

@youknowriad

This comment has been minimized.

Copy link
Contributor

commented Mar 6, 2018

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

@youknowriad youknowriad closed this Mar 6, 2018

@afercia

This comment has been minimized.

Copy link
Contributor Author

commented Mar 6, 2018

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 afercia reopened this Mar 6, 2018

@danielbachhuber danielbachhuber added this to the WordPress 5.0 milestone Jun 4, 2018

@afercia

This comment has been minimized.

Copy link
Contributor Author

commented Jun 25, 2018

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.

@tofumatt tofumatt self-assigned this Sep 6, 2018

@antpb

This comment has been minimized.

Copy link
Contributor

commented Oct 10, 2018

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 tofumatt assigned antpb and unassigned tofumatt Oct 10, 2018

@tofumatt

This comment has been minimized.

Copy link
Member

commented Oct 10, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Oct 10, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Oct 23, 2018

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.

antpb added a commit to antpb/gutenberg that referenced this issue Oct 26, 2018

antpb added a commit to antpb/gutenberg that referenced this issue Nov 2, 2018

antpb added a commit to antpb/gutenberg that referenced this issue Nov 5, 2018

antpb added a commit to antpb/gutenberg that referenced this issue Nov 12, 2018

antpb added a commit to antpb/gutenberg that referenced this issue Nov 12, 2018

@aduth aduth closed this in #11218 Nov 12, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.