WCAG 2.2, BFSG og EUs tilgjengelighetsdirektiv: compliance-stacken for WordPress i 2026

#WCAG 2.2, BFSG og EUs tilgjengelighetsdirektiv: compliance-stacken for WordPress i 2026

Tre dokumenter definerer hva et WordPress-nettsted må gjøre i 2026 for å være juridisk tilgjengelig i Den europeiske union: W3Cs Web Content Accessibility Guidelines 2.2, EUs tilgjengelighetsdirektiv (direktiv 2019/882) og Tysklands Barrierefreiheitsstärkungsgesetz. De er ikke utskiftbare; de stables. Denne artikkelen er gjennomføringskartet.

Teksten henger sammen med tjenestepilaren headless WordPress der den tekniske flaten beskrives, og med sjekklisten SEO-mønstre for headless WordPress der noen tilgjengelighetsmønstre også berører SEO.

#TL;DR

• WCAG 2.2 er den gjeldende W3C-anbefalingen, publisert 2023-10-05.
• EUs tilgjengelighetsdirektiv gjelder fra 2025-06-28 i alle medlemsstater.
• Tysklands BFSG implementerer EAA i føderal rett samme dato.
• Unntak for mikroforetak finnes, men er smalere enn folk antar.
• Bøter etter BFSG paragraf 37 når øvre femsifrede beløp i euro.

#De tre lagene, i rekkefølge

Tre juridiske og tekniske lag stables for å definere nettstedets plikt:

Lag én, WCAG 2.2 (teknisk). Settet med målbare suksesskriterier som definerer tilgjengelig webinnhold. Utarbeidet av W3C Web Accessibility Initiative. WCAG 2.2 ble publisert som anbefaling 2023-10-05 og legger til ni nye suksesskriterier over WCAG 2.1, inkludert fokusutseende, dra-bevegelser og konsistent hjelp.

Lag to, EUs tilgjengelighetsdirektiv (EU). Direktiv 2019/882, vedtatt i 2019, gjelder fra 2025-06-28. Det definerer hvilke produkter og tjenester som må være tilgjengelige og refererer til den europeiske standarden en 301 549, som inkorporerer WCAG ved henvisning. EAA sier ikke ordrett “følg WCAG 2.2”; det henviser til den europeiske harmoniserte standarden, som for tiden inkluderer WCAG 2.1 nivå AA. Nasjonale gjennomføringer kan kreve WCAG 2.2.

Lag tre, nasjonal gjennomføring (medlemsstat). Hver medlemsstat vedtar sin egen lov for å gjennomføre EAA. Tysklands er BFSG, i kraft samme dato som EAA-anvendelsen. Andre medlemsstater gjennomfører med lignende navn og lignende (noen ganger høyere) krav. Nettstedet må overholde gjennomføringsloven i hvert marked det selger inn i, ikke bare i hjemlandet.

Rekkefølgen betyr noe. WCAG er den tekniske lista. EAA er den juridiske rammen på EU-nivå. Den nasjonale loven er det lokale håndhevingsinstrumentet. Revisjoner går i denne rekkefølgen: teknisk først, juridisk deretter, lokalt sist.

#Hva WCAG 2.2 faktisk krever

WCAG 2.2 har 86 suksesskriterier fordelt på 13 retningslinjer under 4 prinsipper (Mulig å oppfatte, Mulig å betjene, Forståelig, Robust). Tre nivåer: A, AA, AAA. Den juridiske og kontraktsmessige standarden er AA. AAA er aspirasjonelt og ikke alltid praktisk for innholdstunge nettsteder.

De ni nye kriteriene i WCAG 2.2 over WCAG 2.1:

1. Fokusutseende (AA, nivå AA kun i 2.2)
2. Fokus ikke skjult minimum (AA)
3. Fokus ikke skjult utvidet (AAA)
4. Dra-bevegelser (AA)
5. Minimum målstørrelse (AA, 24 by 24 CSS pixels)
6. Konsistent hjelp (A)
7. Redundant inntasting (A)
8. Tilgjengelig autentisering minimum (AA)
9. Tilgjengelig autentisering utvidet (AAA)

