WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 4 months ago

#41467 closed enhancement (wontfix)

Disassociate image alt text from media object

Reported by: mor10 Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Media Keywords:
Focuses: ui, accessibility Cc:
PR Number:

Description

Sounds confusing, but bear with me:

Image alt text should not be a property of the media object because the alt text of the image will change depending on what context the image is presented in. Saving a "default" alt text for the image as we do now promotes a misunderstanding of the purpose of the alt text.

Unique alt text should be added for each instance an image is used to ensure it follows the Alt Text Decision Tree (https://www.w3.org/WAI/tutorials/images/decision-tree/) and is accurate to the current context the image is presented in.

Change History (10)

This ticket was mentioned in Slack in #accessibility by mor10. View the logs.


2 years ago

#2 @carlseibert
2 years ago

Hi. Sorry to appear out of nowhere.

I (mostly) disagree. The use case here would be images that are to be reused and would need variable alt text. That's a small slice of the collection. In my experience, when an asset is one that is reused, it's static, nine times out of ten. If you have "Mark V Widget in use", each time it's used, it may be associated with different "real text" (as the W3C calls it) in the caption or body of the post - "Mark V sales....", "What follows the Mark V...", but the picture will be "Mark V Widget in use" every time. (As per the W3C standard.)

Laziness aside, re-keying the alt text each time the image is used would lead to inconsistency. Vision impaired users wouldn't know whether it's same old Mark V picture or a new one.

That said, I wouldn't mind having something in the editor UI that would let me know whether alt text was filled, and what it says.

#3 @joedolson
2 years ago

I'm inclined to agree with @carlseibert - (and thanks for chiming in! No need for apologies!). While I can see where the argument is coming from, I think that the need to change the alt attribute by usage is more of an edge case. It is true that every usage of an image should come with consideration of the alt text for that usage, it would frequently not result in the need to provide separate alt text.

Additionally, I see no benefit to the end-user to increase the amount of labor required to make use of alt text in the editor. I could imagine a benefit to allowing saving multiple alt attributes for a given media object; a default attribute and a set of alternates you can select, but I don't see a benefit to removing it from the saved data.

FYI - There is already a method to check the alt text used for a given image in the visual editor (using a mouse, click on the image to display the edit menu, then click on the edit icon (pencil) to edit the properties of the image; more difficult with a keyboard, but I can describe that if you need it.)

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


2 years ago

#5 @afercia
2 years ago

  • Focuses ui added
  • Milestone changed from Awaiting Review to Future Release
  • Version trunk deleted

Discussed a bit during today's bug scrub, maybe we should start thinking at a better UI first.

This ticket was mentioned in Slack in #core-media by bahia0019. View the logs.


2 years ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


2 years ago

#8 @joedolson
2 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

After further discussion, the a11y team feels that this is really a UI problem, and not a data modeling problem. While it's not unreasonable to break the object apart, it doesn't actually solve the problem, which is getting people to clearly understand that alt attributes are context sensitive, and that you are not necessarily describing the image itself, but the usage of the image. This requires UI changes.

This ticket was mentioned in Slack in #accessibility by sergey. View the logs.


6 months ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


4 months ago

Note: See TracTickets for help on using tickets.