Digital Tillgänglighet - behöver inte vara så dramatiskt

Har du någon gång jobbat i ett team som fått en tillgänglighetsrapport i knät efter det att ni levererat en app eller en webbplats så vet du vad jag menar.

Tillgänglighetsfrågor, liksom även prestandafrågor och arbete med bra användarupplevelser, kan snabbt bli något som lätt prioriteras ner när budgetramar krymper. Den tid som man tilldelats för ett projekt har ätits upp av oförutsedda utmaningar längs projektets väg till leverans.

Allt sammantaget – har man råkat ut för sådana prioriteringar kan det antagligen kännas som att det där med tillgänglighet – hur viktigt det än är – blir mer ett hinder än en möjlighet för projektet.

Utifrån hur det ser ut på många webbplatser som idag finns på nätet verkar det vara alldeles för vanligt att just tillgänglighetsfrågor prioriteras ner i många projekt.

Men behöver det verkligen vara så?

Tillgängligt för vem?

En människa med funktionsnedsättning är inte en människa med särskilda behov utan en människa med vanliga behov som måste tillgodoses av särskilda insatser!

När vi bygger webbplatser och appar har vi tillgång till en hel del hjälpmedel i de plattformar vi bygger för. Det kan vara så enkla saker som att webbläsaren tillåter sin användare att välja hur stor text denne föredrar. Det kan också vara hjälpmedel som användaren kan installera för att till exempel få sin skärm uppläst, eller visad i punktskrift, eller förstorad.

Men vilka är då de där människorna med funktionsnedsättningar – och varför skall vi bry oss om dem egentligen?

Funktionshinder?

Jo – jag menar att vi till att börja med behöver fråga oss om det verkligen finns ett entydigt ”vi” (som inte är funktionsnedsatta) och ett entydigt ”dom” (som är det).

Den traditionella bilden vi har av en funktionshindrad människa har antagligen präglats av symbolen för funktionsnedsättning – rullstolen – tillsammans som många av oss som utvecklar för webben har fått höra att ”Google is blind”.

Dvs vi har på ett eller annat sätt antagligen inletts i synsättet att funktionsnedsättningar har med sjukdom eller det vi traditionellt kallat handikapp att göra.

Men idag börjar insikterna om att det är betydligt mer nyanserat än så och att vi alla – oavsett förutsättningar – under olika faser i livet kommer att vara funktionsnedsatta på ett eller annat sätt.

Det är enkelt att inse att du kommer ha problem att ta dig uppför en brant trappa när du brutit benet, kör en barnvagn eller om du efter en bilolycka tillfälligt sitter i rullstol (och då uppskattar den där rampen eller hissen som finns i närheten).

Men en funktionsnedsättning behöver inte bero på något fysiskt, utan kan också vara tillfälliga och uppkomma genom mer vardagliga omständigheter.

Kort sagt – funktionshinder är något vi alla berörs av i olika omfattning och det där med tillgänglighet är något som berör oss alla förr eller senare – i olika omfattning.

Inkluderande synsätt?

Tekniskt?

Att bygga tillgängliga webbplatser och appar handlar i grunden om att försöka förstå och respektera de funktioner som redan finns i våra plattformar.

I mångt och mycket syftar kraven i WCAG (Web Content Accessibility Guidelines från W3c – riktlinjerna som ligger till grund för alla svenska tillgänglighetsregler och lagar) till att vi inte oavsiktligt bygger bort tillgänglighetsanpassningar.

… eller mänskligt?

Att bygga tillgängligt är för mig som så mycket annat i livet – som t.ex. städning, deklarationen eller julklappsshoppingen – skjuter man upp det för länge så blir det bara mer och mer att hantera ju längre man väntar…

… och man skjuter kanske upp det mer för att det känns jobbigt än för att det verkligen är det om man tar tag i det innan det nästan är försent.

Så vad gör vi då?

Att leverera tillgänglighet har tekniskt stora likheter med både att leverera användarvänlighet och att leverera prestanda.

