Tilgængelighed og inkluderende design - mønstre
Få mere at vide om veludviklet fairness → Tilgængelighed med Lightning og Experience Cloud
Mønstre
| Hvor skal du se | Hvordan godt ser ud |
|---|---|
| Platform | Designstandarder | ✅ WCAG 2.2 niveau AA er den mindste tilgængelighedslinje for tilpasset arbejde (Experience Cloud, LWC’er, tilpassede temaer), der er bekræftet af bygningsteamet |
| Platform | Designstandarder | ✅ Fornemmelsesprincippet: Der findes tekstalternativer for billeder og ikoner. Teksttekster ledsager videoer |
| Platform | Designstandarder | ✅ Handlingsom princip: Al funktionalitet kan handles via tastatur alene, uden at det kræver mus eller touch – voice-control og støttende teknologier til skiftadgang er afhængige af den samme tastatur-/fokusmodel |
| Platform | LWC | ✅ Standard Lightning Web-komponenter bruges som designet, hvilket giver automatisk basistilgængelighed |
| Platform | LWC | ✅ Tilpassede komponenter implementerer eksplicit tilgængelighed valideret gennem test med skærmlæsere |
| Platform | Testplaner | ✅ Tilgængelighedstest er inkluderet i alle testfaser (ikke ad hoc eller valgfrit) |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Platform | Designstandarder | ⚡️ WCAG 2.2 niveau AA behandles som valgfrit eller “rart at have” snarere end minimumkrav |
| Platform | Designstandarder | ⚡️ Billeder og ikoner mangler tekstalternativer, videoer mangler tekster |
| Platform | Designstandarder | ⚡️ Funktionalitet kræver mus- eller touch-interaktion uden tastaturalternativ |
| Platform | LWC | ⚡️ Tilpassede komponenter opbygges uden tilgængelighedsimplementering eller validering |
| Platform | LWC | ⚡️ Tilpassede inputkomponenter bruger div-elementer og CSS-typografi uden nogen semantisk betydning eller tastaturtilgængelighed |
| Platform | Testplaner | ⚡️ Tilgængelighedstest er ad hoc, valgfrit eller udføres kun før start (ikke gennem udvikling) |
Mønstre
| Hvor skal du se | Hvordan godt ser ud |
|---|---|
| Platform | LWC | ✅ Semantiske HTML-elementer (sidehoved, navigation, hoved, side, sidefod, artikel, afsnit) bruges i tilpassede Lightning Web-komponenter |
| Platform | LWC | ✅ ARIA-mærker, roller og egenskaber anvendes, hvor semantisk HTML alene ikke kan formidle grænsefladeadfærd |
| Platform | LWC | ✅ Dynamiske indholdsopdateringer bruger aria-live-områder til at bekendtgøre ændringer til skærmlæserbrugere |
| Platform | LWC | ✅ Tilpassede interaktive komponenter har eksplicitte rolledefinitioner, der matcher deres adfærd |
| Platform | LWC | ✅ Formularbetegnelser er eksplicit tilknyttet alle formularinput ved brug af korrekte betegnelseselementer eller aria-labelledby-attributter |
| Platform | LWC | ✅ Lightning konfigureres med krævede betegnelsesattributter, der giver indbygget betegnelsestilknytning |
| Platform | Testplaner | ✅ Test udføres med faktiske skærmlæsere: JAWS og NVDA på Windows, VoiceOver på macOS og iOS, TalkBack på Android |
| Platform | Testplaner | ✅ Manuel test med virkelig støttende teknologi udføres af personer, der forstår, hvordan skærmlæserbrugere navigerer |
| Platform | Designstandarder | ✅ Pladsholdertekst bruges aldrig som den eneste betegnelse, da pladsholdere forsvinder ved fokus og giver utilstrækkelig kontekst for skærmlæsere |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Platform | LWC | ⚡️ Div-heavy-markeringsstreger betyder, at indholdshierarki tvinger skærmlæsere til at navigere lineært |
| Platform | LWC | ⚡️ ARIA bruges ikke, hvor semantisk HTML alene ikke kan formidle grænsefladeadfærd |
| Platform | LWC | ⚡️ Dynamiske indholdsopdateringer bruger ikke aria-live-områder. Skærmlæserbrugere går glip af vigtige ændringer |
| Platform | LWC | Tilpassede interaktive komponenter mangler eksplicitte rolledefinitioner. Skærmlæsere annoncerer dem forkert |
| Platform | LWC | Formularinputs mangler eksplicit betegnelsestilknytning. Pladsholdertekst bruges som eneste betegnelse |
| Platform | Testplaner | ⚡️ Automatiserede tilgængelighedsværktøjer bruges udelukkende. Manuel skærmlæsertest udføres ikke |
| Platform | Testplaner | ⚡️ Test udføres af synlige brugere, der ikke er bekendt med, hvordan skærmlæserbrugere faktisk navigerer |
Mønstre
| Hvor skal du se | Hvordan godt ser ud |
|---|---|
| Platform | Designstandarder | ✅ Komplet funktionalitet er tilgængelig via tastatur uden at kræve mus- eller touchinteraktion på noget tidspunkt i brugerrejser |
| Platform | LWC | ✅ Logisk fokusrækkefølge følger visuelt layout og interaktionsforløb |
| Platform | LWC | ✅ Når dynamisk indhold indlæses eller modaler åbnes, administreres fokus programmeringsmæssigt for at guide tastaturbrugere til nyt indhold |
| Platform | LWC | ✅ Modaldialogboks- og pop over-komponenter flytter fokus til modaldialogboks-titel eller første interaktivt element ved åbning. Returner fokus til udløserknap ved lukning |
| Platform | Designstandarder | ✅ Synlige fokusindikatorer viser tydeligt, hvilket element der har tastaturfokus på alle tidspunkter |
| Platform | Designstandarder | ✅ Fokusindikatorer opfylder 3:1-kontrastkravet mod omgivende indhold |
| Platform | LWC | ✅ Brugere kan navigere ind og ud af alle komponenter ved brug af tastatur alene uden at blive fanget |
| Platform | LWC | ✅ Modaldialogbokse fanger fokus i modaldialogboksen, mens de er åbne (forhindrer adgang til skjult indhold), men frigivelse fokuserer på lukning |
| Platform | Designstandarder | ✅ Tastaturgenveje for hyppige handlinger undgår konflikter med skærmlæsergenveje og browsergenveje |
| Platform | Designstandarder | ✅ Genveje med et enkelt bogstav aktiveres kun, når specifikke komponenter har fokus (ikke globalt) for at undgå konflikter med skærmlæsernavigationskommandoer |
| Platform | Dokumentation | ✅ Alle tilpassede tastaturgenveje dokumenteres i tilgængeligt hjælpeindhold |
| Platform | Testplaner | ✅ Testtrin inkluderer kun tastaturnavigation gennem alle brugerrejser uden brug af mus eller touch |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Platform | Designstandarder | ⚡️ Funktionalitet kræver mus- eller touch-interaktion. Kun tastaturbrugere kan ikke fuldføre nøgleopgaver |
| Platform | LWC | ⚡️ Fokusrækkefølgen følger ikke det logiske visuelle layout. Brugere tabulerer gennem elementer i uventet rækkefølge |
| Platform | LWC | ⚡️ Modaler åbnes uden fokusstyring. Tastaturbrugere er fanget på knappen Udløser, der nu er skjult |
| Platform | LWC | ⚡️ Modaldialogboks lukning returnerer ikke fokus til udløserknappen. Brugere skal søge efter deres plads på siden |
| Platform | Designstandarder | ⚡️ Fokusindikatorer undertrykkes af æstetiske årsager. Brugere kan ikke se, hvilket element der har fokus |
| Platform | Designstandarder | ⚡️ Fokusindikatorer har utilstrækkelig kontrast (<3:1) |
| Platform | LWC | ⚡️ Brugere bliver fanget i grænsefladeområder uden escape-mekanisme (tastaturfælder) |
| Platform | LWC | Integreret indhold (iframes, tredjepartswidgets) registrerer tastaturfokus permanent |
| Platform | Designstandarder | ⚡️ Genveje med et enkelt bogstav aktiverer globalt konflikt med navigationskommandoer med et enkelt bogstav i skærmlæseren |
| Platform | Dokumentation | ⚡️ Tilpassede tastaturgenveje er ikke-dokumenterede. Brugere kan ikke finde dem |
Mønstre
| Hvor skal du se | Hvordan godt ser ud |
|---|---|
| Platform | Designstandarder | ✅ Mindste kontrastforhold på 4,5:1 for normal tekst under 18pt eller 14pt fed |
| Platform | Designstandarder | ✅ Minimum 3:1-kontrastforhold for stor tekst og for meningsfulde brugergrænsefladekomponenter og grafik (formskærme, informative ikoner). Kun dekorative og inaktiverede elementer er undtaget |
| Platform | Experience Cloud | ✅ Tilpassede temaer og brandede Experience Cloud-lokaliteter inkluderer eksplicit kontrastvalidering ved brug af browserudviklingsværktøjer eller automatiserede kontrolelementer |
| Platform | Designstandarder | ✅ Tekststørrelse til 200 % understøttes uden tab af indhold eller funktionalitet (WCAG-krav) |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Platform | Designstandarder | ⚡️ Tekstkontrastforhold falder under 4,5:1 (normalt tekst) eller 3:1 (komponenter med stor tekst og brugergrænseflade) |
| Platform | Experience Cloud | ⚡️ Tilpassede temaer implementeres uden kontrastvalidering. Lavsynede brugere kan ikke læse indhold |
| Platform | Designstandarder | Redigering af tekststørrelse ud over 200 % afbryder layouts, der mister indhold eller funktionalitet |
Mønstre
| Hvor skal du se | Hvordan godt ser ud |
|---|---|
| Platform | CI/CD | ✅ Axe-core- eller Lighthouse-tilgængelighedsscanning er integreret i CI/CD-pipelines, der fanger strukturelle problemer på hver implementering |
| Platform | CI/CD | ✅ Opbygninger mislykkes, når der registreres problemer med kritisk tilgængelighed |
| Platform | Testplaner | ✅ Manuel test med skærmlæsere, kun tastaturnavigation og browserzoom til 200 % udføres regelmæssigt gennem hele udviklingen |
| Platform | Testplaner | ✅ Test afslører interaktionsproblemer, herunder forvirrende bekendtgørelsesrækkefølge, fejl i fokusstyring og tastaturfælder |
| Platform | Forretning | ✅ Brugere med handicap inkluderes i anvendelighedstest gennem designprocessen |
| Platform | Forretning | ✅ Anvendelsestest afslører praktiske hindringer, som automatiseret og manuel eksperttest mangler |
| Platform | Testplaner | ✅ Automatiseret test (~57 % af problemer efter mængde), manuel test (interaktionsproblemer) og brugertest (barrierer i den virkelige verden) udføres alle |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Platform | CI/CD | ⚡️ Tilgængelighedsscanning er ikke integreret i CI/CD-pipelines |
| Platform | CI/CD | ⚡️ Opbygninger fortsætter på trods af kritiske tilgængelighedsproblemer |
| Platform | Testplaner | ⚡️ Manuel test med støttende teknologi udføres ikke. Der bruges kun automatiseret scanning |
| Platform | Forretning | ⚡️ Brugere med handicap er ikke inkluderet i anvendelighedstest |
| Platform | Testplaner | ⚡️ Automatiseret tilgængelighedsscanner køres en gang før start, og tilgængelighedstest betragtes som udført |