En kunde har fundet den rigtige vare, lagt den i kurven og er klar til at betale. Men fokus forsvinder, når kunden bruger tastaturet. Eller rabatkoden kan ikke læses op af en skærmlæser. Eller farven på en knap er den eneste forklaring på, hvorfor et felt fejler. Det er her, spørgsmålet om, hvad kræver en tilgængelig webshop, bliver konkret: Kunden skal kunne gennemføre et køb uden unødige tekniske barrierer.
Tilgængelighed er ikke et ekstra designlag, der lægges på lige før lancering. Det er et kvalitetskrav til hele købsrejsen, fra første produktliste til ordrebekræftelsen. For e-handelsvirksomheder handler det både om at leve op til relevante krav, mindske forretningsrisikoen og gøre det lettere for flere kunder at handle.
Hvad kræver en tilgængelig webshop?
En tilgængelig webshop skal kunne opfattes, betjenes, forstås og fungere med forskellige hjælpemidler. Det er de fire grundprincipper bag WCAG, som er den internationale standard for webtilgængelighed. I praksis betyder det blandt andet, at indholdet skal virke med tastatur og skærmlæser, at tekst skal være læsbar, og at fejl i formularer skal kunne forstås og rettes.
For mange virksomheder er kravene også reguleringsrelevante. Den europæiske tilgængelighedslov, European Accessibility Act, har fra juni 2025 skærpet kravene til en række digitale produkter og tjenester, herunder e-handel. Den konkrete vurdering afhænger af virksomhedens rolle, størrelse og løsningens karakter. Mikrovirksomheder, der leverer tjenester, kan under bestemte betingelser være undtaget, men det fjerner ikke værdien af at bygge tilgængeligt fra starten.
Det tekniske pejlemærke vil typisk være WCAG 2.1 på AA-niveau, ofte sammenholdt med den europæiske standard EN 301 549. Juridisk compliance bør altid vurderes i den konkrete kontekst. Teknisk set er det afgørende at gøre kravene til målbare acceptkriterier, ikke til en vag ambition om et mere inkluderende website.
Start med den fulde købsrejse
En forside kan se tilgængelig ud, selv om webshoppen fejler i det øjeblik, kunden vælger variant, opretter en konto eller betaler. Derfor skal test og udvikling tage udgangspunkt i de kritiske brugerflows.
Produktkort skal have meningsfulde navne, priser og lagerstatus, der kan forstås uden kun at aflæse layoutet. Produktfiltre skal fortælle, hvilke valg der er aktive, og de skal kunne styres med tastatur. På produktsiden skal billeder have relevante tekstalternativer, når billedet formidler information. Et rent dekorativt billede behøver derimod ikke en beskrivelse.
Kurv og checkout er ofte de mest risikofyldte områder. Her skal kunden kunne ændre antal, fjerne varer, vælge levering og indtaste oplysninger uden at miste fokus eller kontekst. Fejlmeddelelser skal stå tæt på det berørte felt, forklare hvad der er galt og angive, hvordan fejlen løses. Rød kant alene er ikke nok. En formulering som “Indtast et postnummer med fire cifre” er langt mere anvendelig end “Ugyldig værdi”.
Betalingsvinduer, fragtmoduler, cookie-løsninger og produktanmeldelser fortjener særlig opmærksomhed. De leveres ofte af tredjeparter, men kunden oplever dem som en del af webshoppen. Ansvaret for en brugbar købsrejse kan ikke placeres hos kunden, fordi en integration kommer fra en ekstern leverandør.
Byg med semantik før visuelle effekter
Mange tilgængelighedsproblemer opstår, når et design oversættes til generiske HTML-elementer og JavaScript i stedet for at bruge browserens indbyggede funktioner. En knap skal som udgangspunkt være en rigtig knap. En overskrift skal være en overskrift. Et inputfelt skal have en synlig eller programmatisk tilknyttet label.
Semantisk HTML giver skærmlæsere, tastaturbrugere og andre hjælpemidler den struktur, de skal bruge for at navigere. Det gør også løsningen mere vedligeholdbar. Når en udvikler senere ændrer designet, er funktion og mening allerede forankret i koden.
Der er især fem tekniske områder, der bør være faste krav i udviklingen:
- Tastaturnavigation skal følge en logisk rækkefølge, og fokus skal altid være tydeligt på skærmen.
- Dialogbokse, menuer og akkordeoner skal annoncere korrekt til hjælpemidler og kunne lukkes uden mus.
- Kontrast mellem tekst, ikoner og baggrund skal være tilstrækkelig, også for knapper i forskellige tilstande.
- Indhold må ikke gå tabt, når brugeren zoomer, bruger mobilvisning eller ændrer tekststørrelse.
- Dynamiske ændringer, som opdateret antal varer i kurven, skal kommunikeres på en måde, som skærmlæsere kan opfange.
Det er fristende at løse problemer med ARIA-attributter. ARIA kan være nødvendigt i avancerede komponenter, men det er ikke en genvej uden om korrekt HTML. Forkert ARIA gør ofte en ellers enkel brugerflade vanskeligere at anvende.
Tilgængeligt indhold er et redaktionelt ansvar
Udviklerne kan bygge et godt fundament, men redaktører og marketingteams afgør, om webshoppen forbliver tilgængelig efter lancering. Et CMS skal derfor gøre det let at vælge ordentlige overskriftsniveauer, skrive billedtekster og alternativ tekst samt undgå at indsætte uforståelige links som “klik her”.
Produktbeskrivelser bør være konkrete. Hvis størrelse, materiale eller kompatibilitet kun fremgår af et billede eller en visuel tabel, mister nogle kunder vigtig information. Videoer bør som minimum have tekstning, når de indeholder tale, og væsentligt visuelt indhold kan kræve en tekstlig forklaring.
Sproget i sig selv er også en del af tilgængeligheden. Korte instruktioner, tydelige feltnavne og ensartede begreber reducerer fejl for alle brugere. Det gælder særligt ved abonnementer, returvilkår, leveringsvalg og samtykker, hvor uklare formuleringer hurtigt bliver både en kundeoplevelses- og complianceudfordring.
Test med mennesker og værktøjer
Automatiske testværktøjer er nyttige, fordi de kan finde fejl som manglende labels, tomme links og utilstrækkelig kontrast. De finder dog ikke alt. Et værktøj kan eksempelvis se, at en knap har et navn, uden at vurdere om navnet faktisk giver mening for kunden.
En solid testproces kombinerer automatiske scanninger med manuel gennemgang. Test mindst de centrale flows med tastatur alene, med zoom og på mobil. Gennemgå siden med en skærmlæser, og vær særligt opmærksom på formularer, fejl, modaler og opdateringer i kurv og checkout. Når det er muligt, bør faktiske brugere med forskellige forudsætninger inddrages. Det giver indsigt, som en teknisk kontrol ikke kan erstatte.
Testen bør ske før go-live, men også efter større releases, nye temaændringer og installation af plugins. I en WooCommerce-løsning kan en opdatering af et betalingsmodul eller et nyt kampagneelement ændre et centralt flow på få minutter. Tilgængelighed skal derfor indgå i releaseprocessen på samme måde som sikkerhed, performance og GDPR-kontrol.
Gør kravene til en del af indkøb og drift
Tilgængelighed fejler ofte i overleveringen mellem design, udvikling, redaktion og drift. Den bedste modvægt er klare krav tidligt i projektet. Beskriv, hvilke kunderejser der skal fungere, hvilket WCAG-niveau der sigtes efter, og hvordan leverandører dokumenterer deres leverance.
For standardkomponenter og tredjepartsintegrationer bør der være en realistisk vurdering af alternativerne. En funktion, der er utilgængelig, men forretningskritisk, kræver enten en plan for tilpasning, en anden leverandør eller en tilgængelig vej uden om funktionen. Det kan koste mere i projektfasen, men er normalt billigere end en akut ombygning efter lancering.
Driftsmodellen betyder også noget. En webshop med løbende sikkerhedsopdateringer, tydeligt ejerskab til kode og integrationer samt mulighed for at flytte løsningen står stærkere, når krav ændrer sig. Open source og en platform uden unødigt vendor lock-in giver ikke automatisk tilgængelighed, men det gør det lettere at rette fejl og fastholde kontrollen over den tekniske gæld.
En tilgængelig webshop bliver ikke færdig, fordi den har bestået én test. Den bliver bedre, når virksomheden løbende spørger, om en kunde kan finde, forstå og købe varen på sine egne præmisser. Det er et enkelt spørgsmål, men det stiller de rigtige krav til både teknologi, indhold og drift.
