De 5 vanligaste tillgänglighetsproblemen på svenska webbplatser

Innehållsförteckning

Din webbplats ser bra ut. Konverteringen stiger. Marknadsavdelningen är nöjd. Och så får du en granskningsrapport på 80 sidor som säger att din webbplats inte är tillgänglig. Hoppsan.

Goda nyheter: de flesta problem du stöter på är inte komplicerade. De sitter heller inte i ditt CMS eller i din tekniska plattform. Det är saker som saknas, eller som behöver justeras lite.

De fem problem vi på Proper Access hittar oftast löser du med relativt enkla åtgärder. Ingen ombyggnad krävs. Det handlar om justeringar som ger effekt direkt.

Låt oss gå igenom topp 5. Med konkreta exempel, så att du kan börja redan imorgon.

Varför detta är viktigt just nu

Sedan den 28 juni 2025 gäller tillgänglighetslagen (Lag 2023:254) i Sverige. Den ställer krav på i princip alla organisationer som erbjuder digitala produkter eller tjänster till konsumenter. Tänk e-handel, biljettplattformar, banker, försäkringsbolag.

Sanktionsavgiften ligger enligt lagen mellan 10 000 och 10 miljoner kronor. PTS är marknadskontrollmyndighet och prövar kraven sedan den 28 juni 2025; för persontransporttjänster är det Konsumentverket som utövar tillsyn. I sista hand kan en produkt tvingas bort från marknaden.

Och bortom lagen finns kunderna. SCB räknade 2025 till 786 000 personer mellan 16 och 65 år med en funktionsnedsättning, alltså 12 procent. Den siffran är ett golv: räknar du in äldre besökare, tillfälliga skador och nedsatt syn som ingen kallar funktionsnedsättning, blir gruppen betydligt större. Hur mycket större beror helt på hur frågan ställs, och det är därför du ser allt från 10 till över 30 procent i olika källor.

De här besökarna lämnar din webbplats när den inte fungerar med tangentbord, skärmläsare eller förstoringsprogram. Sedan köper de någon annanstans.

1. Saknade eller värdelösa alt-texter på bilder

Problemet

Det här är nummer ett. På riktigt. Nästan varje webbplats vi granskar har problem med detta.

En blind besökare använder en skärmläsare. Den läser upp sidan. Kommer den till en bild utan alt-text? Då säger skärmläsaren: “bild” eller ingenting alls. Jättebra. Väldigt informativt.

Eller ännu värre: ditt CMS genererar automatiskt alt-texter baserat på filnamn. Då får du det här:

<img src="product-123-variant-b-final-FINAL-v2.jpg"
     alt="product-123-variant-b-final-FINAL-v2">

En skärmläsare läser upp det som: “bild product streck etthundratjugotre streck variant streck b streck final streck FINAL streck v två”.

Säg hejdå till din konvertering.

Lösningen

Skriv alt-texter som beskriver bildens funktion eller innehåll. Inte filnamnet. Inte “bild av”. Helt enkelt: vad ser du, eller vad gör den?

<!-- Produktfoto -->
<img src="roda-sneakers.jpg"
     alt="Röda löparskor med vit sula, sidovy">

<!-- Dekorativt element -->
<img src="abstract-pattern.jpg" alt="">

<!-- Call-to-action-knapp som bild (gör inte detta, använd HTML-knappar) -->
<img src="bestall-nu-button.png"
     alt="Beställ nu">

Tre tumregler:

  1. Informativa bilder: Beskriv innehållet kort och koncist. “Diagram som visar 15 % tillväxt” är bättre än “diagram”.

  2. Dekorativa bilder: Använd en tom alt-text (alt=""). Då hoppar skärmläsaren över bilden. Det är vad du vill.

  3. Funktionella bilder: Beskriv handlingen. “Ladda ner PDF” istället för “röd nedladdningsikon”.

Vanligt misstag:

Börja med “bild av” eller “foto av”. Skärmläsaren säger redan att det är en bild. Så detta:

<img src="team.jpg" alt="Foto av vårt team på kontoret">

Läses upp som: “bild foto av vårt team på kontoret”. Dubbelt.

Bättre:

<img src="team.jpg" alt="Vårt team på kontoret">

Bonustips: Har du en komplex bild som en infografik eller diagram? Använd aria-describedby för att hänvisa till en längre beskrivning:

<img src="arsrapport-diagram.jpg"
     alt="Omsättningsutveckling 2020–2024"
     aria-describedby="diagram-beskrivning">

<div id="diagram-beskrivning">
  Diagrammet visar en ökning från 20 miljoner SEK 2020
  till 50 miljoner SEK 2024, med en dipp 2021 på grund av pandemin.
</div>

2. Otillräcklig färgkontrast

Problemet

Grå text på vit bakgrund. Ljusblå länkar. Lila knappar med vit text. Det ser “snyggt” ut enligt din designer, men dina besökare med nedsatt syn, äldre, eller människor i ett starkt upplyst rum? De ser ingenting.

