Innehållsförteckning

Projekthanteringsverktyg som Jira och Azure DevOps är utmärkta för att systematiskt hantera tillgänglighetsbrister. Genom att integrera tillgänglighet i era befintliga processer kan ni spåra brister, prioritera åtgärder, fördela ansvar och dokumentera arbetet – både för internt förbättringsarbete och för rapportering till tillsynsmyndigheter som PTS.

Ärendehantering i tillgänglighetsarbetet: Jira och Azure DevOps

Ni har genomfört en tillgänglighetsgranskning och fått en lång lista med brister. Eller så vill ni börja bygga in tillgänglighet från start i era sprinter. Men hur får ni ordning på det i ert befintliga arbetssätt? Med rätt uppsättning i Jira eller Azure DevOps kan tillgänglighetsarbetet bli en naturlig del av er dagliga utveckling istället för en separat eller glömd punkt. Här får du konkreta tips på hur du strukturerar ärenden, skapar användbara mallar och följer upp arbetet mot LPTT och WCAG-kraven.

Varför integrera tillgänglighet i ärendehanteringen?

Att hantera tillgänglighet genom er befintliga ärendehantering istället för i separata dokument eller kalkylblad ger flera fördelar:

Tillgänglighet blir en naturlig del av Definition of Done. När tillgänglighetskriterier finns direkt i era user stories och tasks behandlas de som alla andra krav – inte som något ”extra” som lätt glöms bort. Varje ärende kan få tydliga acceptanskriterier som måste uppfyllas innan arbetet anses klart.

Spårbarhet och ansvar. Genom att använda samma system som resten av utvecklingsarbetet blir det tydligt vem som ansvarar för vad, vilka brister som återstår och vad som faktiskt har åtgärdats. Ingen behöver undra var informationen finns eller om rätt person har fått kännedom om ett problem.

Mätbarhet och rapportering. Med ärenden som är korrekt kategoriserade och märkta kan ni enkelt ta fram rapporter som visar tillgänglighetsstatus. Detta underlättar inte bara intern uppföljning utan även när ni behöver rapportera till ledning, ta fram underlag för tillgänglighetsredogörelsen enligt LPTT eller svara på frågor från PTS.

Grundläggande struktur för tillgänglighetsärenden

Det första steget är att bestämma vilka ärendetyper ni ska använda för tillgänglighetsarbetet. De flesta team har redan etablerade ärendetyper – använd dem, men tänk på följande:

Bug används för brister som upptäcks i befintlig kod eller design. En saknad alternativtext, otillräcklig kontrast eller en tangentbordsfälla är exempel på bugs relaterade till tillgänglighet. Behandla dessa med samma allvar som andra buggar – särskilt de som helt blockerar användare.

Story eller Task används för proaktivt tillgänglighetsarbete. När ni bygger en ny funktion ska tillgänglighetskraven finnas med från start som en del av storyn. Exempel: ”Som användare med skärmläsare vill jag kunna navigera formuläret med tangentbordet så att jag kan fylla i och skicka mina uppgifter.”

Epic används för större tillgänglighetssatsningar som sträcker sig över flera sprinter. Exempel: ”Uppfylla LPTT-kraven för vår kassaflöde” eller ”Implementera WCAG 2.1 AA för hela användarportalen”.

Viktiga fält att lägga till

För att kunna filtrera, prioritera och rapportera på rätt sätt behöver ni anpassa era ärenden med några tillgänglighetsspecifika fält. Här är de viktigaste:

WCAG-kriterium: Vilket specifikt kriterium som berörs, till exempel ”1.4.3 Kontrast (minimum)” eller ”2.1.1 Tangentbord”. Detta gör det enkelt att spåra vilka krav ni har koll på och vilka ni fortfarande behöver arbeta med.
WCAG-nivå: A, AA eller AAA. LPTT och European Accessibility Act (EAA) kräver nivå AA, så detta hjälper er att prioritera rätt.
Allvarlighetsgrad/Påverkan: Blocker, Critical, Major eller Minor. En brist som helt hindrar någon från att använda tjänsten (till exempel omöjligt att logga in med tangentbord) är en Blocker och bör hanteras akut.
Hjälpmedel som påverkas: Vilka hjälpmedel eller användargrupper som drabbas – skärmläsare, tangentbordsnavigering, förstoring, röststyrning. Detta hjälper er att förstå bredden på problemet.

