Brugbarhed og kvalitet

Webtilgængelighed: kan appen bruges uden mus og ved 400 % zoom?

En app kan være teknisk online og stadig være utilgængelig for den medarbejder, som kun bruger tastatur, den kunde, som forstørrer teksten, eller den bruger, som får felterne læst op. Tilgængelighed skal derfor afprøves i de rigtige arbejdsforløb – ikke kun måles som en automatisk score.

Vælg de forløb, der ikke må låse en bruger ude

Begynd med et lille risikokort. En farvefejl i en sjældent brugt indstillingsside og en utilgængelig login- eller godkendelsesknap har ikke samme konsekvens. Udvælg de forløb, som afgør, om en person kan udføre sit arbejde eller gennemføre en aftale.

Forløb	Typisk barriere	Konsekvens
Login og kontogendannelse	Felt uden label eller fokus, som forsvinder	Brugeren kommer slet ikke ind
Opret sag, booking eller ordre	Fejl vises kun med farve eller uden forklaring	Opgaven kan ikke afsluttes sikkert
Dialog til sletning eller godkendelse	Tastaturfokus bliver bag dialogen	Brugeren aktiverer noget andet end forventet
Tabel eller arbejdsoversigt	Indhold kræver vandret og lodret scroll ved zoom	Sammenhæng og handlinger går tabt

Brug almindelig HTML før specialbyggede kontroller

Et rigtigt <button>-element har allerede navn, rolle, fokus og forventet tastaturadfærd i browseren. En klikbar <div> får ikke de egenskaber, bare fordi den ligner en knap. ARIA kan beskrive en specialbygget kontrol, men giver ikke i sig selv den nødvendige tastaturadfærd.

Knapper udfører handlinger. Links fører til en anden side eller placering. Brug elementet efter formålet.
Overskrifter beskriver strukturen. Brug én H1 og en logisk rækkefølge af H2 og H3 frem for at style tilfældig tekst som overskrift.
Formularfelter har et vedvarende navn. Knyt synlige labels til felterne; en placeholder forsvinder, når brugeren skriver.
Ikoner har et forståeligt navn. En ikonknap skal kunne annonceres som eksempelvis “Luk dialog” – ikke som filnavn eller “knap”.
Dekorative billeder er tavse. Brug tom alt-tekst til ren dekoration, og beskriv den relevante information i informative billeder.

Gå hele forløbet med tastaturet

Læg musen væk. Brug Tab og Shift+Tab til at flytte fokus og Enter eller mellemrum til at aktivere de kontroller, hvor det forventes. Fokus skal bevæge sig i en meningsfuld rækkefølge og hele tiden kunne ses.

Start øverst. Kontrollér at navigation, felter, knapper, links og andre handlinger kan nås uden mus.
Se fokus. Fjern ikke browserens outline uden at erstatte den med en tydelig fokusmarkering.
Åbn lag og menuer. Fokus skal flyttes ind i en modal dialog, blive i den relevante kontekst og returnere til en fornuftig placering, når dialogen lukkes.
Luk igen. Brugeren må ikke ende i en tastaturfælde. Kendte mønstre skal kunne lukkes på den forventede måde.
Prøv efter en fejl. Fokus og beskeder skal hjælpe brugeren frem til det felt eller valg, der kræver handling.

En synlig fokusramme er ikke pynt. Uden den kan en seende tastaturbruger ikke vide, hvilken knap eller hvilket felt der bliver aktiveret.

Gør formularfejl konkrete og mulige at rette

“Der er en fejl” hjælper ikke. Fortæl hvilket felt der har problemet, hvad der mangler, og hvordan det kan rettes. Bevar de værdier, som allerede er gyldige, så brugeren ikke skal begynde forfra.

Synlig besked ved feltet: Forbind teksten teknisk med feltet og markér ikke fejlen alene med rød farve.
Samlet fejloversigt: Ved flere fejl kan en kort oversigt med links føre brugeren til de berørte felter.
Tydelig succes: Bekræft at sagen, bookingen eller ændringen faktisk er gemt.
Dynamiske ændringer annonceres: Status, fejl og resultater, der vises uden sideskift, skal også kunne opdages med hjælpemidler.

Afprøv zoom, tekst og smalle visninger

WCAG's reflow-kriterium bruger 320 CSS-pixels som reference for indhold med lodret læseretning; det svarer også til en 1280-pixels visning ved 400 % zoom. Indhold og funktioner skal som udgangspunkt kunne bevares uden, at brugeren skal scrolle i to retninger. Tabeller, kort og andre elementer, der reelt kræver todimensionelt layout, kan have en afgrænset vandret scroll.

