WCAG: guide till tillgänglighet för svenska företag

WCAG är de riktlinjer som avgör om era webbplatser, kundportaler och digitala verktyg går att använda för alla – inte bara för dem som ser, hör och klickar med mus. Den som navigerar med tangentbord, använder skärmläsare eller förstorar texten ska kunna göra samma sak som alla andra: hitta, förstå och slutföra.

För en byrå är tillgänglighet två saker samtidigt. Det är ett krav som ofta står i kundernas förfrågningar och avtal. Det är också ett mått på kvaliteten i det ni levererar.

I den här guiden går vi igenom vad WCAG är, vad WCAG AA kräver i praktiken, när kraven gäller er och hur vi själva arbetar med tillgänglighet när vi bygger system och AI-widgets.

Vad är WCAG?#

WCAG (Web Content Accessibility Guidelines) är internationella riktlinjer för hur digitalt innehåll görs tillgängligt för personer med olika funktionsvariationer. Det gäller till exempel personer som är blinda eller har nedsatt syn, som är döva eller hörselskadade, som har motoriska begränsningar eller som har kognitiva svårigheter. Riktlinjerna beskriver vad som krävs för att innehållet ska fungera för dem, oavsett vilket hjälpmedel de använder.

Vem står bakom WCAG?

WCAG tas fram av W3C, organisationen som utvecklar standarder för webben, inom deras Web Accessibility Initiative (WAI). Arbetet sker öppet och i samråd med företag, myndigheter, forskare och användarorganisationer. Därför fungerar WCAG som en gemensam referens. När lagkrav och upphandlingar talar om tillgänglighet är det i regel WCAG de hänvisar till, i stället för att formulera egna tekniska krav.

Vilka versioner finns?

Den WCAG som används i dag är version 2, som finns i tre utgåvor: 2.0, 2.1 och 2.2. Varje ny utgåva bygger vidare på den förra och lägger till kriterier, bland annat för mobila enheter, synnedsättning och kognitiva behov. Versionerna är bakåtkompatibla. Det innebär att innehåll som uppfyller WCAG 2.2 också uppfyller 2.1 och 2.0. W3C rekommenderar att man utgår från den senaste versionen. Det gör det enklare att ställa krav, eftersom en nyare version aldrig sänker ribban.

Gäller WCAG bara webbsidor?

Nej. Trots namnet omfattar WCAG i praktiken allt digitalt innehåll som människor ska kunna använda. Det gäller formulär och inloggningar, dokument som PDF:er, mobilappar, kundportaler och interaktiva verktyg som chattar, bokningsflöden och widgets. Ett kontaktformulär som inte går att fylla i med tangentbord är ett lika stort hinder som en sida utan rubriker.

För er som beställer eller levererar AI-lösningar är just den punkten viktig. En AI-chatt på en kunds webbplats är innehåll i WCAG:s mening och ska bedömas på samma sätt som resten av sajten. Förklaringar av AI-begreppen kring sådana lösningar finns i vår ordlista med AI-begrepp för beslutsfattare.

Hur är WCAG uppbyggt? De fyra principerna#

WCAG vilar på fyra principer: innehållet ska vara möjligt att uppfatta, hanterbart, begripligt och robust. Alla krav i riktlinjerna går att föra tillbaka till någon av dem. Tillsammans beskriver de vad som måste fungera för att en användare ska kunna ta del av innehållet, oavsett om hen ser skärmen, lyssnar via skärmläsare eller styr med tangentbord.

I vardagen betyder principerna följande:

• Möjlig att uppfatta. Informationen måste nå användaren genom minst ett sinne. Bilder behöver alt-texter som beskriver vad de visar, filmer behöver undertexter och text behöver tillräcklig kontrast mot bakgrunden för att vara läsbar för den som ser dåligt.
• Hanterbar. Allt som går att göra med mus ska också gå att göra med tangentbord. Användaren ska kunna tabba sig igenom menyer, knappar och formulär i logisk ordning, se var fokus ligger och få tillräckligt med tid att slutföra.
• Begriplig. Innehåll och funktioner ska gå att förstå och bete sig förutsägbart. Felmeddelandet "Ange e-postadressen i formatet namn@foretag.se" hjälper användaren vidare. Ett rödmarkerat fält utan förklaring gör det inte.
• Robust. Koden ska vara så välbyggd att olika webbläsare och hjälpmedel kan tolka den korrekt, både nu och när tekniken utvecklas. En knapp som är kodad som knapp läses upp som knapp av skärmläsaren. En klickbar ruta utan rätt märkning blir osynlig för den som inte ser.

Från princip till testbart kriterium

Principerna är för övergripande för att granska mot direkt, så de bryts ner i två led. Varje princip delas upp i riktlinjer, och varje riktlinje i framgångskriterier. Kriterierna är formulerade så att de går att testa: antingen är de uppfyllda eller inte. Varje kriterium har också en nivå – A, AA eller AAA – som vi går igenom i nästa avsnitt.

