Make WordPress Core

Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#47559 closed defect (bug) (fixed)

Subtitle tracks use English as default (hardcoded) in track element srclang and label attributes

Reported by: bjornw's profile BjornW Owned by: audrasjb's profile audrasjb
Milestone: 5.3 Priority: normal
Severity: normal Version: 5.2.2
Component: Media Keywords: has-screenshots has-patch
Focuses: ui, accessibility, javascript Cc:

Description (last modified by afercia)

Currently (using version 5.2.2) adding a subtitle is needlessly opaque as you can see in the attached screencast. As far as I can tell, it is only possible via the video widget if someone presses the 'edit video' button.

I'd consider this a quite annoying usability issue which I think we need to address rather sooner than later since subtitles are considered best practices for accessibility. Not to mention required for WCAG compliance.

A user might accidentally press the edit video button in the video widget, but nothing indicates that they are able to add subtitles via this button. Adding video via the Gutenberg video block doesn't help either. It has no option to add subtitles at all.

The other issue is that any subtitle added to a video is considered English. Regardless of the contents of the subtitle file's language or the language chosen in WordPress. This is clearly a bug, although while grepping through the trunk source I noticed srclang has been set to 'English' hardcoded.

As the current UI/UX for adding subtitles is already problematic (to say the least), adding an option to set the subtitle label and scrlang attributes feels like polishing a turd.

I'd like to discuss possible solutions to solve this issue and I'm willing to help out with this provided a Core committer commits to solving this issue as well. Without a Core committer I'm not willing to spend any time on patches since they'll probably be lingering for months or even years.

