WordPress.org

Make WordPress Core

Opened 3 months ago

Last modified 5 weeks ago

#50066 assigned enhancement

Make alt text input a textarea on classic editor

Reported by: edent Owned by: sabernhardt
Milestone: 5.6 Priority: normal
Severity: normal Version:
Component: Media Keywords: has-patch needs-refresh
Focuses: ui, accessibility Cc:

Description

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.

Attachments (9)

50066.diff (2.6 KB) - added by sabernhardt 3 months ago.
50066.edit-media.diff (3.4 KB) - added by sabernhardt 3 months ago.
including the Edit Media screen alt text field, without editing styles
edit-media-alt-text-textarea.png (8.7 KB) - added by sabernhardt 3 months ago.
Edit Media screen with textarea field for Alternative Text
50066 edit media diff.png (215.8 KB) - added by afercia 3 months ago.
50066.2.diff (8.7 KB) - added by sabernhardt 2 months ago.
Adding alt-text class, setting textarea height in CSS, updating QUnit
50066 line height too small media library details.png (155.5 KB) - added by afercia 6 weeks ago.
classic-editor-line-breaks.jpg (126.3 KB) - added by sabernhardt 6 weeks ago.
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")
block-editor-line-breaks.jpg (31.5 KB) - added by sabernhardt 6 weeks ago.
new lines remained in alt attribute when text was entered in the block editor sidebar
50066 alt attribute stored without line breaks.png (87.7 KB) - added by afercia 5 weeks ago.
Alt text from textarea saved in the db

Download all attachments as: .zip

Change History (37)

This ticket was mentioned in PR #246 on WordPress/wordpress-develop by edent.


3 months ago

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:

-->

#2 @pigsonthewing
3 months ago

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

#3 @heatherherbert
3 months ago

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.

#4 @afercia
3 months ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 5.5

Related: #47456.

@sabernhardt
3 months ago

@sabernhardt
3 months ago

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

#5 @sabernhardt
3 months ago

  • Keywords has-patch needs-testing added; needs-patch removed

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
3 months ago

Edit Media screen with textarea field for Alternative Text

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


3 months ago

#7 @JavierCasares
3 months ago

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

#8 @afercia
3 months ago

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.

#9 @afercia
3 months ago

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?).

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


3 months ago

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


2 months ago

#12 @afercia
2 months ago

  • Component changed from Editor to Media
  • Owner set to audrasjb
  • Status changed from new to assigned

#13 @afercia
2 months ago

  • Owner changed from audrasjb to sabernhardt

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


2 months ago

#15 @audrasjb
2 months ago

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.

#16 @afercia
2 months ago

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.

Last edited 2 months ago by afercia (previous) (diff)

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


2 months ago

@sabernhardt
2 months ago

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

#18 follow-up: @sabernhardt
2 months ago

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">
  1. 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)
  1. 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.
  1. 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.

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


7 weeks ago

#20 in reply to: ↑ 18 @afercia
6 weeks ago

  • Keywords needs-testing removed

Replying to sabernhardt:

@sabernhardt thanks for the patch!

  1. 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.

  1. 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?

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


6 weeks ago

#22 @sabernhardt
6 weeks ago

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.
  1. 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).
  1. 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
6 weeks ago

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
6 weeks ago

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

#23 @afercia
5 weeks ago

  • Keywords needs-refresh added

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
5 weeks ago

Alt text from textarea saved in the db

#24 @afercia
5 weeks ago

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.

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


5 weeks ago

#26 @joedolson
5 weeks ago

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

#27 @afercia
5 weeks ago

@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.

#28 @davidbaumwald
5 weeks ago

  • Milestone changed from 5.5 to 5.6

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.

Note: See TracTickets for help on using tickets.