This warning should be removed - A11y: Media elements must have a <track kind="captions">

[taw]

To reproduce. Open svelte repl or any svelte project, add audio or video tag:

<audio src="https://media.w3.org/2010/07/bunny/04-Death_Becomes_Fur.mp4" controls />

Expected:

• it just works and compiler is happy

What actually happens:

• A11y: Media elements must have a <track kind="captions"> (1:0)

Reasons this warning needs to be removed:

• Browsers do not even support <track> for <audio> in any way whatsoever
• Even for videos, track tags are not in any kind of widespread use
• There's no accessibility value of empty <track kind="caption"> which linter wants people to add
• As far as I can tell, what linter wants - track without src - is not even valid according to spec! "The src attribute gives the address of the text track data. The value must be a valid non-empty URL potentially surrounded by spaces. This attribute must be present."
• (this is completely unlike empty alt attribute on img which is meaningfully different from no alt for historical reasons)
• Vast majority of audio/video content does not have and will never have any kind of captions
• For a lot of use cases, it wouldn't even make sense (same as a lot of imgs can't even have any meaningful nonempty alt)

[geoffrich]

I agree that it makes sense to remove this check for <audio> elements:

• The corresponding axe-core rule has been deprecated
• The corresponding Lighthouse audit has been deprecated
• As you mentioned, browsers ignore tracks within audio elements

However, the same is not true for the corresponding rule for <video> elements and browser support is good. I think it still makes sense to encourage captions on videos. The warning can always be ignored in the component using <!-- svelte-ignore a11y-media-has-caption -->.

As a side note, I don't read the warning as suggesting you add an empty <track kind="caption"> -- it's implied that you add a src. We could make the rule require a src as well to make this clear.

[geoffrich]

Also note that the Svelte tutorial currently has a compiler warning for missing audio captions. Either the rule should not check audio elements or the tutorial should be updated to resolve the warning. This is also a case where it wouldn't make sense to have captions even if audio captions were supported since it's music only, no speech.

[taw]

The one for video makes a lot more sense than one for audio, since it at least works, but I'd recommend removing it as well, as absolutely overwhelming majority of video content available has no subtitles and will never have any.

Svelte tutorial having invalid fake <track kind="captions"> for video just to make this rule shut up just proves this point.

<!-- svelte-ignore a11y-media-has-caption --> is not much of a solution, as most devs will have no idea it's even a thing, and the warning message doesn't mention that option.

[happycollision]

As a side note, I don't read the warning as suggesting you add an empty <track kind="caption"> -- it's implied that you add a src.

Only to someone familiar enough with the track tag to begin with. Just a couple days ago, I created https://github.com/sveltejs/svelte/issues/6034 which quotes a developer who broke his app by including <track kind="caption"> exactly.

FWIW, I like the solution proposed in this issue better than the proposed solution in mine.

[rchrdnsh]

I agree...I followed this direction and put a <track kind="captions"/> in my <audio> tag and the app completely broke in iOS 14.4 Safari on the iPhone 12 Pro...filed a bug report with webkit and was able to confirm that removing it completely made the app work again...and I am one of those people who had no idea that I needed a src file, to be honest...it was just something I did to make the warning go away...I get wanting to add this to a video with dialog and visual cues, etc...but don't see the value for

[geoffrich]

I opened a PR to remove the warning for audio elements since it's causing the most issues and browsers don't support it. I made sure to note in the PR that it doesn't completely resolve this issue, since there's still some discussion around removing the warning for video elements as well.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lingster]

just to chime in here, we are building a custom video conferencing app using AWS chime and svelte. We get this warning when we are using the <video> tag as this is required for the AWS chime to inject the video stream. As the stream is live, there won't be any captions/subtitles.
<!-- svelte-ignore a11y-media-has-caption --> was added to suppress the warning albeit not optimal.

[aradalvand]

More often than not this warning isn't helpful at all. There are numerous reasons why captions wouldn't make sense + some libraries like hls.js set captions dynamically via videoElement.textTracks after parsing the HLS manifest, so there will be no <track> tag in the markup and rightfully so.

Even in one of the official tutorials there's a dummy <track> just to silence this warning; which goes to show how annoying and unhelpful it is most of the time.

[tgf9]

I'm working on an app that serves silent video. We have no use for an audio track inside of the video, so this warning doesn't even make sense in our context.

[frogdesk]

I don't really agree with this warning either. Why are you assuming my video has words in it? You can't protect devs from every footgun. This is far more likely to be a false positive than a valid warning IMO.

[gregg-cbs]

This warning has made me think about captions. I didnt even know you could have a track inside of a video tag. But in my case the warning is a pain because my video doesnt need a track and even if it did i wouldnt add it because i dont have the capacity to generate captions for all my videos.

[ewen-lbh]

I'm rendering a camera output for a QR code scanner inside of an app. What caption would I even put? If there was one, It'd be the decoded qr code content, but that would be set dynamically, not in the markup (and would a11y technologies even support dynamically-changing <track kind=captions> elements?)

Just chiming in with yet another use case where the video has no available captions, and making this an error instead of a warning makes my build fail. Making it a warning instead of removing it should not be done though, making devs aware of a11y issues is way too important - but making builds fail because of this is a bit much -- and empty tracks should definitely not be suggested tho

[SirVeggie]

I was just about to add that empty track line, before googling it just in case, and now I find out it could actually cause a bug instead. It seems to me that if you know you have captions available, you would most likely already be thinking how to include them, and therefore this warning only serves to introduce a bug, and not encourage accessibility.

The only way I see that this benefits accessibility, is that the developer decides to create captions for the videos after seeing the warning, but considering how involved such a process is, that seems unlikely to happen if a warning is the only reason they would have for it.