For et WordPress-nettsted som allerede siktet mot WCAG 2.1 AA, er den praktiske jobben i 2026 å verifisere de ni nye kriteriene, der målstørrelse og dra-bevegelser er de vanligste hullene (små klikkbare ikoner, glidere som kun støtter dragging).

#EAA: omfang, unntak, frister

EAA dekker en definert liste over produkter og tjenester plassert på markedet fra 2025-06-28. Listen relevant for de fleste WordPress-operatører:

• Forbrukerrettede banktjenester.
• E-bøker og dedikert e-leservare.
• Elektroniske kommunikasjonstjenester.
• Audiovisuelle medietjenester.
• Persontransporttjenester (web- og mobilgrensesnitt).
• E-handelstjenester (samlekategorien for de fleste WooCommerce-butikker).

Direktivet definerer unntak for mikroforetak: færre enn 10 ansatte OG årsomsetning eller balansesum under 2 millioner EUR. Disse unntakene gjelder tjenesteytere; terskelen for produsenter er strengere. Den vanlige feillesningen er “lite nettsted, ingen regler”; den faktiske regelen er “liten operatør, smalere plikt, smalere unntak.”

Overgangsperiode: tjenestekontrakter inngått før 2025-06-28 kan fortsette under pre-EAA-vilkår senest til 2030-06-28. Selvbetjeningsterminaler som allerede er i bruk kan fortsette ut sin levetid, med en hard grense på 20 år.

#BFSG: den tyske implementeringen

Tyskland vedtok Barrierefreiheitsstärkungsgesetz (Lov om styrking av tilgjengelighet) for å gjennomføre EAA. Den trådte i kraft 2025-06-28.

Tre ting BFSG legger til utover EAA-grunnlaget:

Ett, håndheving på føderalt nivå. Bundesanstalt für Arbeitsschutz und Arbeitsmedizin og føderale markedsovervåkingsmyndigheter fører tilsyn med samsvar. Strukturer i medlemsstatene varierer; i Tyskland er føderalt tilsyn mekanismen.

To, bøtestruktur (paragraf 37, BFSG). Sanksjoner for manglende samsvar er definert i BFSG paragraf 37. Spesifikke overtredelsestyper utløser bøter i øvre femsifrede beløp i euro per overtredelse. Gjentatt eller systemisk manglende samsvar akkumuleres.

Tre, krav om tilgjengelighetserklæring. Nettstedet må publisere en tilgjengelighetserklæring lenket fra et lett oppdagbart sted (footer er konvensjonelt). Erklæringen oppgir samsvarsnivå, anførte unntak og en kontaktmekanisme for tilgjengelighetsklager.

Operatører som selger inn i Tyskland uten tysk registrering er fortsatt underlagt BFSG når deres produkter eller tjenester plasseres på det tyske markedet. Forsvaret “jeg er ikke et tysk selskap” finnes ikke.

#Hvå betyr dette for et WordPress-nettsted

Gjennomføringsarbeidet deler seg i fire kolonner.

Tema og kjerne. Velg et tema merket accessibility-ready på WordPress.org og verifiser mot WCAG 2.2 AA. Reviderer WordPress-administrasjonen, ikke bare frontenden; BFSG dekker også brukergrensesnittet ansatte bruker hvis de er omfattet av krav til inkluderende sysselsetting. WordPress-kjernen er generelt tilgjengelighetsbevisst (Accessibility-teamet er aktivt), men plugins og egenutviklet kode bryter listen jevnlig.

Plugins. Reviderer hver aktive plugins frontend-utdata. Konkrete feilmønstre vi ser revisjon etter revisjon:

