Go to Menu

En förenklad guide om webbtillgänglighet: Få kontroll över WCAG

Det kan vara svårt att veta var man ska börja med WCAG. Med denna enkla guide om webbtillgänglighet blir det förhoppningsvis lite lättare.

februari 27, 2023 by Amy Foxwell
En kvinna skriver i en bok på ett skrivbord framför en dator.

Organisationer och företag måste se till att deras webbplatser är tillgängliga också för personer med funktionsnedsättningar. De har ett etiskt ansvar att anpassa sig till så många användare som möjligt – och det finns ingen anledning att ignorera en betydande del av befolkningen. Det gäller alla offentliga och privata webbplatser: företag, skolor, myndigheter och andra typer av institutioner.

Enligt Världshälsorganisation (WHO) har mer än 1 miljard människor i världen minst en funktionsnedsättning. Detta är en uppskattning och det kan finnas ett mörkertal. Enligt en rapport från Statistiska Centralbyrån (SCB) som publicerades 2020 har omkring 36 % av Sveriges befolkning någon form och grad av funktionsnedsättning.

Målet med webbtillgänglighet är att förbättra användarupplevelsen för så många som möjligt. Detta gäller personer med olika typer av funktionsnedsättningar, som till exempel:

  • Döva och personer med hörselnedsättningar
  • Personer med synnedsättningar
  • Personer med neurokognitiva funktionsnedsättningar
  • Personer med fysiska handikapp
  • Personer med psykisk ohälsa

Hur kan webbplats anpassas till alla dessa användare – och hur kan innehållet testas för att säkra att tillgänglighetsarbetet går åt rätt håll?

Goda nyheter: Det finns handfasta regler. Riktlinjer för tillgängligt webbinnehåll (WCAG) utfärdas av World Wide Web Consortium (W3C), en internationell organisation som också står bakom standarder för programmeringsspråken HTML och CSS. Nedan förklarar vi hur en webbplats som följer WCAG når ut till fler människor – och förbättrar efterlevnaden med Diskrimineringslagen och andra regler.

WCAG:s roll i efterlevnad av tillgänglighetskrav

Vissa tillgänglighetslagar bygger direkt på WCAG, som Sveriges lag om tillgänglighet till digital offentlig service (DOS-lagen), medan andra, som det amerikanska tillägget Section 508, nöjer sig med att hänvisa till WCAG. Vi ska återkomma till lagar och regler, men först ska vi ta en närmare titt på hur dessa riktlinjer är uppbyggda.

WCAG består av ett antal framgångskriterier i form av påståenden som kan vara sanna eller falska, som kan användas för att testa innehållets digitala tillgänglighet. Riktlinjerna är utformade för att kunna tillämpas på nästintill alla typer av webbinnehåll, inklusive mobilappar och onlinedokument (t.ex. Adobe PDF-filer).

Framgångskriterierna är organiserade i tre nivåer av överensstämmelse. ”Överensstämmelse” innebär att man frivilligt följer riktlinjerna. Här är de tre nivåerna för WCAG:s framgångskriterier:

 Schematisk bild av WCAC framgångskriterier. De beskrivs en i taget i denna bloggtext, efter denna bild.
  • Nivå A är den lägsta ambitionsnivån och innehåller de högst prioriterade kriterierna.
  • Nivå AA innehåller ytterligare kriterier. Denna nivå ligger till grund för EU-standarden EN 301 549 och utgör därmed lagkrav i EU.
  • Nivå AAA är den högsta ambitionsnivån och innehåller ytterligare kriterier. Det är möjligt att vissa typer av innehåll inte kan anpassas för att uppfylla Nivå AAA.

Varje nivå innehåller samtliga kriterier i de lägre nivåerna. Det innebär att för överensstämmelse med Nivå AA måste också samtliga krav på Nivå A vara uppfyllda.

Internationell lagstiftning om tillgänglighet

Fler och fler länder lagstiftar om tillgänglighet. Det innebär att även om ett företag inte har kontor i ett visst land, men är verksamma där, så är företaget skyldiga att följa gällande lagar och regler.

