Optimering af web­tilgængelighed

Profilfoto - Monika Ananieva

Frontendudvikler

Monika Ananieva

Denne guide giver dig grab’n go tips, du som webredaktør kan anvende i de fleste Content Management Systemer

Her i artiklen vil vi fokusere på nogle helt lavpraktiske tips til redaktører, der har set fidusen i at gøre et website tilgængelige for alle. De tips, du får, kræver på ingen måde, at du har kodekendskab. Det er grab’n go tips, du som webredaktør kan anvende i de fleste Content Management Systemer.

Det er vigtigt at pointere, at skabelsen af et fuldt tilgængeligt website, på ingen måde er en let opgave. Mange af de mere tekniske aspekter kræver et dybt kendskab til websitets kodebase, idet det er her, hjælpemidler som fx skærmlæsere henter deres informationer.

Men når det er sagt, er der stadig meget, du kan gøre på daglig basis, når du producerer indhold til dit website. Et tilgængeligt website kan nå ud til en bredere målgruppe, og samtidigt kan et tilgængeligt website styrke din ranking, helt enkelt fordi Google favoriserer gode og intuitive brugeroplevelser. Derfor er der god grund til at have blikket rettet mod Web Accessibility som disciplin. Det har vi skrevet en anden artikel om, som du med fordel kan læse som indledning til det reelle arbejde med webtilgængelighed.

Webtilgængelighed - kort fortalt

Webtilgængelighed - eller Web Accessibility - betyder kort fortalt, at du gør dit website tilgængeligt for ALLE mennesker herunder brugere med forskellige former for funktionsnedsættelse. Det betyder også, at du gør dit website tilgængeligt for de hjælpemidler, som brugere med funktionsnedsættelse benytter fx skærmlæsere, eyetrackers, specielle tastaturer mm.

Artiklen om de 18 bedste redaktørtips til et tilgængeligt website omhandler

  1. Tydeligt hierarki i overskrifter
  2. Linktekster der bruges til forskellige destinationer
  3. Linktitler
  4. Link åbner i ny fane
  5. Linkstyling
  6. Kontrastforhold mellem brødtekst og baggrund
  7. Sådan tjekker du farvekontrasten
  8. Filnavn som default til alt tekst
  9. Dekorative billeder
  10. Informative billeder
  11. Funktionelle billeder
  12. Billeder med tekst
  13. Transcripts
  14. Captions
  15. Audio descriptions
  16. Indhold der bevæger sig
  17. Web Accessibility med Siteimprove
  18. Web Accessibility med Googles Developer Tool

Overskrifter

1. Tydeligt hierarki i overskrifter

Overskrifterne på en webside skal organiseres hierarkisk. Tænk på overskrifterne som værende vejvisere for brugerne. 

Blinde eller meget svagtseende benytter skærmlæsere til at oplæse indholdet på en webside. En skærmlæser navigerer primært via det tag, som en overskrift er kodet med.

For at skabe overblik for brugeren kan skærmlæseren oplæse en liste over alle overskrifter på en siden, hvis altså overskrifterne er tagget rigtigt op. Nogle brugere med funktionsnedsættelse i hænder og arme benytter TAB-knappen til at gå gennem sidens overskrifter, og derfor bliver rækkefølgen afgørende for forståelsen.

Når du arbejder i din CMS teksteditor, har du mulighed for at tagge din tekst. Du kan formodentligt i en dropdown menu vælge, om teksten er paragraph, H1, H2, H3, quote mm. Tekstformaterne adskiller sig fra hinanden i deres styling, og vil visuelt fremstå meget forskellige. Netop derfor begår mange den fejl at vælge det tag, der passer bedst ind i den visuelle helhed og ser stort på, om rækkefølgen er hierarkisk. Det kan give store forståelsesmæssige udfordringer for den blinde eller svagtseende bruger, fordi den tekst, som skærmlæseren annoncerer, ikke kommer i en meningsfuld rækkefølge.

Screenshot fra Umbraco CMS backoffice viser dropdown med forskellige muligheder for headerstyling.

Overskriftskoder brugt i den rigtige rækkefølge vil give et præcist ‘billede’ af, hvad der findes på websiden. Derfor må overskrifter ikke springe niveauer over. Der skal som minimum være én hovedoverskrift (H1) på siden og underoverskrifter til denne skal være H2 og så videre.

Forkert brug af Heading tags går ikke kun ud over brugeroplevelsen, det gør det også vanskeligere for søgerobotterne at crawle og forstå dit indhold.

Links

2. Samme linktekst bruges til forskellige destinationer