• Sidebyggere (Elementor, Divi, WPBakery): sender ut <h1> for hero-tekst i hver seksjon og bryter overskriftshierarkiet. WCAG 2.4.6 (Overskrifter og etiketter) og 1.3.1 (Informasjon og relasjoner) feiler. Fiks: overstyr overskriftsnivåer på tema-malnivå, eller flytt til blokkredigereren.
• WooCommerce standard legg-i-handlekurv på arkivsider: kun ikon med aria-label, ingen synlig tekst og ingen synlig fokusindikator. WCAG 2.4.7 (Synlig fokus) og 2.5.8 (Minste målstørrelse, 24×24 CSS-piksler i WCAG 2.2). Fiks: utvid klikkbart område til 24×24, synlig fokusring med 3:1 kontrast, gjenopprett synlig tekst der det er mulig.
• Lysbildeplugins (Slick, Owl Carousel, MetaSlider, Smart Slider): ingen støtte for piltaster, ingen pausekontroll på automatisk roterende lysbilder. WCAG 2.2.2 (Pause, Stopp, Skjul) og 2.1.1 (Tastatur) feiler. Fiks: erstatt med et statisk bildegitter der det er mulig; om nødvendig, legg til synlige pause- og forrige/neste-knapper med riktige etiketter.
• Skjemaplugins (Contact Form 7, Gravity Forms, Ninja Forms): hopper over <label for>-koblinger, bruker plassholder som eneste etikett. WCAG 1.3.1 og 3.3.2 (Etiketter eller instruksjoner) feiler. Fiks: eksplisitt <label for="id">, feilmeldinger via aria-describedby, obligatoriske felt med aria-required="true".

Reviderer også admin hvis ikke-utviklerstab bruker den.

Innhold og redaksjonell disiplin. WCAG-håndheving på redaksjonelt nivå krever stående regler: hvert bilde trenger alt-tekst, hver lenke trenger beskrivende tekst (ikke “klikk her”), hvert overskriftshierarki er sekvensielt, hver video har teksting, hver PDF som er innebygd i en side er selv testet. CMS-en gjør teknisk samsvar mulig; redaksjonsteamet får det til å skje.

Tilgjengelighetserklæring og klagemekanisme. Erklæringen er obligatorisk i Tyskland under BFSG. Klagemekanismen (en kontakt-e-post eller skjema) må være funksjonell, ikke en formalitet. Klager om tilgjengelighet må bekreftes og adresseres innen rimelig tid.

#Hvorfor headless WordPress ikke automatisk er tilgjengelig

Et headless WordPress-bygg med en Astro- eller Next.js-front arver ikke tilgjengelighet fra WordPress-opphavet. Frontend-rammeverket er ansvarlig for det renderte HTML-et, modellen for tastaturinteraksjon, fokusstyringen og ARIA-semantikken. Å velge riktig rammeverk hjelper (både Astro og Next.js har sterke tilgjengelighetsmiljøer), men jobben må gjøres eksplisitt.

Per vår Tech Radar-ring-plassering er Astro 5+ og Next.js 15 begge i Adopt-ringen. Ingen av dem er automatisk WCAG 2.2-konform. Tilgjengelighetsrevisjonen er en egen arbeidsstrøm fra rammeverksvalget.

Headless-bygget kjøper én ting: per-rute kontroll over rendret HTML, noe som gjør tilgjengelighetspatcher landbare og forutsigbare. Et monolittisk WordPress-bygg formidlet gjennom en tung sidebygger er vanskeligere å rette opp når byggeren er kilden til utilgjengelig markup.

#Revisjonsfrekvens og verktøy

To revisjoner, to frekvenser:

Automatisert, hver CI-kjøring. axe-core eller pa11y kjørt mot et representativt utvalg av ruter. Stopper byggingen ved enhver ny overtredelse. Fanger opp omtrent halvparten av WCAG-problemene; bommer på halvparten som krever menneskelig vurdering (alt-tekst-kvalitet, intensjon i fokusrekkefølge, intensjon i ARIA-landemerker).

Manuell, årlig pluss ved store endringer. Opplært tilgjengelighetstester som kjører en full WCAG 2.2 AA-revisjon med testing av hjelpemidler (skjermleser, stemmestyring, kun tastatur). Resultatet er en gap-rapport koblet til spesifikke suksesskriterier.