Enligt dessa lagar, som omfattar både offentlig och privat sektor, ska webbplatser vara tillgängliga för användare med funktionsnedsättningar.

  • EU-direktivet 2016/2102 om tillgänglighet avseende myndigheters webbplatser och mobila applikationer trädde i kraft den 26 oktober 2016. Den europeiska tillgänglighetslagen (EEA) som kommer att träda i kraft i EU i juni 2025 syftar till att göra den europeiska marknaden för tillgängliga produkter och tjänster mer funktionell genom att undanröja hinder som beror på skillnader i lagstiftning i olika medlemsländer. Den europeiska lagstiftningen, såväl som EU-direktivet om webbplatsers tillgänglighet, säger att både offentliga och privata webbplatser ska vara tillgängliga för användare med funktionsnedsättningar. I Sverige finns i dagsläget ingen komplett tjänst som kan testa en hel webbplats innehåll mot riktlinjerna för webbtillgänglighet WCAG. Vissa saker måste testas manuellt, andra kan testas med hjälp av automatiska verktyg. Digg, myndigheten för digital förvaltning, erbjuder relevant information om tillgänglighetstestning i en svensk kontext. På deras webbplats finns också Diggs tillsynsmanual för granskning av webbsidor.
  • I USA gäller Americans with Disabilities Act (ADA).
  • Kanadas Accessibility for Ontarians with Disabilities Act (AODA) säger att alla offentliga webbplatser ska uppfylla de flesta framgångskriterierna i WCAG Nivå AA.
  • I Australien finns Disability Discrimination Act (DDA), som i mycket liknar amerikanska ADA. WCAG Nivå AA gäller som rimlig ambitionsnivå för efterlevnad.
  • Sydkoreas Disability Protection Act kräver efterlevnad med Korean Web Content Accessibility Guidelines, som är närmast identiska med framgångskriterierna i WCAG 2.0 Nivå AA.

Denna lista är inte komplett. Samtidigt som dessa lager (och de sanktioner som avvikelser kan medföra) skiljer sig länder emellan är WCAG ett effektivt ramverk för att förbättra efterlevnad av digital tillgänglighet.

Dessa riktlinjer utgör också ett kraftfullt verktyg som gör det lättare för företag att skapa inkluderande webbinnehåll: tillgängliga webbplatser rankas i allmänhet högre i sökresultat och säkrar att användare med funktionsnedsättningar får en bättre användarupplevelse.

Efterlevnad av WCAG betyder helt enkelt att följa bästa praxis vid design av webbinnehåll och att ta hänsyn till användarupplevelsen hos personer med funktionsnedsättningar.

Därför är digital tillgänglighet bra för affärerna

Som vi förklarade ovan är digital tillgänglighet ett lagkrav. Men det är långt ifrån det enda skälet till att göra webbplatsen, produkten eller tjänsten tillgänglig för så många som möjligt.

Ju mer tillgänglig webbplatsen är, desto större räckvidd!

Om även personer med funktionsnedsättningar kan ta del av webbplatsens innehåll blir den potentiella målgruppen större.

Att säkra att webbplatsen uppfyller WCAG:s framgångskriterier är helt enkelt ett effektivt sätt att nå ut till fler. För socialt ansvarstagande företag kommer det naturligt att sträva efter att erbjuda tillgänglighet. Inte minst eftersom även personer utan funktionsnedsättningar gynnas av förbättrad tillgänglighet.

En tillgänglig webbplats ger nöjda användare.

WCAG 101: De fyra grundläggande principerna för tillgänglighet

Nu när vi rett ut varför WCAG är viktigt är det dags att tala om hur det fungerar. Vid en första anblick kan WCAG verka överväldigande – men ramverket består av fyra övergripande principer som var och en bryts ner i mindre riktlinjer som är lätta att förstå. Genom att studera dem i tur och ordning blir det genast mer begripligt och lättare att göra förbättringar löpande.

Vid en första anblick kan WCAG verka överväldigande – men ramverket består av fyra övergripande principer som var och en bryts ner i mindre riktlinjer som är lätta att förstå.

Funktionsnedsättningar kan vara av olika slag och påverka människors förmågor i varierande grad. Vissa personer med synnedsättningar använder ett skärmläsningsprogram medan andra använder sig av digitala förstoringsglas. Personer med neurokognitiva nedsättningar ändrar ofta webbläsarens inställningar så att innehåll visas med ett specifikt typsnitt, medan personer med fysiska nedsättningar ofta föredrar att enbart använda sig av tangentbordet för att navigera på skärmen.