Det är framgångskriterierna man granskar mot i en tillgänglighetsgranskning. Det är också dem lagkrav och avtal i praktiken syftar på när de hänvisar till WCAG.

Varför strukturen gör WCAG hanterbart för er

Ni behöver inte kunna koda för att styra tillgänglighetsarbetet. Strukturen gör att ni kan fråga efter kriterier i stället för att nöja er med en känsla av att lösningen "verkar fungera".

I praktiken blir frågorna konkreta. Vilka kriterier är testade? Hur testades de? Vilka är inte uppfyllda, och vad är planen för dem? Svaren går att jämföra mellan leverantörer, följa upp över tid och skriva in i avtal. Det flyttar tillgänglighet från en diskussion om tycke och smak till något ni kan kräva, mäta och ta ansvar för.

Vad innebär WCAG AA – och varför är det nivån som räknas?#

WCAG AA är den mellersta av WCAG:s tre nivåer – A, AA och AAA – och det är den nivå som i praktiken efterfrågas när lagkrav, upphandlingar och kundavtal ställer krav på tillgänglighet. Nivåerna bygger på varandra. För att uppfylla AA måste en lösning klara alla framgångskriterier på både nivå A och nivå AA. När en kravspecifikation bara säger "WCAG" är det därför i regel AA som avses, även om det inte står utskrivet.

Vad skiljer nivåerna åt?

• Nivå A är grundkraven. Om de inte uppfylls blir innehållet omöjligt att använda för vissa grupper. Exempel är bilder utan textalternativ och funktioner som bara går att nå med mus.
• Nivå AA tar bort de vanligaste och mest betydande hindren. Här finns många av de krav som påverkar flest användare i vardagen.
• Nivå AAA är den högsta nivån. W3C rekommenderar inte AAA som generellt krav för hela webbplatser, eftersom vissa kriterier inte går att uppfylla för allt innehåll. Enskilda AAA-kriterier kan ändå vara motiverade för specifika tjänster eller målgrupper.

AA är alltså ingen kompromiss. Nivån ger hög tillgänglighet och går att uppnå för i stort sett allt innehåll.

Vad kräver AA i praktiken?

Flera AA-kriterier handlar om sådant som syns direkt i designen:

• Tillräcklig kontrast. Text ska ha en fastställd minsta kontrast mot bakgrunden. Detsamma gäller viktiga grafiska element som ramar kring formulärfält och ikoner som bär information.
• Synligt fokus. Den som navigerar med tangentbord ska alltid se var på sidan fokus ligger. I WCAG 2.2 får fokus dessutom inte döljas av andra element, till exempel en fast cookiebanner eller en chattwidget.
• Fungerar vid förstoring. Text ska gå att förstora utan att innehåll försvinner, överlappar eller blir oanvändbart. Layouten ska anpassa sig till smala skärmar och inzoomat läge.

Till det kommer krav på sådant som konsekvent navigering, tydliga etiketter och förslag på hur ett felaktigt ifyllt fält kan rättas.

Vad ni bör kräva av leverantörer

Två saker bör stå i varje förfrågan och avtal.

Den första är en uttalad målnivå, till exempel "WCAG 2.2 nivå AA". Formuleringar som "tillgänglig" eller "följer riktlinjerna" går inte att följa upp.

Den andra är hur nivån verifieras. Be leverantören beskriva vilka kriterier som testas och med vilka metoder, både automatiska verktyg och manuella tester med tangentbord och skärmläsare. Kräv också en dokumentation av avvikelser med en plan för åtgärder. Det ger er ett underlag att granska, jämföra och återkomma till när lösningen förändras.

Gäller WCAG ert företag? Lagkrav och kundkrav#

Det beror på vilka ni är och vilka ni levererar till. Offentlig sektor har lagkrav som bygger på WCAG, vissa privata tjänster omfattas via EU-regler, och för många byråer kommer kraven framför allt genom kundernas avtal. Nedan ger vi en översikt som vägledning. Det är inte juridisk rådgivning, och det exakta läget för er verksamhet bör ni stämma av med jurist eller ansvarig myndighet.

Offentlig sektor: lagen om tillgänglighet till digital offentlig service

Myndigheter, kommuner, regioner och andra offentliga aktörer omfattas av lagen om tillgänglighet till digital offentlig service. Lagen hänvisar till en europeisk standard som i sin tur bygger på WCAG nivå AA. Det gäller webbplatser, e-tjänster, appar och dokument som den offentliga aktören tillhandahåller, även när en extern leverantör har byggt dem.

Privata tjänster: EU:s tillgänglighetsdirektiv