Mallar för olika typer av tillgänglighetsärenden

Att ha färdiga mallar sparar tid och säkerställer att ni alltid samlar in rätt information. Här är tre grundmallar som fungerar för de flesta team:

Mall för tillgänglighetsbrist

Rubrik: [WCAG X.X.X] Kort beskrivning av problemet

Exempel: [WCAG 1.4.3] Otillräcklig kontrast på primärknappen

Beskrivning (template):

**Vad som är fel:**
[Beskriv problemet]

**Var felet finns:**
[URL eller komponent]

**WCAG-kriterium som inte uppfylls:**
[T.ex. 1.4.3 Kontrast (minimum), Nivå AA]

**Hur det påverkar användare:**
[Beskriv konsekvensen för användare]

**Föreslagen lösning:**
[Konkret lösningsförslag]

**Acceptanskriterier:**
- [ ] Problemet är åtgärdat
- [ ] Lösningen har testats med [relevant hjälpmedel/metod]
- [ ] Ingen regression har introducerats

Mall för proaktiv tillgänglighetsutveckling

Rubrik: Som [användarroll] vill jag [behov] för att [värde]

Exempel: Som användare med skärmläsare vill jag få tydlig feedback när jag skickar formuläret så att jag vet att min information har tagits emot

Tillgänglighetskriterier i Definition of Done:

All funktionalitet kan nås och användas med enbart tangentbord
Skärmläsare får tillgång till all information och feedback
Kontrast uppfyller WCAG 2.1 AA (minst 4.5:1 för normal text)
Innehållet fungerar vid 200% zoom
Formulärfält har tydliga etiketter och felmeddelanden
ARIA används korrekt där semantisk HTML inte räcker

Mall för tillgänglighetsepic

Målsättning: [Övergripande mål kopplat till LPTT/EAA]

Exempel: Säkerställa att vår e-handelslösning uppfyller LPTT-kraven inför deadline 28 juni 2025

Relevanta krav från EN 301 549:

Lista de mest kritiska kraven för er produkt/tjänst

Roadmap och milstolpar:

Sprint 1-2: Granskning och inventering
Sprint 3-5: Åtgärda kritiska brister
Sprint 6-7: Åtgärda övriga brister och testning
Sprint 8: Dokumentation och tillgänglighetsredogörelse

Etiketter och kategorisering

Etiketter (labels/tags) är kraftfulla verktyg för att snabbt filtrera och hitta rätt ärenden. Här är ett förslag på etikettstruktur som fungerar för de flesta organisationer:

Övergripande etikett:

tillgänglighet – Använd på alla tillgänglighetsrelaterade ärenden

WCAG-nivå:

wcag-a, wcag-aa, wcag-aaa

Funktionsområde eller hjälpmedel:

tangentbord – Tangentbordsnavigering och fokushantering
skärmläsare – Problem som påverkar skärmläsare
zoom – Förstoring och responsivitet
färg-kontrast – Färg och kontrastproblem
formulär – Formulärtillgänglighet
multimedia – Video, ljud, textning

Testtyp:

automatisk-test – Kan upptäckas av automatiska verktyg
manuell-test-krävs – Kräver manuell testning eller test med hjälpmedel

Arbetsflöden och statusar

Ett tydligt arbetsflöde hjälper teamet att förstå var varje ärende befinner sig i processen. Här är ett exempel på ett statusflöde som fungerar för tillgänglighetsärenden:

Backlog – Ärendet är identifierat men inte analyserat
Analyserad – WCAG-kriterium identifierat, lösning förberedd
Prioriterad – Inkluderad i en sprint, redo att börja arbeta med
I utveckling – Aktivt arbete pågår
Kodgranskning – Inkluderar både vanlig kodgranskning och tillgänglighetsgranskning
Testad med hjälpmedel – Manuell testning med skärmläsare, tangentbord etc. är genomförd
Klar – Ärendet är löst och alla acceptanskriterier uppfyllda
Verifierad av tillgänglighetsspecialist – (vid behov) Extern eller intern expert har verifierat lösningen

Anpassa detta flöde efter ert teams processer. Det viktigaste är att ni har ett steg för manuell testning med hjälpmedel – automatiska verktyg hittar bara cirka 30% av tillgänglighetsproblemen.