WCAG kräver en minsta kontrast på 4,5:1 för normal text och 3:1 för stor text (18pt och större, eller 14pt fetstil).

Det här är en av de mest ignorerade riktlinjerna, för att det “ändå ser bra ut”. Tills du testar det.

Lösningen

Testa dina färger. Punkt. Det finns gratisverktyg:

  • WebAIM Contrast Checker (webaim.org/resources/contrastchecker)
  • Chrome DevTools (inspektera ett element, se “Contrast ratio” i färgpanelen)
  • Figma-plugin: Stark

Exempel på vanliga fel:

/* Otillräcklig kontrast (2,9:1) */
.text {
  color: #999999;
  background-color: #FFFFFF;
}

/* Tillräcklig kontrast (4,54:1) */
.text {
  color: #767676;
  background-color: #FFFFFF;
}

/* Länk som inte syns (3,2:1) */
a {
  color: #5A9FD4;
}

/* Länk med tillräcklig kontrast (4,52:1) */
a {
  color: #2E75A6;
}

Men jag vill behålla min grafiska profil!

Förståeligt. Du har precis gjort en omprofilering för hundratusentals kronor. Men tillgänglighet betyder inte att allt måste bli fult. Det betyder att du gör smarta designval.

Alternativ:

  1. Använd fetstil för viktiga element. Från 14 pt fetstil räknas texten som stor och då räcker 3:1
  2. Öka textstorleken. Från 18 pt räcker 3:1
  3. Lägg till en subtil ram eller skugga på knappar
  4. Justera bara accentfärgen där det behövs (formulär, länkar, knappar)

Vanlig fälla: placeholders

Placeholders i formulär är ofta ljusgrå. Logiskt, för de försvinner när du skriver. Men besökare med nedsatt syn ser dem inte ens:

/* Oläsbar placeholder */
input::placeholder {
  color: #CCCCCC;
}

/* Läsbar placeholder */
input::placeholder {
  color: #767676;
}

Proffstips: Använd placeholders bara för exempel, inte för viktig information. Den hör hemma i ett <label> eller en hjälptext.

3. Formulär utan labels

Problemet

Ditt formulär ser rent ut. Minimalistiskt. Placeholders berättar vad som ska göras. Tills någon med en skärmläsare kommer förbi.

En skärmläsare ser det här:

<input type="text" placeholder="Fyll i din e-postadress">

Och säger: “inmatningsfält, tomt”. Vilket fält? Ingen aning. Placeholdern är inte kopplad till fältet.

Resultat: din besökare måste gissa vad som ska göras. Stor chans att de ger upp.

Lösningen

Använd alltid ett <label> och koppla det till fältet med for och id:

<!-- Korrekt strukturerat formulär -->
<label for="email">E-postadress</label>
<input type="email" id="email" name="email"
       placeholder="namn@exempel.se">

<label for="password">Lösenord</label>
<input type="password" id="password" name="password">

Nu läser skärmläsaren: “E-postadress, inmatningsfält, namn-snabel a-exempel-punkt-se”. Tydligt.

Men jag tycker labels är fula i min design

Okej. Det finns sätt att dölja labels visuellt men behålla dem tekniskt:

