EAA compliance for SvelteKit: WCAG 2.1 AA checklist & fixes

What the EAA actually requires from a SvelteKit site

Svelte's compiler emits accessibility warnings at build time (missing alt, click-on-non-interactive, missing labels, bad ARIA), so under the EAA the obligation partly depends on not silencing those warnings with svelte-ignore. EN 301 549 conformance additionally forces you to announce goto()-driven route changes through a live region, since SvelteKit navigations are silent to assistive tech, and to verify that interactive components are functional through the hydration window. Because SvelteKit server-renders semantic HTML, an auditor sees an accessible base, so the requirement centres on route announcements and post-hydration behaviour.

SvelteKit is favoured by small, fast-moving teams that value shipping accessible-by-default apps, so in-scope SvelteKit sites are typically startup or small-business consumer services facing fixed national fines rather than large-operator turnover penalties. The compiler's build-time warnings mean these teams often ship a cleaner accessibility baseline than equivalent React SPAs, lowering their practical risk. The main exposure is a team that has globally disabled the compiler warnings or leaned on svelte-ignore, which quietly removes the platform's built-in safety net.

Remediation is handled by the developer in the codebase: add a polite live region in the root layout that announces navigation via the afterNavigate hook, and resolve rather than suppress each compiler a11y warning. Keep the Svelte compiler warnings on globally and add eslint-plugin-svelte, then test the SSR output against client hydration to catch flashes for screen readers. Because the compiler surfaces many issues at build time, remediation is usually incremental and low-cost for a SvelteKit-comfortable team.

Top WCAG failures we see on SvelteKit sites

Across hundreds of SvelteKit scans, the same handful of issues show up over and over. None of them require ripping the theme apart — most are fixable in a few hours by someone comfortable in the platform's editor or template files.

• Route changes silent to assistive tech

  goto() does not announce; add a live region.

  4.1.3 — Level AA

• <!-- svelte-ignore --> abuse

  Compiler warnings ignored without addressing the underlying issue.

  all

Concrete code fixes for SvelteKit

Below are copy-paste fixes for the most common SvelteKit issues. They assume you have access to your theme code or the platform's custom-code injection panel. If you cannot edit code directly, share these snippets with whoever maintains the site — every one of them is a ten-minute change.

<script lang="ts">
  import { afterNavigate } from '$app/navigation';
  import { tick } from 'svelte';
  let routeMessage = '';
  afterNavigate(async ({ to }) => {
    await tick();
    const title = document.title;
    routeMessage = `Navigated to ${title}`;
  });
</script>
<div role="status" aria-live="polite" class="sr-only">{routeMessage}</div>
<slot />

Tools and plugins worth installing first

• Svelte compiler a11y warnings (do not disable globally)

• eslint-plugin-svelte

How to scan a SvelteKit site without missing anything

Automated scanners catch about 30–40% of WCAG issues; the rest need manual review. The good news is that the 30–40% includes the most expensive issues to remediate after the fact, so an automated scan is the cheapest way to get unstuck. Run one before you change a line of theme code.

• Test SSR output against client-side hydration; differences create flashes for screen readers.