Variationen inom funktionsnedsättningar är enorm. Så hur kan en samling standarder förbättra användarupplevelsen för alla användare med funktionsnedsättningar?

WCAG:s framgångskriterier bygger på fyra grundläggande principer som tillsammans utgör en stabil grund för tillgänglig webbdesign. Genom att följa dessa principer under byggandet av en webbplats (eller app, eller annan digital produkt) blir innehållet bättre.

Dessa tillgänglighetsprinciper bör införlivas i projektet från start. De är grundläggande för att kunna förstå och tillämpa WCAG:s rekommendationer. Genom att följa dessa principer blir det lättare att bygga en hållbar strategi.

De fyra principerna: Innehåll ska vara Möjligt att uppfatta, Hanterbart, Begripligt och Robust. Nedan följer WCAG:s definition av varje princip och vår tolkning.

Schematisk bild av de fyra principerna för tillgänglighet. De beskrivs en i taget i denna bloggtext, efter denna bild.

1. Möjlig att uppfatta

”Information och komponenter i ett användargränssnitt måste presenteras för användare på sätt som de kan uppfatta.”

Det betyder att innehållet ska presenteras på flera sätt. Till exempel, om webbplatsen innehåller en video utan text eller ljudbeskrivning är den inte möjlig att uppfatta för personer med synnedsättning.

2. Hanterbar

”Komponenter i ett användargränssnitt och navigering måste vara hanterbara.”

Användarna måste kunna använda webbplatsen oavsett vilken metod de använder. Till exempel är det inte ovanligt att personer helt väljer bort musen och istället använder sig enbart av tangentbordet för att surfa på internet.

Om webbplatsen inte är tillgänglig för tangentbordsanvändare är den inte hanterbar för dem. Navigering på en sådan webbplats är helt enkelt omöjlig för dem. För exempel på hanterbar navigering via tangentbord, ta en titt i vår guide för tillgänglighet via tangentbord för ReadSpeakers verktyg webReader.

3. Begriplig

”Information och hantering av användargränssnitt måste vara begriplig.”

Låt oss säga att webbplatsen är tillgänglig med tangentbordsnavigering, men på grund av lite väl snitsig JavaScript måste användare trycka på Enter istället för Tab för att skrolla neråt på sidan.

Det gynnar inte tillgänglighet eftersom det inte är vad användarna förväntar sig. Om det inte finns tydliga användarinstruktioner är det svårt att veta hur man ska navigera. I bästa fall blir användarna bara frustrerade, men i värsta fall får de inte tillbaka kontrollen över sin dator förrän de gissat sig till rätt kommando.

4. Robust

”Innehåll måste vara robust nog för att kunna tolkas på ett pålitligt sätt av ett brett spektrum av olika användarprogram, inklusive hjälpmedel.”

Digitala hjälpmedel (Assistive Technologies AT) kan vara hårdvaror eller programvaror som gör det möjligt för personer med funktionsnedsättningar att använda internet mer effektivt. Ett exempel är skärmläsarprogram som konverterar text till mänskligt tal med tekniken text-till-tal (TTS), men det finns en uppsjö digitala hjälpmedel för olika användarbehov.

Innehåll räknas som robust om det bygger på korrekt kod och märkning (markup). Till exempel, om webbplatsen använder semantisk HTML och WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) for en komplex webbplats med JavaScript så förbättras användarupplevelsen för personer som använder skärmläsningsprogram. Det ökar också chansen att webbplatsen fungerar bra också för personer som använder sig av andra typer av digitala hjälpmedel – inklusive tekniker som ännu inte är allmänt tillgängliga.

Hur man tillämpar WCAG på webbplatser och i appar

Bäst blir det om man läser och tar till sig WCAG:s riktlinjer redan från början. Om man börjar fundera på frågan om tillgänglighet först när det är dags att gå live är risken stor att det blir mer tidsödande (och dyrare). Men, för webbplatser som redan ligger uppe går det att göra tillgänglighetsförbättningar, med några enkla steg – och så finns det ett misstag som man bör undvika.

Förbättra webbplatsens tillgänglighet i 3 steg (och undvik 1 misstag)

