svelte
svelte copied to clipboard
This warning should be removed - A11y: Media elements must have a <track kind="captions">
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,
tracktags 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 -
trackwithoutsrc- 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
altattribute onimgwhich is meaningfully different from noaltfor 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)
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.
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.
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.
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 asrc.
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.
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
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.
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.
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.
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.
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.
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.
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.
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
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.
If anyone came by in 2025, there is a solution for <video>, by putting muted attribute to your video. The catch is that it will permanently mute your video, you can't turn sound on.
<video muted>
<source src="my-video.webm" type="video/webm" >
</video>
That’s quite a catch. 😂
I've built a fairly large website with sveltekit that contains several hundred short videos. The compiler then spams me with several hundred compiler warnings about this issue.
This actively makes my website worse, since (most) of the rest of the compiler warnings are useful and—crucially—I can do something about them. (For example, I want to know if I have an H1 tag with no content, or indeed an image with no alt.)
But the client is not going to supply me with hundreds of hours of transcripts, nice though that would be, and neither can I spend several months transcribing the videos. Most developers will be in a similar scenario.
Yes, I realise I can sprinkle several hundred a11y suppression tags through the codebase but I feel this is not the cleanest solution for this particular warning. It's a valid solution for the vanishingly-rare times you use an img without an alt, but not for cases when you are given an arbitrary-length video with no transcript.
I'd much prefer a svelte compiler option to enable this for developers who really need it.
You can use the warningFilter compiler option to silence this warning for your whole project https://svelte.dev/docs/svelte/svelte-compiler#ModuleCompileOptions
Thank you @dummdidumm that is exactly what I was looking for. I had looked at the Compiler Warnings document but missed the page you linked to. For those (like me) not super-familiar with vite configs, it turns out you just need to edit your svelte.config file and add an "onwarn" property:
const config = {
preprocess: vitePreprocess(),
onwarn(warning, defaultHandler) {
if (warning.code === "a11y-media-has-caption") return;
//console.log("not suppressing warning with code " + warning.code);
defaultHandler(warning);
},
kit: {
// adapter-auto only supports some environments, see https://kit.svelte.dev/docs/adapter-auto for a list.
// If your environment is not supported or you settled on a specific environment, switch out the adapter.
// See https://kit.svelte.dev/docs/adapters for more information about adapters.
adapter: adapter(),
},
It results in the same outcome, but that variant will likely be removed at some point from vite-plugin-svelte.
What I meant is { compilerOptions: { warningFilter: ... }}
This worked. Thank you! Now i dont have to inline the svelte-ignore on every video tag.
Thank you @dummdidumm that is exactly what I was looking for. I had looked at the Compiler Warnings document but missed the page you linked to. For those (like me) not super-familiar with vite configs, it turns out you just need to edit your svelte.config file and add an "onwarn" property:
const config = { preprocess: vitePreprocess(), onwarn(warning, defaultHandler) { if (warning.code === "a11y-media-has-caption") return; //console.log("not suppressing warning with code " + warning.code); defaultHandler(warning); }, kit: { // adapter-auto only supports some environments, see https://kit.svelte.dev/docs/adapter-auto for a list. // If your environment is not supported or you settled on a specific environment, switch out the adapter. // See https://kit.svelte.dev/docs/adapters for more information about adapters. adapter: adapter(), },