Vad är webbtillgänglighet? WCAG och inkluderande design förklarat

Webbtillgänglighet innebär att man bygger webbplatser och appar så att personer med funktionsnedsättning kan använda dem – oavsett om de är blinda och använder skärmläsare, inte kan använda mus, har nedsatt syn eller färgblindhet, är döva eller har kognitiva eller inlärningsrelaterade funktionsnedsättningar. I praktiken handlar det om saker som textalternativ för bilder, tillräcklig färgkontrast, formulär med riktiga etiketter och att allt fungerar med bara tangentbordet. Den internationella standarden för det är WCAG, Web Content Accessibility Guidelines från W3C.

Webbtillgänglighet förkortas ofta a11y – “a”, sedan 11 bokstäver, sedan “y”.

Varför tillgänglighet spelar roll när du bygger med AI

AI-byggare är bra på att skapa appar som ser rätt ut. Tillgänglighet handlar mest om sådant du inte ser på en skärmdump: om en knapp verkligen är en knapp, om ett inmatningsfält har en etikett som en skärmläsare kan läsa upp, om du kan nå menyn med Tab-tangenten.

Därför är det viktigt att fråga:

• Det är lätt att missa. En egenstylad rullgardinsmeny kan se perfekt ut och vara omöjlig att använda utan mus. Du märker det inte om du inte testar.
• Det är billigare att få rätt tidigt. Att be om tillgängliga komponenter i första prompten kostar nästan ingenting. Att efterhand åtgärda en färdig app innebär att ändra varje skärm.
• Det hjälper alla. Undertexter hjälper människor i bullriga miljöer, bra kontrast hjälper folk med telefoner i starkt solljus, och tydliga etiketter gör att alla fyller i formulär snabbare.
• Det överlappar med SEO. Riktiga rubriker, beskrivande länkar och alt-texter hjälper sökmotorer att förstå dina sidor också – se SEO för AI-byggda webbplatser.
• Det kan vara ett krav. Beroende på var du verkar och vem du riktar dig till kan tillgänglighet vara en rättslig skyldighet.

En vardagsliknelse

Tänk på ingången till en byggnad.

Trappsteg fungerar för många. En ramp fungerar för rullstolsanvändare – och även för föräldrar med barnvagn, leveransarbetare med pallvagnar och resenärer med resväskor. Automatiska dörrar, tydliga skyltar, punktskrift på hissknapparna och bra belysning tar bort ett hinder för någon.

Webbtillgänglighet är samma idé för digitala utrymmen: rampen, skyltarna och räckena i din app. Och precis som med en byggnad är det mycket enklare att ta med en ramp i planerna än att bygga till den efter att betongen har stelnat.

WCAG i korthet

WCAG publiceras av W3C:s Web Accessibility Initiative. Den nuvarande versionen är WCAG 2.2, först publicerad i oktober 2023. Den är bakåtkompatibel: innehåll som uppfyller WCAG 2.2 uppfyller också 2.1 och 2.0, och W3C uppmuntrar till att använda den senaste versionen. WCAG 2.2 är dessutom godkänd som internationell standard, ISO/IEC 40500:2025. En helt annan WCAG 3 är under utveckling som ett tidigt utkast, inte en färdig standard.

WCAG är organiserad under fyra principer, ofta sammanfattade som POUR:

Varje riktlinje har testbara framgångskriterier på tre nivåer:

• Nivå A – miniminivån. Att inte uppfylla dessa blockerar vissa personer helt.
• Nivå AA – standardmålet, och den nivå de flesta lagar och policyer hänvisar till.
• Nivå AAA – den högsta nivån. Värd att sträva efter på vissa ställen, men W3C rekommenderar inte att kräva den för hela sajter, eftersom viss innehåll inte kan uppfylla den.

WCAG 2.2 lade till nio framgångskriterier jämfört med 2.1, bland dem Målstorlek (minimum) på nivå AA – klickbara mål bör i allmänhet vara minst 24 gånger 24 CSS-pixlar, med undantag – och Tillgänglig autentisering (minimum), som begränsar inloggningssteg som bygger på minne eller pussel, till exempel att behöva skriva om ett lösenord utan att få klistra in det. Den tog också bort det gamla kriteriet “Parsing”, eftersom det blivit föråldrat.

Ett praktiskt exempel: ett registreringsformulär

Här är ett registreringsformulär som en AI kan ta fram, och vad en tillgänglighetskontroll hittar:

Ingen av åtgärderna ändrar särskilt mycket på hur formuläret ser ut. Alla ändrar om vissa personer alls kan använda det.

Viktiga termer

Vanliga missuppfattningar

• “Tillgänglighet spelar bara roll för blinda användare.” Det omfattar syn-, rörelse-, hörsel-, tal- och kognitiva funktionsnedsättningar, samt tillfälliga situationer som en bruten arm.
• “Tillgängliga sajter ser tråkiga ut.” Tillgänglighet begränsar några saker – kontrast, fokusstilar, textstorlek – men vackra tillgängliga sajter är normen, inte undantaget.
• “En automatisk kontroll säger 100, så vi är klara.” Automatiska verktyg hittar bara vissa problem. Om alt-texten faktiskt är meningsfull, eller om ett flöde är logiskt med en skärmläsare, måste en människa kontrollera.
• “En overlay-widget gör oss kompatibla.” Verktygsrader som läggs ovanpå kan inte åtgärda saknade etiketter eller trasig tangentbordsåtkomst i din kod. Åtgärda källan.
• “Vi har inga användare med funktionsnedsättning.” Du kanske bara inte vet. Många funktionsnedsättningar syns inte, och personer som stöter på ett hinder lämnar oftast bara sajten.

Vad du kan be din AI-byggare om

• “Bygg detta så att det uppfyller WCAG 2.2 nivå AA.”
• “Använd semantisk HTML: riktiga knappar, länkar, rubriker i ordning och etiketter för varje formulärfält.”
• “Se till att varje interaktivt element fungerar med bara tangentbordet och har en synlig fokusstil.”
• “Kontrollera kontrasten för all text- och ikonfärg – 4,5:1 för vanlig text, 3:1 för stor text och ikoner.”
• “Lägg till meningsfull alt-text på informativa bilder och tom alt-text på dekorativa.”
• “Visa formulärfel som text, kopplade till fältet, inte bara med färg.”
• “Respektera användarens inställning för reducerad rörelse för animationer.”
• “Kör en automatisk tillgänglighetskontroll och lista det den inte kan testa, så att jag kan kontrollera det för hand.”

Testa sedan själv: lägg musen åt sidan och försök slutföra ditt huvudflöde med enbart Tab, Shift+Tab, Enter och mellanslag. Prova telefonens inbyggda skärmläsare på startsidan. Zooma webbläsaren till 200 % och se om något går sönder.

Tillgänglighet i Mythex

Mythex innehåller ingen särskild tillgänglighetskontroll, så behandla tillgänglighet som en del av dina prompter och din testning. Be om WCAG 2.2 AA från första prompten, kontrollera resultatet i förhandsvisningen med tangentbordet och använd /test för att låta agenten klicka igenom dina huvudflöden innan du publicerar – se App-testning. SEO-receptet ber också om semantiska rubriker och meningsfull alt-text, vilket tjänar båda målen.

För en praktisk checklista, se hur du gör din webbplats tillgänglig. För design, läs hur du designar en snygg app med AI, och innan lansering, hur du testar din app innan lansering. W3C:s egen WCAG-översikt är den auktoritativa källan.

Frågor