Integration med testverktyg

Moderna utvecklingsprocesser bygger på automatisering där det är möjligt. Här är några sätt att koppla tillgänglighetstestning till er ärendehantering:

Automatiserad testning i CI/CD-pipeline. Verktyg som axe-core, Pa11y eller Lighthouse kan köras automatiskt vid varje commit eller pull request. När dessa verktyg hittar nya problem kan de automatiskt skapa ärenden i Jira eller Azure DevOps, eller kommentera på befintliga pull requests.

Länka testresultat till ärenden. När ni kör manuella tester eller använder verktyg som Accessibility Insights eller WAVE, spara skärmdumpar och testrapporter direkt i ärendet. Detta ger värdefull dokumentation och gör det lättare för utvecklare att reproducera och förstå problemet.

Regressionsövervakning. Sätt upp automatiska tester som kollar att åtgärdade problem inte återkommer. Om en tidigare stängd brist upptäcks igen kan systemet automatiskt återöppna ärendet eller skapa en ny bug.

Dokumentera testmetod. För varje ärende, dokumentera vilka testmetoder som använts – automatiska verktyg, manuell tangentbordsnavigering, skärmläsartest (vilket verktyg och webbläsare), zoomtest etc. Detta är värdefullt både för reproduktion och för att visa PTS hur ni testar.

Rapportering och uppföljning

En av de största fördelarna med att ha tillgänglighetsarbetet i ärendehanteringssystemet är möjligheten att skapa dashboards och rapporter. Här är komponenter som är särskilt användbara:

Dashboard-komponenter

Antal öppna tillgänglighetsärenden per WCAG-nivå – Visar hur många A- respektive AA-brister som återstår
Genomsnittlig tid till lösning – Hjälper er identifiera flaskhalsar
Fördelning per komponent/team – Var finns flest problem? Behöver något team extra stöd?
Trender över tid – Går det åt rätt håll? Skapas nya brister snabbare än ni hinner åtgärda dem?
Status mot LPTT-deadline – Hur många kritiska ärenden måste lösas före deadline?

Exempel på användbara filter

Alla ärenden märkta som Blocker eller Critical med etiketten wcag-aa
Alla tangentbordsrelaterade brister som är äldre än 30 dagar
Ärenden som väntar på tillgänglighetsspecialistverifiering
Stängda ärenden senaste månaden (för att visa framsteg)
Alla ärenden märkta med lptt-krav som inte är klara

Praktiska tips och best practices

Här är några konkreta tips som gör tillgänglighetsarbetet i ärendesystemet mer effektivt:

Involvera tillgänglighetsexpertis tidigt i refinement. Låt en tillgänglighetsspecialist (intern eller extern) delta när ni bryter ner epics till stories. Det är mycket enklare och billigare att bygga rätt från början än att åtgärda i efterhand.

Inkludera tillgänglighetskriterier i alla user stories. Även om en story inte explicit handlar om tillgänglighet bör Definition of Done alltid inkludera grundläggande tillgänglighetskrav. Detta normaliserar tillgänglighet som en självklar del av kvalitet.

Använd komponenter eller kort som kan återanvändas. I Jira kan ni skapa ”Component” för olika delar av er produkt. I Azure DevOps kan ni använda ”Area Path”. Detta gör det enkelt att se vilka delar av produkten som har flest tillgänglighetsproblem.

Dokumentera designbeslut som påverkar tillgänglighet. Använd kommentarfältet eller länka till Confluence/Wiki-sidor där ni förklarar varför en viss lösning valdes. Detta är ovärderligt när någon undrar varför något är gjort på ett visst sätt.

Ha regelbundna retrospektiv om tillgänglighetsarbetet. Avsätt tid i era retrospektiv för att diskutera vad som fungerar och inte fungerar i tillgänglighetsarbetet. Behöver ni fler mallar? Bättre verktyg? Mer utbildning?

Koppla ärenden till dokumentation. Länka från ärenden till relevant dokumentation – designsystem, kodningsriktlinjer, WCAG-kriterier, interna guider. Detta sparar tid och säkerställer att alla har tillgång till samma information.

Vanliga fallgropar att undvika

