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.

#Hva 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.

#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.