Tillgänglighetsredogörelse: Vad det är, varför du behöver en och hur du skriver den

Mer än 96% av de en miljon största webbplatserna uppfyller inte grundläggande WCAG-tillgänglighetsstandarder — och ändå fortsätter antalet ADA-relaterade stämningar kring webben att öka varje år. I den här miljön är en tillgänglighetsförklaring inte bara en artig gest. Den är en av de mest konkreta, offentligt synliga signalerna på att din organisation tar digital inkludering på allvar, och i ett växande antal jurisdiktioner är den också ett lagkrav. Om du inte har en ännu kommer den här guiden att gå igenom allt du behöver veta för att göra den rätt.

What Is an Accessibility Statement?

I grunden är en tillgänglighetsförklaring ett offentligt åtagande från din organisation att göra din webbplats — och de digitala tjänster den tillhandahåller — tillgängliga för alla användare, inklusive personer med funktionsnedsättning. Den ligger på en dedikerad sida på din webbplats och berättar för besökare, med enkel språkdräkt, vilka standarder ni siktar på, vad ni har gjort för att uppfylla dem, var det fortfarande finns brister och hur man når någon om de stöter på ett hinder.

Det är viktigt att skilja en tillgänglighetsförklaring från relaterade men olika dokument. En intern tillgänglighetspolicy beskriver din organisations interna mål och processer — vem som är ansvarig, vilka arbetsflöden som gäller, hur inköpsbeslut fattas. En tillgänglighetsförklaring är däremot utåtriktad. Den är skriven för dina användare, inte ditt team. En Voluntary Product Accessibility Template (VPAT) eller Accessibility Conformance Report (ACR) är ett mycket tekniskt dokument som främst används i upphandlingssammanhang för företag. En tillgänglighetsförklaring ligger mellan dessa: den ska vara ärlig och substantiell, men också begriplig för vem som helst i allmänheten som hamnar på sidan.

Tänk på den som ditt tillgänglighetslöfte, skrivet i det öppna. Den signalerar till användare med funktionsnedsättning att du ser dem, att du arbetar för att betjäna dem och att det finns en verklig person de kan kontakta när något går fel. Den visar också för tillsynsmyndigheter, revisorer och motpartsombud i en eventuell framtida tvist att tillgänglighet är en genomtänkt, pågående praktik i din organisation — inte en eftertanke.

The Legal Landscape: When Is an Accessibility Statement Required?

Svaret på ”behöver jag juridiskt sett en tillgänglighetsförklaring?” beror i hög grad på var du är verksam, vilka dina målgrupper är och vilka lagar som gäller för dig. Bilden har förändrats avsevärt de senaste två åren, och utvecklingen är tydlig: kraven skärps globalt.

I USA kommer den mest direkta rättsliga skyldigheten för delstatliga och lokala myndigheter från Justitiedepartementets slutliga regel från april 2024 enligt Title II i ADA, som klargjorde att myndigheters webbplatser och mobilappar måste uppfylla WCAG 2.1 nivå AA. Att publicera en tillgänglighetsförklaring och etablera styrning kring digital tillgänglighet är en del av den efterlevnadshållningen. Tidsfristerna för efterlevnad enligt denna regel infaller i april 2026 för större enheter och april 2027 för mindre. För privata företag som omfattas av ADA Title III, även om en specifik tillgänglighetsförklaring inte uttryckligen krävs i lagtexten, har avsaknaden av en sådan använts av kärandens ombud som bevis på att organisationens övergripande tillgänglighetsarbete brister — vilket gör det till en betydande juridisk riskfaktor.

I Europeiska unionen är bilden ännu tydligare. EU:s webbtillgänglighetsdirektiv har i flera år krävt att offentliga organ i medlemsstaterna publicerar tillgänglighetsförklaringar. Nu utvidgar European Accessibility Act — som trädde i full kraft den 28 juni 2025 — tillgänglighetskraven till privata företag inom sektorer som e-handel, bank, transport och telekommunikation. Alla företag som erbjuder produkter eller tjänster till kunder baserade i EU, oavsett var företaget har sitt huvudkontor, omfattas. Tänk på EAA som GDPR för digital tillgänglighet: en omfattande, gränsöverskridande reglering som inte bryr sig om var dina servrar finns. EAA är anpassad till WCAG 2.1 nivå AA som teknisk referens för webb- och mobilinnehåll.