Forstør til 200 og 400 %. Kontrollér at knapper, fejlbeskeder og vigtig tekst ikke bliver klippet eller dækket.
Test ved 320 pixels. Brug en rigtig browserbredde; et pænt desktoplayout beviser ikke reflow.
Brug ikke farve alene. Status som godkendt, forsinket eller afvist skal også have tekst, ikon eller anden tydelig forskel.
Mål tekstkontrast. WCAG 2.2 AA kræver normalt mindst 4,5:1 for almindelig tekst og 3:1 for stor tekst, med de undtagelser standarden beskriver.
Tillad brugerens zoom. Deaktivér ikke browserens forstørrelse i viewport-konfigurationen.

Kombinér automatiske kontroller med menneskelig test

Automatiske værktøjer kan finde eksempelvis manglende labels, visse kontrastfejl og ugyldige ARIA-relationer. W3C understreger samtidig, at værktøjer ikke kan afgøre hele tilgængeligheden; der kræves menneskelig vurdering.

Automatisk i udvikling og CI

Kør en tilgængelighedskontrol på de kritiske sider og komponenter. Lad nye alvorlige fund stoppe en udgivelse, men behandl ikke en høj score som en godkendelse.

Manuelt i den rigtige browser

Gennemfør forløbene med tastatur, zoom og mindst én relevant skærmlæserkombination. Brug realistiske fejl, lange tekster, tomme tilstande og indhold efter login.

Når appen skal bruges bredt eller indgår i en tjeneste med konkrete lov- eller kontraktkrav, bør den tekniske test suppleres med en faglig vurdering af det relevante kravgrundlag. Denne guide er en praktisk kvalitetskontrol, ikke en juridisk certificering.

Typiske fejl i AI-byggede brugerflader

Alt er bygget som div-elementer: Knapper, faner og menuer ser rigtige ud, men mangler browserens indbyggede adfærd.
Outline er fjernet globalt: Designet er roligt med mus, men tastaturbrugeren mister sin position.
Placeholder bruges som label: Feltets betydning forsvinder under indtastning og annonceres ikke stabilt.
Fejl vises kun med rød kant: Brugeren får hverken et tekstligt problem eller en rettelse.
En modal lægges kun visuelt øverst: Fokus fortsætter bag laget, og skærmlæseren mangler kontekst.
Desktop er eneste test: Zoom, lange labels og smalle visninger skubber handlinger ud af skærmen.
Automatisk score er eneste bevis: Ingen gennemfører den faktiske opgave uden mus eller med hjælpemiddel.

Tjekliste før medarbejdere eller kunder får adgang

☐ Kritiske brugerforløb og konsekvensen ved en barriere er kortlagt.
☐ Knapper, links, formularfelter, tabeller og overskrifter bruger semantisk HTML.
☐ Alle relevante kontroller kan nås og betjenes med tastatur.
☐ Fokus er synligt, følger en meningsfuld rækkefølge og håndteres korrekt i dialoger.
☐ Formularfelter har synlige labels, forståelige instruktioner og konkrete fejlbeskeder.
☐ Dynamiske fejl, succeser og statusændringer kan opdages med hjælpemidler.
☐ Farve er ikke den eneste måde at vise status eller fejl på.
☐ Tekst og vigtige brugerfladekomponenter har passende kontrast.
☐ Forløbene virker ved 320 pixels samt 200 og 400 % zoom uden tab af vigtig funktion.
☐ Informative billeder har meningsfuld alt-tekst; dekorative billeder har tom alt-tekst.
☐ Automatiske fund er håndteret, og de vigtigste forløb er testet manuelt.
☐ Tilgængelighed indgår i definitionen af færdig og kontrolleres igen efter ændringer.

Relaterede guides

Teststrategi til kritiske brugerrejser XSS og sikker rendering af indhold i browseren PWA til installation, offlineadfærd og opdateringer Driftsdokumentation og kendte begrænsninger Se hele guidebiblioteket

Officielle kilder

WCAG er teknologiuafhængig, mens den konkrete løsning afhænger af appens komponenter, browserstøtte og brugergrupper. Brug standarden og WAI's mønstre som grundlag, og afprøv derefter de faktiske forløb i appen.

Virker appen, men er brugerfladen ikke afprøvet bredt?

Startklar er til virksomheder med en fungerende AI-bygget app, som skal kunne bruges trygt af medarbejdere eller kunder. Her kan de kritiske brugerforløb, komponenter, tests og driftskrav blive gennemgået i den stack, appen faktisk bruger.

Se Startklar-forløbet