7 vanlige feil i forbindelse med tilgjengelighet (og hvordan du kan unngå dem)

Sannsynligvis har du hørt om digital tilgjengelighet før, og du vet at det er viktig å optimalisere nettproduktet ditt for personer med nedsatt funksjonsevne. Det er forståelig hvis du føler deg overveldet av all informasjonen og alle oppgavene du bør gjøre for å forbedre produktet ditt. Kanskje har du konkludert med at det er så komplisert at du må leie inn en ekspert til å gjøre jobben. I mellomtiden bryr du deg! Du vet bare ikke hvordan du skal komme i gang.

Bare rolig; det er ofte ikke så tidkrevende å fikse eller unngå disse problemene! Hvis du vet hvor du skal lete og hva du skal gjøre i stedet. I løpet av de årene jeg har jobbet som webutvikler og frontend-programvareingeniør, har jeg støtt på mange tilgjengelighetsproblemer. Ofte koker de ned til de samme punktene. I de fleste tilfeller tar det ikke mye tid å jobbe med universell utforming. Det er ikke vanskeligere eller dyrere. Det handler om å gjøre det daglige arbeidet med et annet tankesett som forbedrer tilgjengeligheten enormt.

Men nå til saken: La meg forklare hva som er de vanligste tilgjengelighetsproblemene, og - enda viktigere - hvordan du kan unngå dem.

Feil 1: Dårlig semantisk markering

Å unngå tilgjengelighetsproblemer krever ikke ekstra arbeid. Det krever ganske enkelt annerledes arbeid

En av de vanligste feilene som dessverre får store konsekvenser, er dårlig semantisk markering. Hvis du kan litt om HTML, vet du kanskje at en side består av elementer som er definert av HTML-tagger, for eksempel <h1> og <p>. De fleste elementene er semantiske: De beskriver tydelig hva de betyr på en menneske- og maskinlesbar måte.

Hvis du ser på kilden til en nettside, vil du også legge merke til mange <div> og <span> elementer; dette er de ikke-semantiske elementene. Disse elementene er generiske beholdere som ikke tillegger innholdet noen mening.

Skjermlesere er svært avhengige av semantisk HTML. De danner et tilgjengelighetstre basert på semantikken på siden. En bruker med skjermleser kan hoppe fra element til element ved hjelp av snarveier. Den forteller dem hvilke knapper som er knapper, hvilke som er overskrifter, hvor navigasjonen er, hvordan informasjonen på siden forholder seg til andre elementer på siden, og så videre.

Overdreven bruk av ikke-semantiske elementer

Hvis du bruker <div> og <span>-elementer der et semantisk element skulle ha vært, går viktig informasjon tapt umiddelbart. Brukere med synshemming kan ikke se nettstedets struktur ut fra det de ser. De kan ikke se knappene eller navigasjonsmenyen. Nettsiden blir en eneste stor haug med ustrukturert innhold. Enda verre er det at interaktive elementer - for eksempel knapper - ofte blir helt ubrukelige. Når jeg surfer på nettet, støter jeg ofte på <span>-elementer som styres av JavaScript, utformet som en knapp. JavaScriptet er skrevet slik at det aktiveres med et museklikk. Dette fungerer fint for alle som kan bruke mus, men det kan ikke styres med tastaturet, og det er ofte umulig for en skjermleserbruker å finne det i det hele tatt.

Tips: Bruk semantisk HTML

Hvis det ser ut som en knapp og oppfører seg som en knapp, bør det være en knapp

Mitt tips for å unngå denne uønskede oppførselen er sannsynligvis ikke en overraskelse: bruk passende semantiske HTML-elementer så mye som mulig. De eneste tilfellene du bør bruke <div> og <span>-elementene, er når det ikke finnes noe annet element som kan formidle mening. Dette gjelder vanligvis kun dekorative formål.

Ved å bruke semantiske elementer vil du øke tilgjengeligheten til nettsiden din eksponentielt. Dette er fordi de inneholder informasjon til nettleseren om hvordan de skal brukes. Som utvikler eller ingeniør vil du til og med spare tid. Du trenger ikke å tenke på å etterligne virkemåten til for eksempel en knapp, fordi den allerede fungerer slik uten videre.

Bruk av feil semantiske elementer