I Storbritannien kräver Public Sector Bodies Accessibility Regulations 2018 uttryckligen att alla statliga och offentliga webbplatser och appar uppfyller WCAG 2.1 AA-standarder och publicerar en tillgänglighetsförklaring. Kanadas AODA i Ontario, Section 508 i Rehabilitation Act för amerikanska federala leverantörer och olika andra nationella ramverk lägger till ytterligare lager. Om du har en global målgrupp bör du utgå från att minst en tillämplig lag kräver en förklaring från dig.

Även där ingen lag uttryckligen kräver en tillgänglighetsförklaring för just din organisation framstår avsaknaden av en sådan i allt högre grad som vårdslöshet — inte neutralitet. Det är ett lågkostnadssteg med hög signalstyrka som varje webbplatsägare bör ta.

Why Your Accessibility Statement Matters Beyond Compliance

Rättsliga skyldigheter är golvet, inte taket. Det finns starka affärsmässiga och etiska skäl att ha en väl utformad tillgänglighetsförklaring som går längre än att bara undvika stämningar.

Tänk först på dina användare. Ungefär 1,3 miljarder människor världen över lever med någon form av funktionsnedsättning. Många av dem har genom hårda erfarenheter lärt sig att leta efter en tillgänglighetsförklaring innan de litar på en ny webbplats med sin tid eller sina pengar. En tydlig, ärlig förklaring berättar vilka hjälpmedel din webbplats har testats med, vem man kontaktar om något går sönder och hur seriöst din organisation ser på frågan. Den minskar friktion och bygger förtroende just i det ögonblick en användare med funktionsnedsättning bestämmer sig för om de ska stanna på din webbplats.

För det andra finns den reputationsmässiga dimensionen. Att inte ha en tillgänglighetsförklaring — eller att ha en som uppenbart är hämtad från en mall utan anpassning och som ger löften som din webbplats uppenbart inte håller — sänder en negativ signal till kunder, medarbetare och partners som bryr sig om inkludering. Omvänt är en genomtänkt, regelbundet uppdaterad förklaring ett bevis på ett genuint organisatoriskt engagemang. Ledande organisationer som Barclays och Roche publicerar förklaringar som ärligt erkänner deras nuvarande begränsningar samtidigt som de beskriver konkreta åtgärder som pågår för att åtgärda dem. Den transparensen bygger mer goodwill än en förklaring som påstår perfekt efterlevnad någonsin skulle kunna göra.

För det tredje skapar din tillgänglighetsförklaring en intern ansvarsmekanism. När du offentligt åtar dig en standard, en testmetod och en svarstid för användarrapporterade problem skapar du förväntningar som dina egna team måste uppfylla. Det är en funktion, inte en brist. Tillgänglighetsprogram som saknar externa åtaganden tenderar att driva iväg; de med offentliga förklaringar tenderar att hålla kursen.

Slutligen finns SEO och användbarhet att beakta. Bästa praxis för tillgänglighet — semantisk HTML, korrekta rubrikstrukturer, beskrivande alt-texter, tydliga länktexter — korrelerar starkt med signaler för sökmotorrankning. En webbplats som byggs med tillgänglighet i åtanke tenderar att vara en bättre presterande webbplats över hela linjen.

What to Include: The Essential Components

Det finns ingen enskild obligatorisk mall för en tillgänglighetsförklaring i privat sektor, men W3C:s Web Accessibility Initiative ger den tydligaste vägledningen om vad en förklaring bör innehålla. Nedan följer en genomgång av varje komponent du bör ta upp, tillsammans med resonemanget bakom.

Ett åtagande. Inled med ett tydligt, mänskligt formulerat uttalande om din organisations åtagande för digital tillgänglighet. Göm det inte. Det är detta användare med funktionsnedsättning — och kärandens ombud — kommer att läsa först. Undvik företagsfloskler. Säg uttryckligen att ni arbetar mot en inkluderande upplevelse för användare med syn-, hörsel-, fysiska, kognitiva, neurologiska och talrelaterade funktionsnedsättningar.

