#47559 closed defect (bug) (fixed)
Subtitle tracks use English as default (hardcoded) in track element srclang and label attributes
Reported by: |
|
Owned by: |
|
---|---|---|---|
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 )
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)
Change History (39)
@
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
@
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:
↓ 5
@
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
@
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
@
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!
#9
@
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
#11
follow-up:
↓ 12
@
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
@
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
Can it be that it was initially without description?
#13
follow-up:
↓ 14
@
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
@
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?").
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
5 years ago
#19
@
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
@
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
#22
@
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
andlabel
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
@
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
@
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
#27
@
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.
Screencast of subtitle issues #1 adding is way too hard #2 Any subtitle added is considered English even when not..