En annen vanlig feil i denne kategorien er å velge feil semantisk element. Dette er ofte et resultat av at man velger et element på grunn av utseendet i stedet for virkemåten eller formålet. Kanskje du ikke brukte en naturlig <button> fordi du syntes den så stygg ut. Eller kanskje du hoppet over noen overskriftsnivåer og valgte en <h4> i stedet for en <h2>, fordi du likte at den hadde en mindre skriftstørrelse. Dette er feil vei å gå; vi har CSS for det formålet.

Tips: Velg et element på grunn av dets betydning

Bruk HTML-elementer til å strukturere innholdet ditt basert på elementenes betydning, ikke deres utseende. Deretter kan du bruke CSS til å tilpasse stilene etter eget ønske.

Tips: Bruk automatiserte verktøy

En fin måte å hjelpe deg med semantikk på er å bruke et HTML-validatorverktøy. Noen verktøy inkluderer dette i automatiserte tilgjengelighetstester, for eksempel axe Tools. Husk at automatiserte verktøy ikke kan teste alt, og at de ofte inkluderer falske positive og negative resultater. Men det kan bidra til å raskt oppdage feil du kanskje har oversett. Det beste alternativet er å kombinere automatisert og manuell testing for tilgjengelighet.

Feil 2: Dårlig strukturerte skjemaetiketter

Hvis det ser ut som en knapp og oppfører seg som en knapp, bør det være en knapp.

Denne feilen har også mye å gjøre med semantisk HTML. Ta ikke feil: Det er litt av en utfordring å utforme og implementere et brukbart, tilgjengelig og pent skjema!

Innloggingsskjemaet til Easy LMS. Etikettene flyttes opp når du fyller ut et skjemafelt, slik at de forblir synlige.

Inndata og etikett er ikke koblet sammen

Hvert skjema har et inndatafelt og en etikett som beskriver feltet. Jeg har for eksempel tre inndatafelt: "Navn", "E-postadresse" og "Firma". Jeg kan legge til navnene i ren tekst over inndatafeltene (for eksempel i et <span>-element?). Dessverre vil en skjermleserbruker finne tre tomme tekstfelt uten noen indikasjon på hva som skal fylles ut.

Tips: koble sammen etikett og inngang

Å bruke semantiske HTML-elementer for etikettene er allerede langt på vei, men hvis du virkelig ønsker å hjelpe brukerne dine, bør du også parre etiketten og inndataene. Nå vet nettleseren at de to hører sammen. Vi i Easy LMS vil si: profitt!

Bruke plassholderattributter som etiketter

Et annet tilgjengelighetsproblem er å utelate etiketter og i stedet bruke plassholderattributter på inndataene. Dette er dårlig praksis av flere grunner. For det første er det ofte ikke tilgjengelig for mange hjelpeteknologier. For det andre forsvinner etikettene så snart en bruker skriver inn inndataene (eller fyller ut skjemaet automatisk). Da er det vanskelig å sjekke om det er feil i skjemaet. Til slutt er en plassholder ment som et ekstra hint - ikke som en etikett.

Tips: Ikke erstatt en etikett med en plassholder

Utelat aldri etiketter i et skjema. Hvis du må, bruk plassholdere kun for å gi ekstra hint til (seende) brukere i skjemaer. Men enda bedre: Ikke bruk plassholderattributter i det hele tatt, og sørg for at den viktige informasjonen om skjemaet er tilgjengelig for alle.

Feil 3: Bruke lenker som ikke er beskrivende

Hvor ofte har du støtt på lenker som sier "klikk her", "les mer" eller "gå til denne siden"? Jeg tipper: flere enn du kan telle! En av grunnene til at dette er dårlig praksis, er at det ikke gjør det mulig å forstå hensikten med lenken utenfor kontekst. Med hjelpeteknologier kan brukerne raskt navigere gjennom lenkene på en side. Forestill deg at en skjermleser kommuniserer følgende til deg: "Her, lenke. Les mer, lenke. Denne siden, lenke". Det sier deg vel egentlig ingenting?

Tips: inkluder sidens emne i lenken

Så hvordan unngår vi dette? I de fleste tilfeller kan dette løses enkelt ved å inkludere emnet eller tittelen på siden du henviser til inne i lenken. La meg gi deg et eksempel: Du kan lære mer om forskjellige typer funksjonsnedsettelser i denne artikkelen fra W3C. Nå vil skjermleseren kommunisere: "forskjellige typer funksjonshemninger, lenke". Gevinst!

Tips: Optimaliser gjentatte lenker

