Gör rätt från början

Jag har nämnt tidigare hur det här området - Robust - med endast en riktlinje (Kompatibilitet) och två kriterier, nästan är så tydlig som den kan vara redan i rubriksättning. Bygg enligt standarder och säkerställ att din lösning är kompatibel med alla typer av webbläsare.

Låt oss ändå titta på de två kriterierna:

Nivå A

  • 4.1.1 I allt innehåll som implementeras med markup-språk (alltså HTML), så ska element ha fullständiga start- och slut-taggar, de ska vara hierarkiskt strukturerade enligt sina specifikation, det ska inte finnas dubletter och alla ID:n ska ara unika, förutom när specifikationerna tillåter dessa egenskaper.
    Detta kriterium ströks i och med version 2.2 av WCAG. För bakgrund och historik, läs gärna Christophe Strobbes genomgång The Troublesome Life and Lamentable Death of Success Criterion 4.1.1. Strobbe var med och författade ursprungliga 4.1.1.
  • 4.1.2 För alla komponenter i ett användargränssnitt (inklusive men inte begränsat till: formulär-element, länkar och komponenter som genereras av skript), så kan namn och roll utläsas programmatiskt; inställningar, egenskaper och värden som kan bestämmas av användaren kan ställas in programmatiskt; och notifieringar om förändringar finns tillgängliga för webbläsare, inklusive assisterande teknik.

Nivå AA

För robust finns ett nytt kriterium i version 2.1:

  • 4.1.3 version 2.1 Statusmeddelanden. I innehåll som implementerats med markup-språk (HTML) kan statusmeddelanden tolkas programmatiskt genom role eller egenskaper, så att de kan presenteras för användaren med hjälp av assisterande teknik utan att få fokus.

Tydligheten till trots så blir det ju tyvärr ofta fel och det är nog felkällorna som vi bör fokusera på så att vi kan minimera skapandet av lösningar som bidrar till en sämre webb.

Varför så många inte bygger rätt

  • Utbildningarna är bristfälliga. Kurser och utbildningsprogram för webbutvecklare innehåller alldeles för lite kunskap om specifikationer generellt och tillgänglighet i synnerhet. Vi har alltså tusentals webbutvecklare som tar examen varje år med bristande förmågor inom dessa områden. Resultatet blir skapandet av webbtjänster som då av naturliga skäl inte lever upp till vad som kan definieras som kompatibel och tillgänglig webb.
  • Webbägare är ovetande om inkluderande design. Okunskapen sträcker sig förstås ofta hela vägen genom projekt även till de som beställer och förvaltar digitala tjänster. Om man inte tidigt mäter och utvärderar kompatibilitet, och hur man gör det möjligt för fler människor att använda en tjänst, så sitter man snart med en stor härva av otillgängliga lösningar.
  • Otestad extern kod. Många utvecklare vill gärna arbeta mer effektivt och med den senaste tekniken; inte sällan vänder man sig då till färdig kod och färdiga bibliotek från webben. Tyvärr gås denna externa kod sällan igenom för att säkerställa att den uppfyller WCAG:s riktlinjer och kriterier. Resultatet blir att man sitter med flera olika bibliotek där utvecklare har dålig insyn och ingen känner personligt ansvar för koden; samtidigt som alla dessa kan vara bidragande till att många människor inte kan använda en tjänst.
  • Orimliga kravställningar på tid. Det ställs ofta orimliga krav på att lösningar ska hinnas klart inom en viss tid och på ett sätt som lever upp till en ogrundad föreställning om modern, interaktiv webb. Tidspress är en stor källa till dåliga beslut, och därför ett stort skäl till att det blir fel. Om färdigställande i tid gör kunden mer nöjd än hög kvalitet - speciellt när kunden inte kan se skillnad - så kommer också hastighet alltid vinna över god design.
  • Konkurrens i form av tid och pris. Eftersom det ofta går att bygga undermåliga lösningar snabbare och billigare än inkluderande lösningar så kommer undermåliga lösningar fortsätta att vinna många upphandlingar. Undermåliga lösningar kan på ytan se ut precis som en välkonstruerad lösning, men när beställare och webbägare inte har förståelse för hur man inkluderar fler männniskor på webben så kommer tjänster byggas och lanseras utan att denna aspekt följs upp på ett rimligt sätt. Det funkar precis på samma sätt som byggfusk i fastighetsbranschen.
  • Publiceringsverktygen stjälper mer än de hjälper. Om man sitter som innehållsansvarig för en större webbplats så har man också ett löpande redaktionellt ansvar för att leva upp till WCAG, till exempel när det gäller textalternativ och språk. Trots att WCAG 2.0 har funnits sedan 2008 så klarar många etablerade publiceringsverktyg fortfarande inte av att låta webbredaktörer på ett enkelt sätt ange språk för ett enskilt ord/stycke, eller skriva olika ALT-texter för bilder beroende av sammanhang.

Så vad blir lösningen på alla dessa problem? För att göra rätt måste vi satsa på kunskap och förmåga. Fler som ansvarar för digitala lösningar måste inse vad deras ansvar är gentemot alla människor som borde kunna använda tjänsten. När kunskapen finns kommer fler också förhoppningsvis förstå vad som krävs i form av tid för utveckling, och för löpande undersökningar och studier. Då kan vi hjälpas åt att ta fram utvecklingsstöd och verktyg som även har fokus på att bibehålla kvalitet, inte bara kapa tid.

Vi bygger digitala lösningar för människor. Det finns ingen rimlig anledning att satsa på att bygga för färre människor än vi har möjlighet till.