Webbtillgänglighet 2026: Vad EU:s tillgänglighetsdirektiv kräver av ditt företag

En kund kom till oss förra året med ett till synes enkelt klagomål: bokningsformuläret på webbplatsen fungerade, konverteringarna såg bra ut, men en kund hade mejlat och sagt att hon inte kunde genomföra ett köp med tangentbordet eftersom hon aldrig kunde se var markören hamnat. Det där mejlet blev startskottet för en granskning som visade att fokusmarkeringarna hade slagits av utan att någon märkt det, i samband med en CSS-reset två omdesigner tillbaka, att hälften av produktbilderna saknade alt-text, och att kontrasten på "Lägg i varukorg"-knappen knappt gick att läsa i direkt solljus på mobilen. Inget av detta syntes i den vanliga statistiken. Det syntes först när någon som faktiskt behövde de här funktionerna försökte använda sajten.

Det är den praktiska bakgrunden till ett ämne som fått betydligt mer uppmärksamhet sedan juni 2025, då EU:s tillgänglighetsdirektiv (European Accessibility Act, EAA) började gälla i medlemsländerna. Driver du ett företag med någon form av digital närvaro i Europa har du sannolikt stött på begreppet — ofta med mer oro än sakinnehåll bakom. Den här artikeln går igenom vad direktivet faktiskt kräver, vilka som omfattas, vilken standard ni bör bygga mot, och hur ni får ordning på er egen webbplats utan att först behöva anlita en jurist.

Vad tillgänglighet faktiskt innebär i praktiken

Tillgänglighet reduceras alldeles för ofta till "stöd för skärmläsare". Skärmläsare spelar roll, men är bara en del av en betydligt större bild. I praktiken handlar en tillgänglig webbplats om följande:

• Tangentbordsnavigering — varje interaktivt element (menyer, formulär, filter, popup-fönster) går att nå och använda enbart med Tabb, Enter och piltangenterna, utan mus.
• Synliga fokusmarkeringar — när du tabbar dig fram till en knapp eller länk ska det vara uppenbart var du befinner dig. Det är precis det som gick sönder i exemplet ovan, och det är en av de vanligaste regressionerna vi hittar vid granskning efter en omdesign — helt enkelt för att felet är osynligt om man inte faktiskt sitter och navigerar med tangentbord.
• Tillräcklig färgkontrast — text och interaktiva element behöver tillräcklig kontrast mot bakgrunden för att gå att läsa, både för personer med nedsatt syn och för vem som helst som använder mobilen utomhus.
• Beskrivande alt-texter — bilder ska förmedla sitt innehåll även i textform, så att skärmläsaranvändare och alla som surfar utan bilder ändå får med sig informationen.
• Korrekt kopplade formulärfält — varje inmatningsfält har en riktig, programmatiskt kopplad etikett — inte bara platshållartext som försvinner så fort man börjar skriva.
• Logisk rubrikstruktur — H1 till H3 som faktiskt speglar sidans hierarki, så att skärmläsaranvändare kan hoppa mellan avsnitt istället för att lyssna igenom allt linjärt.
• Undertexter och transkriberingar — för video och ljud, så att innehållet går att ta del av utan ljud och samtidigt blir sökbart och indexerbart som text.

Inget av det här är avancerat. Det mesta är helt vanligt frontend-hantverk som fallit bort någonstans på vägen, oftast under tidspress eller för att en mall kopierats in utan att någon kontrollerat vad den faktiskt renderade.

Vad tillgänglighetsdirektivet faktiskt kräver

EAA är ett EU-direktiv, vilket betyder att varje medlemsland omsätter det i egen nationell lagstiftning — ramverket är gemensamt, men detaljerna kring implementering, tidsplaner för specifika delbranscher och tillsyn skiljer sig mellan länder. Direktivet gäller företag som tillhandahåller vissa produkter och tjänster inom dess tillämpningsområde, bland annat:

• E-handel (nätbutiker som säljer varor eller tjänster till konsumenter)
• Bank- och konsumentfinansiella tjänster
• Transport — biljett- och bokningssystem för flyg, tåg, buss och färja
• Elektroniska kommunikationstjänster (telekom, meddelandeappar)
• E-böcker och dedikerad programvara för e-läsning
• Viss konsumentelektronik, exempelvis smartphones, datorer och uttagsautomater/biljettautomater