Jeg kan tenke meg at du ikke ønsker å inkludere tittelen i hver "Les mer"-lenke under en liste med artikler. Det gir mye rot på siden. Det finnes en rekke ulike tilnærminger til hvordan du kan gjøre "les mer"-lenker tilgjengelige, og det varierer fra brukstilfelle til brukstilfelle hvilken som vil fungere best. På oversikten over denne bloggen valgte vi å optimalisere lenkene for skjermlesere ved å legge til en aria-label som inkluderer tittelen på artikkelen.

Feil 4: Avhengig av bilder som eneste måte å formidle informasjon på

Jeg er selv en visuell tenker, og jeg vet hvor mye lettere det kan være å forstå noe ut fra et bilde i stedet for å lese tekst. Jeg vil ikke påstå at det er dårlig å bruke bilder til å forklare eller henvise til i en forklaring. Faktisk vil jeg oppfordre alle til å bruke bilder på denne måten, ettersom det for noen funksjonsnedsettelser (for eksempel dysleksi) faktisk forbedrer tilgjengeligheten. Men å bruke bilder som eneste måte å formidle informasjon på, er dårlig praksis.

På verdensbasis er rundt 43 millioner mennesker blinde, og rundt 295 millioner mennesker har moderat til alvorlig nedsatt syn. Dette tallet inkluderer ikke bare total blindhet, men også for eksempel tap av sentralt eller perifert syn og tåkesyn. Hvis du er avhengig av bilder for å forklare poenget ditt, risikerer du at noen av tilhørerne dine går glipp av store deler av informasjonen.

Skjermbilder

Et eksempel fra virkeligheten er når man forklarer hvordan man bruker et grensesnitt ved hjelp av skjermbilder. Teksten lyder ganske enkelt "klikk på knappen som er markert i skjermbildet" eller "sett opp konfigurasjonen slik det gjøres i følgende skjermbilde". Uten disse bildene er det umulig å vite hva man skal gjøre med disse instruksjonene. Når man tar i betraktning at denne typen artikler ofte finnes i kunnskapsbanker, dokumentasjon eller veiledninger, blir det enda mer problematisk.

Et eksempel på et skjermbilde fra hjelpesenteret vårt. Den medfølgende teksten i hjelpeartikkelen lyder "Du kan justere innstillingene for Pass-kategorien din ved å velge Rediger".

Tips: Teksten din bør være forståelig uten bilder

Publikum skal kunne forstå informasjonen uten bilder. Med instruksjoner i både tekst og bilder kan leseren velge hvilken måte han eller hun foretrekker å ta til seg informasjon på, eller ha en reserve i tilfelle funksjonsnedsettelse. Et triks jeg selv bruker, er å skrive teksten i sin helhet og legge til bildene i etterkant, slik jeg gjorde i denne bloggartikkelen. På denne måten unngår jeg å gå i den fellen at jeg utelater informasjon fordi den var synlig i et bilde mens jeg skrev.

Mangel på alternativ tekst

Ofte har informative bilder på nettsteder enten dårlig alternativ tekst eller ingen tekst i det hele tatt. Målet med alternativteksten er å beskrive bildet for brukere av skjermlesere. Hvis denne er tom, vet ikke skjermleserbrukerne hva som er på bildet, eller om de har gått glipp av viktig informasjon.

Tips: Legg til alternative tekster til funksjonelle og informative bilder

Den alternative teksten vil bli kommunisert til en bruker som ikke kan se bildet (ordentlig). Jeg vil oppfordre alle til ikke å ignorere disse, men å legge til en tydelig beskrivende alternativ tekst for bildet. Dette kan gjøres i kildekoden. I et CMS finnes det ofte et eget inndatafelt for dette.

Tips: Håndter dekorative bilder for skjermlesere på en annen måte

Noen ganger er bilder bare lagt til som dekorasjon for å gjøre en side mer visuelt attraktiv. Noen ganger er det best om bilder hoppes helt over av en skjermleser. Det finnes ulike måter å håndtere alternative tekster på, avhengig av hva som er målet med bildet.

Tekst i bilder

Tekst i bilder er heller ikke forståelig for personer med nedsatt syn. Du vil bli overrasket over hvor mye tekst som er inne i bilder (bare se på en hvilken som helst sosial medieplattform). Igjen, dette er ikke dårlig i seg selv, men sørg for at du også legger til teksten i en beskrivelse eller som alternativ tekst.