/* Visuellt dold, men skärmläsaren läser det */
.visually-hidden {
  position: absolute;
  width: 1px;
  height: 1px;
  margin: -1px;
  padding: 0;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

<label for="search" class="visually-hidden">Sök</label>
<input type="search" id="search" placeholder="Sök...">

Du behåller din minimalistiska design och ditt formulär fungerar för alla.

Extrapoäng: gruppera relaterade fält

Har du flera fält som hör ihop? Använd <fieldset> och <legend>:

<fieldset>
  <legend>Leveransadress</legend>

  <label for="gata">Gata</label>
  <input type="text" id="gata" name="gata">

  <label for="postnummer">Postnummer</label>
  <input type="text" id="postnummer" name="postnummer">

  <label for="ort">Ort</label>
  <input type="text" id="ort" name="ort">
</fieldset>

En skärmläsare säger nu: “Leveransadress, grupp. Gata, inmatningsfält”. Den kontexten är hela poängen.

4. Element som inte går att använda med tangentbord

Problemet

Möss är smidiga. Men inte alla använder dem. Människor med motoriska funktionsnedsättningar, RSI, eller en bruten arm använder tangentbordet. Eller röststyrning. Eller ett annat hjälpmedel.

De vanligaste misstagen:

  • Klickbara <div>-element utan tangentbordsfunktion
  • Dropdown-menyer som bara fungerar med hover
  • Custom checkboxar byggda med spans och divs
  • Modaler som du inte kan tabba ut ur

Testa själv: försök använda din webbplats utan mus. Kan du nå överallt? Kan du öppna varje meny? Klicka på varje knapp?

Om svaret är “nej” har du ett problem.

Lösningen

Använd nativa HTML-element där det går. De är tangentbordstillgängliga som standard:

<!-- Inte tillgängligt -->
<div class="button" onclick="submitForm()">Skicka</div>

<!-- Tillgängligt -->
<button type="submit">Skicka</button>

En <button> är fokuserbar med Tab, aktiverbar med Enter eller Mellanslag, och en skärmläsare vet att det är en knapp.

Vill du ändå ha ett custom-element?

Lägg till rätt ARIA-attribut och event handlers:

<!-- Custom-knapp (gör bara detta om du verkligen måste) -->
<div class="custom-button"
     role="button"
     tabindex="0"
     onclick="submitForm()"
     onkeydown="if(event.key === 'Enter' || event.key === ' ') submitForm()">
  Skicka
</div>

I nästan alla fall är det mindre arbete att ta en <button> och styla den med CSS.

Dropdown-menyer

Hover-only-menyer är en katastrof för tangentbordsanvändare:

/* Bara hover */
.dropdown:hover .submenu {
  display: block;
}

Lösning: gör det fokuserbart med tangentbord också:

.dropdown:hover .submenu,
.dropdown:focus-within .submenu {
  display: block;
}

Fokusstilar

Ser du den blå ramen när du tabbar genom en sida? Det är fokusindikatorn. Behåll den. Ta aldrig bort den med:

/* GÖR ALDRIG DETTA */
*:focus {
  outline: none;
}

Om du verkligen tycker den är ful, ersätt den med något annat som syns:

/* Custom fokus-stil */
a:focus,
button:focus {
  outline: 3px solid #2E75A6;
  outline-offset: 2px;
}

5. Saknade eller otydliga felmeddelanden i formulär

Problemet

Din besökare fyller i ett formulär. Trycker på “Skicka”. Sidan laddas om. Det händer… ingenting? Eller det står någonstans ovanför formuläret i rött: “Ett fel uppstod”. Vilket fel? Vilket fält? Ingen aning.

För någon med en skärmläsare är det här ett svart hål. De vet inte ens att ett felmeddelande har dykt upp, ännu mindre var.

Lösningen

Tre saker är avgörande vid felmeddelanden:

  1. Tydligt ange att det finns ett fel
  2. Vilket fält det gäller
  3. Hur du löser det
<!-- Bra felmeddelandestruktur -->
<form>
  <div class="form-group">
    <label for="email">E-postadress</label>
    <input type="email" id="email" name="email"
           aria-invalid="true"
           aria-describedby="email-error">
    <span id="email-error" class="error">
      Ange en giltig e-postadress, till exempel namn@exempel.se
    </span>
  </div>
</form>

Skärmläsaren säger nu: “E-postadress, inmatningsfält, ogiltigt. Ange en giltig e-postadress, till exempel namn@exempel.se.” Tydligt vad som är fel och hur du löser det.

Sammanfattning av felmeddelanden överst

Vid flera fel: visa en sammanfattning överst i formuläret med role="alert" så att skärmläsaren meddelar den direkt:

<div role="alert" class="error-summary">
  <h2>Formuläret kunde inte skickas</h2>
  <ul>
    <li><a href="#email">E-postadress: ange en giltig adress</a></li>
    <li><a href="#phone">Telefonnummer: fältet är obligatoriskt</a></li>
  </ul>
</div>

Varje länk i sammanfattningen pekar på det fält som har felet. Besökaren kan klicka sig direkt dit.

Tre regler för bra felmeddelanden:

  1. Berätta vad som gick fel: “Ange en giltig e-postadress” säger något, “Ogiltigt värde” gör det inte
  2. Berätta hur man löser det: “Formatet ska vara namn@exempel.se”
  3. Koppla felet till fältet: Använd aria-describedby och aria-invalid="true"

Sammanfattning

Fem problem. Fem lösningar. Ingen av dem kräver en ombyggnad av din webbplats. Det handlar om:

  1. Alt-texter: beskriv vad bilden visar eller gör
  2. Färgkontrast: testa dina färger, minst 4,5:1
  3. Formulärlabels: koppla alltid ett <label> till varje fält
  4. Tangentbordsnavigering: använd nativa HTML-element, behåll fokusstilar
  5. Felmeddelanden: tydliga, kopplade till fältet, med lösningsförslag

Börja med den som är lättast att fixa. Sedan nästa. Varje förbättring gör din webbplats bättre för alla besökare, också för dem som aldrig kommer att kalla sig användare av hjälpmedel.

Osäker på var du ska börja? På Proper Access granskar vi din webbplats och ger dig en konkret åtgärdslista med prioritering, kodexempel och lösningar steg för steg. Kontakta oss.

Julia Tol är grundare av Proper Access och granskar webbplatser sedan 2019. Hon skriver rapporter som utvecklare kan arbeta ur direkt: ordnade per komponent, med skärmdumpar och kodexempel.

Dela :