Huruvida du kan lösa tillgänglighetsproblem själv beror mycket på vilken typ av problem det är. En saknad alternativ text för en bild eller för låg färgkontrast i din visuella profil kan du i många fall anpassa själv, ofta direkt i ditt CMS. Ett betalningssteg som inte fungerar med en skärmläsare, eller ett inloggningsformulär där fokus inte hoppar logiskt, kräver vanligtvis någon som känner till den underliggande koden.
Gränsen ligger alltså inte vid "teknisk eller inte", utan vid djupet på förändringen. Texter, etiketter, färger och innehållsstruktur är vanligtvis inom räckhåll för en kontorschef eller marknadsförare. Interaktiva komponenter, som en kundvagn, ett filter med tangentbordsnavigering eller en steg-för-steg betalprocess, påverkar ofta koden i ditt tema, dina skräddarsydda komponenter eller de plugin-program du använder. Där behövs vanligtvis en utvecklare som vet hur ARIA-attribut, fokusordning och felmeddelanden för formulär fungerar i praktiken.
Vad som rimligen ligger inom dina möjligheter
Många mindre problem är snarare en fråga om rutiner än om teknisk kunskap. Tänk på att fylla i alt-texter för varje ny bild, kontrollera att rubriker är i rätt ordning, eller anpassa en färgkontrast i din stilguide. Det är också möjligt att själv upprättar den obligatoriska tillgänglighetsförklaringen och dokumentera din egen bedömning; med rätt mallar kan du göra dessa steg själv. Läs mer om detta i förklaringen per krav i kunskapsdatabasen.
Vad som ofta underskattas är underhållet. En webbplats förändras ständigt: en ny sida, ett annat formulär, en omarbetad knapp. Varje ändring kan återinföra ett tidigare löst problem. Att hålla reda på detta själv är inte i sig ett tekniskt problem, men det är en process som kräver strukturerad uppmärksamhet, inte en engångsåtgärd.
Där gör-det-själv tar slut
Vissa problem sitter djupare än text eller formatering. Ett betalningssteg som bara kan hanteras med musen, en popup-ruta som inte fångar tangentbordsfokus, eller en sökfunktion som inte meddelar felmeddelanden för en skärmläsare: dessa är situationer där kodstrukturen själv måste förändras. Det handlar inte om att justera en inställning, utan om att bygga om eller skriva om en komponent. För denna typ av arbete krävs vanligtvis en utvecklare, en front-end-specialist eller en leverantör med erfarenhet av tillgängliga gränssnitt.
Det är också den punkt där automatisk testning stöter på sina gränser. En scan kan till exempel upptäcka att en knapp saknar en synlig fokusindikator, men kan inte bedöma om ordningen i vilken element presenteras för en skärmläsare är logisk. Därför står det i varje rapport att en automatisk scan inte kan testa alla krav. quick-scanen visar på några minuter ungefär var du står, men att översätta ett tekniskt upptäckt problem till en fungerande lösning är människoarbete, och ofta arbete för någon annan än dig själv.
Vad en överlagringswidget inte löser
Vissa aktörer lovar att ett separat script, en så kallad overlay, automatiskt åtgärdar tillgänglighetsproblem utan att du behöver ändra i den underliggande koden. Det låter som den perfekta gör-det-själv-lösningen, men en overlay läser och skriver bara om sidan på ytan när en besökare öppnar webbplatsen. Den underliggande strukturen, fokusordningen och själva tangentbordshanteringen ändras inte. En overlay uppfyller inte lagkraven, och därför säljer vi heller inte sådan.
När det är mer vettigt att anlita en leverantör
För att dokumentera, prioritera och övervaka ändringar kan du ta kontroll över processen själv med rätt stöd; det är precis vad axessia är utformad för. För den faktiska reparationen av komplexa komponenter, såsom ett betalningsalternativ eller en anpassad inloggningsskärm, ligger arbetet vanligtvis hos din utvecklare eller byrå. Vi utför inte själva några manuella revisioner och inget reparationsarbete; vi testar, prioriterar, dokumenterar och övervakar att resultatet förblir intakt efter varje ändring. Hur denna testning genomförs i detalj kan du läsa på sidan om vår arbetsmetod och de källor vi använder.
Om du är osäker på huruvida ett specifikt problem är något du kan hantera själv eller bättre kan outsourca, är det en fråga som skiljer sig från situation till situation och som en utvecklare eller tillgänglighetsspecialist kan bedöma bättre än en allmän checklista. En sammanfattning av vanliga praktiska frågor, inklusive denna typ av överväganden, hittar du på sidan med svar på frågor som företagare ofta ställer.
Vill du först veta hur din egen webbplats ser ut just nu, utan att du behöver ett konto? Gör den kostnadsfria snabbscanningen och läs i enkelt språk vilka delar som kräver uppmärksamhet och vilka du förmodligen kan hantera själv.