Feil 5: Dårlig fargekontrast

Velg et HTML-element på grunn av dets betydning, ikke dets utseende

Tekst med lav kontrast var det tilgjengelighetsproblemet som oftest ble oppdaget i de automatiserte testene utført av WebAIM. Dette er ikke bare problematisk for personer med nedsatt syn, men rammer også personer med fargesynssvikt (ulike former for fargeblindhet). Omtrent 1 av 12 menn og 1 av 200 kvinner har en eller annen grad av fargesynsmangel. Noen mennesker er ikke engang klar over at de har dette. Hvis du ser på bildet nedenfor, hvilket tall ser du?

Which number do you see? Image source

Hvis du ser 74, har du kanskje normalt fargesyn. Hvis du ser 21 eller ikke ser noe tall i det hele tatt, kan det hende du har rød-grønn fargesynsmangel. I så fall kan du ha kommet over nettsider med deler som var vanskelige å lese.

I WCAG er det definert et Suksesskriterium for når kontrasten mellom tekst og bakgrunn er høy nok til at personer med moderat svaksynthet kan lese den. WCAGs retningslinjer er kategorisert i tre nivåer av samsvar. På Easy LMS sikter vi mot nivå AA. Disse kontrastforholdene er 4,5:1 for liten tekst og 3:1 for stor tekst.

Tips: Bruk et verktøy for å sjekke fargekontrasten

Så hvordan finner du ut om kontrasten i teksten er høy nok? Det finnes mange verktøy for fargekontrast som du kan bruke til å kjøre tester på nettsiden din. Du kan også teste fargekontrasten manuelt ved å skrive inn fargekodene for forgrunns- og bakgrunnsfargen i en online kontrastkontroll.

Tips: Bruk mørkere eller lysere nyanser av en farge

En utfordring som ofte oppstår i denne sammenheng, er at fargene som brukes i brukergrensesnittet, matcher fargene i merkevarelogoen. Dette kan gjøre det vanskelig å ta tak i, ettersom fargene føles som om de er en del av merkevareidentiteten. En god praksis er å bruke en mørkere eller lysere nyanse av fargen du ønsker for å forbedre kontrasten. Vi justerte fargene på Easy LMS av denne grunn for et par år siden!

Bruk av farger som eneste måte å formidle informasjon på

Jeg har tidligere nevnt problemene som oppstår når man bruker bilder som eneste måte å formidle informasjon på. Det samme gjelder for farger. Fargene rød og grønn brukes ofte som den eneste måten å informere om suksess- og feiltilstander på. Dessverre er rød-grønn fargeblindhet den vanligste typen fargeblindhet. For disse brukerne vil rødt og grønt se likt ut.

Tips: Sørg for flere måter å kommunisere tilstander på

Det er greit å bruke rødt og grønt til disse formålene, men sørg for at du alltid tilbyr en annen måte å kommunisere tilstander på, for eksempel tekst, ulike former eller (merkede) ikoner.

Feil 6: Ikke gi en visuell indikasjon på det aktuelle fokuset

De fleste brukere navigerer på datamaskinen med en pekeenhet, for eksempel en mus eller en styreflate på en bærbar PC. På mobile enheter bruker vi fingrene på en berøringsskjerm. For noen brukere er dette enten vanskelig eller umulig på grunn av en funksjonsnedsettelse. Eksempler på dette kan være lammelser, manglende kroppsdeler, leddgikt eller belastningsskader. I slike tilfeller går brukerne ofte over til å bruke et tastatur eller en alternativ inndataenhet som kan etterligne tastaturet. Brukere med synshemming bruker for det meste et tastatur sammen med skjermleser eller bevegelser på mobile enheter.

Hvis du trykker på Tab-tasten på tastaturet, kan du hoppe mellom interaktive elementer på en nettside, for eksempel knapper og lenker. Du kan prøve det på denne siden: Etter hver tabulator vil du se en visuell indikasjon på hvor du befinner deg på skjermen.

CSS-fokusstiler

I CSS kan du legge til styling for flere ulike tilstander for knapper, for eksempel svevende, fokus og aktiv. Ofte utelates noen eller alle disse tilstandene, og knappen endrer ikke utseende ved interaksjon. En tastaturbruker flyr i blinde i dette tilfellet.

Tips: Bruk fokusstiler sammen med hover-stilene

