Opened 9 months ago
Last modified 4 months ago
#50066 assigned enhancement
Make alt text input a textarea on classic editor
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Future Release | 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)
Change History (41)
This ticket was mentioned in PR #246 on WordPress/wordpress-develop by edent.
9 months ago
#3
@
9 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
@
9 months ago
- Keywords needs-patch added
- Milestone changed from Awaiting Review to 5.5
Related: #47456.
#5
@
9 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; }
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
9 months ago
#7
@
8 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
@
8 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
@
8 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.
8 months ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
8 months ago
#12
@
8 months ago
- Component changed from Editor to Media
- Owner set to audrasjb
- Status changed from new to assigned
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
8 months ago
#15
@
8 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
@
7 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.
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
7 months ago
#18
follow-up:
↓ 20
@
7 months ago
50066.2.diff expands on 50066.edit-media.diff, but I have not addressed the input sanitization.
Updates:
- HTML: I added the
alt-text
class to the twospan
tags withdata-setting="alt"
, to be more consistent with the other two alt-text spans' classes.<span class="setting alt-text has-description" data-setting="alt">
- 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)
- 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.
- 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 months ago
#20
in reply to:
↑ 18
@
7 months ago
- Keywords needs-testing removed
Replying to sabernhardt:
@sabernhardt thanks for the patch!
- 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.
- 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.
7 months ago
#22
@
7 months ago
Thanks @afercia!
- 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.
- 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).
- 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.
@
7 months 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")
@
7 months ago
new lines remained in alt attribute when text was entered in the block editor sidebar
#23
@
7 months 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.
#24
@
7 months 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.
7 months ago
#26
@
7 months 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
@
7 months 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
@
7 months 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.
This ticket was mentioned in Slack in #core-media by sabernhardt. View the logs.
4 months ago
#30
@
4 months ago
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.
This ticket was mentioned in Slack in #core-media by antpb. View the logs.
4 months ago
#32
@
4 months ago
- Milestone changed from 5.6 to Future Release
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.
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:
-->