Standarderna ni siktar på. Namnge den specifika versionen av WCAG som ni siktar på — helst WCAG 2.1 nivå AA som minimum, med WCAG 2.2 nivå AA som nuvarande bästa praxis. Ange ert efterlevnadsnivå ärligt. Om ni är fullt konforma, säg det. Om ni är delvis konforma, säg det också och beskriv vilka områden som brister. Att lämna felaktiga uppgifter om efterlevnad i er förklaring är värre än att redovisa kända brister — det eliminerar möjligheten att hävda god tro i en tvist.

Kända begränsningar. Det här är avsnittet de flesta organisationer gör fel. Antingen listar de inga begränsningar alls (osannolikt för nästan vilken verklig webbplats som helst) eller så använder de tekniska WCAG-kriterienummer som inte betyder något för användare. W3C rekommenderar enkel, begriplig text: i stället för ”WCAG Success Criterion 1.2.2 uppfylls inte”, säg ”vissa av våra äldre videor har inte undertexter”. Var specifik. Var ärlig. Användare uppskattar att få veta i förväg, och det skyddar dig juridiskt genom att visa god tro.

Vad ni har gjort för att hantera tillgänglighet. Beskriv era faktiska insatser: har ni genomfört en tredjepartsgranskning? Testar ni med skärmläsare? Har ni utbildat ert innehållsteam? Använder ni en tillgänglighets-overlay-widget för att tillhandahålla ytterligare hjälpmedelsfunktioner? Redogör för de specifika åtgärder din organisation vidtar. Det här avsnittet förvandlar er förklaring från ett passivt löfte till konkreta bevis på ett efterlevnadsprogram.

Teknisk miljö. Ange de webbläsare, operativsystem och hjälpmedel som din webbplats har testats med. Skärmläsare beter sig olika i olika webbläsarkombinationer, och att dokumentera dina testade miljöer hanterar förväntningar samtidigt som det visar noggrannhet.

Kontaktinformation. Detta kan vara det enskilt viktigaste avsnittet. Gör det enkelt för användare att rapportera tillgänglighetshinder. Tillhandahåll flera kanaler — e-post, telefon och helst ett webbformulär som i sig är fullt tillgängligt. Ange en svarstid och håll den. Forskning visar konsekvent att ju snabbare en organisation svarar på tillgänglighetsklagomål, desto mindre sannolikt är det att klagomålet utvecklas till en stämning. Skicka inte dessa kontakter till en allmän brevlåda som ingen bevakar.

Tredjepartsinnehåll. Om din webbplats bäddar in tredjepartswidgets, sociala flöden, kartor eller annat innehåll som du inte kontrollerar, erkänn detta och klargör att du inte kan garantera tillgängligheten för det innehållet. Du kan ändå beskriva vilka steg du tar för att välja tillgängliga tredjepartsverktyg.

Datum för senaste granskning. Inkludera ett synligt ”senast uppdaterad”-datum. En tillgänglighetsförklaring utan datum ser — och kan vara — inaktuell ut. Åta dig att granska och uppdatera den minst årligen och efter varje större omdesign eller större innehållsändring.

Hänvisningar till tillämpliga lagar. Beroende på din jurisdiktion och målgrupp, hänvisa till relevanta rättsliga ramverk: ADA, Section 508, EAA, UK Accessibility Regulations, AODA eller andra. Detta visar juridisk medvetenhet och hjälper användare att förstå det regulatoriska sammanhanget.

A Structural Template You Can Adapt

Följande är en ren, semantisk HTML-struktur som du kan anpassa för din egen sida med tillgänglighetsförklaring. Ersätt platshållarvärdena med korrekt information som är specifik för din organisation och webbplats.

<h1>Accessibility Statement</h1>

<p>
  [Organization Name] is committed to ensuring digital accessibility
  for people with disabilities. We continually improve the user experience
  for everyone and apply relevant accessibility standards.
</p>

<h2>Conformance Status</h2>
<p>
  We aim to conform to the Web Content Accessibility Guidelines (WCAG)
  2.1 Level AA. These guidelines explain how to make web content more
  accessible to people with disabilities. Our current conformance status
  is: [fully conformant / partially conformant — describe known gaps].
</p>

<h2>Known Limitations</h2>
<p>
  Despite our best efforts, some content may not yet be fully accessible:
</p>
<ul>
  <li>[Example: Some older PDF documents do not have text
      equivalents. We are converting these on a rolling basis.]</li>
  <li>[Example: Videos published before [date] may not have
      accurate captions. We are prioritizing recaptioning.]</li>
</ul>