Når du legger til stiler for hover-tilstanden til knappene, er det lurt å legge til stiler for fokustilstanden også. Ideelt sett bør fokusstilen være tydeligere enn hover-stilen, så du kan også legge dem til hver for seg i en annen nyanse.

Nettleserens fokusoversikt

En grunnleggende fokusindikator leveres automatisk av nettleseren og vises vanligvis som en ramme. Hvis du nettopp har bladd deg gjennom denne siden, har du kanskje sett den. Dessverre er denne rammen ofte deaktivert med CSS, av estetiske årsaker. Men når omrisset er deaktivert og det ikke finnes noen fokusstiler, er det umulig å navigere på en nettside kun ved hjelp av tastaturet.

Tips: Ikke deaktiver omrisset

Musebrukere vil ikke se nettleseromrisset du ser når du tabber deg gjennom en nettside med tastaturet. Ikke deaktiver dette omrisset med CSS, da det er et viktig hjelpemiddel for brukere med nedsatt funksjonsevne. Den fungerer også fint som en back-up i tilfelle fokusstilene dine er for utydelige eller mangler ved et uhell.

Husk at tastaturfokusindikatorene i nettlesere kan variere og ha ulike former. Derfor kan du ikke stole helt på dem. På den annen side vil det kreve mye testing for å vite sikkert om fokusstilene dine er tydelige nok for brukere med nedsatt funksjonsevne. Derfor anbefaler jeg at du alltid har begge deler.

Feil 7: Bruk av umerkede ikoner i knapper og lenker

Ikoner som brukes i programvare blir gjenkjennelige ved gjentatt bruk

Ikoner er en fin måte å unngå rot i nettproduktet ditt på. De kan også forbedre tilgjengeligheten for personer med ulike funksjonsnedsettelser, forutsatt at de er entydige. De fleste av oss vet at hvis vi ser et blyantikon, betyr det "rediger", og en søppelbøtte betyr "slett". Når vi bruker ikoner i et brukergrensesnitt, er det best å holde seg til de vi kjenner, slik at vi slipper å gjette. Men selv da er det mye som kan gå galt når det gjelder tilgjengelighet.

Ikoner kan brukes sammen med den tilhørende tekstetiketten eller alene. Som oftest er det ingen etikett når de brukes alene. Jeg legger for eksempel til en ikonknapp for en redigeringshandling, med bare et ikon av en blyant inni. Hvis jeg ikke legger til en tekstetikett for dette ikonet, blir knappen en tom knapp. Det stemmer: en skjermleser vil kommunisere til meg: "Knapp". Det er ikke særlig nyttig.
Enda mer: Jeg antar at brukeren vet at et blyantikon betyr "rediger". Men det vet jeg ikke med sikkerhet.

Tips: Legg til en etikett for ikoner

Hvis ikonet er en viktig del av brukergrensesnittet, er det best å legge til en etikett. Du kan gjøre dette ved å legge til en aria-label på ikonet. En annen måte er å legge til tekst som du skjuler for skjermer, men som er synlig for brukere av skjermlesere. Det er best å legge til et tittelattributt også. På den måten vises etiketten hvis en musebruker holder musepekeren over den.

Ikonknapper i Easy LMS-instrumentbordet som viser en tittel når du holder musepekeren over dem

Tips: Skjul dekorative ikoner

Hvis du har lagt til et ikon som et rent sukker på toppen, og informasjonen er forståelig uten det, er det best å skjule elementet for brukere av skjermlesere.

Konklusjon: Ikke jobb hardere, jobb smartere

Tanken på at du må endre disse tingene kan fortsatt være litt overveldende. Da jeg først lærte om universell utforming, hadde jeg den samme reaksjonen. Det er så mye å lære og så mange ulike typer funksjonsnedsettelser. Det er vanskelig å lage et brukergrensesnitt som er perfekt for alle.

Men jeg vil fortelle deg at det ikke handler om å revidere produktet eller nettstedet ditt. Jeg har funnet ut at den beste måten dette fungerer på, er å integrere det i arbeidsflyten. Neste gang jeg lager eller itererer på en del av produktet, bruker jeg det jeg har lært om tilgjengelighet med en gang. På denne måten kan vi forbedre tilgjengeligheten ett skritt om gangen. Som en av mine tilgjengelighetshelter Léonie Watson råder: "Det trenger ikke å være perfekt, det må bare være litt bedre enn i går." Preik!