Det är värt att vara precis här: EAA täcker inte alla webbplatser i Europa rakt av. Direktivet är avgränsat till specifika produkt- och tjänstekategorier, med vissa undantag för mikroföretag (i grova drag bolag med färre än 10 anställda och under 2 miljoner euro i årsomsättning) som tillhandahåller tjänster — undantaget gäller dock inte alltid själva produkterna, och det betyder inte att mindre företag automatiskt slipper undan om de verkar inom en berörd bransch. Säljer ditt företag fysiska varor online, driver ett bokningssystem eller erbjuder någon form av konsumentfinansiell tjänst, är ni med största sannolikhet inom tillämpningsområdet oavsett storlek.

Sverige är ett bra exempel på hur det här bygger vidare på befintliga regler snarare än börjar från noll. Digitala tjänster inom offentlig sektor i Sverige har omfattats av tillgänglighetskrav sedan 2019 enligt DOS-lagen (lagen om tillgänglighet till digital offentlig service), baserad på samma WCAG-standard som EAA nu pekar mot för den privata sektorn. Svenska företag som arbetar mot offentlig sektor, eller som följt hur de kraven tillämpats i praktiken, har alltså redan en referenspunkt för vad efterlevnad faktiskt innebär i verkligheten — EAA breddar en liknande förväntan till privata kommersiella tjänster.

Eftersom omfattning, tidsplaner och tillsyn skiljer sig åt mellan länder och branscher är den här artikeln en praktisk utgångspunkt, inte juridisk rådgivning. Är ni osäkra på om ert företag omfattas av EAA är ett kort samtal med en jurist som är insatt i er specifika bransch och marknad väl värt kostnaden — betydligt billigare än att bygga om en plattform i efterhand.

WCAG 2.1/2.2 AA: måttstocken att bygga mot

Oavsett exakt vilket regelverk som gäller för just ert företag finns det egentligen en standard värd att bygga mot: Web Content Accessibility Guidelines (WCAG), för närvarande i version 2.2, med nivå AA som den konformitetsnivå som både EAA och de flesta nationella tillgänglighetslagar i Europa hänvisar till (inklusive svenska DOS-lagen). WCAG bygger på fyra principer — innehåll ska vara möjligt att uppfatta, hanterbart, begripligt och robust — och nivå AA ligger på en realistisk mellannivå: mer krävande än grundnivån A, men utan de mycket strikta kraven i nivå AAA som de flesta vanliga webbplatser varken behöver eller i praktiken uppnår.

Om du bara ska ta med dig en sak från den juridiska sidan av det här: bygg mot WCAG 2.1/2.2 AA så ligger ni i linje med praktiskt taget all tillgänglighetslagstiftning ni sannolikt stöter på inom EU, inte bara EAA. Det är standarden som återkommer om och om igen i olika länders lagstiftning, vilket gör den till ett betydligt mer användbart mål än att försöka hålla koll på ett tiotal nationella tolkningar var för sig.

En praktisk startchecklista

Ni behöver inte en fullständig granskning för att komma en bra bit på vägen. Det här är de åtgärder som ger mest effekt för minst insats, och som vi alltid kollar först på en webbplats:

• Alt-text på alla bilder som förmedlar information. Rent dekorativa bilder (mellanrum, bakgrundsdetaljer) kan ha tomma alt-attribut; allt som faktiskt förmedlar innehåll behöver en riktig beskrivning.
• Färgkontrast på minst 4,5:1 för normal text och 3:1 för stor text, kontrollerad mot den faktiska bakgrunden den ligger på — inte bara mot designfilen.
• Full tangentbordsnavigering — tabba dig igenom hela webbplatsen, inklusive menyer, filter och eventuella popup-fönster, utan att röra musen. Tappar du bort var fokus befinner sig kommer era besökare att göra det också.
• Synliga fokusmarkeringar med hög kontrast på varje interaktivt element — ta aldrig bort standardkonturen i CSS utan att ersätta den med något minst lika tydligt.
• Explicita etiketter på formulärfält, kopplade till rätt fält via `for`/`id` (eller `aria-label` där en synlig etikett verkligen inte passar), plus tydliga felmeddelanden som förklarar vad som behöver rättas.
• En logisk rubrikhierarki — en H1 per sida, rubriker som följer på varandra i ordning, och inga rubriktaggar valda enbart för teckenstorleken.
• Undertexter på videoinnehåll och transkriberingar för poddar eller rent ljudinnehåll.
• Beskrivande länktexter — "Läs vår fraktpolicy" istället för ett kalt "Klicka här", eftersom skärmläsaranvändare ofta navigerar via en lista med länkar helt utan omgivande sammanhang.