Den samme linktekst anvendes til flere links, som fører forskellige steder hen. Nogle brugere kan ikke se forskellen mellem disse to enslydende links, hvis det ikke er forklaret.

Som de fleste har du formodentligt en webside, der indeholder en oversigt over alle dine blogindlæg eller nyheder.

For æstetikkens skyld afsluttes samtlige links med samme generiske linktekst ”Læs mere” eller ”Klik her”. Uden en linktitel, der beriger linket med gode informationer, er det svært for brugere, der navigerer via skærmlæsere, at forstå hvad der konkret sker, når man klikker på linket.

3. Linktitler

Linktitler tilføjer ekstra information om den kontekst linket indgår i, og den destination linket fører til. Link titler bliver særligt nyttige, når du anvender generiske linktekster som nævnt ovenfor.

4. Link åbner i ny fane

Når du indstiller et link til at åbne i en ny fane eller browservindue, risiker du, at brugere med nedsat syn, eller som er helt blinde, farer vild i deres søgen efter indhold og svar, fordi det ryger ud af konteksten, når et nyt vindue eller en ny fane åbner.

Hvis du ønsker, linket skal åbne i en ny fane, bør du tilføje ekstra information til linket ved hjælp af en linktitel. Linktitlen kan fx være: ”Denne artikel om web accessibility åbner i en ny fane”

5. Linkstyling

Et link, der er indsat i et almindeligt tekstafsnit, skal stå i kontrast til den øvrige tekst i form af nogle tydelige visuelle signaler. Dette kan fx gøres ved, at linkteksten er med store bogstaver, er understreget, med fed eller en anden farve end brødteksten.

Hvis links i tekstafsnit kun identificeres ved farve, skal farvekontrastforholdet mellem linkteksten og den omgivende tekst være mindst 3:1.

Men farve bør ikke være det eneste visuelle signal. Et yderligere visuelt signal kan være understregning af linket eller fremhævelse med fed skrift.

Bemærk at farvekontrastforholdet 3:1 for links, der udelukkende identificeres af farve, skal være målt som tekst mod tekst og ikke som tekst i forhold til baggrund.

Dette gælder for links, der visuelt er en del af en tekstblok. Menupunkter osv. er ikke omfattet af dette.

6. Kontrastforhold mellem brødtekst og baggrund

I nogle tilfælde bruges farvede baggrunde til at skabe kontrast og variation i forhold til de forskellige blokke på en side. Har du tekst på en farvet baggrund, er det vigtigt at kontrastforholdet mellem tekst og baggrund er mere end 4,5:1.

7. Sådan tjekker du farvekontrasten

Der findes et hav af værktøjer til at tjekke, om du har det rigtige kontrastforhold mellem farverne. Prøv blot at google ”Color Contrast Checker” – listen er lang.

Her er et par af dem:

https://contrastchecker.com/

https://monsido.com/tools/contrast-checker

I de fleste værktøjer, skal du indtaste de to farvekoder, som du vil undersøge kontrastforholdet imellem. Hvis du ikke lige kender koden på farverne, kan du bruge Googles Developer Tool.

I eksemplet herunder vil vi gerne undersøge forholdet mellem farven på det aktive brødkrummeniveau og baggrunden, og vi har derfor brug for at kende de pågældende farvekoder.

Højreklik på det element, du gerne vil undersøge farven på og vælg ”undersøg” i dropdown-menuen.

Inspect Color Contrast (2)

Klik på ”Select” ikonet.

Screenshot af select funktion i Lighthouse

Før markøren henover det element, du vil undersøge, og se koden på den markerede farve.

Du kan være heldig, at Google giver dig et par accessibility hints i forhold til kontrastfarver og brug af tab-funktion til at navigerer rundt på siden.

Screenshot viser om kontrastfarver er webtilgængelige

Koden, på den første farve vi skal bruge i dette eksempel, er #242F52. Følg helt samme procedure for testens anden farve og indtast dem begge i det værktøj, du har fundet frem til.

Billeder

Billeder benytter vi på forskellige vis til at understøtte vores budskab i teksterne. Generelt er huskereglen, at et billede skal være flankeret af en alt-attribut, som giver en alternativ information om billedet, på samme måde som linktitlerne, vi tidligere skrev om.

Langt de fleste Content Management Systemer har i redaktørinterfacet et inputfelt til et billedes alt tekst. Her er et eksempel fra Umbraco CMS.

En skærmlæser kan ikke forklare, hvad der foregår på et billede, og derfor skal du som redaktør med alt-attributten, tilføre billedet værdi i den kontekst, det indgår i.

Du behøver ikke starte dine alt tekster med ”billede af….”, da en skærmlæser automatisk identificere elementet ud fra filtypen og annoncerer overfor brugeren, at elementet er et billede.

