Hoppa till huvud innehåll

Allt om LPTT

Allt om LPTT
Meny

Hjälpmedel för digital tillgänglighet

Innehållsförteckning

För att skapa tillgängliga digitala produkter behöver du förstå de hjälpmedel som människor faktiskt använder. Från skärmläsare och punktdisplayer till röststyrning och ögonstyrning – när du designar och utvecklar med dessa hjälpmedel i åtanke skapar du produkter som fungerar för alla.

Vad är hjälpmedel för digital tillgänglighet?

Hjälpmedel (assistive technologies, AT) är produkter, utrustning eller system som hjälper personer med funktionsnedsättningar att utföra uppgifter som annars skulle vara svåra eller omöjliga. I digital kontext handlar det om tekniker som hjälper människor att interagera med datorer, mobiltelefoner, webbplatser och appar.

Hjälpmedel kan vara:

  • Programvara – Skärmläsare, förstoringsprogram, röststyrning
  • Hårdvara – Punktdisplayer, alternativa tangentbord, ögonmuscontroller
  • Inbyggda funktioner – Tillgänglighetsfunktioner i operativsystem
  • Anpassningar – Webbläsartillägg, egna CSS-stilmallar

Viktigt att förstå: Din uppgift som utvecklare, designer eller innehållsskapare är inte att bygga hjälpmedlen – de finns redan. Din uppgift är att se till att dina produkter fungerar med de hjälpmedel som användare redan har.

Hjälpmedel för synnedsättningar

Skärmläsare

Vad är en skärmläsare?

En skärmläsare är ett program som läser upp text och beskriver innehåll på skärmen med syntetiskt tal eller skickar det till en punktdisplay. Skärmläsare används av personer med synnedsättning (allt från nedsatt syn till total blindhet) samt personer med vissa kognitiva eller läs- och skrivsvårigheter.

Vanligaste skärmläsare:

  • JAWS (Job Access With Speech) – Windows, kommersiell, mest använda
  • NVDA (NonVisual Desktop Access) – Windows, gratis, open source
  • VoiceOver – macOS och iOS, inbyggd i Apple-produkter
  • TalkBack – Android, inbyggd i Google-produkter
  • ORCA – Linux, gratis, open source
  • Narrator – Windows, inbyggd men mindre använd

Hur skärmläsare fungerar:

  • Läser HTML-struktur – Rubriker, listor, tabeller, formulär
  • Använder semantisk markup – Förlitar sig på korrekt HTML och ARIA
  • Navigerar med tangentbord – Hoppar mellan element med genvägar
  • Ger kontext – ”Rubrik nivå 2”, ”Länk”, ”Knapp”, ”Kryssruta markerad”

Så stödjer du skärmläsare:

  • Semantisk HTML – Använd rätt element för rätt syfte (button, nav, main, article)
  • Alternativtexter – Alla informationsbärande bilder behöver beskrivande alt-text
  • Rubrikstruktur – Logisk hierarki H1-H6, hoppa inte nivåer
  • Formuläretiketter – Alla fält måste ha tydliga, kopplade labels
  • Beskrivande länkar – Länktext ska vara meningsfull utan kontext
  • ARIA när nödvändigt – För komplex interaktivitet som inte täcks av HTML
  • Tangentbordsnavigation – Allt måste vara åtkomligt med Tab, Enter, Space
  • Fokushantering – Synlig fokusindikator, logisk fokusordning

Testa med skärmläsare:

Punktdisplayer (Braille displays)

Vad är en punktdisplay?

En punktdisplay är en hårdvaruenhet som översätter digital text till läsbar punktskrift (braille) med hjälp av små stift som höjs och sänks. Punktdisplayer används framför allt av dövblinda personer och personer som föredrar att läsa i punktskrift istället för att lyssna på syntetiskt tal.

Hur punktdisplayer fungerar:

  • Kopplas till skärmläsare – Fungerar tillsammans med JAWS, NVDA, VoiceOver
  • Visar en rad i taget – Vanligtvis 40-80 tecken
  • Styr med knappar – Navigation med fysiska knappar på enheten
  • Läser exakt text – Till skillnad från syntetiskt tal som kan hoppa över interpunktion

Så stödjer du punktdisplayer:

  • Samma som skärmläsare – Punktdisplayer använder skärmläsarens output
  • Korrekta tecken och symboler – Undvik Unicode-dekorationer som inte översätts väl
  • Logisk läsordning – Innehåll i rätt ordning när det läses linjärt
  • Meningsfull formatering – Rubriker, listor, betoning markeras korrekt

