Tillgänglighet i webbprojekt från start

Tillgänglighet på webben handlar inte bara om regler och checklistor. Det handlar om att bygga webbplatser och webbapplikationer som fler människor faktiskt kan använda.
För utvecklare blir tillgänglighet ofta som svårast när den kommer in för sent i projektet. Då kan färger, typografi, komponenter, formulär och interaktioner redan vara byggda på ett sätt som kräver mycket arbete att ändra.
Därför är det smart att tänka på tillgänglighet redan från början. Inte för att allt måste bli perfekt direkt, utan för att många viktiga beslut tas tidigt i design och utveckling.
Använd variabler för färger och typografi
Ett enkelt sätt att göra ett projekt mer hållbart är att använda variabler för färger och typografi, till exempel CSS-variabler eller design tokens.
Det gör det lättare att samla färger, textstorlekar, radavstånd och andra grundvärden på ett ställe i stället för att sprida ut dem över hela projektet.
Om en textfärg eller bakgrund senare visar sig ha för dålig kontrast behöver man inte leta igenom varje komponent manuellt. På samma sätt blir det enklare att justera textstorlekar, rubriknivåer och radavstånd om läsbarheten behöver förbättras.
Det blir också enklare att arbeta med teman, till exempel ljust och mörkt läge. I vissa sammanhang behöver webbplatser och appar kunna respektera användarens egna inställningar för färgtema, kontrast och textstorlek. Även när det inte är ett direkt krav är det en bra teknisk grund att inte låsa fast hela gränssnittet i hårdkodade färger och typografiska värden.
Variabler löser inte tillgänglighet automatiskt, men de gör det mycket lättare att justera och förbättra gränssnittet över tid.
Tänk på kontraster tidigt
Kontrast är en av de vanligaste sakerna som skapar tillgänglighetsproblem.
Det kan handla om ljusgrå text på vit bakgrund, knappar som inte syns tillräckligt tydligt eller formulärfält där felmeddelanden bara visas med färg.
Om kontraster testas först i slutet av projektet kan det leda till att stora delar av designen behöver justeras. Därför är det bättre att kontrollera färger och textnivåer redan när komponenter och vyer tas fram.
Bra kontrast gör inte bara sidan mer tillgänglig. Det gör den också lättare att läsa och använda för alla.
Testa löpande med verktyg
Automatiska verktyg kan inte avgöra om en webbplats är helt tillgänglig, men de är väldigt användbara som första kontroll.
Lighthouse i webbläsaren kan till exempel hitta vissa vanliga problem, som saknade namn på knappar, bristande kontraster eller enklare strukturella fel.
Det är också bra att komplettera med andra verktyg och kontroller under utvecklingen. Poängen är inte att vänta tills allt är klart, utan att testa löpande så att problemen upptäcks medan de fortfarande är enkla att åtgärda.
Om tillgänglighet bara testas precis innan lansering finns risken att man behöver göra om mycket i efterhand.
Testa med tangentbord
Ett av de enklaste manuella testerna är att använda sidan utan mus.
Går det att tabba sig igenom navigation, länkar, knappar och formulär? Syns det tydligt vilket element som är aktivt? Går det att öppna menyer, stänga modaler och skicka formulär med tangentbord?
Det här testet avslöjar ofta problem som automatiska verktyg inte alltid fångar.
För många användare är tangentbordet inte ett alternativt sätt att använda sidan. Det är det huvudsakliga sättet.
Testa med riktiga hjälpmedel
Det är också värdefullt att testa med riktiga hjälpmedel, till exempel en skärmläsare.
På Mac finns VoiceOver inbyggt, och på Windows används ofta verktyg som NVDA. Man behöver inte vara expert från början, men även enkla tester kan ge mycket insikt.
Det kan snabbt visa om rubrikerna är logiska, om knappar har begripliga namn och om formulär går att förstå utan att se hela sidan visuellt.
Det gör också tillgänglighet mindre abstrakt. Man märker ganska snabbt om sidan faktiskt går att använda eller om den bara ser bra ut.
Bygg komponenter på rätt sätt från början
Många tillgänglighetsproblem uppstår i komponenter som återanvänds över hela webbplatsen.
Om en knapp, meny, modal eller formulärkomponent byggs fel från början kan samma problem spridas till många olika sidor.
Därför är det viktigt att använda rätt HTML och rätt beteende. En knapp ska vara en knapp. En länk ska vara en länk. Formulärfält ska ha tydliga labels. Felmeddelanden ska gå att förstå utan att bara förlita sig på färg.
När grundkomponenterna är tillgängliga blir resten av projektet betydligt enklare att hålla på en bra nivå.
Det är bättre att börja än att strunta i allt
Tillgänglighet kan kännas stort. Det finns många riktlinjer, verktyg och detaljer att hålla reda på.
Men det betyder inte att man ska ge upp.
Det är bättre att göra det man kan än att låta bli helt för att det känns svårt. Börja med kontraster, rubrikstruktur, tangentbordsnavigation, formulär och tydliga komponenter.
I nya projekt kan tillgänglighet bli en naturlig del av arbetet. I befintliga projekt kan man förbättra steg för steg.
Det viktiga är att se tillgänglighet som en del av kvaliteten, inte som något extra som bara görs om det finns tid kvar.
Behöver du hjälp att bygga mer tillgängliga webbplatser och webbapplikationer?
Vill du bygga en ny webbplats eller webbapplikation där tillgänglighet finns med från start?
På Probyte hjälper vi företag att planera, utveckla och förbättra digitala lösningar med fokus på struktur, användbarhet och teknisk kvalitet.
Tillgänglighet behöver inte göra ett projekt krångligare. Rätt hanterat gör det lösningen bättre.