Är det dyrt att göra tillgängliga webbplatser?
Svaret skulle jag vilja säga är ja och nej, eller det “beror på”.
Det kan bli dyrt om man sitter på en befintlig webbplats där tanken på tillgänglighet inte funnits när man byggde den och inte tänkte på kontraster, koda enligt standarder och följa HTMLs semantik, ja, då kan det bli dyrt eftersom man ofta får göra om saker.
Men har man med tillgänglighet från början så behöver det inte bli så dyrt.
Ett par tips att att tänka på i början av ett projekt
Tänk på funktionsnedsättningar redan när ni gör user research. Prata med användare som har en funktionsnedsättning. En person som är blind brukar vara en bra början, och försök få se hur de använder sin skärmläsare när de använder webben.
Jag tycker man ska prata med människor som har andra funktionsnedsättningar också, så som någon form av kognitiv nedsättning. Där kan man lära sig mycket!
Kolla storlekar, avstånd och kontraster i designfasen. Det finns bra plugins i tex Figma för det så att en designer kan stämma av det löpande i sitt arbete. Jag brukar använda Stark - Contrast & Accessibility Checker till Figma när jag jobbar.
Det man kan ha lite extra koll på när man designar är att det inte bara är kontrast på text som har regler. Tänk även på hur ikoner, hover och focusmarkeringar ska se ut. Focusmarkering måste vara tydlig, gärna en ram runt objektet som har minst 3:1 i kontrast till sin omgivning, alltid vara synlig ska inte döljas av saker på sidan som kan ligga över den, så som popups och banners.
Använd välkända designmönster
Undvik gärna designmönster som kan vara utmanande, så som tabbar, karuseller och sidoscroll.
Här kan folk reagera på för det kanske ger lite mer begränsande design, men skulle vilja påstå att tabbar och framförallt karuseller är dålig UI för alla. Var istället kreativ och hitta lösningar som fungerar bättre för alla, oavsett funktionsnedsättning.
Man kan givetvis göra karuseller och tabbar tillgängliga också, men det krävs lite mer jobb och kan göra det lite onödigt komplext, vilket blir mer tid och då dyrare. Men väljer man den vägen ska allt vara klickbart och hanterbart med tangentbord och inte kräva rörelser som att dra. Man måste även tänka lite extra på att skicka information till skärmläsare att något har hänt, nytt innehåll har dykt upp och annat kanske försvunnit?
Att karuseller är till för att göra olika stekholders glada och varför det är dåligt för användaren har många skrivit om tidigare, till exempel Anton Sten “Why carousels don't work”.
Tabbar känns som att det kan vara ett OK mönster om det inte blir sidoscroll. Men blir det sidoscroll kan det vara en bättre idé att göra om dom till ackordion istället. Människor som har svårt med motoriken kan få problem om man ska växla mellan lodrätt och horizontell scroll. Tittar man för alla användare så försvinner ju innehåll åt sidan och det är lätt att missa. Även här kräv det lite mer av front-end koden så andra lösningar som att lista innehåll mer naturligt brukar vara att föredra för de flesta.
Koden är viktig
Koda enligt standard. Detta brukar lösa många problem. HTML är byggt enligt filosofin att den ska vara öppen och tillgänglig för alla. Följer man standards och kodar semantiskt så minimerar man problem. Givetvis finns det edge cases och designmönster där front-end utvecklaren måste göra lite extra, som att lägga till ARIA men som regel så löser sig mycket om man följer standarden. Det är alltid bättre att använda sig av korrekta semantiska element i HTML än att lösa problemen med ARIA i efterhand.
HTML är ett mark-up språk vars syfte är att beskriva för klienten som besöker sidan vad allt innehåll faktiskt är, struktur och hur det hänger ihop. CSS beskriver hur det sen ser ut. Skärmläsare bryr sig inte om CSS:en, de läser HTML och får information om vad som är huvudinnehåll, vad som är rubrik, bild och löptext.
Så även fast man kan koda en knapp med en div-tagg och lägga på roller och funktion i efterhand så är det alltid en sämre lösning än att använda korrekt HTML element. Tyvärr så finns det en del gamla webbplatser vid liv fortfarande där en del utvecklare inte brytt sig lära sig HTML och är det en sådan webbplats som ska tillgänglighetsanpassas så är det här den stora kostnaden kommer att vara.
Rubriker
Ett exempel på semantik där många gör fel är att de använder rubrik taggarna i HTML (H1, H2, H3 osv) för att ge ett visst utseende till en rubrik. Det kan leda till att man hoppar över rubriksnivåer på en sida vilket ställer till det för människor som använder till exempel skärmläsare. Många verktyg för att läsa webbplatser låter en användare navigera med att till exempel bara lista alla rubriker för sig, vilket ger en bra överblick om vad en sida handlar om och lättare för användaren att skapa en bra uppfattning om innehållet, hur det är strukturerat och hoppa till relevant del.
Det blir konstigt om en rubriksnivå 3 (H3) kommer före en rubriksnivå 2 (H2), Då 2 är viktigare och borde rama in rubriksnivå 3 (H3).
Separera gärna rubrikernas struktur och utseende. Skapa CSS klasser för utseendet och låt redaktören välja rubriksnivå och ett utseende om man använder ett innehållshanteringssystem.
Ett sätt är att skapa CSS klasser som utgår från till exempel t-shirt storlekar. Skapa klasser som heter till exempel “headin-XL”, “heading-L”, “heading-M” osv och ge dessa olika utseenden som redaktören sen kan välja mellan på vilken rubriks tagg hen vill.
Knappar och länkar
Ett annat vanlig misstag är att blanda knappar och länkar. Jag tror det här ibland har med utseendet att göra. Vissa CTA-länkar (call-to-actions) vill man ska ha en tydlig utformning som syns, och dessa brukar vara mer lika knappar än de vanliga länkarna. Istället för att göra en ny CSS-class så använder man en knapp.
Men en knapp och en länk har olika funktion. En knapp ska posta något, till exempel ett formulär.
En länk ska gå till en annan sida. Använd inte knappar som länkar då det förväntande beteendet blir fel och vissa hjälpmedel strular. Länkar och knappar kan få liknande utseende med CSS om man vill, men tänk på funktionen.
Landmarks
HTML har så kallade landmarks som strukturerar en sidas innehåll. Exempel är nav, main, aside med flera. De här berättar för klienten vad för typ av innehåll som finns var. Nav ska innehålla sidans navigering, och inte text innehåll om något ämne.
Main används för att markera ut var huvudinnehållet finns. Det är även den man kan använda för att skapa länkar som hoppar direkt till innehållet så att personer som använder skärmläsare inte behöver lyssna på hela sidans topp som logotyp och navigering.
Webbplatsens kod är viktig
Om ni vill läsa mer så har jag har skrivit lite mer om varför koden på en webbplats är viktig.
Sammanfattning
Anledningen till att många uppfattar Tillgängllighet som dyrt är att man ofta arbetar med befintliga webbplatser och digitala system, och sedan försöker “fixa till” dem så de blir tillgängliga. Tyvärr så finns det många exempel då det inte blir så lätt eftersom koden är gammal och man då ändå måste skriva om stora delar av koden.
Det finns också tyvärr en del utvecklare som inte kan koda HTML men ändå gör det. Jag vet att det finns många som tycker HTML verkar simpelt och slänger ihop lite HTML till en sida, och så blir allt div-taggar utan rätt semantik och struktur.
Och samma sak på design sidan. Finns lite för många designers med väldigt bra skärmar och sitter och designar “snygga saker” som syns bra på en högupplöst skärm med bra färgåterspegling, och testar aldrig på utrustning som vanligt folk har råd med.
Och sitter man med en gammal webbplats, kodad av någon som inte kan HTML, designad av en som inte kan kontraster, ja då kan det bli dyrt.
Men om man har med tillgänglighet ifrån början, då blir det inte mer jobb. Man löser problemen direkt och ser till att det inte blir utmaningar. Det kan ta lite mer tid att lösa vissa problem, beroende på målet med webben, designmönster som valts mm. Men det tar betydligt mindre tid än om man ska lägga på det senare.
Ha med funktionsnedsättning i minst en målgruppsbeskrivning. Och ha med en människa med funktionsnedsättning i testpanelen när man gör användartester. Man lär sig massor av nyttiga saker när man testar en webbplats med människor som använder hjälpmedel. Och i slutändan blir det ofta bättre för alla!
Länkar:
Tillbaka