7 almindelige tilgængelighedsfejl (og hvordan du undgår dem)

Sandsynligvis har du hørt om digital tilgængelighed før, og du ved, at det er vigtigt at optimere dit onlineprodukt for mennesker med handicap. Det er forståeligt, hvis du føler dig overvældet af alle de oplysninger og opgaver, du skal udføre for at forbedre dit produkt. Måske har du konkluderet, at det er så kompliceret, at du er nødt til at hyre en ekspert til at gøre arbejdet. I mellemtiden er du ikke ligeglad! Du ved bare ikke, hvordan du skal komme i gang.

Bare rolig; det er ofte ikke så tidskrævende at løse eller undgå disse problemer! Hvis man altså ved, hvor man skal lede, og hvad man skal gøre i stedet. I de år, jeg har arbejdet som webudvikler og front-end softwareingeniør, er jeg stødt på mange tilgængelighedsproblemer. Ofte kan de koges ned til de samme punkter. I de fleste tilfælde tager en tilgængelighedsorienteret tilgang ikke meget tid. Det er ikke sværere eller dyrere. Det handler om at udføre sit daglige arbejde med en anden tankegang, som forbedrer tilgængeligheden enormt.

Men nu til det egentlige: Lad mig forklare, hvad de mest almindelige tilgængelighedsproblemer er, og endnu vigtigere: hvordan man undgår dem.

Fejl 1: Dårlig semantisk markup

Det kræver ikke ekstra arbejde at undgå tilgængelighedsproblemer. Det kræver blot anderledes arbejde

En af de mest almindelige fejl, der desværre har store konsekvenser, er dårlig semantisk opmærkning. Hvis du ved lidt om HTML, ved du måske, at en side består af elementer defineret af HTML-tags, for eksempel <h1> og <p>. De fleste elementer er semantiske: De beskriver tydeligt deres betydning på en menneske- og maskinlæsbar måde.

Hvis du ser kilden til en webside, vil du også bemærke en masse <div> og <span> elementer; det er de ikke-semantiske elementer. Disse elementer er generiske containere, der ikke giver mening til deres indhold.

Skærmlæsere er stærkt afhængige af semantisk HTML. De danner et tilgængelighedstræ baseret på sidens semantik. En bruger med en skærmlæser kan springe fra element til element ved hjælp af genveje. Det fortæller dem, hvad der er knapper, hvad der er overskrifter, hvor navigationen er, hvordan information på siden relaterer til andre elementer på siden og så videre.

Overforbrug af ikke-semantiske elementer

Hvis du bruger <div> og <span>-elementer, hvor der skulle have været et semantisk element, går vigtig information tabt med det samme. Brugere med synshandicap kan ikke se hjemmesidens struktur ud fra det, de ser. De kan ikke se knapperne eller navigationsmenuen. Websiden bliver en stor bunke ustruktureret indhold. Endnu værre er det, at interaktive elementer - som f.eks. knapper - ofte bliver helt ubrugelige. Når jeg surfer på nettet, støder jeg ofte på <span>-elementer, der styres af JavaScript og er udformet som en knap. JavaScriptet er skrevet til at blive aktiveret ved et klik med musen. Det fungerer fint for alle, der kan bruge en mus, men det kan ikke styres med tastaturet, og det er ofte umuligt for en skærmlæserbruger at finde det overhovedet.

Tip: brug semantisk HTML

Hvis det ligner en knap og opfører sig som en knap, bør det være en knap.

Mit tip til at undgå denne uønskede adfærd er nok ikke en overraskelse: brug passende semantiske HTML-elementer så meget som muligt. De eneste tilfælde, hvor du bør bruge <div> og <span>-elementer, er, når der ikke er andre elementer til rådighed til at formidle mening. Det drejer sig normalt kun om dekorative formål.

Brug af semantiske elementer vil øge tilgængeligheden af din webside eksponentielt. Det skyldes, at de indeholder information til browseren om, hvordan de skal bruges. Desuden vil det som udvikler eller ingeniør endda spare tid. Du behøver ikke at tænke på at efterligne opførslen af f.eks. en knap, fordi den allerede fungerer på den måde uden videre.

Brug af de forkerte semantiske elementer

