Make alt text input a textarea on classic editor

[edent]

The alt text interface is a single line which only shows a few characters of text.

If we want people to add meaningful alt text, this should be improved.

I suggest making it a textarea element.

This is already the case in the Gutenberg editor - see ​https://github.com/WordPress/gutenberg/pull/6119

The code is in /src/wp-includes/media-template.php :

<span class="setting has-description" data-setting="alt">
        <label for="attachment-details-alt-text" class="name"><?php _e( 'Alt Text' ); ?></label>
        <input type="text" id="attachment-details-alt-text" value="{{ data.alt }}" aria-describedby="alt-text-description" {{ maybeReadOnly }} />
</span>

That input type="text" can be changed to a <textarea> element.

Trac ticket: https://core.trac.wordpress.org/ticket/50066
This makes it easier to add meaningful alt text to images. It brings the interface in line with the caption and description fields.

See also ​https://github.com/WordPress/gutenberg/pull/6119/files

<!--
Hi there! Thanks for contributing to WordPress!

Pull Requests in this GitHub repository must be linked to a ticket in the WordPress Core Trac instance (​https://core.trac.wordpress.org), and are only used for code review. No pull requests will be merged on GitHub.

See the WordPress Handbook page on using PRs for Code Review more information: ​https://make.wordpress.org/core/handbook/contribute/git/github-pull-requests-for-code-review/

If this is your first time contributing, you may also find reviewing these guides first to be helpful:

• FAQs for New Contributors: ​https://make.wordpress.org/core/handbook/tutorials/faq-for-new-contributors/
• Contributing with Code Guide: ​https://make.wordpress.org/core/handbook/contribute/
• WordPress Coding Standards: ​https://make.wordpress.org/core/handbook/best-practices/coding-standards/
• Inline Documentation Standards: ​https://make.wordpress.org/core/handbook/best-practices/inline-documentation-standards/
• Browser Support Policies: ​https://make.wordpress.org/core/handbook/best-practices/browser-support/
• Proper spelling and grammar related best practices: ​https://make.wordpress.org/core/handbook/best-practices/spelling/

-->

[pigsonthewing]

This would be a good step towards improving accessibility; please apply ASAP!

[heatherherbert]

Sounds a good idea to me. I wonder if a larger field may make it more prominent in the user's mind as well and therefore more likely to be used.

[afercia]

Related: #47456.

[sabernhardt]

including the Edit Media screen alt text field, without editing styles

[sabernhardt]

Thanks @edent for the pull request!

50066.diff includes the 4 fields you identified for switching to textarea tags. I just moved the data.model.alt variable inside the tag for the last item (the Image Details modal).

The option 50066.edit-media.diff also changes the alt text field to a textarea on the Edit Media screen (editing an image under Media -> Library). The current input is already wide, but this would be more consistent with the post editor then. The caption field there has a height of 4em, yet I did not set the height for alt text as well.

If the additional textarea is desired, I'm not sure whether it's better to change the CSS selector to .wp_attachment_details textarea.widefat or to add the alt text ID explicitly along with the caption like this:

.wp_attachment_details #attachment_alt,
.wp_attachment_details #attachment_caption {
	height: 4em;
}

[sabernhardt]

Edit Media screen with textarea field for Alternative Text

[JavierCasares]

Hi... we should review also these files:

Unit Tests:

• /tests/qunit/index.html:1166
• /tests/qunit/index.html:1331
• /tests/qunit/index.html:1623
• /tests/qunit/index.html:1678

About the CSS, we should check:

• /build/wp-admin/css/media.css:808
• /build/wp-admin/css/media-rtl.css:809

And the plugin experiments

• /src/wp-content/plugins/design-experiments/sass/new-colors.scss:9543
• /src/wp-content/plugins/design-experiments/css/new-colors.css:9322

[afercia]

Thanks @JavierCasares the QUnit index.html is pretty out of date but yes we should at least update it with the new textarea. Re: the CSS: files in the build directory shouldn't be touched, as they're generated during the build process. Same applies to the rtl files, which are generated automatically.

[afercia]

Regarding the patch, this ticket was discussed during last weekly accessibility bug-scrub. The only concern is that by making the alt text textarea have the same size of the Caption and Description textareas, users might think entering a long text is a good thing. Instead, ideally the alt text should be short. Longer descriptions of the image's purpose should go in the caption or in the page content.