Skärmförstorare

Vad är skärmförstoring?

Skärmförstorare (screen magnifiers) förstorar delar av eller hela skärmen för personer med nedsatt syn som kan se, men behöver större text och grafik.

Typer av förstoring:

  • Webbläsarförstoring – Inbyggd zoom (Ctrl/Cmd +)
  • Operativsystemförstoring – Windows Magnifier, macOS Zoom, iOS Zoom
  • Dedikerade program – ZoomText, MAGic, Supernova

Så stödjer du skärmförstoring:

  • Responsiv design – Layout anpassar sig vid förstoring
  • Relativa enheter – Använd em/rem istället för px för text
  • Ingen horisontell scrollning – Vid 200% zoom ska innehåll fortfarande vara läsbart
  • Tydliga kontraster – Behövs ännu mer vid förstoring
  • Tillräckliga touch-targets – Minst 44x44px för att träffa vid förstoring
  • Behåll funktionalitet – Allt ska fungera vid 400% zoom (WCAG 2.1 AAA)

Högkontrastlägen

Vad är högkontrast?

Högkontrastlägen ändrar färger för att skapa maximal kontrast mellan text och bakgrund. Används av personer med synnedsättningar, färgblindhet, eller i starkt solljus.

Typer av högkontrast:

  • Windows High Contrast Mode – Systemnivå, tvingar egna färger
  • macOS Increase Contrast – Förstärker kontraster
  • Dark Mode – Mörkt gränssnitt med ljus text
  • Inversering – Byter ljusa och mörka färger

Så stödjer du högkontrast:

  • Testa i högkontrastläge – Se att innehåll fortfarande syns
  • Använd systemfärger – Respektera användares färgval
  • Färgoberoende – Information förmedlas inte bara genom färg
  • Kontrastkrav – Minst 4.5:1 för normal text, 3:1 för stor text (WCAG AA)
  • Ikoner och gränser – Ska synas även i högkontrast

Hjälpmedel för hörselnedsättningar

Textning och undertexter

Vad är textning?

Textning (captions) är text som visar vad som sägs och relevanta ljud i videor. Används av döva, hörselskadade, personer i bullriga miljöer, eller när ljud inte kan spelas upp.

Typer av textning:

  • Closed captions – Kan stängas av, inkluderar ljudeffekter
  • Open captions – Inbränd i videon, alltid synlig
  • Automatisk textning – AI-genererad, behöver ofta korrigering
  • Live-textning – Realtidstext för livestreams

Så stödjer du textning:

  • Alla videor textas – Både förinspelade och live om möjligt
  • Korrekt synkronisering – Text visas samtidigt som talet
  • Identifiera talare – Visa vem som pratar vid flera personer
  • Inkludera ljudeffekter – [musik], [applåder], [dörr stängs]
  • WebVTT-format – Standardformat för webbtextning
  • Kontroller – Tydliga knappar för att aktivera/inaktivera textning

Transkript

Vad är transkript?

Transkript är fullständig textversion av allt audio- och videoinnehåll. Mer omfattande än textning och inkluderar ofta beskrivningar av visuella element.

Så stödjer du transkript:

  • Tillhandahåll alltid transkript – För alla audio- och videofiler
  • Lätt att hitta – Länk nära media-spelaren
  • Beskrivande – Inkludera visuell information när relevant
  • Sökbart – Textformat som kan sökas och indexeras
  • Tidsstämplar – Hjälper användare navigera till specifika delar

Teckentolkning

Vad är teckentolkning?

Teckentolkning visar innehåll i teckenspråk (t.ex. svenskt teckenspråk, SSL). För många döva är teckenspråk förstaspråk och lättare att förstå än skriven text.

Så stödjer du teckentolkning:

  • Video-i-video – Teckentolk synlig i hörn av huvudvideo
  • Tillräcklig storlek – Tolken måste vara tydligt synlig
  • Kontroller – Möjlighet att visa/dölja tolkfönster
  • Alternativ till video – Teckentolkning är WCAG AAA-krav

Hjälpmedel för motoriska funktionsnedsättningar

Tangentbordsnavigation

Varför är tangentbord kritiskt?

Många hjälpmedel emulerar tangentbordskommandon. Personer som inte kan använda mus förlitar sig helt på tangentbordet eller tangentbordsemulatorer.