En anden almindelig fejl i denne kategori er at vælge det forkerte semantiske element. Det er ofte resultatet af, at man vælger et element ud fra dets udseende i stedet for dets adfærd eller formål. Måske brugte du ikke en indbygget <knap>, fordi du syntes, den så grim ud. Eller måske sprang du et par overskriftsniveauer over og valgte en <h4> i stedet for en <h2>, fordi du godt kunne lide, at den havde en mindre skriftstørrelse. Det er den forkerte vej rundt; vi har CSS til det formål.

Tip: Vælg et element på grund af dets betydning

Brug HTML-elementer til at strukturere dit indhold baseret på hvert elements betydning, ikke dets udseende. Anvend derefter stilarter efter eget ønske med CSS.

Tip: Brug automatiserede værktøjer

En god måde at hjælpe dig med semantik på er at bruge et HTML-validatorværktøj. Nogle værktøjer inkluderer dette i automatiserede tilgængelighedstests, f.eks. axe Tools. Husk, at automatiserede værktøjer ikke kan teste alt, og at de ofte indeholder falske positive og negative resultater. Men det kan hjælpe med hurtigt at spotte fejl, som du måske har overset. Den bedste løsning er at kombinere automatiseret og manuel test af tilgængelighed.

Fejl 2: Dårligt strukturerede formularer

Hvis det ligner en knap og opfører sig som en knap, bør det være en knap.

Denne fejl har også meget at gøre med semantisk HTML. Tag ikke fejl: at designe og implementere en brugbar, tilgængelig og flot formular er noget af en udfordring!

Login-formularen til Easy LMS. Etiketterne flyttes op, når du udfylder et felt i formularen, så de forbliver synlige.

Input og label er ikke forbundet

Hver formular har et inputfelt og en etiket, der beskriver det pågældende inputfelt. Jeg har for eksempel tre indtastningsfelter: "Navn", "E-mail-adresse" og "Virksomhed". Jeg kunne tilføje navnene over inputfelterne i almindelig tekst (f.eks. i et <span>-element?). Desværre vil en skærmlæserbruger finde tre tomme tekstinput uden en indikation af, hvad der skal udfyldes.

Tip: par label og input

At bruge semantiske HTML-elementer til etiketterne rækker allerede langt, men hvis du virkelig vil hjælpe dine brugere, bør du også parre din etiket og dit input. Nu ved browseren, at de to hører sammen. Hos Easy LMS ville vi sige: profit!

Brug af pladsholderattributter som etiketter

Et andet tilgængeligheds-no-go er at udelade labels og i stedet bruge placeholder attributes på inputs. Det er dårlig praksis af flere grunde. For det første er det ofte ikke tilgængeligt for mange hjælpemidler. For det andet forsvinder etiketterne, så snart en bruger indtaster input (eller udfylder formularen automatisk). Det er svært at tjekke formularen for fejl på den måde. Endelig er en pladsholder ment som et ekstra hint - ikke som en label.

Tip: Erstat ikke en label med en pladsholder

Udelad aldrig etiketter i en formular. Hvis du er nødt til det, så brug kun pladsholdere til at give ekstra hints til (seende) brugere i formularer. Men endnu bedre: Brug slet ikke pladsholderattributter, og sørg for, at de vigtige oplysninger om formularen er tilgængelige for alle.

Fejl 3: Brug af ikke-beskrivende links

Hvor ofte er du stødt på links, hvor der står "klik her", "læs mere" eller "gå til denne side"? Mit gæt: flere end du kan tælle! En af grundene til, at det er dårlig praksis, er, at det ikke giver mulighed for at forstå linkets formål uden for kontekst. Med hjælpemidler kan brugerne hurtigt navigere gennem linkene på en side. Forestil dig, at en skærmlæser kommunikerer følgende til dig: "Her, link. Læs mere, link. Denne side, link". Det fortæller dig ikke rigtig noget, vel?

Tip: Inkluder sidens emne i linket.

Så hvordan undgår vi det? I de fleste tilfælde kan det nemt løses ved at inkludere emnet eller titlen på den side, du henviser til, i linket. Lad mig give dig et eksempel: Du kan lære mere om forskellige typer af handicap i denne artikel fra W3C. Nu vil skærmlæseren kommunikere: "forskellige typer af handicap, link". Det er en fordel!

Tip: optimer gentagne links

