Low Adoption of <track> Element

[yashrajbharti]

What is the issue with the HTML Standard?

Inaccessibility of Web Videos Due to Low <track> Adoption

Only 0.5% of web videos include a <track> tag (Web Almanac 2024 Report), leaving the vast majority of online video content inaccessible for individuals who rely on captions.

Impact

• Excludes people with hearing impairments, non-native speakers, and others who benefit from captions.
• Undermines accessibility standards on the web, which aim to make content inclusive by default.

Why This Matters

The <track> element was introduced to provide captions, but its low adoption highlights significant barriers for developers, such as:

• Lack of awareness or knowledge about the <track> element.
• Additional effort required to create and manage caption files.
• Limited incentives for publishers to prioritize captions.

Gap in the Standard

The standard does not currently address how browsers or user agents might provide fallback mechanisms for captions when no <track> is present. This gap leaves accessibility largely dependent on content authors, which is not a scalable or equitable solution.

[aardrian]

The standard does not currently address how browsers or user agents might provide fallback mechanisms for captions when no is present.

That feels like it's outside the scope of HTML. Partly because:

• that involves UAs creating content from scratch (remember that captions represent more than spoken dialogue),
• UAs and OSes already offer platform-level features to auto-generate captions from speech (I can do it on my Windows machine and Android device today, though they are far from ideal),
• Audio Description (one of the uses of <track>) has no support in browsers today, so some of that gap is from UAs, not authors.

Here are existing bugs about lack of AD support:

• Chromium: 1447858 Feature Request: text-based Audio Descriptions in Chrome, 22 May 2023
• Chromium: 361123861 Flag expired : text-based-audio-descriptions is expired in M130, 20 August 2024.
• Chromium: 40664325 Support description tracks in native HTML 5 video elements w/o extra extensions, 18 December 2019.
• WebKit: 266724 – AX: Feature request: Support WebVTT-based synthesized audio description in video, 20 December 2023.
• Firefox: 1871143 Feature request: Support WebVTT-based synthesized audio description in video, 20 December 2023.

To address two of your points about barriers to developers:

• Additional effort required to create and manage caption files.

This is also true for any alternatives to media files, including AD and alternative text, which are realities of supporting all users.

• Limited incentives for publishers to prioritize captions.

True for any accessibility considerations, and why arguments proliferate around business cases and SEO and branding, but still boil down to risk under existing laws (which incorporate or reference WCAG).

This gap leaves accessibility largely dependent on content authors, which is not a scalable or equitable solution.

I agree there is a gap from authors, but do you have a proposal for how HTML could make authors do better or how, as a technical standard, HTML could define some sort of fallback?

[yashrajbharti]

Thank you for your thoughtful response! I appreciate the points you've raised. I understand the concerns about the scope of the proposal, particularly around user agents (UAs) generating content from scratch, such as captions.

However, I want to emphasize that the issue of the lack of captions in web videos is significant, with only 0.5% of web videos currently having captions, as you can see from resources like Web Almanac by HTTPArchive.

Audio Description (one of the uses of <track>) has no support in browsers today

I agree that there are gaps in support for Audio Descriptions (AD), and I'm aware that work is being done on this. However, this shouldn’t detract from the fact that captions, which are more readily available, can still play a crucial role. The track element offers a potential solution, and UAs can certainly take on the responsibility of handling cases where captions are missing.

Captions represent more than spoken dialogue

I completely agree. Captions often need to reflect non-verbal sounds or other relevant context. However, in the absence of comprehensive captions, even a basic fallback would be a huge step forward. It’s certainly not perfect, but it’s better than no captions on the web. It can also get better over time with this mindset.

Chromium: 1447858 Feature Request: text-based Audio Descriptions

I don’t feel aligned with the notion that the lack of AD support should dilute the importance of the issue at hand. While AD support is being addressed separately (Compatibility chart), captions are a crucial part of the accessibility conversation, and pursuing solutions for captions should remain a priority.

I agree there is a gap from authors, but do you have a proposal for how HTML could make authors do better or how

I’m open to feedback and ideas, and I think it’s important for the community to brainstorm solutions. The existing 0.5% and 0.1% availability rates for captions and audio captions are very low, and I don’t believe that pushing the issue out of scope will help solve the problem.

[aardrian]

So your issue is about low adoption of closed captions specifically (provided in HTML via the <track> element). Got it. And you have identified a gap but have not proposed a solution. Which is fine. And are asking for feedback and ideas. Ok.

Here is my feedback / ideas:

• There is plenty of pre-existing content out there on best practices, how to make captions, legal requirements, etc. You can raid all of that to propose some suggestions for fallback content.
• The Understanding doc for SC 1.2.2 offers some starting points (and guardrails for failures) for your effort.
• Starting a discussion with the W3C working group might be a good idea. That is more likely to include dedicated accessibility stakeholders given its focus.

But absent suggestions, I still think this is out of scope for HTML.

As an aside...

I don’t feel aligned with the notion that the lack of AD support should dilute the importance of the issue at hand. While AD support is being addressed separately (Compatibility chart) [...]

I am aware of the MDN compat chart. I am responsible for its accuracy. But it does not speak to support "being addressed separately". The issues I linked above speak to that.

[ericwbailey]

I'm not sure this is the right place to voice this sort of thing—the lack of adoption of the standard does not speak to its efficacy.

track's usage being low is like ruby or other elements, in that it's author responsibility. If you're angling for a heuristics-based UA fallback solution it might be more effective to bring it up with browser vendors.

[yashrajbharti]

Thanks a lot!
I intend to take as much feedback and tips in doing so. Currently instead of the solutions, I am more focused on the problem and its use cases. And I would love to understand better how to go about it from a11y experts.

I feel the problem statement, "Only 0.5% of web videos include a <track> tag, leaving a majority of online video content inaccessible for individuals who rely on captions", is sufficient for opening an issue here.

I think, unlike ruby, low adoption of track has its implications on web accessibility.

Also, as per https://whatwg.org/faq#adding-new-features the kind of issue that the WHATWG process prefers: A problem description, without any proposed solution required or expected, and I shall be looking to draft feature requests to various vendors as well.