Så stödjer du tangentbordsnavigation:

  • Allt åtkomligt med tangentbord – Tab, Enter, Space, pilar
  • Logisk fokusordning – Följ visuell ordning, vänster-till-höger, topp-till-botten
  • Synlig fokusindikator – Tydlig ram/outline på fokuserat element
  • Inga tangentbordsfällor – Användaren ska alltid kunna ta sig vidare
  • Skip links – ”Hoppa till huvudinnehåll” för att hoppa över repetitiv navigation
  • Kortkommandon – Dokumenterade och avaktiverade vid konflikt

Alternativa tangentbord och switchar

Vad är alternativa inmatningsenheter?

  • Enkelhanstangentbord – Anpassade layouter för begränsad rörlighet
  • Stora tangentbord – Med större knappar
  • Switchar – En eller flera knappar för scanning-baserad inmatning
  • Sip-and-puff – Styrning genom blåsning och sugning

Så stödjer du alternativa tangentbord:

  • Standardiserade tangentbordskommandon – Tab, Enter, Space, Escape
  • Tillräcklig tid – Inga strikta tidsgränser för inmatning
  • Stora klickområden – Minst 44x44px touch-targets
  • Förlåtande design – Lätt att ångra misstag

Röststyrning (Voice Control)

Vad är röststyrning?

Röststyrning låter användare styra datorn eller mobilen med röstkommandon istället för mus eller touch. Används av personer med motoriska funktionsnedsättningar.

Vanliga röststyrningssystem:

  • Dragon NaturallySpeaking – Windows, professionell
  • Windows Speech Recognition – Inbyggd i Windows
  • Voice Control – macOS och iOS (iPhone/iPad)
  • Voice Access – Android

Så stödjer du röststyrning:

  • Synliga etiketter – Knappar och länkar behöver synlig text att säga
  • Unika namn – Varje knapp behöver unikt namn (”Spara” vs ”Spara ändringar”)
  • Accessible names – aria-label ska matcha synlig text
  • Standardiserade kontroller – Native HTML-element känns igen
  • Undvik enbart ikonknappar – Svårt att säga ”klicka på ikonen”

Huvudstyrning och ögonstyrning

Vad är huvud- och ögonstyrning?

  • Huvudstyrning – Kamera spårar huvudrörelser som styr muspekaren
  • Ögonstyrning – Spårar ögonrörelser, låter användare ”klicka” med ögonen

Så stödjer du huvud-/ögonstyrning:

  • Stora klickområden – Minst 44x44px, helst större
  • Tillräckligt avstånd – Space mellan klickbara element
  • Undvik hover-beroende – Inte enbart hover-menyer
  • Dwell-time friendly – Ingen oavsiktlig aktivering vid fokus
  • Tangentbordsnavigation – Många använder virtuellt tangentbord

Hjälpmedel för kognitiva funktionsnedsättningar

Lässtöd och skärm läsare för dyslexiFörstoring

Vad är lässtöd?

Lässtöd inkluderar verktyg som hjälper personer med dyslexi, ADHD, eller andra läs- och skrivsvårigheter att läsa och förstå text.

Typer av lässtöd:

  • Text-to-speech – Läser upp text (inte bara för synnedsättning)
  • Ordprediktion – Föreslår ord medan användaren skriver
  • Läslinjaler – Markerar aktuell rad för att hålla fokus
  • Dyslexivänliga typsnitt – OpenDyslexic, Comic Sans, Lexie Readable
  • Färgöverlägg – Anpassade bakgrundsfärger

Så stödjer du lässtöd:

  • Semantisk HTML – Låter verktyg förstå innehållets struktur
  • Anpassningsbar text – Användare kan ändra typsnitt och storlek
  • Tydlig struktur – Rubriker, listor, korta stycken
  • Enkelt språk – Se vår guide om kognitiv tillgänglighet
  • Läsläge – Reader mode-vänligt innehåll

Minnesstöd och påminnelser

Vad är minnesstöd?

Verktyg och funktioner som minskar krav på arbetsminne och hjälper användare komma ihåg information.

Så stödjer du minnesstöd:

  • Spara progress – Automatisk sparning i formulär
  • Visa tidigare val – Dropdown med historik
  • Bekräftelser – ”Din beställning är mottagen”
  • Breadcrumbs – Visa var användaren är
  • Progress indicators – ”Steg 2 av 5”
  • Inga strikta tidsfrister – Eller möjlighet att förlänga

Webbläsartillägg och anpassningar

Vanliga tillgänglighetstillägg

Innehållsanpassning:

  • Dark Reader – Skapar dark mode på alla webbplatser
  • Stylus/Stylish – Användardefinierade CSS
  • NoSquint – Spara zoom-nivåer per site

