8 trin til inkluderende webdesign

Tilgængelighed er en menneskeret, og i nogle lande er loven. Faktisk oplevede 2018 en enorm stigning i retssager om webtilgængelighed. Nu begynder designere at indse, at webtilgængelighed er et must. Med det i tankerne er her otte bedste tips til at sikre, at dit webdesign er optimeret til tilgængelighed og så inkluderende som muligt.

Hvis du beslutter dig for at revidere de tilgængelige elementer på dit websted og indser, at dit webdesign trænger til en total opfriskning, her er de hotteste webdesign værktøjer og ressourcer, du kan bruge til at hjælpe. Starter du en hjemmeside fra bunden? Prøv en hjemmesidebygger, og sørg for at udforske alle dine webhosting muligheder.

01. Definer tilgængelighed

Tilgængelighed og inkluderende design refereres nogle gange i flæng, men det kan have drastiske konsekvenser at undlade at genkende skelnen mellem dem. Tilgængelighedsdesign handler om at fjerne forhindringer, så alle brugere kan bruge de apps og hjemmesider, vi designer.

Lad os derefter huske, at større skriftstørrelser reducerer "kan ikke læse teksten"-hindringen, så enten giver vi visse brugere mulighed for at skifte til en alternativ 'tilgængelighedstilstand', eller vi opretter en tilgængelig, men separat version, som kan tilgås ved hjælp af et link i navigationen. Nu slører dette ikke kun grænsen mellem tilgængelig og utilgængelig (da synshandicappede brugere stadig nødt til at finde dette 'tilgængelighedssted'), men det er slet ikke inkluderende, fordi vi har fremmedgjort disse brugere. De er blevet adskilt, fået det til at føles anderledes, og for at toppe det, har vi været nødt til at designe og udvikle to versioner af vores grænseflade, hvilket har brugt ekstra tid og kræfter.

I stedet kunne vi simpelthen have designet en enestående, mere inkluderende grænseflade, hvor skrifttypen er større for alle. Når alt kommer til alt, vil selv brugere, der ikke er synshandicappede, have gavn af at kunne læse tekst lettere, og det er derfor, at inkluderende design er en gevinst for både handicappede og ikke-handicappede brugere. Inklusivt design formindsker ikke oplevelsen for dem, der ikke er handicappede. Faktisk er langt de fleste tilgængelighedsregler som defineret af WCAG – Retningslinjer for tilgængelighed til webindhold, dobbelt op som brugervenlighedstip, som alle brugere vil drage fordel af, hvis de implementeres.

02. Forenkle sproget

Når det kommer til det skrevne ord, er der et stort udvalg af overvejelser, der skal tages i betragtning, hvis vi vil designe oplevelser, der henvender sig til alle. Der er selve ordenes enkelhed (som kan påvirke dem med læsevanskeligheder), der er typografien (som kan påvirke synshandicappede brugere), og der er konsistensen (som kan påvirke dem, der er kognitivt handicappet). Og selvfølgelig påvirker suboptimalt design dem, der ikke er handicappede, lige så meget som dem, der er.

Sådan forbedrer du typografi og dermed læsbarhed:

• Juster kun tekst til venstre eller højre
• Understreg links for ekstra visuel kontrast
• Håndhæv linjeafstand på (mindst) 1,5x skriftstørrelsen 
• Afsnitsafstand: mindst 1,5x linjeafstanden
• Afsnitsbredde: ikke mere end 80 tegn

Sådan reducerer du kognitiv belastning:

• Brug et simpelt sprog 
• Definer forkortelser ved første brug
• Sørg for, at linkteksten beskrives effektivt 
• Match identiske URL'er med identisk linktekst 
• Strukturer indhold logisk ved hjælp af klart formulerede overskrifter

03. Optimer farvekontrasten