Et nettsted som bare kjører den automatiserte revisjonen er ikke WCAG 2.2 AA-konform. Et nettsted som bare kjører den manuelle revisjonen driver mellom årlige gjennomganger. Begge er nødvendige.

#Start med avgrensning: hvem, hvilket marked og hvilken tjeneste

Ikke start med å installere en tilgjengelighetswidget. Start med en kort vurdering av virksomheten og tjenesten, og få den juridiske tolkningen bekreftet der det er nødvendig. Dokumenter hvem som leverer tjenesten, hvilke markeder den tilbys i, om mottakeren er forbruker, hvilke transaksjoner som kan fullføres digitalt, og hvilket selskap i konsernet som eier butikk, betaling og kundestøtte. Nettstedets språk, domenet eller antall sider avgjør ikke alene om reglene gjelder.

Det tekniske omfanget for WordPress må strekke seg lenger enn forsiden. Kartlegg produkt- og kategorimaler, søk, handlekurv, utsjekk, kundekonto, autentisering, skjemaer, nedlastinger, samtykkeløsninger og innebygde tredjepartsflater. Hvis kjøpet går videre til en betalingsleverandør eller et reservasjonssystem, dokumenter grensesnittet og test overgangen. Brukeren opplever én kundereise selv om organisasjonen fordeler den mellom flere leverandører.

Avgrensningen bør ende i en beslutningstabell, ikke bare konklusjonen «EAA gjelder» eller «vi er unntatt». For hver tjeneste registrerer du marked, målgruppe, forretningseier, systemene i reisen, grunnlaget for vurderingen og hvem som godkjente den. Dersom et unntak vurderes, behold underlaget og datoen for vurderingen. Dette er arbeidsdokumentasjon, ikke juridisk rådgivning eller en garanti for at en tilsynsmyndighet vil tolke forholdet likt.

#Bevispakken som gjør revisjonen etterprøvbar

En liste fra et automatisk verktøy er ikke alene bevis på en forsvarlig prosess. En nyttig bevispakke knytter omfang, funn og beslutninger til den konkrete versjonen som ble testet. Den bør inneholde:

• testede URL-er og grensesnittstilstander med dato, versjon, nettleser og visningsstørrelse;
• en WCAG 2.2 AA-matrise med resultat, bevis, brukerkonsekvens og ansvarlig for utbedring;
• protokoll fra tastatur, zoom og avtalte kombinasjoner av skjermleser og nettleser;
• skjermbilder, korte opptak eller DOM-utdrag som viser feilen og resultatet av retesten;
• register over unntak, tredjepartsbegrensninger og akseptert risiko med beslutningseier og ny vurderingsdato;
• gjeldende tilgjengelighetserklæring og prosessen for å motta, prioritere og lukke henvendelser.

Hvert funn må kunne gjenskapes. I stedet for «menyen virker ikke med skjermleser» beskriver rapporten ruten, starttilstanden, brukt teknologi, forventet oppførsel, faktisk oppførsel og relevant suksesskriterium. Da kan utvikleren rette feilen, testeren bekrefte resultatet og produkteieren forstå konsekvensen uten å gjenta hele revisjonen.

Oppbevar bevis sammen med utgivelsen de gjelder. Når tema, utsjekk eller skjemaarkitektur endres, beskriver ikke gamle resultater den nye versjonen. Unngå også en generell påstand om «fullt samsvar» når bare et utvalg er testet. Et nøyaktig angitt omfang er mer troverdig enn et vidt løfte.

#Akseptansetesting og en målbar definisjon av ferdig

Avtal akseptansekriteriene før utbedringen starter. Definisjonen av ferdig må angi hvilke maler og oppgaver som skal bestå, hvordan feil hos tredjepartsleverandører håndteres, og hvem som kan akseptere restrisiko. For WooCommerce bør scenarioene minst dekke å finne et produkt, velge variant, endre antall, håndtere valideringsfeil, betale, motta ordrebekreftelse og bruke kundekonto uten mus.