<h2>Measures We Take</h2>
<ul>
  <li>Annual third-party accessibility audits against WCAG 2.1 AA</li>
  <li>Manual testing with screen readers (NVDA, JAWS, VoiceOver)</li>
  <li>Automated scanning on each deployment</li>
  <li>Accessibility widget providing user-controlled display options</li>
  <li>Staff training on accessible content creation</li>
</ul>

<h2>Technical Specifications</h2>
<p>
  This website has been tested on the following environments:
</p>
<ul>
  <li>Chrome + NVDA on Windows 11</li>
  <li>Safari + VoiceOver on macOS and iOS</li>
  <li>Firefox + JAWS on Windows 11</li>
</ul>

<h2>Feedback and Contact</h2>
<p>
  If you experience any accessibility barriers on this website, please
  contact us. We aim to respond within 2 business days.
</p>
<ul>
  <li>Email: <a href='mailto:[email protected]'>
      [email protected]</a></li>
  <li>Phone: +1 (555) 000-0000</li>
</ul>

<h2>Formal Complaints</h2>
<p>
  If you are not satisfied with our response, you may contact the
  relevant enforcement authority in your jurisdiction.
</p>

<p><em>This statement was last reviewed on [Month YYYY].</em></p>

Common Mistakes to Avoid

De flesta tillgänglighetsförklaringar som finns på webben idag är antingen frånvarande, plagierade från en mall utan ändringar eller aktivt vilseledande. Här är de specifika fallgroparna att undvika.

Att påstå full efterlevnad när ni inte är fullt konforma. Detta är det farligaste misstaget. Automatiska verktyg fångar som bäst ungefär 30–40% av WCAG-problemen, vilket innebär att en webbplats som klarar automatiska tester fortfarande kan ha betydande hinder. Om er förklaring påstår full WCAG 2.1 AA-efterlevnad och en användare eller kärande kan visa motsatsen, förstärker det falska påståendet er juridiska exponering i stället för att minska den. Korrekt angivna delvisa efterlevnadsnivåer, kombinerade med en tydlig plan för åtgärder, är både mer ärliga och mer försvarbara.

Att göra själva förklaringssidan otillgänglig. Detta händer oftare än man kan tro. Själva tillgänglighetsförklaringen ska uppfylla WCAG. Testa sidan, kontrollera färgkontraster, verifiera tangentbordsnavigering och se till att skärmläsare kan tolka rubrikerna korrekt. En otillgänglig tillgänglighetsförklaring är åtminstone pinsam — och i värsta fall bevis i ett klagomål.

Att inte tillhandahålla någon verklig kontaktväg. En förklaring som uppmanar användare att ”kontakta oss” via ett trasigt formulär eller en generell info@-adress som ingen bevakar är värre än värdelös. Användare som försöker rapportera ett hinder och inte får svar är betydligt mer benägna att vända sig till en tillsynsmyndighet eller en advokat.

Att aldrig uppdatera den. En förklaring daterad för tre år sedan som hänvisar till tekniker eller standarder som sedan dess har ersatts undergräver omedelbart förtroendet. Skapa en kalenderpåminnelse om att granska din förklaring minst en gång per år och omedelbart efter varje större omdesign av webbplatsen.

Att gömma den där ingen hittar den. W3C rekommenderar att du länkar till din tillgänglighetsförklaring från flera framträdande platser: sidfoten, hjälpmenyn, webbplatskartan och ”om oss”-sidan. Använd konsekvent länktext — ”Accessibility Statement” eller ”Accessibility” — så att användare som vet att de ska leta efter den kan hitta den snabbt.

Where Accsible Fits Into Your Accessibility Strategy

En tillgänglighetsförklaring är dokumentation av ditt åtagande, men ett åtagande utan genomförande är bara ord. Det är här ett verktyg som Accsibles overlay-widget-SDK kommer in som ett lager i en bredare tillgänglighetsstrategi.

Accsible låter dig bädda in en konfigurerbar tillgänglighetswidget på din webbplats som ger användare direkt kontroll över sin upplevelse — justera teckenstorlekar, kontrastinställningar, markörstorlek, minska animationer och mer. Dessa användarorienterade kontroller utökar din webbplats användbarhet för personer med en rad syn-, motoriska och kognitiva behov. Viktigt är att när du inkluderar en tillgänglighetswidget i din verktygslåda blir din tillgänglighetsförklaring mer specifik och trovärdig: du kan namnge de specifika funktioner widgeten tillhandahåller, beskriva de miljöer den har testats i och visa att du har vidtagit aktiva, tekniska steg mot inkludering.