Går ni igenom listan ärligt, på den faktiska livesajten och inte bara på designskisserna, fångar ni upp de flesta av de allvarligaste problemen innan ni behöver ta in extern hjälp.

Egengranskning eller ta in en specialist

En grundläggande egengranskning är genuint användbar och kräver inga särskilda verktyg. Stäng av musen och navigera hela webbplatsen med enbart tangentbordet. Kör era viktigaste sidor genom en gratis automatiserad kontroll (verktyg som WAVE eller tillgänglighetsgranskningen inbyggd i Chrome DevTools/Lighthouse fångar en betydande andel problem, särskilt kontrast och saknad alt-text). Testa sajten med en skärmläsare i tio minuter — VoiceOver på Mac eller NVDA på Windows, båda gratis — bara för att känna hur annorlunda den upplevs.

Automatiserade verktyg fångar dock tillförlitligt bara en bråkdel av WCAG:s framgångskriterier — ofta uppskattat till 30–40 procent — eftersom mycket av tillgänglighetsarbetet är kontextberoende: om en alt-text faktiskt beskriver bilden eller bara finns där, om ett formulärs felhantering är begriplig när den läses upp, om en egenbyggd dropdown-meny fungerar korrekt för hjälpmedelsteknik. Det är där det blir värt att ta in en specialist, särskilt om:

• Ni verkar i en bransch som tydligt omfattas av EAA (e-handel, finansiella tjänster, transportbokning) och behöver dokumenterad efterlevnad, inte bara goda avsikter.
• Sajten bygger tungt på egenutvecklade interaktiva komponenter — filter, flerstegs-kassor, bokningskalendrar, dashboards — där automatiserade verktyg missar mest.
• Ni redan gjort egengranskningen, åtgärdat det ni hittade, och vill ha en oberoende kontroll innan ni betraktar arbetet som klart.

Är er senaste omdesign mer än ett par år gammal är brister i tillgängligheten ofta ett symptom bland flera värda att se över — det tas kort upp som en av flera varningssignaler i Tio tecken på att din hemsida behöver en redesign, tillsammans med saker som långa laddtider och dålig mobilanpassning. Den här artikeln är egentligen den fördjupning som ägnas åt just den punkten.

Affärsnyttan bortom regelefterlevnad

Att enbart se tillgänglighet som en juridisk risk att hantera underskattar värdet av arbetet. Ett par saker brukar bli tydliga när ett företag väl går igenom processen på riktigt:

Den möjliga målgruppen är större än de flesta räknar med. Funktionsnedsättning är inte en liten, statisk minoritet — det handlar om permanenta tillstånd, tillfälliga (en armbrottsskada, en ögoninflammation) och situationsbetingade (starkt solljus mot en mobilskärm, en bullrig miljö där undertexter gör skillnad, en långsam uppkoppling där ren, semantisk kod laddar snabbare än en uppblåst skräddarsydd layout). Att bygga för ytterlighetsfallen brukar förbättra upplevelsen för alla däremellan också.

Det finns ett verkligt överlapp med SEO. Beskrivande alt-texter, ren rubrikhierarki, meningsfulla länktexter och snabb, semantisk kod är grundläggande för tillgänglighet och SEO samtidigt — sökmotorer och skärmläsare är i någon mening båda "icke-visuella användare" som försöker tolka sidans struktur. Fixar man det ena hjälper det oftast det andra.

Det ger generellt en bättre upplevelse för alla. Tydliga fokusmarkeringar hjälper vana användare att navigera snabbt. Bra kontrast hjälper alla som befinner sig i dålig belysning. Väl märkta formulär minskar fel och avbrutna köp rakt igenom, inte bara för användare med funktionsnedsättning. Tillgänglighetsarbete stannar sällan vid "tillgänglighetsfunktionen" — det brukar höja lägstanivån för hela gränssnittet.

Inget av det här kräver att ni bygger om webbplatsen från grunden. De flesta företag kan täppa till merparten av gapet med riktat frontend-arbete: åtgärda kontrast och fokusmarkeringar, strukturera om rubrikerna, lägga till riktiga alt-texter och formulärsetiketter, och texta befintligt videoinnehåll. Ger egengranskningen fler än en handfull strukturella problem, eller vill ni hellre ha en specialist som bekräftar att arbetet uppfyller WCAG 2.1/2.2 AA innan ni kallar det klart, är det precis den typen av projekt vårt arbete med skräddarsydd webbdesign omfattar — hör av er via vår kontaktsida så går vi igenom vad just er webbplats behöver.