EU:s tillgänglighetsdirektiv utvidgar kraven till vissa privata produkter och tjänster, bland annat e-handel och banktjänster. Vilka verksamheter som omfattas, vilka undantag som finns för mindre företag och hur kraven ska uppfyllas avgörs av den svenska lagstiftning som genomför direktivet. Kontrollera därför vad som gäller för just er och för de kunder ni bygger åt, i stället för att utgå från att ni står utanför.

För byråer: kraven kommer via kunderna

Även om ingen lag riktar sig direkt mot er byrå, gör era kunders krav det i praktiken. Kunder med offentliga uppdrag måste föra kraven vidare till sina leverantörer. Privata kunder som själva omfattas av regler eller som har egna policyer för tillgänglighet gör detsamma. Resultatet är att WCAG AA ofta står i förfrågningar, kravspecifikationer och avtal – ibland som ett skall-krav som avgör om ni ens får lämna anbud.

Tillgänglighet hör därför till samma kategori som frågan om var er AI-data lagras och vem som kontrollerar den. Det är ett krav som avgör affärer. Den som kan visa hur kravet uppfylls har ett försprång.

Varför är tillgänglighet affärsnytta och inte bara compliance?#

Tillgänglighet är affärsnytta eftersom fler kan använda tjänsten, upplevelsen blir bättre för alla och lösningen blir billigare att förvalta. Lagkraven sätter golvet, men värdet märks i det dagliga arbetet.

Fler kan bli kunder

En tjänst som inte går att använda tappar affärer i tysthet. Den som inte kan slutföra en bokning med tangentbord eller inte kan läsa ett ljusgrått formulärfält hör sällan av sig för att klaga. Hen går till en konkurrent. Ni ser det inte i någon rapport, bara i affärer som aldrig blev av. För en byrå gäller det i ett led till, eftersom det är era kunders kunder som når eller inte når fram.

Det som hjälper några hjälper alla

Krav som tar sikte på funktionsvariationer förbättrar upplevelsen för alla användare:

• Klarspråk hjälper den som läser på sitt andraspråk.
• God kontrast hjälper den som använder mobilen i solljus.
• Tydlig struktur och begripliga felmeddelanden hjälper den som ska lösa något på två minuter mellan två möten.

Tillgänglighet är i praktiken användbarhet med testbara kriterier.

Bättre kod som är lättare att hitta

Tillgänglig kod är ofta bättre kod. Korrekta rubriker, riktiga knappar och märkta formulärfält gör strukturen tydlig för skärmläsare. De gör den också tydlig för utvecklare som ska underhålla lösningen och för sökmotorer och AI-sök som ska tolka innehållet. Samma semantik som gör en sida begriplig för hjälpmedel gör den lättare att indexera och citera.

Billigare att göra rätt från början

Det kostar mindre att bygga in tillgänglighet från start än att åtgärda den i efterhand. När kontrast, fokus och tangentbordsstöd finns i designsystemet följer de med i varje ny sida och komponent. Läggs de på i slutet måste färger, komponenter och flöden göras om. Det sker ofta efter lansering och ibland under tidspress inför en upphandling.

Behandla därför tillgänglighet som vilken investering som helst: sätt ett mål och följ upp det. Samma resonemang som ligger bakom att AI som inte mäts bara är en förhoppning gäller här. Det som har tydliga kriterier går att styra mot.

Hur tänker vi kring WCAG när vi bygger system och AI-widgets?#

Vi behandlar tillgänglighet som en del av själva lösningen, inte som ett tillägg. En AI-lösning som bara vissa kan använda löser bara en del av problemet, och det är sällan den delen kunden egentligen betalar för.

Utgångspunkten: hela problemet, för alla användare

Vår tes är att problemet sällan är unikt, men att lösningen är det. När vi bygger skräddarsydd AI utifrån ert eget problem räknar vi in alla som ska använda den. Det gäller besökaren som navigerar med tangentbord, medarbetaren som använder skärmläsare och kunden som zoomar in på mobilen. Om någon av dem inte kommer fram finns flaskhalsen kvar, den har bara flyttat.

Med från kartläggningen, inte i slutet

Tillgänglighet finns med i varje steg av vår metod med kartläggning, körbar prototyp och löpande drift. I kartläggningen frågar vi vilka som ska använda lösningen, vilka krav som står i kundens avtal och vilken WCAG-nivå som gäller, i regel AA. I prototypen testar vi med tangentbord och skärmläsare medan flödena fortfarande är enkla att ändra. I driften följer vi upp när innehåll, design eller AI-svar förändras.

Så ser det ut i en AI-widget

En chattwidget är krävande ur tillgänglighetssynpunkt. Innehållet ändras hela tiden, widgeten ligger ovanpå resten av sidan och den ska fungera på kundens webbplats, inte på vår. I våra AI-widgets för kundens webbplats arbetar vi därför särskilt med fyra saker:

