Innehållsförteckning
Detta är en guide för att etablera ett designsystem som systematiskt stödjer tillgängliga digitala produkter i enlighet med LPTT och EN 301 549. Innehållet fokuserar på prioriterade beslut, tydlig ansvarsfördelning mellan designer, utvecklare och produktägare samt nödvändiga kvalitetskontrollpunkter inför varje release. Målet är en effektiv och spårbar utvecklingsprocess där komponenter byggs, utvärderas och vidareutvecklas med konsekvent kvalitet och hög återanvändning.
För designers
- Färg och kontrast: Ta fram ett litet, testat färgset med godkända par (text–bakgrund, ytor, status).
- Typografi: Bestäm hierarkier och miniminivåer (storlek/line-height). Ingen text i bilder.
- Stater: Skissa alltid focus/hover/active/error/disabled/loading.
- Ikoner & meningsbärande färg: Lägg alltid till text eller mönster som inte bara bygger på färg.
För utvecklare
- Semantik först: Använd inbyggda HTML-element. ARIA bara när det behövs.
- Tangentbord: All interaktion ska fungera med tab/shift+tab/enter/space/piltangenter.
- Fokus: Tydlig, synlig fokusmarkering – aldrig avstängd.
- Zoom & reflow: Fungerar till 400 % utan horisontell scroll. Testa i verkliga webbläsare.
För produktägare
- Ägarskap och budget: Designsystmet är en produkt. Ge ett litet core-team tid att förvalta.
- Kvalitetskontrollpunkter: Kräv a11y-check innan “klar”. Koppla till Definition of Done.
- Adoption: Styr mot återanvändning. Mät avvikelser (egna komponenter) och ta bort duplicat.
- Spårbarhet: Spara beslut, versioner och testresultat så det går att visa efterlevnad.
Startpaket: 10 steg för att komma igång
- Sätt mål: “återanvändning + tillgänglighet” och välj ett litet komponent-scope.
- Ta fram tokens (färg/typografi/spacing) med verifierad kontrast.
- Välj 6–10 kärnkomponenter (knapp, länk, formulärfält, etikett, varningsruta, dialog, lista, navigation).
- Skissa stater och felmeddelanden för varje.
- Bygg web-komponenter med semantik och tangentbordsstöd från dag 1.
- Lägg in automatiska a11y-tester (t.ex. axe-core) i CI.
- Testa med skärmläsare (NVDA/VoiceOver) och 400 % zoom innan release.
- Skapa enkla “do/don’t”-exempel för rätt användning (bilder räcker).
- Bestäm hur ändringar föreslås och godkänns (en lätt RFC-kanal räcker).
- Släpp version 0.x och förbättra i små steg. Hellre litet och stabilt än stort och spretigt.
Kontrollpunkter (inför varje släpp)
- Kontrast godkänd: för alla statusfärger och teman.
- Tangentbordsnavigering: kan du skapa, använda och stänga allt utan mus?
- Skärmläsare: namn/roll/tillstånd läses korrekt; fokus förloras inte.
- Zoom & reflow: inget innehåll klipps; interaktion fungerar.
- Fel & tomt läge: tydliga texter, inte bara färg/ikon.
Vanliga fallgropar
- “Vi börjar med 40 komponenter” → börja med 6–10.
- Färgsystem utan testade par → gör färgpar, inte bara paletter.
- Fokuindikatorer som nästan inte syns.
- Felmeddelanden som göms bakom hover eller ikoner.
- ARIA som ersätter semantik i onödan.
Frågor och svar
Måste vi ha dark mode från start?
Omfattas ni av lagen så är det krav på dark mode för mobila appar. Det kan därför vara bra att ta höjd för att behöva stödja dark mode på webben. Bygg tokens så att teman går att lägga till och testa kontrast när ni gör det.
Räcker automatiska a11y-tester?
Nej. De fångar ~30–40 %. Gör manuella tester (till exempel med tangentbord) innan release.
När ska vi skapa nya komponenter?
När ni hittar ett återkommande mönster som flera produkter behöver och det inte går att lösa med befintliga varianter.
Hur visar vi att vi följer LPTT och EN 301 549?
Spara testresultat per release, länka varje komponent/mönster till relevanta WCAG-kriterier och behåll beslutslogg.
Hur hanterar vi rörelse och animationer?
Minimalt, funktionellt, och respektera “prefers-reduced-motion”. Ge alternativa mönster.