När man börjar läsa på om webbtillgänglighet brukar företag som erbjuder tillägg i form plugins med multipla tillgänglighetslösningar dyka upp ganska snart. Sådana tillägg går under namnet ”accessibility overlays”. När företag av den typen utlovar att lösa alla tillgänglighetsproblem i ett svep bör man dra öronen åt sig.

Tillgänglighet är något som bäst uppnås med en väl genomtänkt design, inte genom att betraktas som ett ”problem” som kan fixas med en enkel lösning. Vissa accessibility overlays kan till och med störa skärmläsningsprogram och andra digitala hjälpmedel. Och då blir det ju effekten den motsatta: klart försämrad tillgänglighet.

Istället för att leta efter en quickfix som löser allt på ett bräde bör man söka specifika lösningar för varje tillgänglighetsbrist. Här kommer en process i tre steg för hur man kan gå tillväga för webbtillgänglighet.

Steg 1 Inventera webbplatsen

Det är lättare att identifiera tillgänglighetsbrister om man utgår från en detaljerad beskrivning av webbplatsen: samtliga sidor, gränssnittets funktioner och digitala resurser. Genom att inventera webbplatsen blir det lättare att organisera arbetet med att öka tillgängligheten.

Steg 2 Testa webbplatsens tillgänglighet mot WCAG.

Att regelbundet testa webbplatsen mot WCAG:s riktlinjer är det bästa sättet att hålla koll på webbplatsens tillgänglighet. En blandning av automatiska och manuella tester är mest effektivt. Ta en titt på Testa innehåll för att överensstämmelse med WCAG för mer detaljer.

Steg 3 Addera funktioner som kompenserar tillgänglighetsbrister.

Genom att testa webbplatsen blir det uppenbart var det finns tillgänglighetsbrister. Det finns flera olika sätt att fixa dessa problem (och många potentiella problem som behöver lösas). Ett sätt är att bädda in ett frivilligt text-till-tal-verktyg (TTS). Man kan också lägga till funktioner till webbplatsen, som förstoring av text, fokus/nedtoning, eller TTS med simultan markering av texten. Eller manuella lösningar, som att till exempel skriva tydliga alternativtexter för alla bilder.

Som nämnts ovan består alla WCAG:s framgångskriterier av enkla påståenden som är sanna eller falska. Vi ska nu titta närmare på några av dessa framgångskriterier, och vanliga misstag som gör att de inte uppfylls.

Schematisk och textrik bild som visar definitionerna för WCAG framgångskriterier. De beskrivs en i taget i denna bloggtext, efter denna bild.

WCAG 2.1 Framgångskriterium 1.1.1: Innehåll som inte är text

”Allt innehåll som inte är text, som presenteras för användaren har ett textalternativ med samma syfte.”

Det allra första framgångskriteriet kräver en alternativtext för allt innehåll som inte är text, med några få undantag. Detta är särskilt viktigt för bilder. Varje bild måste ha en alternativtext (så kallad ”alt text” eller ”image alt tags”) som beskriver bildens syfte och funktion.

Avsaknad av alternativtext åberopas ofta i stämningar, exempelvis Robles v. Domino’s Pizza LLC, som blev avgörande för att fastställa att Americans with Disabilities Act (ADA) också gäller för digitalt innehåll.

För att uppfylla detta kriterium räcker det att inkludera alternativtext för bilder, grafer, animationer och andra typer av visuellt innehåll.

WCAG 2.1 Framgångskriterium 1.4.3: Kontrast (minimum)

“Den visuella presentationen av text och text i form av bild har ett kontrastvärde på minst 4,5:1 […]Text i stor stil och bilder av text i stor stil har ett kontrastvärde på minst 3:1.”

Kontrastvärde är skillnaden i den relativa ljusstyrkan mellan text och bakgrund. Text med låg kontrast kan vara svårläst för vissa användare, särskilt för färgblinda eller personer med andra typer av synnedsättningar.

Färgblindhet av olika grad är vanligt förekommande i befolkningen – men något som är enkelt att ta hänsyn till. Webbdesigners kan testa kontrastvärdet för alla färgkombinationer med gratis onlineverktyg som exempelvis the a11y® Color Contrast Accessibility Validator.

WCAG 2.1 Framgångskriterium 1.3.1: Information och relationer