Lässtöd:

  • Read&Write – Text-to-speech och ordprediktion
  • Helperbird – Många lässtödsfunktioner
  • BeeLine Reader – Färggradient för lättare läsning

Navigation:

  • Vimium – Tangentbordsnavigation
  • Headings Map – Översikt av sidans rubriker

Så stödjer du tillgänglighetstillägg:

  • Respektera användarinställningar – prefers-color-scheme, prefers-reduced-motion
  • Anpassningsbar CSS – Använd CSS custom properties
  • Semantisk markup – Tillägg förlitar sig på korrekt HTML
  • Testa med tillägg – Se att din sida fortfarande fungerar

Mobila tillgänglighetsverktyg

iOS tillgänglighetsfunktioner

Inbyggda iOS-verktyg:

  • VoiceOver – Skärmläsare (vår guide)
  • Zoom – Skärmförstoring med gester
  • Voice Control – Fullständig röststyrning
  • Switch Control – För externa switchar
  • AssistiveTouch – Anpassad touch-meny
  • Display & Text Size – Stor text, bold, kontrast

Så stödjer du iOS-tillgänglighet:

  • Dynamic Type – Respektera användares textstorleksinställning
  • VoiceOver-labels – Alla UI-element behöver accessibility labels
  • Reducerad rörelse – Respektera prefers-reduced-motion
  • Stor text – Layout anpassar sig vid större text

Android tillgänglighetsfunktioner

Inbyggda Android-verktyg:

  • TalkBack – Skärmläsare (vår guide)
  • Magnification – Triple-tap zoom
  • Voice Access – Röststyrning
  • Switch Access – För externa switchar
  • Select to Speak – Välj text för uppläsning
  • Live Caption – Realtidstextning av audio

Så stödjer du Android-tillgänglighet:

  • Content descriptions – Alla ImageView och ikoner behöver beskrivningar
  • Touch-target size – Minst 48dp x 48dp
  • Färgkontrast – Följ Material Design-riktlinjer
  • Testa med TalkBack – Regelbunden testning under utveckling

Hur du designar och utvecklar med hjälpmedel i åtanke

Designprinciper

1. Designa för tangentbord först

  • Tänk på fokusordning från start
  • Designa synliga fokustillstånd
  • Planera för tangentbordsgenvägar

2. Designa för olika input-metoder

  • Stora touch-targets (minst 44x44px)
  • Tillräckligt avstånd mellan klickbara element
  • Fungerar med mus, touch, röst, switch

3. Designa för anpassning

  • Flexibla layouter vid förstoring
  • Anpassningsbara färger och typsnitt
  • Respektera systeminställningar

Utvecklingsprinciper

1. Använd semantisk HTML

  • Rätt element för rätt syfte: button, a, nav, main, article
  • Formulär korrekt märkta: label kopplad till input
  • Rubriker i hierarki: H1-H6 utan att hoppa nivåer
  • Listor för grupperat innehåll: ul, ol, dl

2. Implementera ARIA korrekt

  • No ARIA is better than bad ARIA – Använd bara när HTML inte räcker
  • ARIA-roller: För komplexa widgets (tabs, accordion, dialog)
  • ARIA-states: aria-expanded, aria-selected, aria-checked
  • ARIA-properties: aria-label, aria-describedby, aria-live
  • Testa alltid: Verifiera att ARIA fungerar som tänkt

3. Hantera fokus korrekt

  • Logisk tab-ordning: Följ visuell ordning
  • Synligt fokus: :focus-visible för tangentbordsanvändare
  • Fokushantering: Flytta fokus vid modal, sidändring, fel
  • Skip-länkar: Hoppa över repetitiv navigation

4. Gör allt tangentbordsåtkomligt

  • Tab, Enter, Space: Standard-interaktioner
  • Escape: Stäng modaler och menyer
  • Pilar: Navigation i komplexa widgets
  • Inga tangentbordsfällor: Alltid möjligt att navigera vidare

5. Testa med riktiga hjälpmedel

  • Skärmläsare: NVDA, JAWS, VoiceOver, TalkBack
  • Endast tangentbord: Koppla bort musen
  • Zoom: 200% och 400%
  • Högkontrast: Windows High Contrast Mode
  • Röststyrning: Voice Control (macOS/iOS)

Testning med olika hjälpmedel

Grundläggande testplan