Jeg kan forestille mig, at du ikke ønsker at inkludere titlen i hvert "Læs mere"-link under en liste med artikler. Det giver en masse rod på siden. Der er en række forskellige tilgange til, hvordan man gør "læs mere"-links tilgængelige, og det er forskelligt fra brugssag til brugssag, hvilken der fungerer bedst. På oversigten over denne blog valgte vi at optimere linkene til skærmlæsere ved at tilføje en aria-label, der indeholder titlen på artiklen.

Fejl 4: Afhængig af billeder som den eneste måde at formidle information på

Da jeg selv tænker visuelt, ved jeg, hvor meget lettere det kan være at forstå noget ud fra et billede i stedet for at læse en tekst. Jeg vil ikke påstå, at det er dårligt at bruge billeder til at forklare eller henvise til i en forklaring. Faktisk vil jeg opfordre alle til at bruge billeder på den måde, da det for nogle funktionsnedsættelser (som f.eks. ordblindhed) faktisk forbedrer tilgængeligheden. Men at bruge billeder som den eneste måde at formidle information på er dårlig praksis.

Globalt er omkring 43 millioner mennesker blinde, og omkring 295 millioner mennesker har moderat til svær synsnedsættelse. Dette tal omfatter ikke kun total blindhed, men også f.eks. tab af centralt eller perifert syn og sløret syn. Hvis du er afhængig af billeder for at forklare din pointe, risikerer du, at nogle af dine tilhørere går glip af en stor del af informationen.

Skærmbilleder

Et eksempel fra det virkelige liv på dette problem er at forklare, hvordan man bruger en brugerflade ved hjælp af skærmbilleder. Teksten lyder ganske enkelt: "Klik på den knap, der er markeret i skærmbilledet" eller "Konfigurer din brugerflade som vist i det følgende skærmbillede". Uden disse billeder er det umuligt at vide, hvad man skal gøre med disse instruktioner. Når man tænker på, at den slags artikler ofte findes i vidensbanker, dokumentation eller vejledninger, bliver det endnu mere problematisk.

Et eksempel på et skærmbillede fra vores Help Center. Den ledsagende tekst i hjælpeartiklen lyder: "Du kan justere indstillingerne for din Pass-kategori ved at vælge Rediger".

Tip: din tekst skal være forståelig uden billeder

Dit publikum skal kunne forstå informationen uden billederne. Med instruktioner i både tekst og billeder kan din læser vælge sin foretrukne måde at få information på eller har en reserve i tilfælde af nedsat funktionsevne. Et trick, jeg selv bruger, er at skrive teksten som en helhed og tilføje billederne bagefter, som jeg gjorde til denne blogartikel. På den måde kommer jeg ikke til at udelade information, fordi den var synlig på et billede, mens jeg skrev.

Mangel på alternativ tekst

Ofte har informative billeder, som du finder på hjemmesider, enten en dårlig alternativ tekst eller slet ingen. Målet med alt-tekster er at beskrive billedet for brugere af skærmlæsere. Hvis den er tom, ved skærmlæserbrugere ikke, hvad der er på billedet, eller om de er gået glip af vigtige oplysninger.

Tip: Tilføj alternative tekster til funktionelle og informative billeder

Den alternative tekst vil blive kommunikeret til en bruger, der ikke kan se billedet (ordentligt). Jeg vil opfordre alle til ikke at ignorere disse, men at tilføje en klar beskrivende alternativ tekst til billedet. Dette kan gøres i kildekoden. I et CMS er der ofte et dedikeret inputfelt til det.

Tip: Håndter dekorative billeder til skærmlæsere på en anden måde

Nogle gange tilføjes billeder kun som dekoration for at gøre en side mere visuelt attraktiv. Nogle gange er det bedst, hvis billeder helt springes over af en skærmlæser. Der er forskellige tilgange til, hvordan man håndterer alternative tekster afhængigt af formålet med billedet.

Tekst i billeder

Tekst i billeder er heller ikke forståeligt for mennesker med synshandicap. Du vil blive overrasket over, hvor meget tekst der er i billeder (bare se på en hvilken som helst social medieplatform). Igen, det er ikke dårligt i sig selv, men sørg for også at tilføje teksten i en beskrivelse eller som alternativ tekst.