“Information, struktur, och relationer som förmedlas genom presentation kan bli automatiskt tydliggjord eller finnas som text.”

Automatiskt tydliggjord betyder att informationen är tillgänglig för programvara. Till exempel, för ett webbformulär med obligatoriska fält måste det framgå för användarna att dessa fält är obligatoriska. Om användaren inte kan skicka in formuläret för att något eller några av de obligatoriska fälten inte är ifyllda måste programvaran kunna informera användaren om vari problemet ligger. För visuella användare fungerar det att rödmarkera fältet, men för personer med synnedsättningar behövs något annat. Det finns ett enkelt sätt att lösa detta: Markera obligatoriska fält med en asterisk och inkludera ”obligatoriska fält är märkta med en asterisk” i instruktionerna för formuläret.

WCAG 2.1 Framgångskriterium 2.4.4: Syftet med en länk (i sammanhanget)

“Syftet med varje länk framgår av länktexten i sig själv eller av länktexten tillsammans med sitt automatiskt tydliggjorda länksammanhang, utom då syftet med länken skulle vara tvetydigt för användare i allmänhet.”

Enkelt uttryckt betyder det att användarna, genom att se länken – eller lyssna på texten via ett skärmläsarprogram – ska kunna förstå dess syfte. Om länktexten består av ”klicka här” eller ”läs mer” får inte användaren tillräckligt med information. Länktexter bör vara beskrivande: Om man istället för ”läs mer” skriver ”läs mer om X, Y eller Z”. Om länktexten går till en artikel om AI i skolan kan länktexten helt enkelt vara ”AI i skolan”. På så vis har användarna den information som behövs för att avgöra om de vill klicka på länken eller inte.

WCAG 2.1 Framgångskriterium 1.2.2: Textbeskrivningar (Färdiginspelade)

“Det finns textbeskrivningar till allt förinspelat ljud innehåll i synkroniserad media, utom när mediet är ett mediealternativ till text och tydligt är märkt som sådant.”

Detta kriterium gäller i allmänhet multimedia – video, presentationer och annat innehåll som kombinerar ljud och bild.

Med textbeskrivningar kan användarna förstå innehållet, även om de inte kan lyssna på ljudet (eller väljer att inte aktivera ljudet). Genom att erbjuda textbeskrivning ökar webbplatsens räckvidd: En Facebookstudie visar att videoannonser med textbeskrivning ökar visningstiden med i snitt 12 %.

Detta är bara några exempel av de närmare 80 framgångskriterierna i WCAG version 2.1. (Vi ska berätta mer om de olika versionerna av WCAG i nästa stycke.) Men vilket framgångskriterium det än gäller så är det samma sak som gäller för efterlevnad: att tillgängligheten testas.

Testa tillgängligheten för efterlevnad av WCAG

Om en webbplats frivilligt följer WCAG:s riktlinjer på nivå A och AA betraktas den som tillgänglig för de allra flesta. För att vara säker på att webbplatsens innehåll kan betraktas som tillgängligt behöver den testas mot riktlinjerna, och det regelbundet.

För att vara säker på att webbplatsens innehåll kan betraktas som tillgängligt behöver den testas mot riktlinjerna, och det regelbundet.

Vid varje version av WCAG tillkommer nya framgångskriterier och W3C rekommenderar att testa innehållet mot de senaste officiella rekommendationerna för optimal tillgänglighet.

Så vilken version av WCAG bör man sikta på? Det beror förstås dels på när du läser detta. När denna text publiceras, i början av 2024, är det WCAG 2.1 som gäller. Det är först när EU-kommissionen beslutar om en ny version av EN-standarden, som bygger på WCAG 2.2, som Digg, svenska myndigheten för digital förvaltning, kommer att ändra sin tillsyn. Varje version av WCAG 2 är bakåtkompatibel. Det betyder att WCAG 2.2 innehåller alla framgångskriterier som finns i WCAG 2.1.

Samtidigt befinner sig WCAG 3.0 i skisstadiet i skrivande stund, med ett okänt publiceringsdatum men som antagligen ligger ”år” framåt. WCAG 3 kommer att införa en ny bedömningsskala, så den kommer inte att vara bakåtkompatibel med WCAG 2.

Två sätt att testa efterlevnad av WCAG