Farvekontrast er et mål for, hvor godt farverne i to designelementer adskiller sig fra hinanden. Enheden for denne måling er et forhold, og der er et minimumsforhold at sigte efter. Forudsat at forskellige designelementer opfylder det minimale farvekontrastforhold som defineret af WCAG, er det ikke kun vi muliggør læsbarhed for synshandicappede brugere, men vi booster det for dem, der ikke er synshandicappede også. Dette er en af ​​de mange måder, hvorpå vi designer inklusivt med praktisk talt ingen indsats.

Så hvad er minimumskravet, og hvordan kontrollerer vi det? For det første kan farvekontrastanalysatorer lide Stark kan bruges til at måle farvekontrastforhold. Det minimumsforhold, vi skal sigte efter, afhænger dog af selve elementet, dvs. om det er et vigtigt brugergrænsefladeelement, såsom et ikon eller ej. formularfelt, eller, hvis elementet er tekstbaseret, om skriftstørrelsen er lille eller stor, da større skrifttyper er mere læsbare, selv før der bliver pillet ved kontrast.

Dette er kravene til farvekontrastforhold for tekst over baggrund som defineret af WCAG:

• 14 pkt fed eller 18 pkt normal: 4,5:1 (7:1 er bedre) 
• 14 pkt fed eller 18 pkt normal og derover: 3:1 (4,5:1 er bedre) 

Disse er kravene til UI-elementer:

• Grafiske objekter (som diagrammer): 3:1 
• Fokus, svæv og aktive tilstande: 3:1
• Klikbare ikoner og formularelementer: 3:1

Stark-appen nævnt ovenfor kan også simulere, hvordan vores design ser ud for brugere med forskellige typer farveblindhed – 4,5 % af verden er trods alt mange potentielle brugere. Hvis du har svært ved at opnå optimal kontrast med links i en tekst, skal du understrege dem for at gøre linkene nemmere at få øje på, fordi nogle farveblinde brugere ikke ser farvekontrast på alle!

04. Hjælp brugerne med at rette fejl

Fejl resulterer ofte i en sky af forvirring, især når brugeren ikke ved, hvad de præcist gjorde, eller hvordan man fikser det. Fejl er uundgåelige, især for den moderne bruger, der skynder sig at engagere sig i grænseflader, tungt bevæbnet med deres mentale model, og det er derfor, at det er afgørende at hjælpe brugere (handicappede eller på anden måde) med at overvinde deres fejl. inklusivitet.

Naturligvis er det mest almindelige scenarie, hvor brugeren kan begå en fejl, når han udfylder en formular, og ofte som følge af en række forskellige handicap, dvs. vanskeligheder med at forstå som følge af en kognitiv funktionsnedsættelse, forkert dataindtastning som følge af et motorisk handicap, og snart. For det første, hvis vi kan rette brugerens fejl programmatisk, så afværges krisen. Et eksempel på dette i aktion kunne være at tilføje https:// til deres URL-indsendelse, hvis den ikke allerede er tilføjet, i modsætning til at tvinge brugeren til selv at rette det.

Overvej disse andre tips til at reducere formularfejl:

• Brug altid formularetiketter til at beskrive inputfelter 
• …og pladsholdere for at vise et eksempel på acceptabelt input 
• Aktiver autofyld og autofuldførelse for at reducere skrivekravene 

Og disse tips til at hjælpe brugere med at rette fejl:

• Vis formularfejl tydeligt i realtid 
• Lad brugeren bekræfte deres input før indsendelse 
• Vigtigt og ofte glemt: lad ikke brugerne føle sig dumme!

05. Bemærk "Spring til hovedindhold"

Skip-to-main-content er en relativt obskur tilgængelighedsfunktion rettet mod dem, der navigerer i brugergrænseflader med skærmlæsere. Du har højst sandsynligt aldrig hørt om denne funktion; sådan er det inkluderende. Skærmlæsere, eller simpelthen dem, der for det meste navigerer i brugergrænseflader ved hjælp af tastaturet, tavler gennem trykmål ved hjælp af tabulatortasten. Hvis du ikke er deaktiveret, ville du sandsynligvis have oplevet dette, uanset når du tabulerede gennem formularfelter på en desktop-webbrowser, da det er meget nemmere end at klikke.

