Beloppet för en åtgärdsplan i sig är vanligtvis begränsat: det är dokumentet med den prioriterade listan över problem, motsvarande tidsfrister och motivering för varför något är eller inte är brådskande. De verkliga kostnaderna ligger i nästa steg, det faktiska anpassningsarbetet på webbplatsen, webbutiken eller appen av en utvecklare. Och det beloppet varierar enormt, beroende på ett par faktorer som diskuteras nedan.
Vad som framför allt avgör det är inte antalet identifierade problem utan typen av problem och var det finns. En saknad färgkontrast på ett par rubriker kan lösas på en eftermiddag. En checkout-process som inte är möjlig att använda med ett tangentbord påverkar ofta den underliggande koden för en betald eller skräddarsydd komponent, och det tar märkbart längre tid. Åtgärdsplanen säger vad som måste göras och i vilken ordning; den säger inte hur många timmar en utvecklare behöver för det, eftersom det beror på hur webbplatsen är byggd.
Vart priset kommer ifrån
De flesta offerter för att åtgärda tillgänglighetsproblem är uppbyggda av tre delar: tiden för att förstå problemet, tiden för att åtgärda det och tiden för att kontrollera att lösningen också fungerar med en skärmläsare eller enbart med tangentbord. Den senare delen glöms ofta bort i en första bedömning, men det är precis där åtgärdningsarbete kan försenagas: en knapp som ser visuellt bra ut kan fortfarande inte meddela vad den gör för hjälpmedel.
En andra kostnad är själva plattformen. En webbutik på en standardplattform med väl underhållna teman har ofta redan mycket av grunderna på plats, såsom korrekt rubrikstruktur och grundläggande fokussekvens. En affärswebbplats med en skräddarsydd inloggningsmiljö eller ett eget checkout-flöde kan helt sakna denna grund, och då handlar det inte om att justera inställningar utan att skriva om komponenter. läsa per situation vad som exakt testas ger en bild av vilka delar av en webbplats vanligtvis kräver mest arbete.
En tredje faktor är vem som utför arbetet. Interna utvecklare som redan känner koden är ofta snabbare än en extern part som först måste ta reda på hur allt hänger ihop. Omvänt har en extern part som ofta gör denna typ av åtgärdningsarbete en fördel av erfarenheten med just denna typ av brister, såsom formuläretikettar eller alternativ text som saknas strukturellt.
Vad som inte minskar beloppet
En tillgänglighetswidget som hävdar att förbättra webbplatsen med ett klick löser ingen av dessa underliggande problem och minskar därför inte de faktiska kostnaderna. Sådan ett lager lägger till ett skikt på framsidan av webbplatsen, men den underliggande koden, formuläretiketterna, fokussekvensen förblir oförändrad. Tillsynsmyndigheter och lagstexten själv utgår från den faktiska tillgängligheten för den underliggande tjänsten, inte från vad en widget lovar att göra. Den som förlitar sig på detta skjuter bara upp kostnaderna för verklig åtgärning.
En annan missuppfattning är att allt måste åtgärdas på en gång för att spara kostnader på timtaxa. I praktiken fungerar ofta en fasad strategi billigare, eftersom de allvarligaste problemen — till exempel en checkout-process som inte kan slutföras med en skärmläsare — åtgärdas först, medan mindre problem såsom färgkontrast följer med i en vanlig underhållscykel. Det är precis där en prioriterad actiellista i vanlig språk tillför värde: utvecklare vet då var de ska börja först, i stället för att ta tag i allt samtidigt.
Vad axessia gör och inte gör
Axessia upprättar åtgärdslistan, dokumenterar vad som har testats och övervakar om en ändring av webbplatsen kräver omtestning. Det faktiska reparationsarbetet, skrivning av ny kod eller anpassning av ett tema, är din utvecklares eller byrås ansvar. Den skillnaden är avsiktlig: en automatiserad skanning kan inte testa alla krav, och utförande av reparationer kräver kunskap om din specifika plattform som en skanning inte har.
Den som vill veta vilken del av kostnaderna som är relevant för sin egen situation börjar med frågan om lagstiftningen är tillämplig. få en första indikation i ett par frågor visar om ett undantag gäller, till exempel för mikroföretag, innan man tänker på reparationskostnader. För den som redan vet att lagstiftningen gäller och är nyfiken på vad axessia:s egen rapportering och förklaring kostar, är det skilt från reparationsarbetet på översikten över prenumerationer och vad de innehåller.
Är du fortfarande osäker på någon del av din webbplats, eller vill du veta hur en tidigare testning genomfördes innan du kontaktar en utvecklare? läsa var bedömningen kommer från förklarar vilka källor som användes.
Den kostnadsfria snabbskanningen ger en första överblick över de största flaskhalsarna på ett antal kärnor utan att ett konto krävs. Det är en bra utgångspunkt för att bedöma hur mycket reparationsarbete som ungefär väntar innan du begär en offert från en utvecklare.