Lär av andras misstag. Här är de vanligaste problemen vi ser när team börjar hantera tillgänglighet i sina ärendesystem:

Att samla alla brister i ett stort ärende. ”Fixa tillgänglighet på startsidan” är för stort och otydligt. Bryt ner i specifika, testbara ärenden – ett per problem eller per WCAG-kriterium. Detta gör det enklare att prioritera, delegera och följa upp.

Att inte prioritera kritiska blocker för användare. En knapp med lite för svag kontrast är mindre allvarligt än ett formulär som är helt omöjligt att skicka med tangentbord. Använd allvarlighetsgrader på ett meningsfullt sätt och behandla verkliga blockers som akuta buggar.

Att glömma verifiera med riktiga hjälpmedel. Att ett automatiskt verktyg säger ”OK” betyder inte att allt faktiskt fungerar. Testa alltid manuellt med tangentbord, skärmläsare och andra relevanta hjälpmedel innan ni stänger ett ärende.

Att inte involvera utvecklare i lösningsdiskussioner. Tillgänglighetsspecialister kan identifiera problem, men utvecklare är ofta de som hittar de mest eleganta lösningarna. Skapa dialog, inte envägskommunikation.

Att sakna tydliga acceptanskriterier. ”Ska vara tillgängligt” är inte ett acceptanskriterium. ”Alla formulärfält ska ha synliga och tillgängliga etiketter kopplade med for/id” är ett acceptanskriterium som går att verifiera.

Frågor och svar

Hur många ärenden skapar man från en tillgänglighetsgranskning?

Det beror på omfattningen av problemen, men en typisk granskning av en större webbplats kan resultera i 50-200 ärenden. Det är viktigt att bryta ner till hanterbara ärenden – varje ärende bör vara specifikt nog att en utvecklare kan lösa det i en sprint. Gruppera gärna liknande problem (till exempel ”Alla knappar saknar accessible name i komponent X”) men undvik att blanda helt olika problem i samma ärende.

Ska tillgänglighetsbrister alltid vara bugs?

Nej, inte alltid. Brister i befintlig funktionalitet är typiskt bugs. Men om ni bygger något nytt och vill säkerställa tillgänglighet från start, inkludera kraven i storyn istället. Tumregel: Om något har släppts till produktion och är felaktigt = bug. Om något ska byggas och ni vill säkerställa att det blir rätt = del av story/task.

Hur prioriterar vi tillgänglighetsärenden mot annan backlog?

Börja med att identifiera vad som är absoluta blockers – funktionalitet som helt hindrar användare från att utföra kritiska uppgifter. Dessa bör få högsta prioritet, i nivå med andra kritiska buggar. För övriga tillgänglighetsbrister, väg in:

Antal användare som påverkas
Allvarlighetsgrad av påverkan
Lagkrav (LPTT-deadline)
Teknisk komplexitet och risk
Affärsvärde och användarnytta

Många organisationer väljer att alltid ha en viss procentandel av sprintkapaciteten dedikerad till tillgänglighetsarbete.

Vem ska ansvara för att skapa tillgänglighetsärenden?

Det beror på hur ärendet upptäckts. Efter en formell granskning skapar ofta tillgänglighetsspecialisten eller testaren ärendena. Under utveckling kan utvecklare och designers skapa ärenden när de upptäcker problem. Det viktiga är att någon har mandat och ansvar att se till att identifierade problem faktiskt dokumenteras och hamnar i backlog. Många team utser en ”tillgänglighetschampion” som har övergripande ansvar.

Hur hanterar vi tredjepartskomponenter som inte är tillgängliga?

Detta är en vanlig utmaning. Skapa ärenden även för tredjepartsproblem, men märk dem tydligt (till exempel med etikett tredjepartskomponent). Dokumentera problemet och vilken leverantör det gäller. Lösningarna kan vara:

Kontakta leverantören och be om en fix (inkludera tidslinje i ärendet)
Hitta en alternativ lösning eller ett annat verktyg
Bygga ett eget accessible wrapper runt komponenten
I värsta fall: dokumentera problemet som en känd begränsning i er tillgänglighetsredogörelse

Att ha dessa ärenden dokumenterade visar också PTS att ni är medvetna om problemen och aktivt arbetar med dem.

Ärendehantering i tillgänglighetsarbetet med Jira och Azure DevOps