Fejl 5: Dårlig farvekontrast

Vælg et HTML-element efter dets betydning, ikke dets udseende

Tekst med lav kontrast var det mest almindeligt opdagede tilgængelighedsproblem i automatiserede tests udført af WebAIM. Dette er ikke kun problematisk for mennesker, der lider af nedsat syn, men påvirker også mennesker med farvesynsmangel (forskellige former for farveblindhed). Omkring 1 ud af 12 mænd og 1 ud af 200 kvinder har en eller anden grad af farvesynsmangel. Nogle mennesker er ikke engang klar over, at de har det. Hvis du ser på billedet nedenfor, hvilket tal ser du så?

Which number do you see? Image source

Hvis du ser 74, har du måske et normalt farvesyn. Hvis du ser 21 eller slet ikke noget tal, kan du have en rød-grøn farvesynsmangel. I så fald er du måske stødt på hjemmesider med dele, der var svære at læse.

I WCAG er der defineret et Succeskriterium for, hvornår kontrasten mellem tekst og baggrund er høj nok til, at personer med moderat nedsat syn kan læse den. WCAG's retningslinjer er kategoriseret i tre niveauer af overensstemmelse. Hos Easy LMS sigter vi efter niveau AA. Disse kontrastforhold er 4,5:1 for lille tekst og 3:1 for stor tekst.

Tip: Brug et værktøj til at tjekke farvekontrasten

Så hvordan finder du ud af, om kontrasten i teksten er høj nok? Der findes mange værktøjer til farvekontrast, som du kan bruge til at køre tests på din webside. Du kan også teste farvekontrasten manuelt ved at indtaste farvekoderne for forgrunds- og baggrundsfarven i en online kontrasttjekker.

Tip: Brug mørkere eller lysere nuancer af en farve

En udfordring, der ofte opstår i forbindelse med dette spørgsmål, er, at de farver, der bruges i brugergrænsefladen, matcher farverne i brandets logo. Det kan gøre det svært at løse, da farverne føles som en del af brandets identitet. En god praksis er at bruge en mørkere eller lysere nuance af den farve, du ønsker, for at forbedre kontrasten. Vi justerede farverne på Easy LMS af denne grund for et par år siden!

At bruge farver som den eneste måde at formidle information på

Tidligere nævnte jeg de problemer, der opstår, når man bruger billeder som den eneste måde at formidle information på. Det samme gælder for farver. Farverne rød og grøn bruges ofte som den eneste måde at informere om succes- og fejltilstande på. Desværre er rød-grøn farveblindhed den mest almindelige form for farveblindhed. For disse berørte brugere vil rød og grøn se ens ud.

Tip: Sørg for flere måder at kommunikere på

Det er OK stadig at bruge rød og grøn til disse formål, men sørg for altid at give en anden måde at kommunikere tilstande på, f.eks. tekst, forskellige former eller (mærkede) ikoner.

Fejl 6: Ikke at give en visuel indikation af det aktuelle fokus

De fleste brugere navigerer på deres computere med en pegeenhed, f.eks. en mus eller en trackpad på en bærbar computer. På mobile enheder bruger vi vores fingre på en berøringsskærm. For nogle brugere er dette enten vanskeligt eller umuligt på grund af deres handicap. Eksempler er lammelse, en manglende kropsdel, gigt eller repetitiv stressskade. I disse tilfælde skifter brugerne ofte til et tastatur eller en alternativ inputenhed, der kan efterligne tastaturets adfærd. Brugere med synsnedsættelse bruger for det meste et tastatur sammen med deres skærmlæser eller bevægelser på deres mobile enheder.

Hvis du trykker på Tab-tasten på dit tastatur, kan du springe mellem interaktive elementer på en webside, f.eks. knapper og links. Du kan prøve det på denne side: Efter hver tabulator vil du se en visuel indikation af din placering på skærmen.

CSS-fokusstile

I CSS kan man tilføje styling til flere forskellige tilstande for knapper, f.eks. hover, focus og active. Ofte udelades nogle eller alle disse tilstande, og knappen ændrer ikke udseende ved interaktion. En tastaturbruger flyver i blinde i dette tilfælde.

Tip: Anvend fokus-stilarter sammen med hover-stilarterne