Skip-to-main-content er en tilgængelighedsforbedring for at hjælpe denne delmængde af brugere med at undslippe gentagelse ved at omgå hovednavigationen – dette virker ved at have det første faneblad et link, der springer til hovedet indhold. Det er uklart for dem, der ikke bruger skærmlæsere, fordi dette link kun vises én gang med faner. Prøv at google noget, og tryk derefter på tabulatortasten!

Det er også vigtigt visuelt at angive, hvilket element der i øjeblikket er fokuseret på, da faneindekset kan skifte til en uventet placering (faneindekser og derfor skærmlæsere læser fra top til bund.) Når du tabulerer gennem tryk retter sig mod :fokus tilstand udløses, og browseren ved derefter at style elementet automatisk. Med hensyn til CSS-kode ser dette ofte ud, som om det er en blå box-skygge:, men det er det faktisk omrids:, så sørg for, at du ikke overskriver denne stil!

06. Skab ikke pres

Ingen kan lide at føle sig presset, men for dem med motoriske eller kognitive handicap kan pres være angstfremkaldende. Grænseflader er blevet meget mere dynamiske gennem årene, da flere og flere opgaver nu kan udføres ved hjælp af en enhed. Desværre er alt for mange dynamiske oplevelser resultatet af designere, der forsøger at gøre brugergrænseflader mere fantasifulde på bekostning af brugervenlighed. Et nyttigt uddrag af råd ville være at forenkle layoutet og fjerne unødvendige dynamiske elementer.

Dette inkluderer karruseller, popups og advarsler og distraherende animationer.

Lad os derefter tage et kig på, hvordan vi kan gøre disse elementer, hvis vi har brug for dem, tilgængelige for dem med handicap. Først og fremmest skal vi tilføje et kontrolniveau for automatisk afspilning af medier, der kræver opmærksomhed, da dette kan tilføje en ubehagelig mængde ekstra kognitiv belastning for dem med kognitive handicap. Reglen er, som defineret af WCAG 2.0, at hvis medier kører i mere end tre sekunder, skal det være kontrollerbart. Alt andet, der ruller, blinker eller på anden måde bevæger sig automatisk, uden at brugeren behøver at interagere med det (dvs. animationer og karruseller) bør også kunne kontrolleres, hvis det varer i mere end fem sekunder.

Generelt kan brugerne ikke lide uventede bevægelser/medier, og det er bedst at undgå det. Bemærk, at en lignende regel gælder for elementer, der blinker mere end tre gange i sekundet, især hvis det er højkontrast og rødt, da dette kan fremkalde anfald!

Med hensyn til chatbeskeder, advarsler, påmindelser, nyhedsfeeds og lignende, bør brugere kunne begrænse deres frekvens for at give sig selv mere tid til at læse og forstå, hvad der kommunikeres, og det er også tilrådeligt at lade brugeren nemt afvise alle advarsler eller synlige forhindringer med esc nøgle. Pres for at udføre en opgave er nogle gange uundgåeligt, da nogle grænseflader (såsom bankgrænseflader) kan timeout af sikkerhedsmæssige årsager, og disse advarsler skal naturligvis være indlysende. I dette scenarie bør handicappede brugere, der kræver mere tid, tilbydes chancen for at gøre det, og lade grænsefladen vide, at brugeren ikke har forladt det og fejlagtigt efterladt deres data blotlagt.

(Hvis du har mange medier, så husk at sikkerhedskopiere dem i den bedste cloud-lagring, der er tilgængelig for dig.)

07. Relæ med udviklere