Den specifikheten spelar roll. Domstolar, tillsynsmyndigheter och användare reagerar alla bättre på förklaringar som beskriver konkreta åtgärder än på vaga utfästelser. Din förklaring bör hänvisa till widgeten, vad den gör och vilka användarbehov den adresserar — tillsammans med ditt granskningsprogram, din testmetodik och din mänskliga kontaktpunkt för feedback. Widgeten är inte en ersättning för semantisk, välstrukturerad underliggande kod, men den är ett meningsfullt, dokumenterat lager av insats som hör hemma i din förklaring.

Accessibility is a program, not a product. Your statement documents that program. Every tool, audit, training session, and feedback loop you put in place makes your statement more credible — and your site genuinely more inclusive.

Keeping Your Statement Current: A Maintenance Checklist

En tillgänglighetsförklaring är ett levande dokument. I samma ögonblick som din webbplats förändras — ett nytt kassaflöde, en omdesignad navigation, en ny inbäddad videospelare — påverkas potentiellt riktigheten i din förklaring. Bygg in en underhållsrytm i ditt tillgänglighetsprogram så att förklaringen alltid speglar verkligheten.

• Efter varje större release eller omdesign: Granska avsnittet om kända begränsningar och de tekniska specifikationerna. Uppdatera testade miljöer om webbläsare eller hjälpmedel har ändrats.
• Årligen: Beställ eller genomför en fullständig tillgänglighetsgranskning. Uppdatera efterlevnadsstatusen och avsnittet om åtgärder så att de speglar aktuella verktyg, processer och resultat. Uppdatera datumet ”senast granskad”.
• När standarder ändras: WCAG 2.2 är nu publicerad och WCAG 3.0 är under utveckling. När tillsynsmyndigheter uppdaterar sina tekniska standarder, uppdatera din förklaring så att den återspeglar den version du siktar på och din plan för migrering.
• När lagar ändras: EAA, tidsfristerna i ADA Title II och andra regleringar utvecklas aktivt. Om nya krav börjar gälla för din organisation, uppdatera de juridiska hänvisningarna i din förklaring i enlighet med detta.
• När kontaktuppgifter ändras: Uppdatera omedelbart alla e-postadresser, telefonnummer eller formulärlänkar. En bruten kontaktkanal i en tillgänglighetsförklaring är både ett användbarhetsfel och en juridisk risk.

Att logga den tillgänglighetsfeedback du får — de problem användare rapporterar, hur du svarade och hur lång tid åtgärder tog — skapar också en dokumentation som visar god tro. Om din organisation någonsin ifrågasätts kring sina tillgänglighetsrutiner kan den dokumentationen vara ovärderlig.

Key Takeaways

• En tillgänglighetsförklaring är både ett verktyg för juridisk riskhantering och en signal om användarförtroende. I många jurisdiktioner — inklusive för företag på EU-marknaden under EAA och offentliga aktörer i USA under ADA Title II-regeln — krävs nu någon form av offentligt tillgänglighetsåtagande eller antyds starkt i lag.
• Ärlighet om begränsningar skyddar dig mer än överdrivna påståenden. Att ange att du är delvis konform med en tydlig åtgärdsplan är mer juridiskt försvarbart än att felaktigt påstå full WCAG-efterlevnad. Domstolar och tillsynsmyndigheter reagerar väl på visad god tro.
• Gör din kontaktväg verklig och övervakad. Tillhandahåll flera sätt att rapportera hinder — e-post, telefon, ett webbformulär — och åta dig en specifik svarstid. Snabba svar på användarrapporterade problem minskar dramatiskt risken för juridisk eskalering.
• Din sida med tillgänglighetsförklaringen måste i sig vara tillgänglig. Testa den mot WCAG, verifiera tangentbordsnavigering, kontrollera färgkontrast och säkerställ kompatibilitet med skärmläsare innan du publicerar.
• Behandla förklaringen som ett levande dokument, inte en engångsuppgift. Granska den efter varje större förändring på webbplatsen, minst årligen och när tillämpliga lagar eller WCAG-standarder uppdateras. Håll datumet ”senast granskad” synligt och korrekt.