PS: Sorry about the numbers linking (can't edit this) in the attached screencast description.

Attachments (10)

subtitle-issue-edit.mp4 (3.7 MB) - added by BjornW 6 years ago.
Screencast of subtitle issues #1 adding is way too hard #2 Any subtitle added is considered English even when not..
screenshot-2019-06-28_22-09-13.png (203.4 KB) - added by BjornW 6 years ago.
Screenshot of video block in Gutenberg editor has no option to set subtitles
screenshot-2019-06-28_22-20-04.png (272.6 KB) - added by BjornW 6 years ago.
Press the edit video button to add subtitles. As far as I can tell this is the only way to add subtitles…
Capture d’écran 2019-08-10 à 11.36.58.png (163.9 KB) - added by audrasjb 6 years ago.
Proposal: manual language selector
Capture d’écran 2019-09-27 à 23.47.20.png (142.7 KB) - added by audrasjb 5 years ago.
Proposal
47559.diff (1.0 KB) - added by audrasjb 5 years ago.
First proposal
47559.2.diff (2.6 KB) - added by afercia 5 years ago.
01 track en.png (148.1 KB) - added by afercia 5 years ago.
The video player interface displaying the available track languages
02 track it.png (149.3 KB) - added by afercia 5 years ago.
It is possible to switch track language "on the fly"
03 track UI.png (102.3 KB) - added by afercia 5 years ago.
UI in the media modal with two track languages

Change History (39)

#1 @SergeyBiryukov
6 years ago

  • Component changed from General to Media

@BjornW
6 years ago

Screencast of subtitle issues #1 adding is way too hard #2 Any subtitle added is considered English even when not..

@BjornW
6 years ago

Screenshot of video block in Gutenberg editor has no option to set subtitles

@BjornW
6 years ago

Press the edit video button to add subtitles. As far as I can tell this is the only way to add subtitles...

#2 @BjornW
6 years ago

  • Focuses ui accessibility added
  • Version set to 5.2.2

Currently (using version 5.2.2) adding a subtitle is needlessly opaque as you can see in the attached screencast. As far as I can tell, it is only possible via the video widget if someone presses the 'edit video' button.

I'd consider this a quite annoying usability issue which I think we need to address rather sooner than later since subtitles are considered best practices for accessibility. Not to mention required for WCAG compliance.

A user might accidentally press the edit video button in the video widget, but nothing indicates that they are able to add subtitles via this button. Adding video via the Gutenberg video block doesn't help either. It has no option to add subtitles at all.

The other issue is that any subtitle added to a video is considered English. Regardless of the contents of the subtitle file's language or the language chosen in WordPress. This is clearly a bug, although while grepping through the trunk source I noticed srclang has been set to 'English' hardcoded.

As the current UI/UX for adding subtitles is already problematic (to say the least), adding an option to set the subtitle label and scrlang attributes feels like polishing a turd.

I'd like to discuss possible solutions to solve this issue and I'm willing to help out with this provided a Core committer commits to solving this issue as well. Without a Core committer I'm not willing to spend any time on patches since they'll probably be lingering for months or even years.

PS: Sorry about the numbers linking (can't edit this) in the attached screencast description.

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


6 years ago

#4 follow-up: @afercia
6 years ago

  • Focuses javascript added
  • Keywords needs-patch has-screenshots added
  • Milestone changed from Awaiting Review to 5.3

Discussed during today's accessibility bug scrub and agreed this is something to fix.

The inability to properly set the language is, well a bit unfortunate and should definitely be fixed. Also the UI should make this task easier.

Proposing for 5.3 consideration.

#5 in reply to: ↑ 4 @BjornW
6 years ago

Hi @afercia,

Great to hear this issue is considered for 5.3. What's the next step in making this happen? Is there already a plan for fixing the UI/UX for the subtitles? Or is this something we need to discuss?

#6 @afercia
6 years ago

Hello @BjornW! For Gutenberg, there's already this issue (created 1 year ago at the time of writing) with some UI explorations: https://github.com/WordPress/gutenberg/issues/7673

Discussion with the media and design teams would certainly help in framing the steps to take. For now, I'd tend to think the best option would be focusing on the functionality part. Specifically: find a way to get a list of languages (language code / language name) and make it available in the media views. Once that works, focus on the UI, both in the Classic Editor and in Gutenberg.

Any help would be greatly appreciated so if you're willing to start exploring, that would be very welcome!

#7 @audrasjb
6 years ago

  • Owner set to audrasjb
  • Status changed from new to accepted

@audrasjb
6 years ago

Proposal: manual language selector

#8 @audrasjb
6 years ago

  • Description modified (diff)
  • Keywords needs-design-feedback added

#9 @audrasjb
6 years ago

Hi there,

I tried a workaround (see screenshot above): add a language selector so we can populate both srclang and label attributes.

Works fine on my side, adding needs-design-feedback keyword since we'll need a design feedback before making a proper patch.

(I also commented in the related Gutenberg GitHub issue)

Cheers,
Jb

#10 @audrasjb
6 years ago

  • Description modified (diff)

#11 follow-up: @audrasjb
6 years ago

OMG I removed the initial description…
That would be cool if someone could restore the initial version please, looks like I can't do that :\

#12 in reply to: ↑ 11 @birgire
6 years ago

Replying to audrasjb:

OMG I removed the initial description…
That would be cool if someone could restore the initial version please, looks like I can't do that :\

I don't see the initial description in Trac's revision

https://core.trac.wordpress.org/ticket/47559?version=0

https://core.trac.wordpress.org/ticket/47559?action=history

https://core.trac.wordpress.org/ticket/47559?sfp_email=&sfph_mail=&action=diff&version=8&old_version=0

Can it be that it was initially without description?

#13 follow-up: @BjornW
6 years ago

@audrasjb thanks for helping out with this issue!

Is the language dropdown still only available via the video widget if someone presses the 'edit video' button? Where do the languages used as options come from (how can this be extended?)? Would it be possible to derive the language from the subtitle file without options?

Adding the dropdown, does not (yet) solve the surrounding issue of finding this setting. What are your ideas about solving this (and how does this relate with Gutenberg?)

#14 in reply to: ↑ 13 @audrasjb
6 years ago

Replying to BjornW:

Is the language dropdown still only available via the video widget if someone presses the 'edit video' button?

Yes of course. That was even the place where I worked, which was easier for me since I'm widgets screen component maintainer.

Where do the languages used as options come from (how can this be extended?)?

In this workaround, I only copied WordPress language dropdown available WP Admin General Settings.

Would it be possible to derive the language from the subtitle file without options?

I don't think so, because as far as I know there is no meta data tags in subtitle files.

Adding the dropdown, does not (yet) solve the surrounding issue of finding this setting. What are your ideas about solving this (and how does this relate with Gutenberg?)

It is not related to Gutenberg in my opinion. It is related to interface design (in the broader sense of design – aka not only graphic design) and to WordPress Documentation ("Where can I find these settings?").

#15 @afercia
6 years ago

  • Description modified (diff)

#16 @afercia
6 years ago

  • Description modified (diff)

#17 @afercia
6 years ago

Did I restore the correct initial description? :)

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


5 years ago

#19 @afercia
5 years ago

Discussed during today's accessibility bug-scrub. Agreed the new select to pick a language doesn’t seem to greatly impact the UI from a visual perspective. Some design feedback would be nice :) /Cc @karmatosed

#20 @karmatosed
5 years ago

  • Keywords needs-design-feedback removed

I don't see what other options we have for this right now so from design perspective approving. I do think this section is incredible complex now but adding a brand new pattern won't help.

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


5 years ago

@audrasjb
5 years ago

First proposal

#22 @audrasjb
5 years ago

  • Keywords has-patch dev-feedback added; needs-patch removed

Hi there,

I finally figured out that we don't have what we need to propose a relevant language select, since we need to display all languages in that select and we currently only have a list of WordPress Polyglots Locales. It's not enough.

The, I'd like to propose a really simple alternative. In 47559.diff

  • remove readonly attribute from input text so srclang and label attributes could be manually edited
  • add a short description of the field to explain that those attributes values could be changed if needed.

Any thoughts @afercia @SergeyBiryukov ?
Thanks,
Jb

#23 @sabernhardt
5 years ago

The note text might be better as "Attribute values can be edited to reflect the kind or language of the track." (The kind might be "captions" or another type.)

Technically, fixing the bug only requires providing a way to edit language settings, and removing the readonly attribute does that (at least in my test of the Video widget). Then we could add a new ticket to propose the enhancement(s) for a more intuitive UI in 5.4.

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


5 years ago

#25 @audrasjb
5 years ago

  • Keywords commit added

As said during today's bugscrub, the patch is good to go. Adding commit keyword.

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


5 years ago

@afercia
5 years ago

#27 @afercia
5 years ago

  • Keywords dev-feedback removed

The approach looks good to me. Reviewed a bit the patch in 47559.2.diff.

The existing code in the media views always allowed to insert more than one track.

However, the current code needs to be changed to properly generate multiple unique IDs needed for the label / input association. I also moved the description underneath the input field, as that's the convention in core and used an aria-describedby attribute to associate the description to the field. Shortened a bit the translatable string and used sprint() to help translators understand they don't have to translate the HTML attributes names.

As agreed during today's accessibility bug scrub, this is a first step. In the next release cycle there's should be some focus to introduce a new user interface to edit the srclang, label, and kind attributes. Also, the same functionality needs to be introduced in Gutenberg.

Screenshots attached below.

@afercia
5 years ago

The video player interface displaying the available track languages

@afercia
5 years ago

It is possible to switch track language "on the fly"

@afercia
5 years ago

UI in the media modal with two track languages

#28 @afercia
5 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 46373:

Accessibility: Media: Allow users to set a proper language for Video subtitles.

For a number of years, subtitles track added to videos were always set to "English" regardless of the actual subtitles language.

By making the track srclang, label, and kind attributes editable, content authors are now able to set a language that matches the actual track content.

Props BjornW, audrasjb, birgire, karmatosed, sabernhardt, afercia.
Fixes #47559.

#29 @afercia
5 years ago

  • Keywords commit removed
Note: See TracTickets for help on using tickets.