Tilgjengelighetswidget: derfor holder den ikke for UU-forskriften

Søker du etter «gjør nettstedet WCAG-compliant automatisk», møter du raskt en håndfull leverandører som accessiBe, UserWay og EqualWeb. Løftet er nesten likt hos alle: lim inn en kodesnutt, og nettstedet blir tilgjengelig i løpet av minutter.

Det er en attraktiv snarvei for en virksomhet som har lest om UU-forskriften og dagbøtene den kan medføre, men ikke har tid til en full gjennomgang av koden. Snarveien holder likevel ikke det den lover.

Hva en widget faktisk gjør

En tilgjengelighetswidget er et skript som lastes inn på siden, som regel via en enkelt kodelinje i head-taggen eller footeren. Skriptet setter typisk opp en flytende meny der brukeren kan justere kontrast, tekststørrelse, skrifttype og noen få andre visuelle innstillinger.

Noen widgets går lenger og forsøker automatisk kodereparasjon: de leter etter bilder uten alternativtekst og fyller inn en gjettet beskrivelse, eller forsøker å rette opp manglende skjemaetiketter uten at en utvikler har sett på koden.

Det er nettopp den automatiske reparasjonsdelen som er problemet. Alternativtekst skal beskrive hva bildet betyr i sin kontekst — det kan ikke gjettes av et skript som ikke forstår innholdet.

Markedsføringen bruker ofte formuleringer som «AI-drevet compliance» eller «gjør nettstedet ditt WCAG 2.1-kompatibelt». Det er fristende språk for en virksomhet som vil ha problemet løst raskt. Men compliance er ikke en tilstand et skript kan sette — det er et resultat av at koden og innholdet faktisk oppfyller hvert enkelt kriterium.

Hvorfor automatikk ikke er nok

Dette gjelder ikke bare widgets — det gjelder alle automatiske verktøy. UUTilsynets egen veiledning peker på at automatiske verktøy er et nyttig supplement, men ikke gode nok til å erstatte manuell testing alene. Vi går gjennom hvorfor i vår artikkel om gratis testverktøy — automatikk fanger typisk 30–40 prosent av faktiske WCAG-brudd. Resten krever at et menneske tester tastaturnavigasjon, skjermleseropplevelse og om innholdet faktisk er forståelig.

En widget er fortsatt automatikk. Den kan ikke vite om tabulatorrekkefølgen på et bestillingsskjema er logisk, om en video har riktig teksting, eller om en feilmelding faktisk forklarer hva brukeren gjorde galt. Disse kravene ligger i selve koden og innholdet — ikke noe et skript i footeren kan fikse utenfra.

Fagmiljøets kritikk

Kritikken mot overlay-widgets kommer ikke bare fra konkurrenter. Flere brukerorganisasjoner for personer med nedsatt funksjonsevne har uttalt at widgetene i praksis kan komme i konflikt med hjelpemidler brukeren allerede har satt opp selv — som en skjermleser med egne innstillinger for navigasjon.

Når widgeten legger nye elementer inn i siden, kan den forstyrre rekkefølgen skjermleseren leser opp, eller introdusere navigasjonselementer brukeren ikke ba om. Løftet er en enklere opplevelse. Realiteten kan bli det motsatte for brukeren verktøyet skal hjelpe.

Det er bakgrunnen for at flere i tilgjengelighetsmiljøet anbefaler å styre helt unna overlay-widgets som løsning, og heller bruke tid og budsjett på faktisk retting av koden. En kontrastvelger eller innstilling for tekststørrelse er ikke skadelig i seg selv — problemet oppstår når det selges inn som svaret på hele regelverket.

Det juridiske: en widget er ikke en erklæring

UU-forskriften krever at nettstedet faktisk oppfyller WCAG-kravene — ikke at du har installert et verktøy som hevder å oppfylle dem. For offentlig sektor skal status dokumenteres i en tilgjengelighetserklæring, punkt for punkt mot alle suksesskriteriene. Der må du oppgi det faktiske avviket, ikke at «vi har løst dette med en widget».

Det er ingen bestemmelse i regelverket som sier at bruk av et bestemt verktøy fritar deg fra kravene. UUTilsynet tester det faktiske nettstedet når de fører tilsyn — ikke hvilke tredjepartsskript som er lastet inn.

Samme logikk gjelder for privat sektor, selv uten plikt til erklæring. Blir du klaget inn eller tatt ut til tilsyn, er det det faktiske nettstedet som testes mot WCAG-kriteriene. Et abonnement på en widget er ingen dokumentasjon på at kravene er oppfylt.

Hva du bør gjøre i stedet

Den reelle veien til compliance går gjennom faktisk retting i koden, ikke et lag på toppen av den. En realistisk startliste:

1. Kjør en automatisk skanning som baseline.
   Verktøy som axe DevTools, Lighthouse eller Vordr finner de tekniske feilene raskt — manglende alternativtekst, for dårlig kontrast, skjema uten etiketter.
2. Rett feilene i koden, ikke rundt den.
   Legg alternativtekst direkte i bildekoden. Fiks kontrastverdiene i stilarket. Gi skjemafelt ordentlige `label`-elementer. Dette er permanent, og fungerer uavhengig av om besøkende har JavaScript aktivert.
3. Test manuelt der automatikk stopper.
   Tab deg gjennom siden uten mus. Test med en skjermleser. Vurder om språket er forståelig. Dette fanger de 60–70 prosentene automatikk aldri ser.
4. Dokumenter status ærlig.
   Er du i offentlig sektor, før faktisk status inn i tilgjengelighetserklæringen — inkludert avvikene du ikke har rettet ennå, med en realistisk frist.

Videre lesning

• UU-forskriften: krav, tilsyn og bøter for nettsteder — pillar-artikkelen om hva regelverket faktisk krever, og hva som skjer ved brudd.
• WCAG 2.1 AA-sjekklisten — alle 50 kravene med typiske feil, for den som vil rette selv.
• UUTilsynets veiledning om testverktøy — myndighetens egen vurdering av hva automatiske verktøy fanger, og hva som krever manuell testing.