WordPress.org

Make WordPress Core

Opened 12 months ago

Last modified 2 weeks ago

#38759 reviewing defect (bug)

Accessibility glitch when editing an embedded video

Reported by: Presskopp Owned by: joemcgill
Milestone: 4.9 Priority: normal
Severity: normal Version: 3.9
Component: Media Keywords: has-screenshots has-patch needs-testing
Focuses: accessibility Cc:

Description

to reproduce: make a new page and enter video shortcode for embedding a video like

[video src="https://www.youtube.com/watch?v=KF8bGYks-bk"]

in text mode. Switch to Visual Mode, click to edit the video.

Above the URL of the video will be an area (titled SRC) where you have a mouse pointer like if it was a link, but it isn't. See screenshot..

The label "SRC" is hardcoded in \wp-includes\media-template.php L.1044/1127

Attachments (2)

video-hover.jpg (156.5 KB) - added by Presskopp 12 months ago.
38759.diff (5.9 KB) - added by afercia 7 weeks ago.

Download all attachments as: .zip

Change History (12)

#1 @joemcgill
12 months ago

  • Component changed from General to Media
  • Focuses accessibility added

Thanks @Presskopp is this new to Trunk or is this reproducible in the current stable version of WP (4.6.1) as well?

#2 @joemcgill
12 months ago

  • Owner set to joemcgill
  • Status changed from new to reviewing

#3 @Presskopp
12 months ago

same in 4.6.1

#4 @joemcgill
12 months ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to Future Release
  • Version trunk deleted

Thanks for confirming. Since this isn't a regression, let's look at this in a future release.

#5 @lukecavanagh
12 months ago

@Presskopp

Confirmed the issue is reproducible in 4.7-beta3-39201.

#6 @afercia
12 months ago

  • Keywords has-screenshots added
  • Version set to 3.9

SRC is just the label for the input field. In other places, for example the attachments browser, a similar field has a URL label and the field is readonly but not disabled. This allows, at least, to copy and select the URL:

https://cldup.com/dbW4JTiM3o.png

I'd suggest to rename the label and make the field (also the other ones for additional sources) enabled and readonly.

An additional a11y issue here is that, inside the label, there's also the button to remove the video source. This button should be moved out from the label.

Side note: I think this was added in [27411] and the buttons later.

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

@afercia
7 weeks ago

#8 @afercia
7 weeks ago

  • Keywords has-patch added; needs-patch removed
  • Milestone changed from Future Release to 4.9

Looking a bit into this, there are a few occurrences in the media templates where <label> elements are used incorrectly:

  • to wrap just text (no form controls)
  • to wrap an input field and a button
  • to wrap a mix of the two cases above

Label elements should be used just for labelable elements. 38759.diff is a first attempt to fix most of these cases and produce valid, semantic markup. As per the accessibility standards, labels should be associated using for/id attributes.

The patch can be certainly improved and need testing. Given how so badly associated labels impact accessibility, I'd like to propose to try to fix this in 4.9.

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

#9 @Presskopp
2 weeks ago

  • Keywords needs-testing added

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


2 weeks ago

Note: See TracTickets for help on using tickets.