Antingen har man en prestandabudget eller användartester inplanerade för att mäta användarvänlighet som man hanterar vid typ varje sprintavslut. Det kan även vara andra mekanismer som gör att man kan upprätthålla målen på prestanda/användarvänlighet genom hela projektet. Då ska den vara förankrad både hos kravställare, beställare, projektledare och hos medlemmarna i teamet…

… eller så riskerar man att åka på att anpassa det man byggt i efterhand (typ sätta dyrt läppstift på en gris). Det leder till att man riskerar att behöva bygga om en massa med allt vad det innebär i efterhand.

WCAG är omfattande, men tar man sig an även tillgänglighet systematiskt genom hela projektet blir det mer hanterbart. Exempelvis att man kör valideringsverktyg som en del av all acceptanstestning, använder automatiserade tester av de tillgänglighetskrav som kan automattestas i byggkedjor i sina utvecklingsverktyg och byggservrar osv.

Min erfarenhet är att man kommer långt genom att börja med det lilla (plocka den lågt hängande frukten först), och sedan steg för steg lära sig mer. På webben kanske det handlar om att se över sina rubrikstrukturer (används för navigering vid uppläsning), eller undersöka om man verkligen har kontraster nog mellan text och bakgrunder för att någon skall kunna läsa det som står under en solig vårutflykt. Det kan också handla om att upptäcka att man kanske råkat öppna för oavsiktliga funktioner (högerklicka och ”öppna i ny flik” t.ex. som lätt kan hända när man använder en länk istället för en knapp genom att ge länken ett snyggt, knappliknande, utseende). Eller tvärtom, råkar bygga bort möjligheter (genom att t.ex. använda en knapp för att navigera till en ny sida istället för en länk – vilket stänger av alla möjligheter att använda högermenyn).

Hursomhelst – börjar du använda de verktyg som finns därute (som webbläsartillägg och valideringswebbplatser) kommer du snart att hitta en mängd tips på hur du bygger dina produkter för att undvika sådant rent tekniskt. Allt kan inte automatiseras eller testas med verktyg (begriplighet osv finns också med bland kraven) – men börjar med sådant somkan automattestas brukar även uppfyllelse av resten av kraven bli mer eller mindre hanterbart.

Anpassning för några kan ge mer värde åt alla.

Utmana dig själv!

Den 16 maj är det den årligen återkommande Global Accessibility Awareness Day (”GAAD”)

En dag där vi som jobbar med tillgänglighet uppmanas att sprida förståelse och insikt kring hur det kan vara att använda webb och appar när man har funktionsnedsättningar.

Syftet med GAAD är att öka förståelsen för hur de system vi använder eller bygger kan upplevas av besökare som av olika orsaker påverkas av funktionsnedsättningar.

Du kan delta med så enkla medel som att gå ut en stund i solen med din skärmintensitet neddragen och surfa en stund på din mobiltelefon, försöka se en film på telefonen utan att ha hörlurar inkopplade medan du åker kollektivt, eller varför inte försöka sköta dina vardagliga datorsysslor utan mus/pekplatta i en halvtimme.

Blev du nyfiken?

Det finns mycket mer att säga om hur man sätter sig in i tillgänglighetsarbete. Det jag hoppas ha kunnat ge dig med den här bloggtexten är en nyfikenhet på hur du kan gå vidare och lära dig mer. på Webstep har vi flera kollegor som är engagerade i tillgänglighetsfrågor och som har erfarenhet av att arbeta med det tillsammans med våra kunder. Mitt syfte med det här blogginlägget är att inspirera och förhoppningsvis få flera att förstå hur viktig tillgänglighet är – och hur enkelt det kan vara.

På https://webbriktlinjer.se/#tidsbudget finns fler utmaningar och tips på hur du kan utmana dig själv ytterligare – där finns också länkar till flera bra verktyg och en mängd bra information för att bygga på din kunskap kring webbtillgänglighet.