Tilgjengelighet og inkluderende design – mønstre
Lær mer om godt utformet rettferdighet → Tilgjengelighet med Lightning og Experience Cloud
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Utformingsstandarder | ✅ WCAG 2.2 nivå AA er minimums tilgjengelighetslinjen for tilpasset bygd arbeid (Experience Cloud, LWC-er, tilpassede temaer), bekreftet av bygningsteamet |
| Plattform | Utformingsstandarder | ✅ Oppfattet-prinsipp: Tekstalternativer finnes for bilder og ikoner, tekstbegreper følger med videoer |
| Plattform | Utformingsstandarder | ✅ Operativ princip: All funksjonalitet kan opereres bare via tastaturet, uten å kreve mus eller berøring – talekontroll og hjelpeteknologier for bytte-tilgang er avhengig av den samme tastatur-/fokusmodellen |
| Plattform | LWC | ✅ Standard Lightning brukes slik de er utformet, og gir automatisk tilgjengelighet som standard |
| Plattform | LWC | ✅ Tilpassede komponenter implementerer eksplisitt tilgjengelighet validert via testing med skjermlesere |
| Plattform | Testplaner | ✅ Tilgjengelighetstesting er inkludert i alle testfaser (ikke ad hoc eller valgfritt) |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Utformingsstandarder | ⚡️ WCAG 2.2 nivå AA behandles som valgfritt eller “godt å ha” i stedet for minimumskrav |
| Plattform | Utformingsstandarder | ⚡️ Bilder og ikoner mangler tekstalternativer, videoer mangler tekster |
| Plattform | Utformingsstandarder | ⚡️ Funksjonalitet krever mus- eller berøringsinteraksjon uten alternativt tastatur |
| Plattform | LWC | ⚡️ Tilpassede komponenter bygges uten implementering eller validering av tilgjengelighet |
| Plattform | LWC | ⚡️ Tilpassede inndatakomponenter bruker div-elementer og CSS-stil uten semantisk betydning eller tastaturtilgjengelighet |
| Plattform | Testplaner | ⚡️ Tilgjengelighetstesting er ad hoc, valgfri eller utføres bare før oppstart (ikke under utvikling) |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | LWC | ✅ Semantiske HTML-elementer (overskrift, navigering, hoved, side, bunntekst, artikkel, del) brukes i tilpassede Lightning Web-komponenter |
| Plattform | LWC | ✅ ARIA-punkter, roller og egenskaper brukes der semantisk HTML alene ikke kan overføre grensesnittvirkemåte |
| Plattform | LWC | ✅ Dynamiske innholdsoppdateringer bruker aria-live-områder til å kunngjøre endringer til skjermleserbrukere |
| Plattform | LWC | ✅ Tilpassede interaktive komponenter har eksplisitte rolledefinisjoner som samsvarer med virkemåten deres |
| Plattform | LWC | ✅ Skjemaetiketter er eksplisitt knyttet til alle skjeminndata ved bruk av riktige etikettelementer eller aria-labelledby-attributter |
| Plattform | LWC | ✅ Lightning konfigureres med nødvendige etikettattributter som gir innebygd etikettilknytning |
| Plattform | Testplaner | ✅ Testing utføres med faktiske skjermlesere: JAWS og NVDA i Windows, VoiceOver i macOS og iOS, TalkBack i Android |
| Plattform | Testplaner | ✅ Manuell testing med ekte hjelpeteknologi utføres av personer som forstår hvordan skjermleserbrukere navigerer |
| Plattform | Utformingsstandarder | ✅ Plassholdertekst brukes aldri som eneste etikett fordi plassholdere forsvinner ved fokus og gir ikke tilstrekkelig kontekst for skjermlesere |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | LWC | ⚡️ Svært omfattende kodestrenger som betyr fra innholdshierarkiet tvinger skjermlesere til å navigere lineært |
| Plattform | LWC | ⚡️ ARIA brukes ikke der semantisk HTML alene ikke kan overføre grensesnittvirkemåte |
| Plattform | LWC | ⚡️ Dynamiske innholdsoppdateringer bruker ikke aria-direkte områder, skjermleserbrukere går glipp av viktige endringer |
| Plattform | LWC | ⚡️ Tilpassede interaktive komponenter mangler eksplisitte rolledefinisjoner. Skjermlesere kunngjør dem feil |
| Plattform | LWC | ⚡️ Skjemainndata mangler eksplisitt etikettilknytning, plassholdertekst brukes som eneste etikett |
| Plattform | Testplaner | ⚡️ Automatiske tilgjengelighetsverktøy brukes eksklusivt, manuell skjermlesertesting utføres ikke |
| Plattform | Testplaner | ⚡️ Testing utføres av synlige brukere som ikke er kjent med hvordan skjermleserbrukere faktisk navigerer |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Utformingsstandarder | ✅ Full funksjonalitet er tilgjengelig via tastaturet uten å kreve interaksjon med mus eller berøring på noe tidspunkt i brukerreiser |
| Plattform | LWC | ✅ Logisk fokusrekkefølge følger visuelt oppsett og flyt for interaksjon |
| Plattform | LWC | ✅ Når dynamisk innhold lastes inn eller modaler åpnes, administreres fokus programmatisk for å veilede tastaturbrukere til nytt innhold |
| Plattform | LWC | ✅ Modal- og popoverkomponenter flytter fokus til modal tittel eller første interaktivt element ved åpning, retur fokus til utløserknapp ved avslutning |
| Plattform | Utformingsstandarder | ✅ Synlige fokusindikatorer viser tydelig hvilket element som har tastaturfokus hele tiden |
| Plattform | Utformingsstandarder | ✅ Fokusindikatorer oppfyller 3:1-kontrastkravet mot omgivende innhold |
| Plattform | LWC | ✅ Brukere kan navigere inn og ut av alle komponenter med tastaturet alene uten å bli fanget |
| Plattform | LWC | ✅ Modale dialogbokser fanger fokus i modalen mens de er åpne (hindre tilgang til skjult innhold), men frigjør fokus ved avslutning |
| Plattform | Utformingsstandarder | ✅ Tastatursnarveier for hyppige handlinger unngår konflikter med skjermleser-snarveier og nettlesersnarveier |
| Plattform | Utformingsstandarder | ✅ Snarveier med én bokstav aktiveres bare når bestemte komponenter har fokus (ikke globalt) for å unngå konflikter med skjermlesernavigeringskommandoer |
| Plattform | Dokumentasjon | ✅ Alle tilpassede tastatursnarveier dokumenteres i tilgjengelig hjelpeinnhold |
| Plattform | Testplaner | ✅ Testtrinn inkluderer bare tastaturnavigering gjennom alle brukerreiser uten å bruke mus eller berøring |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Utformingsstandarder | Funksjonalitet krever mus- eller berøringsinteraksjon. Brukere som bare bruker tastaturet, kan ikke utføre viktige oppgaver |
| Plattform | LWC | ⚡️ Fokusrekkefølge følger ikke logisk visuelt oppsett. Brukere faner gjennom elementer i uventet rekkefølge |
| Plattform | LWC | ⚡️ Modaler åpnes uten fokusbehandling. Tastaturbrukere er stående på nå skjult utløserknapp |
| Plattform | LWC | ⚡️ Modal lukking returnerer ikke fokus til utløserknapp, brukere må lete etter plass på siden |
| Plattform | Utformingsstandarder | ⚡️ Fokusindikatorer undertrykkes av estetiske årsaker. Brukere kan ikke se hvilket element som har fokus |
| Plattform | Utformingsstandarder | ⚡️ Fokusindikatorer har ikke tilstrekkelig kontrast (<3:1) |
| Plattform | LWC | ⚡️ Brukere blir fanget i grensesnittområder uten escape-mekanisme (tastaturfeller) |
| Plattform | LWC | ⚡️ Innebygd innhold (iframer, tredjeparts widgeter) fanger opp tastaturfokus permanent |
| Plattform | Utformingsstandarder | ⚡️ Snarveier med én bokstav aktiverer globalt konflikt med navigeringskommandoer med én bokstav i skjermleseren |
| Plattform | Dokumentasjon | ⚡️ Tilpassede tastatursnarveier er udokumenterte, brukere kan ikke oppdage dem |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | Utformingsstandarder | ✅ Minimum kontrastforhold 4,5:1 for normal tekst under 18pt eller 14pt fet skrift |
| Plattform | Utformingsstandarder | ✅ Minimum 3:1-kontrastforhold for stor tekst og for meningsfylte brukergrensesnittkomponenter og grafikk (formkantlinjer, informasjonsikoner); rent dekorative og deaktiverte elementer er unntatt |
| Plattform | Experience Cloud | ✅ Tilpassede temaer og merkeprofilerte Experience Cloud-nettsteder inkluderer eksplisitt kontrastvalidering ved bruk av nettleserutviklingsverktøy eller automatiske sjekkere |
| Plattform | Utformingsstandarder | ✅ Endring av tekststørrelse til 200 % støttes uten tap av innhold eller funksjonalitet (WCAG-krav) |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | Utformingsstandarder | ⚡️ Tekstkontrastforhold faller under 4,5:1 (normal tekst) eller 3:1 (komponenter med stor tekst og grensesnitt) |
| Plattform | Experience Cloud | ⚡️ Tilpassede temaer distribueres uten kontrastvalidering, brukere med lav syn kan ikke lese innhold |
| Plattform | Utformingsstandarder | ⚡️ Endring av tekststørrelse over 200 % bryter oppsett og mister innhold eller funksjonalitet |
Mønstre
| Hvor du kan se | Hvordan det ser bra ut |
|---|---|
| Plattform | CI/CD | ✅ Aksekjerne- eller Lighthouse-tilgjengelighetsskanning er integrert i CI/CD pipelines og fanger opp strukturelle problemer ved hver distribusjon |
| Plattform | CI/CD | ✅ Bygger mislykkes når kritiske tilgjengelighetsproblemer oppdages |
| Plattform | Testplaner | ✅ Manuell testing med skjermlesere, navigering bare for tastatur og zoom til 200 % i nettleseren utføres regelmessig gjennom hele utviklingen |
| Plattform | Testplaner | ✅ Testing avdekker interaksjonsproblemer, inkludert forvirrende kunngjøringsrekkefølge, feil i fokusbehandling og tastaturfeller |
| Plattform | Virksomhet | ✅ Brukere med funksjonshemming inkluderes i brukertesting gjennom hele utformingsprosessen |
| Plattform | Virksomhet | ✅ Brukertesting avdekker praktiske barrierer som automatisert og manuell eksperttesting mangler |
| Plattform | Testplaner | ✅ Automatisert testing (~57 % av problemene etter volum), manuell testing (interaksjonsproblemer) og brukertesting (sannhetsbarrierer) utføres alle |
Anti-Mønstre
| Hvor du kan se | Hvordan dårlig ser ut |
|---|---|
| Plattform | CI/CD | ⚡️ Tilgjengelighetsskanning er ikke integrert i CI/CD pipelines |
| Plattform | CI/CD | ⚡️ Byggingen fortsetter til tross for kritiske tilgjengelighetsproblemer |
| Plattform | Testplaner | ⚡️ Manuell testing med hjelpeteknologi utføres ikke, bare automatisk skanning brukes |
| Plattform | Virksomhet | ⚡️ Brukere med funksjonshemming inkluderes ikke i brukertesting |
| Plattform | Testplaner | ⚡️ Automatisk tilgjengelighetsskanner kjøres én gang før oppstart, og tilgjengelighetstesting anses som utført |