Svelte a11y compiler warnings: deciding between build-time enforcement and suppressions

Context

Svelte's compiler performs static accessibility analysis during compilation, emitting warnings for issues like missing alt attributes on images, invalid ARIA usage, and keyboard navigation gaps. These warnings appear in the build output without any external linting setup, and individual cases can be suppressed with svelte-ignore comments.

The decision

I'm designing a team workflow around these warnings and hitting a tension the documentation doesn't resolve. The compiler's analysis is static, so it cannot catch accessibility problems that emerge from dynamic state changes at runtime — for example, focus management after a conditional block renders, or live region behavior. That means the build-time warnings alone can't be the whole accessibility story.

At the same time, liberal use of svelte-ignore for edge cases (where the compiler can't know the runtime context) risks quietly eroding real coverage if suppressions are never revisited.

Questions

• Is there a documented or conventional way to treat a11y compiler warnings as build failures (rather than console noise) in a standard Svelte/SvelteKit pipeline?
• What is the recommended practice for auditing or scoping svelte-ignore suppressions so they don't accumulate unchecked?
• Which runtime checks (e.g., browser-based tooling) are typically paired with the compiler warnings to cover dynamic-state issues?

Assume a recent Svelte version; please note if behavior differs across major releases.