WCAG 2.1 innehåller totalt 78 framgångskriterier och WCAG 2.2 förväntas presentera ytterligare 9 nya framgångskriterier. Hur är det möjligt att testa webbplatsens innehåll mot tiotals kriterier?

De flesta tillgänglighetsexperter rekommenderar att kombinera två tekniker:

  • Automatisk testning med AI-baserade verktyg för vissa tillgänglighetsbrister Automatiska tester är snabbt och billigt men går inte lika djupt som manuella tester.
  • Manuell testning som utförs av utbildade tillgänglighetsexperter. Manuella tester bör helst utföras av personer som själva har funktionsnedsättningar eller som har gedigen erfarenhet av skärmläsningsprogram och andra digitala hjälpmedel.

Automatiska tester är visserligen billiga, men resultatet blir inte perfekt: För vissa framgångskriterier krävs en mänsklig bedömning. Till exempel kan ett AI-baserat verktyg avgöra om bilder har alternativtext – men de kan inte avgöra om alternativtexten faktiskt beskriver bilden.

Automatiska tester är visserligen billiga, men resultatet blir inte perfekt: För vissa framgångskriterier krävs en mänsklig bedömning.

Genom att kombinera manuell och automatisk testning är det möjligt att gå igenom hela webbplatsens innehåll utan att kostnaderna skenar iväg. Nedan delar vi med oss av några tips som kan komma väl till pass när det är dags att testa webbplatsens innehåll.

  • Undvik att en enda person eller ett enda arbetslag utför all testning mot WCAG. Det är inte ett hållbart tillvägagångssätt: om denna person av någon anledning lämnar företaget går all kunskap förlorad.
  • Säkra att alla förstår syftet och målet med tillgänglighet. Varje person i arbetslaget kan ha en uppgift: Webbdesigner väljer lämpliga färgkombinationer, webbutvecklare skriver ren och AI-vänlig kod, och innehållsskapare använder sig av undertitlar och listor (som denna) för att göra innehållet läsbart.
  • Testa regelbundet. Testa på ett tidigt stadium, från allra första början.
  • Publicera ett tillgänglighetsintyg som beskriver de steg som tagits och de långsiktiga målen. Inkludera kontaktuppgifter och lyssna på all feedback som kommer från användarna.

Det är alltid en god idé att vara transparent med sitt tillgänglighetsarbete. Om en tredjepart involveras för tester, publicera dessa resultat. Som ett exempel, här är ReadSpeakers senaste ReadSpeaker’s senaste granskning av tillgänglighet från konsulterna ILUNION Accesibilidad S.A.

Och här är ytterligare ett exempel: Här är det senaste Uttalandet om Tillgänglighet för ReadSpeakers webReader TTS-lösning.

När ett företag vill erbjuda produkter eller tjänster till federala myndigheter i USA måste en så kallad VPAT®, Voluntary Product Accessibility Template, uppvisas. Det är ett dokument som visar överensstämmelse med tillgänglighetstillägget Section 508. Nyfiken på hur det ser ut? Här är VPAT för webReader.

Det första steget för att lösa ett tillgänglighetsproblem: förstå syftet

När ett företag eller organisation testar sitt innehåll mot WCAG händer det att ett stort antal tillgänglighetsproblem identifieras och behöver fixas innan webbplatsen, appen, eller vilken digital produkt det må vara, kan gå live.

Men det kan också hända att helt nya tillgänglighetshinder uppstår som en konsekvens av att sådana problem fixas. Kanske behövs alternativtext läggas till för bilder, och om beskrivningarna då inte är korrekta – eller för långa – så förbättras ju inte tillgängligheten.

WCAG ger råd och tips om hur man bäst tar sig an varje framgångskriterium, som man kan läsa i WCAG 2.1 Understanding documentation. Genom att läsa på och metodiskt ta sig an varje problem blir det lättare att förstå syftet bakom varje kriterium.

Innan man börjar fundera på den tekniska lösningen för ett visst tillgänglighetshinder är det bra att först ställa sig några frågor:

  • Varför är detta ett problem?
  • Hur påverkar det användarna?
  • Vilket är det bästa sättet att lösa detta problem?
  • Hur kommer resten av innehållet att påverkas av att detta problem blir löst?