Når det kommer til at lave tilgængelighedsforbedringer, bør udviklere dele halvdelen af ​​ansvaret, især når det kommer til at gøre brugergrænseflader skærmlæservenlige. Optimering af websteder til skærmlæsere sker for det meste bag kulisserne og påvirker overhovedet ikke ikke-handicappede brugere, hvilket gør disse websteder meget inkluderende for brugere på alle niveauer. For dem, der undrer sig, hjælper en skærmlæser synshandicappede brugere ved hørbart at læse, hvad der er på skærmen. Men hvad med billeder? Hvad med ikoner uden tekstetiketter? Hvordan formidler skærmlæsere designelementer uden tekstbeskrivelse, og hvordan skifter disse hjælpeteknologier hurtigt fokus til vigtige vartegn som søgning og navigation? Nå, det er præcis her, udvikleren kommer ind i det.

Designelementer uden tekst, der ledsager elementet, kan beskrives bag kulisserne ved hjælp af HTML. Her er en fantastisk tjekliste du ønsker at bogmærke.

Lad os gennemgå nogle af de vigtigste aspekter:

• Brug semantiske HTML-elementer såsom og
• Brug ARIA skelsættende roller for at tilføje yderligere kontekst til HTML-elementer 
• Erklær det (korrekte) sprog (WCAG vejledning her)
• Form altid elementer
• Brug "alt tekst" (Fejl! Filnavn ikke angivet.) for tekstalternativer til billeder (vejledning her) 
• Giv ingen JS-faldbacks og brug aldrig inline scripting

08. Vælg enkle bevægelser

At vælge enkle bevægelser frem for komplekse vil vinde over ikke-deaktiverede brugere, samtidig med at brugergrænseflader bliver tilgængelige for handicappede brugere. Bevægelser har en tendens til at variere mellem apps og websteder. For det første er der spørgsmålet om brugernes forventninger; for eksempel er swiping-interaktioner på touchscreen-apps ret normalt, men brugere ville typisk ikke tænke på at engagere sig i swiping på et websted (ikke engang på et mobilwebsted). Bortset fra, er noget ud over simpelt at trykke og klikke vanskeligt for handicappede brugere?

Svaret er ja, men de er også en smule skræmmende for ikke-handicappede brugere, med swiping muligvis en undtagelse, fordi det kan gøres med kun tommelfingeren. Jeg mener, har du nogensinde prøvet at rotere et Google Map? Det er en rigtig finurlig oplevelse, og for dem med nogle motoriske handicap ville det være en næsten umulig opgave at udføre. Da Google Maps ikke tilbyder en alternativ måde at rotere ved hjælp af klikbare knapper, er denne funktionalitet hverken tilgængelig eller inkluderende.

Så vi er nødt til at spørge os selv fra sag til sag, 'har vi virkelig brug for denne komplekse gestus?' Ville for eksempel en statisk, lodret stak fungere lige så godt som en swiping-karrusel? I begge scenarier ville vi have indhold, der flyder over visningsporten på begge måder, så hvad opnår en swiping-karrusel egentlig? Kunne strygningen være en progressiv forbedring for ikke-handicappede brugere? Enklere er bedre i dette tilfælde.

I mellemtiden skal du sikre dig, at trykmål er mindst 44px2 (så de er nemme at trykke og klikke, og også for visuel overkommelighed) og med rimelig afstand (for at reducere antallet af fejlklik).

Slut dig til os den 26. september til Generate CSS, bragt til dig af Creative Bloq, net og Web Designer. Spar 50 £ med en Early Bird-billet når du bestiller inden 15. august 2019.

Denne artikel blev oprindeligt publiceret i nummer 287 af magasinet kreativt webdesign Webdesigner. Køb nummer 287 eller abonnere på Web Designer.

Læs mere:

• Fremtiden for webdesign
• En webdesigners guide til CSS-metoder
• De 7 lektioner i webdesign, du skal vide