Mens du tilføjer stilarter til knappernes hover-tilstand, er det god praksis også at tilføje dem til fokustilstanden. Ideelt set skal fokus-stilen være mere tydelig end hover-stilen, så du kan også tilføje dem hver for sig i en anden nuance.

Oversigt over browserens fokus

En grundlæggende fokusindikator leveres automatisk af webbrowseren og vises typisk som en kant. Hvis du lige har bladret igennem denne side, har du måske set den. Desværre er dette omrids ofte deaktiveret med CSS af æstetiske årsager. Men når omridset er deaktiveret, og der ikke er nogen fokusstile, er det umuligt at navigere på en webside udelukkende med tastaturet.

Tip: Lad være med at deaktivere konturen

Musebrugere vil ikke se den browserkontur, som du ser, når du tabber dig gennem en webside med et tastatur. Du må ikke deaktivere dette omrids med CSS, da det er en vigtig hjælp for brugere med handicap. Den fungerer også fint som back-up, hvis dine fokusstile er for uklare eller mangler ved et uheld.

Husk, at browsernes indikatorer for tastaturfokus kan variere og antage forskellige former. Derfor kan du ikke stole helt på dem. På den anden side vil det kræve en masse test at vide med sikkerhed, om dine fokusstile er tydelige nok for brugere med et handicap. Derfor vil jeg råde dig til altid at have begge dele.

Fejl 7: Brug af umærkede ikoner i knapper og links

Ikoner, der bruges i software, bliver genkendelige ved gentagen brug

Ikoner er en god måde at undgå rod i dit onlineprodukt. De kan også forbedre tilgængeligheden for forskellige handicap, hvis de altså er entydige. De fleste af os ved, at hvis vi ser et blyantsikon, betyder det "rediger", og en skraldespand betyder "slet". Når vi bruger ikoner i en brugergrænseflade, er det bedst at holde sig til dem, vi kender, for at undgå gætterier. Men selv da er der meget, der kan gå galt, når det gælder tilgængelighed.

Ikoner kan bruges ved siden af deres tilsvarende tekstmærke eller alene. Oftest er der ikke nogen etiket, når de bruges alene. For eksempel tilføjer jeg en ikonknap til en redigeringshandling med blot et ikon af en blyant indeni. Hvis jeg ikke tilføjer en tekstlabel til dette ikon, bliver knappen en tom knap. Det er rigtigt: En skærmlæser vil kommunikere til mig: "Knap". Det er ikke særlig nyttigt.
Endnu mere: Jeg antager, at brugeren ved, at et blyantsikon betyder "rediger". Men det ved jeg ikke med sikkerhed.

Tip: tilføj en etiket til ikoner

Hvis ikonet er en vigtig del af din brugergrænseflade, er det bedst at tilføje en etiket. Det kan du gøre ved at tilføje en aria-label på ikonet. En anden måde er at tilføje tekst, som du skjuler for skærme, men som er synlig for skærmlæserbrugere. Det er også bedst at tilføje en titelattribut. På den måde vises etiketten, hvis en musebruger svæver over den.

Ikonknapper i Easy LMS-dashboardet, der viser en titel, når du holder musen over dem

Tip: Skjul dekorative ikoner

Hvis du har tilføjet et ikon udelukkende som sukker på toppen, og informationen er forståelig uden det, er det bedst at skjul elementet for brugere af skærmlæsere.

Konklusion: Arbejd ikke hårdere, arbejd smartere.

Tanken om, at du er nødt til at ændre disse ting, kan stadig være lidt overvældende. Da jeg første gang lærte om tilgængelighed, havde jeg samme reaktion. Der er så meget at lære og så mange forskellige slags handicap. Det er svært at lave en brugergrænseflade, der er perfekt for alle.

Men jeg vil gerne fortælle dig, at det ikke handler om at lave om på dit produkt eller din hjemmeside. Jeg har fundet ud af, at den bedste måde, det fungerer på, er at integrere det i din arbejdsgang. Næste gang jeg skaber eller itererer på en del af produktet, anvender jeg det, jeg har lært om tilgængelighed, med det samme. På den måde kan vi forbedre tilgængeligheden et skridt ad gangen. Som en af mine tilgængelighedshelte Léonie Watson siger: "Det behøver ikke at være perfekt; det skal bare være en lille smule bedre end i går." Preach!