What is Svelte's approach to accessibility?

Answer

Svelte has built-in accessibility warnings at compile time — if you write inaccessible HTML, the compiler warns you during development. Checks include: missing alt text on images, non-descriptive button/link labels, invalid ARIA attributes, missing lang attribute, and interactive elements without accessible roles. These warnings appear in the terminal and can be configured in compilerOptions.warningFilter. Svelte-specific a11y patterns: Svelte's transition system respects the prefers-reduced-motion media query: import { prefersReducedMotion } from 'svelte/motion'; or use @media (prefers-reduced-motion: reduce) in CSS. SvelteKit's router announces route changes to screen readers via a live region — this is often missing in custom SPA routers. Focus management: SvelteKit moves focus to the main content on navigation. Best practice: use semantic HTML elements (<nav>, <main>, <button>), leverage ARIA roles only when semantic elements are insufficient, and test with screen readers (NVDA, VoiceOver) and keyboard navigation.