WCAG är som mest effektivt när digital tillgänglighet blir en verklig prioritering. Genom att ställa sig frågor som dessa blir det lättare att förstå kriteriernas bakomliggande syfte (och därmed undvika att behöva lösa liknande problem om och om igen).

Därför är WCAG mer än en enkel checklista

Det stämmer att överensstämmelse med WCAG Nivå A/AA ger ökad efterlevnad av digital tillgänglighet. Men, målet med digital tillgänglighet är att erbjuda den bästa möjliga upplevelsen för alla, inte att checka av punkter på en lista. För att skapa innehåll som är tillgängligt för alla på riktigt måste tillgänglighetsarbetet ständigt vara i fokus, och vara en självklar del i alla beslut som tas. Det är ett stort åtagande.

Varför göra mer än det strikt nödvändiga? För det första så är tillgänglighet något som gynnar alla användare – inklusive personer som inte har någon funktionsnedsättning. Om och om igen har vi kunnat se hur hjälpmedelstekniska lösningar kommit att betraktas som  standard av alla typer av användare.

Tillgänglighet gynnar alla användare – inklusive personer utan funktionsnedsättningar.

Till exempel så utvecklades högkontrastlägen (”dark modes”) ursprungligen som stöd för färgblinda användare, men de blev snabbt populära bland gemene man, eftersom många helt enkelt föredrar den mörkare estetiken. Undertextning utvecklades för personer med hörselnedsättningar, men många – inklusive 70 % av Gen Z – föredrar helt enkelt att titta på videoinnehåll med undertext. En annan studie visar att bara 5 % av universitetsstudenter använder digitala hjälpmedel på grund av funktionsnedsättningar, men att 18 % samtidigt betraktar sådana hjälpmedel som ”nödvändiga”.

Text-till-tal (TTS) är kanske det bästa exemplet på förbättrad digital tillgänglighet som verkligen påverkat hur vi alla konsumerar innehåll online. Tidiga TTS-system utvecklades för att också personer med synnedsättningar skulle kunna ta del av textinnehåll, men idag är TTS en självklarhet i våra digitala landskap. Om du någon gång pratat med Alexa, Siri eller någon annan röstassistent så har du redan använt TTS. Skärmläsningsprogram bygger på TTS och feedback från användare med funktionsnedsättningar har varit till stor hjälp för att utveckla verklighetstrogna TTS-röster.

TTS som följer WCAG – såhär kan det se ut: ReadSpeaker och Library of Congress

På amerikanska Library of Congress offentliga webbplats, congress.gov, finns en ReadSpeaker TTS plug-insom omvandlar text till tal på användarens kommando. Själva verktyget överensstämmer med WCAG 2.1 AA — och TTS bidrar förstås till att hela webbplatsen överensstämmer med WCAG.

Detta TTS-verktyg är ett tillval som inte stör skärmläsningsprogram. Användaren behöver bara klicka på Lyssna-knappen, eller öppna en rullgardinsmeny med hjälpfunktioner (förstorad text, ladda ned mp3, med mera). Det är ett exempel på ett TTS-verktyg som erbjuder extra funktioner för den som vill, utan att störa personer som redan använder andra hjälpmedel.

Samarbetet mellan Library of Congress och ReadSpeaker visar på värdet i flexibla TTS-verktyg för att förbättra överensstämmelse med WCAG – och den tillgänglighet som blir resultatet av sådan efterlevnad.

Vi på ReadSpeaker vill erbjuda TTS-teknik för alla. Det betyder att vi ständigt är på jakt efter nya sätt att skapa engagerande upplevelser online.

Vi vet också att digital tillgänglighet sträcker sig längre än till WCAG. När organisationer betraktar tillgänglighet som ett kärnvärde och strävar efter att öka tillgängligheten för sitt innehåll, då förbättras användarupplevelsen – och det gynnar organisationen. Människor är mer benägna att uppskatta varumärken med starka värderingar, och investering i tillgänglighet ger därför mycket hög avkastning över tid. För ett företag eller organisation som bestämt sig för att satsa på tillgänglighet kan ReadSpeakers TTS vara precis vad som behövs för att ta nästa steg.

Related articles
Börja använda text till tal idag

Gör era produkter mera tillgängliga med våra text-till-tal-lösningar.

Kontakta oss