See the attached screenshot, which illustrates the new textarea will have (almost always) the same size of the other textareas. Maybe some visual hierarchy might help, by making the alt text textarea have a smaller height (let's say the equivalent of two lines of text?).

[audrasjb]

Worth noting that by default, line breaks will be escaped.
This is not an issue, it's normal, given alt attributes content may use esc_attr() function.

[afercia]

I think this will also need to be checked on the sanitization side, when the values get saved in the db. It should be OK as long as the value is treated as it came from an input field, i.e. not keeping new lines. Also the way this value is handled in the REST API would need a quick check.

[sabernhardt]

Adding alt-text class, setting textarea height in CSS, updating QUnit

[sabernhardt]

50066.2.diff​ expands on 50066.edit-media.diff, but I have not addressed the input sanitization.

Updates:

1. HTML: I added the alt-text class to the two span tags with data-setting="alt", to be more consistent with the other two alt-text spans' classes. <span class="setting alt-text has-description" data-setting="alt">

2. CSS (modals): The Caption height is 62 pixels, and 52 pixels is the smallest the Alt Text box can be while showing two full lines without the scrollbar. (13px font with 1.42857143 line-height, plus 6px top and bottom padding, plus 1px border)

3. CSS (media edit screen): The Caption height is 4em, so the Alt Text field is noticeably shorter at 2.5em but slightly taller than the input was. To keep the cursor centered vertically, I changed the line-height to 2. The vertical alignment seems to work with zoom, but not as well with minimum font size.

4. QUnit: Without checking for other discrepancies, I only updated the alt text spans. All four now have the labels and textareas inside the span, and the same alt-text class.

[afercia]

Replying to sabernhardt:

@sabernhardt thanks for the patch!

2. CSS (modals): The Caption height is 62 pixels, and 52 pixels is the smallest the Alt Text box can be while showing two full lines without the scrollbar. (13px font with 1.42857143 line-height, plus 6px top and bottom padding, plus 1px border)

In the Media Library > grid mode > Attachment Details modal, the ling-height value is 1.14285714 instead. I think we should fix that and make it consistent. It's definitely too small and it doesn't help readability (apart from the height issue). See attached screenshot.

3. CSS (media edit screen):

I was thinking to make the textarea height contain 2 lines of text here. And then further differentiate it from the Caption by setting max-width: 500px;. This value is already used for textareas in the User edit pages (see the user Bio). Thoughts?

[sabernhardt]

Thanks @afercia!

1. If we change line-height for consistency, I'd like to set all of those fields to 1.5 instead of having decimals based on fourteenths. The font size is set to 13px, or else 16px for smaller screens. So the line-height would become a more even decimal value at desktop sizes and an even value for mobile.

2. I'm unsure about—though not opposed to—setting a max-width of 500px on the Alt Text field. I'd rather not have both of its dimensions smaller than the Caption field's width and height on larger screens. While the visual hint to keep alt text short might be understood at larger viewports, that's not as effective in the middle range (especially around 600px wide).

3. The line breaks (new lines) are not always filtered out. In a test with the block editor's sidebar textarea field, the line breaks remained in the final output. With the classic editor, the first break was removed (but not a second break) when there was a caption, and the line breaks remained when the image had no caption. The breaks also were sometimes removed when switching from Visual to Text mode or when editing the image details after the post was published/updated.

Anyway, we could look more closely into all this for 5.6, with input from the Media team.

[sabernhardt]

some new lines are removed from alt attribute with the classic editor, some remain (line break was inserted and between "line" and "break(s)" as well as after the word "two")

[sabernhardt]

new lines remained in alt attribute when text was entered in the block editor sidebar

[afercia]

Thanks @sabernhardt !

If we change line-height for consistency, I'd like to set all of those fields to 1.5 i

We aim to get computed values that are integers. 13 pixels multiplied by 1.5 would give 19.5. Values with decimals are subject to browsers rounding. Not surprisingly, browsers use different rounding algorithms so that the final result may differ across browsers. This is the reason why we tend to use line-height values with decimals (Chrome especially needs a lot of decimals) to get a computed value without decimals. For example, with a font-size of 14 pixels, a 1.42857143 line-height is computed to 20.

setting a max-width of 500px on the Alt Text field

Yeah, I have no strong opinions. However, the alt text textarea needs to suggest users that the text needs to be short. Shorter than the caption. Open to other suggestions. In the last patch seems to me in one case the textarea height is too small and looks like an input field.

line breaks

To my understanding, when the alt text is saved either via form submission or via AJAX, it goes through wp_strip_all_tags( $alt, true );. Notice the second parameter true which makes the function remove line breaks. Thus, the alt text is stored in the database without line breaks. See screenshot below. This is a good first step :)

However, when editing a post, the alt text is added to the HTML blob "as is", with the line breaks. I think this should be fixed in the Media views.

[afercia]

Alt text from textarea saved in the db

[afercia]

Looking into the block editor side, I think there will be the need for changes there as well to avoid line breaks (and tab characters?) in the alt text.

[joedolson]

Here are the results of testing line breaks in alt text using current screen readers/browsers:

Alt text with line breaks

1) NVDA, Windows 10, Firefox: Line breaks ignored
2) NVDA, Windows 10, Chrome: Line breaks ignored
3) NVDA, Windows 10, Edge: Line breaks ignored
4) NVDA, Windows 10, IE 11: Line breaks ignored
5) JAWS, Windows 10, Firefox: Line breaks read as if each line is new image, e.g. "line 1 graphic; line 2 graphic; line 3 graphic"
6) JAWS, Windows 10, Chrome: Line breaks ignored
7) JAWS, Windows 10, Edge: Line breaks ignored
8) JAWS, Windows 10, IE 11: Line breaks read as if each line is new image, e.g. "line 1 graphic; line 2 graphic; line 3 graphic"
9) VoiceOver, Mac OS 10.15.5, Firefox: Line breaks ignored
10)VoiceOver, Mac OS 10.15.5, Safari: Line breaks ignored
11) VoiceOver, iPadOS 13.5.1, Safari: Line breaks pause reading

[afercia]

@joedolson thanks for the thorough testing! Given today's Beta 1 day, I think this change would be better addressed in the next release cycle.

[davidbaumwald]

Per @afercia's suggestion, and with 5.5 Beta 1 releasing shortly, this is being moved to 5.6. If any maintainer or committer feels this can be resolved in time, or wishes to assume ownership during a specific cycle, feel free to update the milestone accordingly.

[bluetriangle]

during the core-media meeting on October 1st I suggested we could make accessibility fields stand out more by adding an icon next to said fields.

[hellofromTonya]

Per Media scrub today, we agreed to punt this ticket to a Future Release as we are less than 2 weeks to Beta 1 and this ticket needs more soak time.

If any maintainer or committer feels this can be resolved in time, or wishes to assume ownership during a specific cycle, feel free to update the milestone accordingly.