Img Alt Text

8. Filnavn som default til alt tekst

Nogle systemer er kodet til at benytter billedets filnavn som default alt tekst. Dette er generelt ikke optimalt , da vi sjældent har en god disciplin omkring filnavngivning. Et Filnavn, som fx header-image.png, siger intet om, hvad billedet viser, og skaber derfor ikke værdi for den synshandikappede bruger. Et andet eksempel er, i det tilfælde, hvor samme billede bliver brugt i to forskellige kontekster. Her kan vi have brug for at angive to forskellige alt tekster og derfor er filnavnet ikke tilstrækkeligt.

Angiv derfor altid en alt tekst, med mindre der er tale om et dekorativ billede - det kan du læse mere om i artiklens næste afsnit.

I det efterfølgende gennemgår vi forskellige måder at bruge billeder på, og hvad du skal være opmærksom på i forhold til din alt tekst.

9. Dekorative billeder

Dekorative billeder kan fx være en baggrund, som blot skal understøtte det visuelle udtryk. Disse billeder er i konteksten ligegyldige for en bruger, som er svagt seende eller blind. Til trods for dette, skal disse billeder stadig have en alt attribut, men værdien skal blot være tom. Årsagen er, at en skærmlæser, der støder på et billede helt uden alt attribut, i stedet for vil læse filnavnet på billedet op for brugeren, hvilket ofte ikke tilfører nogen synderlig værdi. Derfor bør du lade alt teksten være ”blank” på dekorative billeder.

10. Informative billeder

Informative billeder kan være billeder, der understøtter instrukser og guidelines, hvor man på billedet kan se nogen foretage den handling, som bliver forklaret i teksten. Hvis teksten fx er en instruktion i forbindelse med anvendelse af en brandslukker, vil en god alt tekst til billedet være ”Kvinde viser, at sikringen fjernes ved at trykke på den grønne knap”

Angiv så vidt muligt særlige farver i billedet, hvis de er vigtigste i konteksten.

11. Funktionelle billeder

Funktionelle billeder er fx et logo i toppen, der også linker til forsiden. Det kan også være en ikon - eksempelvis luppen, der signalerer, at et klik aktiverer en søgefunktion.

En alt tekst til et funktionelt billede bør fortælle brugeren, om de handlinger, der gemmer sig bag ikonet/billedet. En god alt tekst som ”Foretag en søgning på siden”, er at foretrække frem for ”search-icon”.

Det er ikke sikkert, at du som redaktør har adgang til at definere værdien af alt-attributten på et funktionelt billede, og derfor kan du være nødt til at overlevere alt-teksterne til en udvikler, som herefter tilføjer dem i koderne.

12. Billeder med tekst

Billeder, der indeholder tekst, bør du generelt afholde dig fra af to årsager. Dels fordi skærmlæsere ikke kan læse og afkode et billede med tekst, på samme måde som normaltseende kan og dels fordi, når billeder skaleres til forskellige mobile enheder, bliver teksten ulæselig for de fleste.

Multimedier

Hvis du benytter dig af multimedier som podcasts, video eller livestreaming, har din hosting-udbyder formentligt en række forskellige værktøjer, der kan benyttes til at gøre dine multimedier mere tilgængelige. På YouTube og Vimeo kan du fx gøre brug af transcriptions og captions til at understøtte indholdet i videoen. Er dine multimediefiler indlejret på websitet, skal du muligvis have en udvikler med på sidelinjen, for at gøre transcriptions og captions tilgængelige i medieplayeren.

Læs herunder om de forskellige muligheder, og hvad der adskiller dem.

13. Transcripts

Transcripts er tekstversioner af, hvad der siges i en video, podcast eller livestreaming. De benyttes af brugere med lav eller slet ingen hørelse. Der findes mange både gratis og betalte værktøjer til at genere et transcript af en video- eller lydfil og din hosting-udbyder har formodentligt også lignende muligheder, som du kan benytte, når du har uploadet en video eller lydfil.

Transcriptions kan være automatiserede eller manuelle. Auto transcriptions baserer sig på audio-til-tekst-teknologi, og kan alt efter lydkvaliteten på din video automatisk lave en tekstversion af det, der bliver sagt i videoen. Det kræver dog ofte lidt efterarbejde for at sikre, at den rette mening og de rette budskaber kommer frem.

Ved manuelle transcriptions omsætter du selv audio til tekst formodentligt ved brug af et tekstbehandlingsprogram.