Nivå 1: Snabb kontroll (30 minuter)

  1. Tangentbordstest: Navigera genom hela sidan med Tab
  2. Skärmläsartest: 5 minuter med NVDA eller VoiceOver
  3. Zoomtest: 200% zoom i webbläsaren
  4. Högkontrasttest: Aktivera Windows High Contrast

Nivå 2: Grundlig test (2-3 timmar)

  1. Skärmläsare grundligt: Testa kritiska flöden med NVDA/VoiceOver
  2. Mobil skärmläsare: VoiceOver på iOS och TalkBack på Android
  3. Röststyrning: Prova Voice Control (macOS/iOS)
  4. Endast tangentbord: Genomför hela användarresor
  5. 400% zoom: Testa vid maximal förstoring

Nivå 3: Experttest (med riktiga användare)

  • Användartester: Personer som faktiskt använder hjälpmedel dagligen
  • Olika hjälpmedel: Skärmläsare, röststyrning, switchar
  • Olika plattformar: Desktop, mobil, surfplatta
  • Verkliga scenarion: Låt användare genomföra faktiska uppgifter

Checklista för hjälpmedelskompatibilitet

För skärmläsare:

  • ☐ All funktionalitet åtkomlig med tangentbord
  • ☐ Semantisk HTML används korrekt
  • ☐ Alla bilder har alt-text (eller tom alt för dekorativt)
  • ☐ Formulär har korrekt kopplade labels
  • ☐ Rubriker skapar logisk struktur
  • ☐ Länkar är beskrivande utan kontext
  • ☐ ARIA används korrekt där nödvändigt
  • ☐ Live regions för dynamiska uppdateringar

För tangentbordsnavigation:

  • ☐ All funktionalitet med Tab, Enter, Space, Escape
  • ☐ Synlig fokusindikator på alla interaktiva element
  • ☐ Logisk tab-ordning
  • ☐ Inga tangentbordsfällor
  • ☐ Skip-länkar för att hoppa över navigation
  • ☐ Kortkommandon dokumenterade och avaktiverade vid konflikt

För förstoring och zoom:

  • ☐ Ingen horisontell scrollning vid 200% zoom
  • ☐ Text kan förstoras till 200% utan förlust av funktionalitet
  • ☐ Layout anpassar sig responsivt
  • ☐ Touch-targets minst 44x44px
  • ☐ Relativa enheter (em/rem) för text

För röststyrning:

  • ☐ Alla knappar och länkar har synlig text
  • ☐ Accessible names matchar synlig text
  • ☐ Unika namn på kontroller
  • ☐ Inte enbart ikonknappar utan text

För video och audio:

  • ☐ Alla videor har textning (captions)
  • ☐ Transkript tillgängligt för alla media
  • ☐ Media-kontroller tangentbordsåtkomliga
  • ☐ Autoplay kan stängas av

Vanliga misstag som bryter hjälpmedel

Misstag som påverkar skärmläsare

1. Div-knappslåda:

Problem: <div onclick="...">Klicka här</div>
Varför det är fel: Inte åtkomligt med tangentbord, inte igenkänt som knapp
Rätt: <button>Klicka här</button>

2. Saknade alt-texter:

Problem: <img src="product.jpg">
Varför det är fel: Skärmläsare säger bara ”image” eller filnamnet
Rätt: <img src="product.jpg" alt="Röd läderväska med justerbara axelband">

3. Placeholder istället för label:

Problem: <input placeholder="E-postadress">
Varför det är fel: Försvinner vid inmatning, inte tillgängligt för skärmläsare
Rätt: <label for="email">E-postadress</label><input id="email">

4. ”Klicka här”-länkar:

Problem: ”För mer info, klicka här”
Varför det är fel: Länken är meningslös utan kontext
Rätt: ”Läs mer om våra produkter”

Misstag som påverkar tangentbordsnavigation

1. Fokus inte synligt:

Problem: *:focus { outline: none; }
Varför det är fel: Omöjligt att se vad som är fokuserat
Rätt: Designa tydlig fokusindikator, använd :focus-visible

2. Tabindex-missbruk:

Problem: <div tabindex="0" onclick="..."> överallt
Varför det är fel: Skapar kaos i tab-ordning, använd rätt element
Rätt: Använd semantisk HTML, tabindex bara för edge cases

3. Tangentbordsfällor:

Problem: Modal utan Escape-hantering, fokus fastnar
Varför det är fel: Användare kan inte ta sig vidare
Rätt: Implementera fokus-trap med möjlighet att lämna (Escape)

Misstag som påverkar förstoring

1. Fixed pixel-storlekar:

