Tilgjengelighet (WCAG 2.2) i 2026: Er WordPress-siden din lovlig?

I juni 2025 endret det digitale landskapet seg for alltid. European Accessibility Act (EAA) trådte i full kraft, og gjorde digital tilgjengelighet til et lovkrav for nesten alle digitale virksomheter som opererer i Europa.

Det er ikke lenger bare “kjekt å ha”. Det er beslektet med GDPR. Manglende overholdelse risikerer betydelige bøter og søksmål.

For WordPress-utviklere og nettstedeiere er standarden WCAG 2.2 Nivå AA. Denne guiden (2000+ ord) bryter ned nøyaktig hva som endret seg i 2026 og hvordan du sikrer at temaet ditt ikke bryter loven.

#1. Eaa: Hvorfor 2025 var vendepunktet

Tidligere gjaldt tilgjengelighetslover hovedsakelig offentlig sektor (Stat/Kommune). EAA utvidet dette til E-handel, Bank, Transport og e-bøker.

• Omfang: Hvis du selger en t-skjorte til en kunde i Frankrike (eller Norge), må utsjekkingsflyten din være tilgjengelig.
• Straffen: Bøter varierer fra land til land, men de kan være alvorlige, kombinert med omdømmeskaden ved å ekskludere 15% av den globale befolkningen.

#2. WCAG 2.2: De nye kriteriene forklart

WCAG 2.2 bygget på 2.1, og la til 9 nye kriterier. De mest kritiske for WordPress-temaer er:

#2.4.11 fokus ikke skjult (minimum) (aa)

• Problemet: Du tabber nedover en side. Et element får fokus, men din “Sticky Header” eller “Cookie Banner” dekker det til. Brukeren vet at de er et sted, men kan ikke se hvor.
• Løsningen: Bruk CSS scroll-padding-top på html-elementet for å sikre at fokuserte elementer scroller inn i det synlige området under den klebrige overskriften din.

#2.5.8 målstørrelse (minimum) (aa)

• Regelen: Interaktive mål (knapper) må være minst 24x24 CSS-piksler.
• Virkeligheten: De små “X” lukkeknappene på popup-vinduene dine? De er ulovlige. Gjør dem større. Fingertrykk er upresise.

#3.3.8 tilgjengelig autentisering (aa)

• Regelen: Ikke tving brukere til å løse gåter (CAPTCHA-er) eller huske passord uten hjelp.
• WordPress-påvirkningen: Støtt passordbehandlere (ikke blokker innliming i passordfelt) og bruk “Magic Links” eller WebAuthn (Biometri) der det er mulig.

#3. Semantisk HTML: Fundamentet

90% av tilgjengelighetsproblemer løses ved å skrive korrekt HTML.

• Landemerker: Bruk <main>, <nav>, <aside>, <footer>. Skjermleserbrukere hopper mellom disse regionene. Ikke drukne alt i <div>-suppe.
• Overskrifter: h1 til h6 er et hierarki, ikke et stilvalg. Ikke hopp fra h2 til h4 bare fordi du vil ha en mindre skrifttype. Bruk CSS for størrelse.
• Knapper vs. Lenker:
  • Går til en ny URL? Bruk <a>.
  • Endrer noe på gjeldende side (åpner en meny)? Bruk <button>.
  • Bruk aldri <div onClick="...">. Det er usynlig for tastaturer.

#4. “Overlegg”-fellen

Du har sett dem. Det lille “mann i sirkel”-ikonet i hjørnet som åpner en meny for å endre kontrast eller skriftstørrelse. Unngå dem.

• Falsk trygghet: De hevder å gjøre deg kompatibel umiddelbart med én linje JS. Det gjør de ikke. De kan ikke fikse semantiske HTML-feil.
• Brukerfriksjon: Blinde brukere har allerede skjermlesere. De trenger ikke at overlegget ditt forstyrrer verktøyene deres.
• Juridisk risiko: I USA har selskaper som bruker overlegg blitt saksøkt oftere fordi det beviser at de visste at de hadde et problem, men valgte en “plaster”-løsning.

#5. Testing: Automatisert vs. Manuell

Du kan ikke automatisere tilgjengelighet 100%.

#Testarbeidsflyten

1. Automatisert (30%): Bruk axe-core eller Lighthouse “Accessibility”-revisjon. Dette fanger opp manglende alt-tekst og lav kontrast.
2. Manuell tastatur (50%): Koble fra musen. Kan du navigere i hele menyen, åpne undermenyene og fylle ut kontaktskjemaet ved å bruke kun Tab, Enter og Mellomrom-tastene? Hvis ikke, stryker du.
3. Skjermleser (20%): Slå på VoiceOver (Mac) eller NVDA (Windows). Lukk øynene. Kan du forstå hva som skjer?

#6. Tilgjengelige skjemaer i WordPress

Contact Form 7 og Gravity Forms er populære, men ofte feilkonfigurert.

• Etiketter: Hver inndata trenger en <label>. Plassholdere er IKKE etiketter (de forsvinner når du skriver).
• Feilmeldinger: “Feil funnet” er ubrukelig. “E-postadressen mangler @-symbolet” er tilgjengelig.
• Fokusstyring: Når en bruker sender inn et skjema og det er en feil, flytt tastaturfokuset programmatisk til det første feilfeltet slik at de kan fikse det umiddelbart.

#7. Konklusjon

Tilgjengelighet blir ofte fremstilt som en begrensning. I virkeligheten er det en kvalitetsindikator. Tilgjengelig kode er renere, mer robust og bedre for SEO. I 2026 er det å bygge et inkluderende nett ikke bare loven – det er den eneste profesjonelle måten å jobbe på.

Trenger du en tilgjengelighetsrevisjon? WPPoland tilbyr WCAG 2.2-utbedringstjenester for bedrifter.