Jeg skrev et stykke om hva WCAG er, og kom med en påstand i det: AI-verktøy gir deg et nettsted som ser ferdig ut og i det stille er utilgjengelig. Så gjorde jeg det åpenbare og kjørte sjekkene på mitt eget nettsted, det du leser dette på. Det fikk 100. Jeg var likevel ikke ferdig, og denne gjennomgangen er grunnen.
Har du ikke lest forklaringen, så er kortversjonen: WCAG er standarden for tilgjengelig nett, og «kan alle bruke dette» er hele spørsmålet. Her forklarer jeg det ikke. Jeg sjekker et ekte nettsted mot det, finner hullet verktøyene bommet på, fikser det, og kobler på sjekken så den kjører uten meg.
Steg 1: kjør den automatiske skannen (2 minutter)
Raskeste signal er Lighthouse. Det ligger inne i Chrome.
1. Åpne nettstedet i Chrome, åpne DevTools (høyreklikk, Inspiser).
2. Gå til Lighthouse-fanen, huk av Accessibility, klikk Analyze page load.
Eller fra terminalen, som er det jeg gjorde for å kunne lagre resultatet:
lighthouse https://kenove.no/ --only-categories=accessibility \
--chrome-flags="--headless=new" --output=html --output-path=./a11y.htmlMitt resultat: 100, null feilende sjekker.
Her er fellen. Lighthouse kjører axe-core-regler under panseret, og de automatiske reglene fanger kanskje en tredjedel til halvparten av WCAG. En 100 betyr «ingenting en maskin kan oppdage er ødelagt». Det betyr ikke at nettstedet fungerer for alle. Så scoren er starten på sjekken, ikke slutten.
Steg 2: den manuelle runden (15 minutter)
Dette er delen scoren ikke kan gjøre for deg. Ingenting av det krever kode.
Trekk ut musa. På ekte. Trykk så Tab, om og om igjen, fra toppen av siden.
Når du frem til hver lenke, knapp og felt?
Ser du alltid hvor du er? Det må være en synlig fokusmarkering.
Gir rekkefølgen mening, ovenfra og ned, eller hopper fokus et merkelig sted?
Kan du betjene alt: åpne menyer, sende inn skjemaet, lukke dialoger?
Kjør en skanner til. Installer den gratis utvidelsen axe DevTools eller WAVE i nettleseren og les hva den flagger. Et verktøy nummer to fanger ting Lighthouse formulerer annerledes eller bommer på.
Sjekk noen detaljer for hånd:
Se kildekoden og bekreft at <html lang="..."> er satt, og at den er riktig per språk. På de norske sidene mine er den nb, som er riktig.
Én <h1> per side, deretter overskrifter som trapper nedover i rekkefølge uten å hoppe over nivåer.
Ekte landemerker: <main>, <nav>, <header>, <footer>.
Hvert meningsbærende bilde har alt som beskriver det. Dekorative bilder får tom alt="".
Kjør en kontrastsjekker på brødtekst og knapper. Sikt mot AA-verdiene (4,5:1 for normal tekst).
Steg 3: hva den manuelle runden faktisk fant
To ting, og begge er hele poenget med denne gjennomgangen.
En falsk positiv. Det første raske skriptet mitt flagget e-postfeltet til nyhetsbrevet for å mangle en merkelapp. Jeg så på koden før jeg trodde på det:
<label for="footer-email" class="sr-only">Email address</label>
<input type="email" id="footer-email" placeholder="you@domain.com" required />Det er merket riktig. Merkelappen er visuelt skjult med sr-only, men leses opp av en skjermleser, og for/id-paringen stemmer. Verktøyet tok feil, og eneste måten å vite det på var å sjekke. Det er vanen: et flagg er et spørsmål, ikke en dom.
Et ekte hull scoren aldri nevnte: ingen hopp-til-innhold-lenke. En tastaturbruker som lander på en hvilken som helst side må tabbe gjennom hele toppfeltet og menyen før den når innholdet, på hver side. Fiksen er en «Hopp til innhold»-lenke som er det første du når, skjult til den får fokus. Dette er WCAG 2.4.1 Hoppe over blokker (nivå A). Strengt tatt tar riktige landemerker deg et stykke på vei på papiret, men hopp-lenken er teknikken enhver revisjon forventer, og opplevelsen av å tabbe gjennom alt er reell uansett. Lighthouse ga 100 og nevnte det aldri. Tastaturrunden fant det på rundt tretti sekunder.
Steg 4: fiks det (den faktiske endringen)
Nettstedet mitt er bygd i Lovable (React, TanStack Start). Her er nøyaktig hva jeg la til.
En liten komponent, visuelt skjult til den får fokus:
export function SkipLink({ locale }: { locale: "en" | "no" }) {
const label = locale === "no" ? "Hopp til innhold" : "Skip to content";
return (
<a
href="#main-content"
className="sr-only focus:not-sr-only focus:absolute focus:left-4 focus:top-4 focus:z-50 focus:rounded focus:bg-ink focus:px-4 focus:py-2 focus:text-paper focus:no-underline focus:shadow-lg focus-visible:outline-none"
>
{label}
</a>
);
}Lagt inn som det første elementet inni <body>, så det er det første et tastatur når:
<body>
<SkipLink locale={locale} />
{children}
<Scripts />
</body>Og målet den hopper til: hver sides <main> får samme id, og tabIndex={-1} så fokus faktisk lander der.
<main id="main-content" tabIndex={-1}> ... </main>Verifiser så, ikke anta. Typesjekk, og trekk ut musa igjen: Tab én gang fra toppen, «Hopp til innhold»-brikken skal dukke opp, Enter skal hoppe deg forbi menyen til innholdet.
Steg 5: koble det på så det forblir fikset
Å gjøre dette én gang er rutinearbeid. Verdien ligger i å få det til å kjøre uten deg. Tre lag, fra minst til mest oppsett.
Skann ved hver publisering. Lovable synkroniserer til et ekte GitHub-repo, så en GitHub Action kan skanne hver push. En minimal en med pa11y-ci:
name: accessibility
on: [push]
jobs:
pa11y:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with: { node-version: 22 }
- run: npx pa11y-ci --sitemap https://kenove.no/sitemap.xmlEn felle jeg gikk i på ekte: GitHubs nåværende Ubuntu-runnere lar ikke Chrome starte sandkassen sin, så den første kjøringen min døde før den fikk skannet en eneste side. Fiksen er en liten konfigurasjonsfil som heter .pa11yci ved siden av koden din:
{
"defaults": {
"chromeLaunchConfig": { "args": ["--no-sandbox"] }
}
}Med den på plass kjørte testen grønt mot det live nettstedet. Den går gjennom sitemap-en, kjører sjekkene, og lar kjøringen feile hvis et nytt avvik dukker opp. Du endrer en knapp, sjekken kjører, og du oppdager det på minutter i stedet for tre uker senere. (Lighthouse CI, @lhci/cli, gjør det samme med score-budsjetter om du heller vil ha et tall å holde.)
Skann etter en tidsplan. For en sikkerhetsnett-sjekk som ikke avhenger av en publisering, peker jeg en n8n-flyt mot det live nettstedet én gang i uka: en Schedule-trigger, en Execute Command-node som kjører pa11y på nøkkel-URL-ene, og en Gmail-node som sender meg differansen. Satt opp én gang, oversett til den har noe å si.
Gjør resultatet om til rettelser med Claude. En rå pa11y- eller axe-rapport ser ut som feilkoder. Lim den inn i Claude og be den forklare hvert problem på vanlig norsk og foreslå den konkrete endringen for rammeverket ditt. Samme grep på de kjedelige delene: lag utkast til alt-tekst for en bunke bilder, eller la den gå gjennom én komponent for tilgjengelighetsfeil før du publiserer.
Grensen, igjen
Automatisering tok meg til 100 og holder meg der. Den fant ikke hopp-lenken, og den kan ikke fortelle meg om tastaturrekkefølgen kjennes riktig eller om en skjermleserbruker faktisk får fullført oppgaven. Den delen forblir menneskelig, i hvert fall foreløpig. Mønsteret er tre steg, og bare det midterste er nytt: oppdag automatisk, rett med AI-hjelp, verifiser for hånd. Maskinen flagger, AI-en lager utkast til rettelsen, du bekrefter at den faktisk fungerer.
Det er hele metoden. Nettstedet mitt fikk 100, hadde et ekte hull likevel, og har nå en sjekk som kjører på hver push. Ditt kan også det, på omtrent tiden det tok å lese dette.