Problem: font-size: 14px;
Varför det är fel: Skalas inte vid webbläsarzoom
Rätt: font-size: 0.875rem; (relativ till root)

2. Horisontell scrollning vid zoom:

Problem: Fixed width-containers vid 200% zoom
Varför det är fel: Användare måste scrolla horisontellt
Rätt: Responsiv design med max-width och flexible units

Misstag som påverkar röststyrning

1. Ikonknappar utan text:

Problem: <button aria-label="Spara">💾</button>
Varför det är fel: Användare kan inte säga ”klicka på spara” (ingen synlig text)
Rätt: <button>💾 Spara</button> eller använd sr-only text

2. Aria-label skiljer sig från synlig text:

Problem: Synlig text: ”Köp”, aria-label: ”Lägg i varukorg”
Varför det är fel: Röststyrning fungerar inte (”klicka på köp”)
Rätt: Aria-label ska inkludera synlig text

Vanliga frågor om hjälpmedel

Måste jag testa med alla hjälpmedel?

Nej, börja med de vanligaste: NVDA/JAWS på Windows, VoiceOver på Mac/iOS, TalkBack på Android, och tangentbordsnavigation. Om du följer standarder (WCAG 2.1 AA) och testar med dessa kommer de flesta andra hjälpmedel också att fungera.

Räcker det att testa med NVDA eller behöver jag JAWS också?

NVDA täcker majoriteten av testbehov och är gratis. JAWS har vissa unika funktioner och används mer i professionella sammanhang. För LPTT-compliance räcker NVDA för grundtestning, men lägg till JAWS för kritiska affärssystem om möjligt.

Hur ofta ska jag testa med hjälpmedel?

Idealt vid varje release. Som minimum: testa med skärmläsare och tangentbord vid större funktionsändringar, och inkludera automatiserade accessibility-tester i CI/CD. Användartest med riktiga hjälpmedelanvändare minst kvartalsvis för kritiska tjänster.

Kan jag lita på automatiserade tillgänglighetsverktyg?

Automatiserade verktyg hittar cirka 30-40% av tillgänglighetsproblem – främst tekniska fel som saknade alt-texter. De kan INTE bedöma om alt-texter är meningsfulla, om fokusordning är logisk, eller om innehåll är begripligt. Komplettera alltid med manuell testning.

Vad händer om jag använder ett JavaScript-ramverk som React/Vue/Angular?

Moderna ramverk kan skapa både utmärkta och fruktansvärt otillgängliga gränssnitt. Nyckeln är att förstå hur ramverket hanterar fokus, ARIA och DOM-uppdateringar. Använd tillgängliga komponentbibliotek (Headless UI, Radix UI, Material-UI med accessibility) och testa regelbundet med skärmläsare.

Hur hanterar jag dynamiskt innehåll som laddas via AJAX?

Använd ARIA live regions (aria-live=”polite” eller ”assertive”) för att meddela skärmläsare om uppdateringar. För större ändringar (som att ladda ny sida-innehåll), flytta fokus till det nya innehållet och ge tydlig feedback om vad som hände.

Fungerar hjälpmedel med PWA:s (Progressive Web Apps)?

Ja, om PWA:n är byggd med tillgänglighet i åtanke. PWA:s kan faktiskt vara mer tillgängliga än native appar om de följer web-standarder. Testa särskilt offline-funktionalitet, push-notiser och ”Add to Home Screen”-flödet med skärmläsare.

Vad är skillnaden mellan ”compatible with assistive technology” och ”accessible”?

”Compatible” betyder att hjälpmedel tekniskt kan läsa innehållet. ”Accessible” betyder att det också är användbart och begripligt. En sida kan vara compatible men oanvändbar om information är förvirrande eller navigation är komplex. Sikta på båda.

Hur testar jag om mina PDF:er fungerar med hjälpmedel?

Öppna PDF:en i Adobe Reader med en skärmläsare (NVDA, JAWS) aktiverad. Testa om du kan navigera med Tab, om rubriker finns, om formulär är ifyllbara, och om bilder har alt-text. Se vår guide: Skapa tillgängliga PDF-dokument.

Vad gör jag om ett tredjepartsbibliotek inte är tillgängligt?

Tre alternativ: 1) Hitta ett tillgängligt alternativ, 2) Fixa biblioteket själv och bidra tillbaka, 3) Bygg en egen tillgänglig version. För kritiska bibliotek utan tillgängliga alternativ kan du behöva investera i egen utveckling eller konsultstöd.