• Tangentbordsstyrning. Widgeten ska gå att öppna, använda och stänga utan mus. Fokus ska hamna rätt när den öppnas och återgå när den stängs, och widgeten får inte dölja fokus på sidan bakom.
• Skärmläsarstöd för chattflöden. Nya svar ska meddelas till skärmläsaren utan att användaren tappar sin plats i samtalet. Knappar och fält ska ha begripliga namn.
• Kontrast som håller i kundens grafiska profil. Färgerna ska kännas som kundens egna, men text, knappar och fokusmarkering ska klara kontrastkraven på AA-nivå.
• Klarspråk i AI-svaren. Vi instruerar AI:n att svara kort, konkret och utan onödig jargong. Det är WCAG:s princip om begriplighet tillämpad på genererad text.

Varumärke och verifiering i balans

Ibland krockar tillgänglighet med en grafisk profil. Oftast gäller det en ljus accentfärg som inte klarar kontrastkraven. Då föreslår vi en justerad nyans, eller att färgen används där den inte bär text, i stället för att tumma på kravet. Beslutet fattar vi tillsammans med kunden, med kriteriet på bordet.

Vi är också tydliga med var gränsen går för vad som kan verifieras. Struktur, kontrast och tangentbordsflöden går att testa mot framgångskriterierna. AI-genererade svar varierar däremot och kan inte kontrolleras ett och ett i förväg. Där arbetar vi med instruktioner, stickprov och löpande uppföljning. Det säger vi rakt ut, i stället för att lova mer än vi kan visa.

Så kommer ni igång med WCAG – fem steg#

Ni kommer igång med WCAG genom att sätta en målnivå, ta reda på var ni står och åtgärda först det som påverkar affären mest. Arbetet går att dela upp i fem steg:

1. Bestäm målnivå och skriv in den. I regel är det WCAG 2.2 nivå AA. Skriv in nivån i era kravspecifikationer, kundavtal och offerter, så att alla vet från start vad som ska levereras.
2. Gör en första genomgång. Börja med automatiska verktyg. De hittar snabbt till exempel saknade alt-texter och låg kontrast. Verktygen fångar bara en del av kriterierna, så komplettera med manuella tester: gå igenom sidorna med enbart tangentbord och lyssna på dem med en skärmläsare.
3. Prioritera flödena som bär affären. Ta kontaktformulär, köp, bokning och kundtjänst först. Ett hinder där kostar mer än ett hinder på en gammal nyhetssida.
4. Ställ samma krav på leverantörer och tredjepartskomponenter. Chattwidgets, bokningsmoduler, cookiebanners och inbäddade formulär räknas som en del av er tjänst. Be om målnivå och testunderlag innan ni köper in eller byter.
5. Följ upp löpande. Nytt innehåll, nya komponenter och ändrad design kan förstöra det som fungerade. Lägg in tillgänglighet i er vanliga kvalitetskontroll och gör återkommande genomgångar, till exempel inför större releaser.

Vill ni gå igenom hur det här ser ut för en AI-lösning hos er eller era kunder kan ni boka ett kostnadsfritt samtal på 30 minuter. Svar om pris, tid till drift och ägande av kod och data finns bland våra vanliga frågor om hur vi arbetar.

Vanliga frågor#

Vad är skillnaden mellan WCAG 2.1 och WCAG 2.2?

WCAG 2.2 bygger på 2.1 och lägger till nya kriterier, bland annat om fokus som inte får döljas, storlek på klickytor och enklare inloggning. Den som uppfyller 2.2 uppfyller därför även 2.1.

Går det att testa WCAG helt automatiskt?

Nej. Automatiska verktyg hittar en del fel, men många kriterier kräver manuell bedömning med tangentbord och skärmläsare.

Räcker ett tillgänglighetsplugin eller overlay för att uppfylla WCAG?

Nej. Ett overlay lägger ett lager ovanpå sidan men rättar inte bristerna i kod och innehåll. Tillgängligheten måste byggas in i själva lösningen.

Vem ansvarar för tillgängligheten – byrån som bygger eller kunden som äger tjänsten?

Kunden som äger tjänsten ansvarar gentemot användare och myndigheter. Byrån ansvarar för att leverera enligt den nivå som står i avtalet, och därför ska nivån stå där. Hur vi hanterar ägande av kod och data beskriver vi i våra vanliga frågor om pris, drift och ägande.

Behöver PDF:er och dokument också följa WCAG?

Ja. Dokument som publiceras digitalt behöver bland annat rubrikstruktur, alt-texter och rätt läsordning.

Hur ofta bör man se över tillgängligheten på en webbplats?

Se över den vid varje större ändring av design, komponenter eller innehåll. Gör dessutom återkommande genomgångar, oftare ju mer som förändras.