Tillgänglighet är inte bara utvecklarens jobb – så publicerar du tillgängligt innehåll

Grunden för det mesta som räknas som digital tillgänglighet idag är WCAG (Web Content Accessibility Guidelines), en internationell standard från The World Wide Web Consortium (W3C). WCAG bygger på fyra principer: innehåll ska vara möjligt att uppfatta, hanterbart, begripligt och robust. I Sverige och EU är detta även lagstadgat – DOS-lagen ställer krav på offentlig sektor sedan 2021, och sedan 2025 omfattar tillgänglighetsdirektivet (European Accessibility Act) stora delar av det privata näringslivet också, från e-handel till bankappar.

Men tillgänglighet är mer än en juridisk formalitet att bocka av. Lagkraven är golvet, inte taket – de sätter en lägstanivå, men en verkligt tillgänglig tjänst utgår från användarnas faktiska behov, inte bara från vad som går att mäta i ett automatiserat test. Och till skillnad från vad många tror är det sällan bara en fråga för utvecklare: en stor del av tillgängligheten avgörs av hur innehåll struktureras, skrivs och publiceras.

Rubriker är struktur, inte stil

Ett vanligt misstag är att använda stor, fetad text istället för en riktig rubrik. Det kan se rätt ut visuellt, men för en skärmläsare eller någon som navigerar med tangentbord finns ingen struktur att hänga upp sig på. Använd istället din editors rubriknivåer (Heading 1–Heading 6) konsekvent:

• Varje sida ska ha exakt en H1 som sammanfattar sidans innehåll.
• Underrubriker ska följa logisk ordning – hoppa aldrig från H2 till H4 bara för att det ser bättre ut.
• Skriv rubriker som beskriver vad som kommer efter, inte vaga etiketter som ”Mer info” eller ”Övrigt”.

Testa gärna själv: läs bara rubrikerna på en sida i följd. Går det att förstå vad sidan handlar om? Om inte behöver rubrikerna ses över.

Länkar ska gå att förstå utan sammanhang

”Klicka här” och ”Läs mer” är klassiska fallgropar. Ett vanligt sätt att navigera med skärmläsare är att ta fram en lista över alla länkar på en sida – och då måste varje länktext bära sin egen mening, till exempel ”Läs mer om fraktvillkor” istället för bara ”Läs mer”.

Länkar bör också gå att urskilja utan att enbart förlita sig på färg, eftersom färgblinda användare annars missar dem helt – en understrykning eller ett annat visuellt kännetecken räcker långt.

Alt-text handlar om syfte, inte beskrivning

En bra alt-text är inte nödvändigtvis en bokstavlig beskrivning av bilden – den ska förmedlar bildens funktion i sitt sammanhang. Fråga dig själv vad bilden faktiskt fyller för syfte:

• Informativ bild: skriv en kort, konkret alt-text (1–2 meningar) som förmedlar samma information som bilden ger seende användare. Hoppa över fraser som ”Bild av …”.
• Dekorativ bild: Behöver ingen alt-text. Lämna tomt så att skärmläsare hoppar över bilden – annars stör det läsflödet i onödan.
• Komplex bild, till exempel ett diagram: en kort sammanfattning i alt-attributet räcker sällan. Erbjud den fullständiga informationen i löpande text i anslutning till bilden.

Samma bild kan behöva helt olika alt-texter beroende på var den används – en bild av en ryggsäck betyder något annat i en produktbeskrivning än i en artikel om hållbart resande.

Färg och kontrast – syns det för alla?

WCAG kräver en kontrast på minst 4,5:1 mellan text och bakgrund, och minst 3:1 för viktiga icke-textelement som ikoner och ramar runt formulärfält. Ett enkelt sätt att kontrollera detta löpande är WebAIM:s Contrast Checker. Kom också ihåg att färg aldrig får vara det enda sättet att förmedla information – ”de gröna raderna är godkända” fungerar inte för den som inte uppfattar färg. Komplettera alltid med exempelvis text eller ikon.

Skriv så att texten går att skumma

Användare läser sällan text på webben ord för ord – de skummar. För personer med lässvårigheter eller kognitiv trötthet är det avgörande att texter är utformade för att underlätta detta:

• Korta stycken med luft emellan, vänsterjusterad text.
• Använd gärna listor, men se till att de är skapade med riktiga list-funktioner i editorn istället för manuella radbrytningar och punkttecken.
• Klarspråk – korta meningar, vardagliga ord, aktiv form. Isof:s klarspråkshjälp är ett bra stöd om du vill finslipa.

Formulär: etiketter, inte platshållare

Platshållartext (den grå texten inuti ett input-fält) försvinner så fort användaren börjar skriva, och kan därför aldrig ersätta en riktig etikett. Se till att varje fält har en synlig etikett kopplad till rätt fält i koden, att obligatoriska fält och förväntat format framgår tydligt, och att felmeddelanden beskrivs i text – inte bara markeras med rött. Långa formulär mår bra av att delas upp i steg, särskilt för användare med kognitiva funktionsnedsättningar.

Vanliga fallgropar att hålla utkik efter

Några återkommande missar i publicerat innehåll: rubriknivåer valda efter utseende snarare än struktur, tomma paragrafer som ersättning för marginal, listor byggda med manuella punkttecken, bilder utan alt-text, och länkar som öppnas i nya flikar utan förvarning. Inget av detta kräver utvecklarkunskap att fixa – bara uppmärksamhet i publiceringsflödet.

Lagkraven är golvet, inte taket

Sedan DOS-lagen trädde i kraft fullt ut 2021 ska offentlig sektors digitala tjänster uppfylla WCAG 2.1 nivå AA, och sedan 2025 omfattar tillgänglighetsdirektivet (EAA) även stora delar av den privata sektorn. Men som vi skrev i början av det här inlägget: lagkraven är golvet, inte taket. Det räcker inte att tekniskt klara ett automatiserat test för att innehållet ska vara verkligt tillgängligt – målet bör alltid vara den faktiska användarupplevelsen.

Vill du testa hur din egen sida ligger till kan verktyg som WAVE, axe DevTools eller Lighthouse ge en snabb första koll av de mer tekniska bitarna. Men de fångar sällan otydliga rubriker eller dålig länktext – det krävs fortfarande ett redaktörsöga för det.