Svelte: a11y gives img alt warnings when it shouldn't

[UltraCakeBakery]

Describe the bug
The following repl gives a warning about the 'alt' attribute on the img.
https://svelte.dev/repl/b9996b40855e4d73b835e066ae0a6557?version=3.24.1

I think it is a unfair warning as there is no way to describe what this image is without the use of the word 'picture' without using too many unnecessary other words.

Logs
None

To Reproduce
https://svelte.dev/repl/b9996b40855e4d73b835e066ae0a6557?version=3.24.1

Expected behavior
I expect svelte to make exceptions in situations like a profile picture, an image that shows someone printing an image described as 'someone printing a picture or image', etc. I should not have to add a ignore warning for these cases. Not ever, really.

Information about your Svelte project:

• Your browser and the version: unrelated
• Your operating system: unrelated
• Svelte version: the one used in the repl
• Sappers default rollup template

Severity
It is annoying and confusing to Svelte newbies like me.

Additional context
Here is my original issue I made about this over at https://github.com/sveltejs/language-tools/issues/524

[Conduitry]

Svelte's a11y warnings are based on those from eslint-plugin-jsx-a11y, and as far as I can tell, the corresponding one for this warning would also warn about this. The warning is slightly unfortunate in this case, but I don't think this is something we want to change or where we want to diverge from the original implementation. You can use comments to disable individual warnings.

Separately, I have no idea how the compiler would be able to make exceptions here without being able to understand English.

[UltraCakeBakery]

The compiler already knows I'm using the word 'image' or 'picture'. So in theory it could simply check for common combinations. There should never be a need for dampening warnings imo.

Is svelte's implementation of the a11y linting entirely separate from eslint-plugin-jsx-a11y?
Can we configure exceptions easily?

[dummdidumm]

I know it's unfortunate but I doubt we will change this. Opening the door to exceptions by checking for combinations opens the door to many more requests like this which would become unmaintainable at some point. And what about other languages? Adding the ignore comment is meant exactly for edge cases like this.

[UltraCakeBakery]

I know it's unfortunate but I doubt we will change this. Opening the door to exceptions by checking for combinations opens the door to many more requests like this which would become unmaintainable at some point. And what about other languages? Adding the ignore comment is meant exactly for edge cases like this.

Fully agree with this. Still don't like the ignore comment. This is also not an ideal way to solve this issue.
Are there any alternatives? Something like a a11y config?

[pngwn]

No, we won’t be adding an a11y config. The ignore comments exist to solve this case already on a case by case basis.