Opened 7 years ago
Last modified 14 months ago
#43178 assigned enhancement
Rethinking what “captions” means for video
Reported by: | postphotos | Owned by: | postphotos |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | 5.1 |
Component: | Media | Keywords: | has-patch reporter-feedback has-ux-feedback has-ui-feedback needs-refresh phase-3-media-triage |
Focuses: | accessibility, javascript, administration | Cc: |
Description
Because different users will use the word "caption" in different ways, it would be helpful to look at reducing this term in WordPress media and clarifying all media terms as a whole.
Captions carry a meaning in the video industry that is closely related to subtitles. It's recommended that we change how we describe our images, videos, and other media used within WordPress.
Note: For architectural reasons, the field data should be left alone, but we need a better label for the associated meta. I also talked about this a bit in #31177
This proposal further explores the messy language in media attachments and focuses on clear description so that all users can understand them, including clarifying WordPress' use of video subtitles.
A proposal to revising these terms is below.
Images
1) Wherever images use data-setting="title"
- instead of "Title" the English label should read "Media Title."
2) Wherever images use data-setting="caption"
- instead of "Caption" the English label should read "Image Caption." Because the specific term "photo captioning" describes a widely-used industry term, it should be clarified here but not removed.
3) Wherever images use data-setting="description"
- instead of "Description" the English label should read "Longer Description." This is because theme developers do not output this data beyond attachment pages and having three ill-described content areas - alt, caption, description - is an anti-pattern to describe what these images.
Videos
1) Wherever images use data-setting="title"
- instead of "Title" the English label should read "Media Title."
2) Wherever video use data-setting="caption"
- instead of "Caption" the English label should read "Media Description."
3) Wherever images use data-setting="description"
- instead of "Description" the English label should read "Longer Description." This is because theme developers do not output this data beyond attachment pages and having three ill-described content areas - alt, caption, description - is an anti-pattern to describe these images.
By adjusting these terms and exposing utility of the meta values, this level of clarity will greatly enhance the ability for all users, especially those helping create content for both multi-lingual and Deaf audiences, to understand the meta values in managing media work without the need to read documentation.
Goals:
- Because videos are reused on separate posts and all subtitled videos should contain this as a part of their output, create a meta value (or some other object type) that stores associated SRTs per language.
- Allow for a better way for all videos that stores the associated SRTs to be associated with a language or as another kind of subtitle track - i.e. commentary, descriptive text, etc.
- Allow videos uploaded at the same time with the same subtitle file name (or in a language structure) to be associated with each other. Assume the default core language for videos with no LANG code and associate the only subtitle as belonging to default core’s. (If there’s only one SRT with no lang suffix, it’s probably a caption.)
If we leave the existing labels as-is, new and old users will both continue to put the wrong information in because of the lack of context to each field. Whatever fix we decide on, this should also be further adjusted in each target language that WordPress core is released in.
Attachments (6)
Change History (38)
This ticket was mentioned in Slack in #accessibility by postphotos. View the logs.
7 years ago
This ticket was mentioned in Slack in #core-media by postphotos. View the logs.
7 years ago
#4
@
7 years ago
Hey there @postphotos -- what a great issue.
We often think of screen readers for the visually impaired. This is a great ticket to help those who are Deaf and hard of hearing. I do watch all TV with captions and I technically have my hearing intact.
Video captions are good for SEO, too. So that's a bonus.
#5
@
7 years ago
- Focuses javascript added
- Keywords needs-patch added
- Milestone changed from Awaiting Review to Future Release
Thanks for the ticket and great description + mockups @postphotos!
I agree, and would love to see these changes.
cc: @joemcgill
This ticket was mentioned in Slack in #accessibility by postphotos. View the logs.
7 years ago
#7
@
7 years ago
- Keywords has-patch added; needs-patch removed
Finally getting to this - hope I submitted my first patch correctly! :)
This ticket was mentioned in Slack in #accessibility by postphotos. View the logs.
7 years ago
#9
@
7 years ago
- Keywords reporter-feedback ux-feedback ui-feedback added
Hi @postphotos,
Thanks for the excellent write up, and thinking that's gone into this. I'm in support of the goals to improve the the media modal and library UI to make it easier to save video captions along with video files and to clear up the ambiguity between the current usage of the word "caption" as it applies to videos and the kind of video captioning that is produced by uploading SRT files.
I do have a few questions:
First, based on your description and screenshots, my understanding is that you're describing two separate tasks with this ticket: 1) making the use of the word "caption" less ambiguous when editing video data, and 2) making it easier to add video captioning (i.e., SRT files) globally to videos in the media library. However, the patch here only deals with the former. Is your intent to limit this ticket to dealing with the former and accomplishing the latter in #31177, or did are you hoping to iterate on your current approach to cover both tasks here? Either is ok, I just want to make sure I'm following your thinking properly.
Additionally, I'm curious why you chose to use the terms "media description" and "media caption" for videos, rather than "video description/caption," which would be consistent with your choice of "image description/caption"? I'd also be interested in getting some user testing on these changes to see if the proposed labels really do help people have a better understanding of what those fields are for. It may be good to get some UX feedback on these labels.
The patch looks correct to me except for one small mistake—you've got two labels using the string "Media Description" in wp-includes/media-template.php
. I think you meant for the second one to be "Longer Description".
Overall, really great job putting this together. Thanks again!
#10
@
6 years ago
- Keywords needs-refresh added
@joemcgill @postphotos as 4.9.9 focuses also on small accessibility fixes, do you think this can be milestoned for 4.9.9?
This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.
6 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
6 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
6 years ago
#19
@
6 years ago
@postphotos (as owner of this ticket) @joemcgill (as component maintainer) what's left here? The patch needs to be refreshed. Also, I see there are some unanswered questions. Ten days left to 5.2 beta 1. I'd really appreciate some feedback to not punt this ticket again to a next release. Thank you :)
This ticket was mentioned in Slack in #design by karmatosed. View the logs.
6 years ago
#21
@
6 years ago
- Keywords has-ux-feedback has-ui-feedback added; ux-feedback ui-feedback removed
I would caution adding 'media' in front of every line of text, this really doesn't seem to be needed. It is ok to just say 'description'.
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
6 years ago
#23
@
6 years ago
- Milestone changed from 5.2 to 5.3
This still needs more work. If it receives the attention needed and a committer is confident in it before 5.2 beta 1 (less than 2 days), feel free to add it back!
#24
@
6 years ago
@postphotos are you able to follow up with @joemcgill's questions above so this can progress during 5.3?
This ticket was mentioned in Slack in #core-media by karmatosed. View the logs.
5 years ago
This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.
5 years ago
This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.
5 years ago
#28
@
5 years ago
No great progress on this ticket in a while and there are a few questions to answer yet.
WordPress 5.3 Beta 1 deadline for enhancements is in 4 days on Monday September 23rd. If the points above aren't addressed by Monday and the patch refreshed, I'm afraid this ticket will need to be punted to the next release cycle.
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
5 years ago
#30
@
5 years ago
- Milestone changed from 5.3 to Future Release
Hi @postphotos!
I'm sorry to have to move this out of the 5.3 milestone due to beta tomorrow. I've moved it into Future Release, but if you want to work on it for 5.4, let me know and I'll move it into that milestone.
As always, if this ticket sees motion before the 5.3 beta release, I'm happy to help things move forward earlier!
Before 1