Kjør den automatiske skanningen etter endringen og på et representativt ruteutvalg, men bruk ikke en Lighthouse-poengsum som eneste godkjenningskrav. Manuell akseptanse bør kontrollere fokusrekkefølge og fokusutseende, dynamiske meldinger, feilbehandling, zoom og reflow, forståelige etiketter og om oppgaven kan fullføres. Kritiske reiser testes fra start til slutt, fordi en korrekt komponent kan svikte i kombinasjon med et modalvindu, en fast header eller skjemavalidering.

Et funn lukkes først etter retest på versjonen som faktisk skal utgis. En commit, leverandørens påstand eller fravær av skannerfeil er ikke nok. Sluttrapporten bør skille mellom bekreftet rettet, gjenstående med plan, leverandøravhengig og utenfor avtalt omfang.

#Utbedringsrekkefølge som reduserer risiko og dobbeltarbeid

Rett først barrierer som hindrer en oppgave: manglende tastaturstøtte, fokusfeller, utilgjengelig autentisering, feil som ikke er synlige eller kunngjøres, og kontroller som ikke kan aktiveres. Deretter retter du delte mønstre i tema og komponentbibliotek, som navigasjon, modal, skjema, produktkort og statusmeldinger. Én systemisk rettelse kan fjerne samme feil fra hundrevis av adresser.

Gå så videre til enkeltstående innholds- og dokumentfeil. Samtidig må kilden til nye barrierer stoppes med komponenttester, redaksjonelle regler og kontroll før publisering. En overlay eller widget erstatter ikke retting av kode, innhold og arbeidsmåte. Den kan endre presentasjonen uten å fjerne årsaken, og kan skape nye konflikter med hjelpemiddelteknologi.

Lanser små, testbare endringssett. Når semantikk, JavaScript og CSS endres i én stor leveranse, blir regresjoner vanskelige å spore. Kjør en rask kontroll av kritiske reiser etter hvert sett og en full retest av avtalt utvalg før programmet avsluttes.

#Løpende styring etter første utbedring

Tilgjengelighet er ikke et engangsprosjekt. Produkteieren bør eie prioritering og frister, teknisk team komponenter og regresjonstester, redaksjonen bilder, overskrifter, lenker og media, og kundestøtte den tilgjengelige kontaktkanalen. Tema- eller pluginleverandøren kan bidra, men overtar ikke organisasjonens beslutning om å publisere.

Gjennomgå nye maler, brukerhenvendelser og åpne unntak regelmessig. Test kritiske reiser ved større utgivelser. Utfør en bredere revisjon etter avtalt kadens og når utsjekk, tema, innlogging eller en sentral leverandør endres. Tilgjengelighetserklæringen oppdateres når nettstedets faktiske tilstand endres, ikke bare på årsdagen for publisering.

For et omfang som kan estimeres, send en skriftlig brief med nettstedets adresse, markeder, salgsmodell, aktivt tema og sentrale plugins, kritiske kundereiser, kjente barrierer og ønsket lanseringsdato. Da kan en WCAG-revisjon av WordPress deles i avgrensning, testing, utbedringsplan og retest. Leveransen dokumenterer tilstanden og neste tiltak, men er ikke et løfte om juridisk sikkerhet eller en automatisk garanti for samsvar.

#Hvor dette passer inn

Denne pilaren forankres i headless WordPress-tjeneste-klyngen som compliance-dimensjonen. For rammeverksvalg, se Next.js vs Astro-beslutningsmatrisen. For SEO-migrasjonsrisikoer (noen tilgjengelighetsmønstre påvirker også SEO, særlig overskriftshierarki og lenketekst), se SEO-mønster-sjekklisten. For NIS2- og DORA-samsvar, som ofte dukker opp i samme anskaffelses-scorecard, se den dedikerte NIS2- og DORA-på-WordPress-artikkelen.