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.