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 är inte heller beroende av ditt CMS-val eller din tech stack. Det är helt enkelt saker som saknas, eller som behöver justeras lite.

Ännu bättre nyheter: de fem vanligaste problemen som vi på Proper Access hittar i granskningar? De löser du med relativt enkla åtgärder. Vi pratar inte om en komplett ombyggnad. Vi pratar om smarta quick wins som ger direkt effekt.

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.

Sanktionerna? Upp till 10 miljoner SEK. Produkter kan krävas återdragas från marknaden. PTS granskar redan aktivt.

Men bortom lagen: ungefär 20 % av Sveriges befolkning har en funktionsnedsättning. Det är potentiella kunder som lämnar din webbplats för att den inte fungerar med deras hjälpmedel. Tangentbord, skärmläsare, förstoringsprogram — det spelar ingen roll. Om din webbplats inte fungerar, köper de någon annanstans.

Affärsnyttan finns. Deadline har passerat. Dags att börja.

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 — den kräver mindre kontrast
  2. Öka textstorleken — stor text får ha 3:1 kontrast
  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 är tillgängligt. Win-win.

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”. Kontext = kung.

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>

Men ärligt? Använd bara en <button>. Styla den med CSS. Klart.

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” — inte bara “Ogiltigt värde”
  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. Sedan nästa. Varje förbättring gör din webbplats bättre för alla besökare — inte bara de med funktionsnedsättningar.

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 steg-för-steg-lösningar. Kontakta oss.

Julia Tol är grundare av Proper Access och hjälper organisationer att uppnå digital tillgänglighet. Inte med tjocka rapporter, utan med konkreta lösningar som utvecklare faktiskt kan använda.

Taggar :

Dela :