Selv uden problemer med hørelsen vil der til tider være brug for at læse et transcript – fx når du befinder dig et sted, hvor internetforbindelsen er for dårlig til at afspille en video, eller du sidder i en forsamling uden mulighed for at afspille en mediefil med lyd.

14. Captions

Captions er undertitler, der vises samtid med en video afspilles.

Du kan tilføje open captions, som altid afspilles simultant med videoen eller closed captions, som brugeren kan slå til og fra alt efter behov. Closed captions er klart at foretrække, da det overlader styringen til brugeren, hvilket også er en fordel rent SEO-mæssigt.

15. Audio descriptions

Audio descriptions er et lydspor, der fortæller, hvad der sker, og således giver blinde eller svagtseende mulighed for at forstå handlingen i videoen. Captions fortæller hvad personerne siger, mens audio descriptions forklarer, at der fx er et publikum der klapper, eller at to personer omfavner hinanden. Videoer uden lyd bør altid indeholde audio descriptions, hvis der er vigtige visuelle informationer i videoen.

16. Indhold der bevæger sig

Hurtigt bevægende indhold kan trigge forskellige former for anfald, relateret til fx epilepsi og migræne. Tommelfingerreglen er, at der ikke må være elementer, der blinker mere end 3 gange pr sekund.

Dette gratis værktøj kan teste, om et website overholder kravene. Photosensitive Epilepsy Analysis Tool

Accessibility tjek

WCAG er en forkortelse for "Web Content Accessibility Guidelines". WCAG er en international standard for webtilgængelighed udviklet af W3C, som også har udviklet internationale standarder for HTML og CSS.

Retningslinjerne i WCAG omfatter en bred vifte af anbefalinger - inddelt i 3 niveauer - til at gøre et website tilgængeligt for brugere med forskellige handicaps. I Danmark er der lovgivningsmæssige krav til offentlige organers websites og applikationer. Kravene omfatter de første 2 niveauer A og AA i WCAG 2.1 anbefalingerne.

Der findes mange forskellige digitale værktøjer til at teste webtilgængelighed, men ikke mange, som kan teste på samtlige WCAG 2.1 anbefalingerne. Nogle værktøjer tester på laveste niveau (A), nogle tester kun på udviklerrelaterede krav, og andre tester på specifikke krav som fx farvekontrastforholdet. Vi vil anbefale, at du altid benytter værktøjer, der tester op imod WCAG standarderne, da det er dem, vi i Danmark retter ind efter.

Ikke alle WCAG anbefalingerne kan tjekkes med et digitalt værktøj, og derfor kan det være nødvendigt at supplere med et manuelt tjek, der gør brug af forskellige hjælpemidler.

17. Web Accessibility tjek med Monsido

Hos Illumi benytter vi platformen Monsido, der indeholder mange værktøjer, som samlet set giver et rigtig godt overblik over et websites performance – herunder også tilgængelighed. Værktøjet måler et websites tilgængelighed op mod mange af succeskriterierne i WCAG 2.1, og der arbejdes hele tiden på at understøtte flere af succeskriterierne. Monsido er en licensbaseret software og er særlig anvendelig i større virksomheder, hvor der er mange forskellige udviklerteams og redaktørgrupper, som deles om ansvaret for et tilgængeligt website.

18. Web Accessibility tjek med Googles Developer Tool

En anden og gratis måde at få indblik i et websites accessibility, er ved at benytte Googles Developer Tool.

Googles Accessibility Audit får du adgang til ved at klikke på ”Tilpas Google Chrome” - de 3 prikker i højre øverste hjørne af dit browservindue.

Screenshot viser dropdown med Googles udviklerværktøjer

Når Developer Tool-fanerne åbnes, skal du ikke lade dig forvirre af den kode, som du umiddelbart ser, men i stedet vælger menupunktet ”Lighthouse”.

Screenshot af dropdown med Inspector funktioner

Det næste du skal, er at konfigurere din audit. Her vælger du kategorien Accessibility og enten mobil eller desktop.

Generate Report

I resultatet vil det fremgå, hvilke accessibility fejl websitet har, og du finder ligeledes under den enkelte fejl et link til mere information om succeskriterierne beskrevet i WCAG 2.1.

Accessibility Score

Har du brug for hjælp til at øge webtilgængeligheden?

En web-strategi med fokus på tilgængelighed for alle, kan have mange fordele for din forretning, og selvom der er tale om to forskellige discipliner, har optimering af webtilgængelighed og SEO grundlæggende en gensidig fordelagtig effekt.

Har du brug for hjælp til at identificere konkrete punkter, der i øjeblikket ikke lever op til kravene og/eller til implementering af forbedringer, så ring til os på 5811 2160 eller skriv til [email protected].

Relateret indhold