Add ALT text field to upload form

[alexstine]

Currently, the upload form for ​https://wordpress.org/photos/ does not have a field for ALT text.

1. Let's add a field and figure out how to store the value. Maybe via postmeta or other custom field?
2. Let's figure out a good description text and where to link users on how to give their image good ALT text.
3. Should moderators try to ensure ALT text is giving images good descriptions? I hate to give others extra work, but I personally think it is important enough to warrant the ask at the very least.
4. Decide if ALT text should be optional. I believe it should not be optional that way screen reader users can enjoy the images as others can.
5. Should the ALT text be outputted so other users can copy it after they download the photo? That could be really cool. Helping users describe the image when they use it on their own site.

Hopefully this will help us start thinking about how to make this feature implementation a success.

[dd32]

Previously: #5985

(Thanks alexstine!)

[Otto42]

#6523 was marked as a duplicate.

[coffee2code]

Proposed change to the upload form. (The link would be to a help resource somewhere that explains how to write good ALT text. Ideally the reosource proposed in ​Learn#1463, or something else in the meantime.)

[Otto42]

Having two description fields is kind of pointless. There should be only one description of the image, and it should be the alt text for that image.

Suggest we rename the labeling for the description field to "alt text" and make it mandatory.

Also suggest going back and editing any descriptions we have, and make them suitable for alt text.

[alexstine]

Please note, ALT text is generally not visible visually. Would it be okay to do away with the visual description? The visual description would not have to be as verbose as the ALT text since ALT text serves the purpose of explaining the image to someone who cannot see it.

[Otto42]

The "description" in this case was always intended to be a description of the image. Basically, it's supposed to be the alt text. It's a photo library. We have no need for a "visual description".

In this case, the description being displayed visually would be the equivalent of what the alt text would be. It's not a "caption" as such, because a caption relates the image to the surrounding content. In this case, there is no surrounding content. It's just the image and a description of the image.

The purpose of the photo directory is to provide photos and associated properties surrounding them, such as the alt text description. We don't have a visual description and a different alt text description because, well, what would be the point? In providing the image available to WordPress sites we would include the description as the alt text. That was the entire purpose of it, from the beginning.

So yes, I propose that we replace the labeling of description with "alt text", make it a required field, and then go back and edit the description appropriately for each image, as needed. Also to replace the text field with a textarea. And possibly eliminate the 250 character requirement.

Note that this description is stored as the post_content. This because, for our purposes, we want that text to be the post content to be easily searchable. Storing it as a separate field, for example, as a metadata, makes it not as easily searchable. Additionally, having that alt text in a post_content gives us more to search on.

[alexstine]

Sounds good to me.

[coffee2code]

Otto's explanation pretty much covers our intent as to why only one description field was ever presented. There could have been more clarity on the matter sooner, but admittedly at the onset of the Directory it wasn't clear how much of an onus on moderators we were willing to require to help actually ensure the provided text resembled usable and appropriate ALT text.

Anyhow, I'm about to push up changes that implement everything according to the seeming consensus.

Here's a summary of what will be changed:

• To the upload form:
  • Rename the field from "Description" to "Alternative Text"
  • Make the field required
  • Increase field's input limit to 350 characters (this can be expanded or omitted later)
  • Display the field as a textarea
  • Add help text that explicitly requests that the contents of the photo be described

• To the single photo page (the only place the text wasn't provided in the alt attribute for the img):
  • Output the text as the alt attribute value for the photo
  • Add aria-hidden="true" to the figcaption, since it is visually displaying the ALT text and duplicative for assistive devices
  • Prefix the displayed ALT text below the photo with "Alternative Text:"

Relatedly, here are some separate efforts that will likely stem from these changes:

• We may need some front-end mechanism (a submission/comment form) that solicits for ALT suggestions from logged-in users. This form may be open to all photos that haven't been closed to further input (i.e. once a photo has definitely had its ALT text defined and verified by a moderator, we likely don't need additional edits, or if we did it would be through a separate "suggest-an-edit" form).
• If front-end suggestions are desired, moderators will have the added effort (shared, or overseen by a dedicated sub-team) to handle incoming ALT text suggestions.
• Moderators will have the added effort during normal photo moderation of assessing the submitted photo descriptions through the lens of being ALT text, and most likely having to write the ALT text themselves with cues from the submitted text.
• Moderators will have to plan an effort or sub-team to go through all photos and improve existing ALT text (and also provide missing ALT text if they aren't planning to solely rely on front-end submissions)
• We may look into using AI to generate the ALT text, though likely only as a draft that will need moderation prior to actually being shown on the site.
• The team's handbook will likely need amending to address assessing, and in most cases, composing ALT text for each photo. The Learn team is ​working on a documentation for how to produce good ALT text which can be worked on in tandem and eventually get referenced.
• When the aforementioned Learn documentation on how to write good ALT text is completed, the upload form can link to it so contributors have something to reference.

@alexstine: I welcome any feedback regarding the single-photo page output for including the ALT text in the img tag, but also displaying it on the page. In this context, we ideally do not want assistive technologies to read out the same text twice.

[coffee2code]

In 12539:

Photo Directory, Uploads: Reinforce intent of text input as being for alternative text.

• Rename the field from "Description" to "Alternative Text"
• Make the field required
• Increase field's input limit to 350 characters
• Display the field as a textarea
• Add help text that explicitly requests that the contents of the photo be described

Props alexstine, otto42, coffee2code.
See #6173.

[coffee2code]

In 12540:

Photo Directory: On single photo pages, improve accessibility of ALT text display.

Adds actual text to alt attribute for the photo img, but hides the figcaption from screen readers since it also displays the ALT text.

Props alexstine, coffee2code.
See #6173.

[alexstine]

@coffee2code Can you find me a photo with ALT text? Happy to check but having a hard time finding one.

Also, couple edits needed for the form.

<textarea name="post_content" id="ug_content" class="textarea" maxlength="350" required="required" aria-required="true"></textarea>

HTML5 required attribute is good enough, no need to have aria-required. Aria-required is only needed when HTML5 validation needs to be avoided.

Can you add aria-describedby to associate the help text? Something like:

aria-describedby="ug_help_sr"

Then you simply add an ID to the description text with the value of aria-describedby.

Related links:

1. ​https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/required
2. ​https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-required
3. ​https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-describedby

Thanks!

[Otto42]

Replying to alexstine:

@coffee2code Can you find me a photo with ALT text? Happy to check but having a hard time finding one.

As of [12540], all the photos have alt text.

[alexstine]

Replying to Otto42:

Replying to alexstine:

@coffee2code Can you find me a photo with ALT text? Happy to check but having a hard time finding one.

As of [12540], all the photos have alt text.

No ALT text on this page: ​https://wordpress.org/photos/photo/2966434354/

[dd32]

Replying to alexstine:

Replying to Otto42:

As of [12540], all the photos have alt text.

No ALT text on this page: ​https://wordpress.org/photos/photo/2966434354/

That photo appears to contain a valid alt text.

[alexstine]

Hmm, I think this might be caused by the elements wrapping the image.

​https://developer.mozilla.org/en-US/docs/Web/HTML/Element/figure

Probably need to do the following:

1. Remove the figure.
2. Remove the link wrapping the image.
3. Figure out some other way to represent ALT text to sighted users.
4. Place the view larger image button somewhere else.

In the context of a link, the ALT text should actually describe what the link does not what the image is. These are things I sadly did not think about from the top of this ticket.

Thoughts?

[Otto42]

I'm sorry, what is the problem exactly? The alt text is on the img. Not the figure and not the link.

Is the issue that the alt text is not being read by a screen reader?

Remember that alt text does not show on hover. The title attribute shows on hover.

[alexstine]

Replying to Otto42:

I'm sorry, what is the problem exactly? The alt text is on the img. Not the figure and not the link.

Is the issue that the alt text is not being read by a screen reader?

Remember that alt text does not show on hover. The title attribute shows on hover.

Correct. It seems like the current implementation, 2 things are going wrong.

1. The aria-hidden on the caption is not working to prevent reading in Firefox but it does in Chrome.
2. In Chrome, the aria-label on the link is read but not the ALT text or caption.

[joedolson]

When aria-label is used, it changes the accessible name calculation and overrides all descendant text. So the use of aria-label for the link that wraps the image means that the complete accessible name for the link and all its contents is "View larger photo".

I suggest appending "View larger photo: " to the alt text that describes the image and removing the aria-label. That would allow all the information to be communicated.

I don't think that dealing with Firefox reading the hidden figcaption is a huge priority, but we could fix that by using aria-labelledby on the img to reference the associated figcaption. Because this would override the alt text on the image, we'd need to have multiple aria-labelledby targets to include the 'View larger photo' instructions. E.g.

<img aria-labelledby="instructions id-figcaption" alt="">
<figcaption id="figcaption">Alt text</figcaption>

<span class="screen-reader-text" id="instructions">View larger photo</span>

The span, because it's repeated for every image, could be placed as a single-use text in the footer and let every img reference the same span; it doesn't need to be reproduced independently for each image.

[alexstine]

@joedolson Yes, the current problem with the figcaption being read is ALT text plus figcaption in Firefox equals a long reading string. Not a great experience. Need to only read the ALT or maybe just read the figcaption if this text needs to remain visually. Adding the ALT attribute may not have been needed here, just need to have text that reflects good ALT description. Something like this for example.

<figure>
	<a href="https://pd.w.org/2023/04/7364394ce3091cc0.09281796-rotated.jpg">
		<img class="single-photo" src="https://pd.w.org/2023/04/7364394ce3091cc0.09281796-225x300.jpg" srcset="https://pd.w.org/2023/04/7364394ce3091cc0.09281796-225x300.jpg 225w, https://pd.w.org/2023/04/7364394ce3091cc0.09281796-768x1024.jpg 768w, https://pd.w.org/2023/04/7364394ce3091cc0.09281796-1152x1536.jpg 1152w, https://pd.w.org/2023/04/7364394ce3091cc0.09281796-1536x2048.jpg 1536w" alt="" aria-labelledby="image-label" aria-description="View larger image"></a>
	<figcaption class="wp-caption-text" id="image-label">
		<span>Alternative Text: </span>Tour Eiffel - Paris</figcaption>
</figure>

Do you think it is a problem that I am using aria-description to communicate the links purpose? I am trying to balance usefulness and verbosity. It makes sense to me to read the figcaption but users may not want to hear every time that the link opens a larger image view. This is where accessibility spec gets a little stupid in my opinion.

The other thing we could do is expose it outside of the figure element all together. Something like a Copy ALT Text button. I think that would be a much cleaner approach.

[coffee2code]

To summarize the requested changes... First, using ​this photo here's what we have currently:

<figure>
    <a href="https://pd.w.org/2023/04/167643962da0092c4.76808684.jpg" aria-label="View larger photo">
        <img class="single-photo" src="https://pd.w.org/2023/04/167643962da0092c4.76808684-300x225.jpg" srcset="..." alt="View of a Venetian canal with one person photographing from the bridge">
    </a>

    <figcaption class="wp-caption-text" aria-hidden="true">
        <span>Alternative Text:</span>View of a Venetian canal with one person photographing from the bridge
    </figcaption>
</figure>

Here's that same markup after the proposed changes:

<figure>
    <a href="https://pd.w.org/2023/04/167643962da0092c4.76808684.jpg">
        <img class="single-photo" src="https://pd.w.org/2023/04/167643962da0092c4.76808684-300x225.jpg" srcset="..." alt="" aria-labelledby="photo-alt-text view-larger-photo">
    </a>

    <figcaption id="photo-alt-text" class="wp-caption-text">
        <span aria-hidden="true">Alternative Text: </span>View of a Venetian canal with one person photographing from the bridge
    </figcaption>
    <span id="view-larger-photo" class="screen-reader-text">View larger photo</span>
</figure>

Here's a summary of changes:

1. Remove aria-label attribute from a.
2. Remove text from the alt attribute of img, leaving it blank.
3. Add aria-labelledby="view-larger-photo photo-alt-text" attribute to img, pointing both to a new span containing the "View larger photo" instruction and to the figcaption.
4. Add id="photo-alt-text" to figcaption.
5. Remove the aria-hidden="true" from the figcaption
6. Create a new span containing the text "View larger photo". (This general markup only appears on single-photo pages, so it will only appear in the markup once and not be repeated for multiple images.)
7. Add aria-hidden="true" to the span within the figcaption. This wasn't requested, but I wondered if it was unnecessary for assistive technologies to announce that the text is labelled as "Alternative Text:" if it was serving that purpose already. For sighted users, the intent was to make it clear that the text can be used by them as ALT text.

Do you think it is a problem that I am using aria-description to communicate the links purpose? I am trying to balance usefulness and verbosity. It makes sense to me to read the figcaption but users may not want to hear every time that the link opens a larger image view.

If verbosity is the concern, bear in mind that this use of figure only occurs on single-photo pages, so the "View larger photo" instruction would only appear once on the page, wherever it ends up.

The other thing we could do is expose it outside of the figure element all together. Something like a Copy ALT Text button. I think that would be a much cleaner approach.

A copy-to-clipboard button for the ALT text is definitely on the agenda once we've addressed this ticket. I was thinking a button that appears at the end of the figcaption text. How does moving the displayed ALT text out of the figure element help with this? I would think, semantically at least, we'd still want that text associated with the image, thus all included in the figure.

[alexstine]

Because for all purposes, screen readers do not pay much attention to figures. Joe may disagree with me but I have never seen much value come from using these elements for accessibility.

I think number 7 is okay as well. No need to state the obvious.

My worry with this approach is the figcaption will likely still get read as a caption to screen readers so that could be some undesired behavior.

[joedolson]

@alexstine Using aria-describedby for the link purpose puts the link purpose at the end of the reading text, since that will be read second; and also could be a poor option for VoiceOver users. So I'd be hesitant about that. Using aria-labelledby will be read as two successive but equal statements, which seems better; and having the link purpose first is preferable both to convey what the link does and to get the consistent and shorter link out of the way first.

@coffee2code I agree that hiding the label 'alternative text' makes sense. Otherwise, that sounds good.

I put up a codepen of this, and can confirm that the figcaption is still read, so we still have the duplication problem. We may be overthinking this.

The figure/figcaption relationship makes sense if we think of the alt text as a caption; but as we've already established, it's not a caption: it's a visual display of the alt text for the image. We could probably do away with the figure/figcaption entirely, in which case we no longer have the problem with reading the figcaption content as part of the figure. I'm going to create a couple of relevant codepens for testing different options.

[joedolson]

If we don't use the figure/figcaption, then using aria-hidden on the element with the alt text doesn't run up against Firefox reading it out as part of the figure's name. However, this should be tested widely, as referencing an element with the aria-hidden attribute as a label is tricky.

I kind of wonder if we're not just over thinking this, and that it's just fine for the alt text to be present on the image and also in visible text immediately after. The major problem is that inside a figure, that results in reading both, which is annoying. If this isn't a figure, however, the image link is stand alone and so is the associated text. With the text 'alternative text' present, a screen reader will get the link purpose, the alt text, then navigate to the paragraph that starts with 'Alternative text', which should tell them "I've already heard this and can move on."

I'm suggesting this. Just very simple; no excess semantics that create relationships that are not, in this case, helpful.

​Suggestion at CodePen

In this case, I'm *not* hiding the text Alternative Text, as that is useful to inform the user that this text is redundant for them.

[alexstine]

I approve. This looks fine.

[coffee2code]

In 12544:

Photo Directory: Improve accessibility of displayed ALT text on single photo pages.

Props joedolson, alexstine, coffee2code.
See #6173.

[coffee2code]

The latest suggestions have been pushed to production. Is that enough to close this ticket out?

[alexstine]

@coffee2code Looks good to me. I think we can address other areas in follow-up tickets. Thanks.