# Webbtillgänglighet ## Vad det är Webbtillgänglighet handlar om hur väl en webbplats, en app eller ett verktyg fungerar för personer med funktionsnedsättning. I dagligt tal säger man oftast bara tillgänglighet, på engelska web accessibility, och kortformen a11y räknar de elva bokstäverna mellan a och y. W3C:s Web Accessibility Initiative (WAI) definierar begreppet utifrån vad människor kan göra: uppfatta, förstå, navigera och interagera med webben, och bidra till den. Det sista verbet väger tungt. En webbplats där en blind besökare kan läsa varje artikel men inte skriva en kommentar, ladda upp en fil eller slutföra en registrering har uppfyllt halva definitionen. Omfånget är varje funktionsnedsättning som påverkar åtkomsten till webben. WAI räknar upp hörsel, kognition, neurologi, motorik, tal och syn, och var och en för med sig egna hinder: video utan undertexter, instruktioner som lutar sig mot minnet, rörelse som utlöser symtom, kontroller som kräver en stadig hand och en mus, röstgränssnitt som förutsätter flytande tal, text som bara fungerar i en storlek och med en kontrast. Under den synliga sidan bygger webbläsaren en andra struktur åt hjälpmedlen. ARIA-specifikationen kallar den tillgänglighetsträdet (accessibility tree): ett träd av tillgängliga objekt där varje nod motsvarar ett element i gränssnittet, som en tryckknapp eller en kryssruta, och exponeras genom plattformens tillgänglighets-API. Skärmläsare, röststyrning, kontaktstyrning och punktskriftsskärmar arbetar utifrån det trädet, inte utifrån pixlar. Varje nod bär ett namn, en roll och ett tillstånd, och framgångskriteriet 4.1.2 Name, Role, Value i WCAG 2.2 kräver att programvara kan avgöra dem för varje komponent i gränssnittet. Inbyggda HTML-kontroller, påpekar standarden, uppfyller redan 4.1.2 när de används enligt specifikationen. En `div` med en klickhanterare hamnar i trädet som generisk text, utan roll och utan plats i tangentbordsordningen. Tillgänglighet beror på att flera delar fungerar tillsammans, skriver WAI: webbteknikerna, webbläsarna, publiceringsverktygen och webbplatserna själva. Den som äger en webbplats styr över den sista av dem, och det är där WCAG i testbara termer anger vad innehållet måste klara. ## Varför det spelar roll Webben bär utbildning, arbete, offentlig service, handel och vård, och WAI påpekar att FN:s konvention om rättigheter för personer med funktionsnedsättning definierar tillgång till informations- och kommunikationsteknik, webben inräknad, som en grundläggande mänsklig rättighet. Tillgänglighet krävs också enligt lag i många situationer. I Sverige kräver DOS-lagen (lagen om tillgänglighet till digital offentlig service) att offentliga aktörers webbplatser och mobila applikationer är tillgängliga, och Digg är tillsynsmyndighet. Tillgänglighetslagen (LPTT) täcker i sin tur produkter och tjänster som riktar sig till konsumenter, t.ex. e-handel och banktjänster. Beställare gör om kraven till en rad i avtalet som namnger WCAG 2.2 nivå AA, och den raden avgör vad leverantören måste bygga och kunna bevisa. Samma arbete hjälper människor som aldrig skulle kalla sig funktionsnedsatta. WAI:s egen lista tar upp den som använder telefon, klocka eller tv med liten skärm och andra sätt att mata in, äldre vars förmågor förändras med åldern, den som har brutit armen eller tappat glasögonen, den som sitter i starkt solljus eller på en plats där ljud inte kan spelas upp, och alla med en långsam eller dyr uppkoppling. Undertexter hjälper på ett tyst tåg, och stark kontrast hjälper på en telefon mitt på dagen. Tidpunkten sätter priset. WAI kallar det mest effektivt att bygga in tillgänglighet från projektets allra första dag, så att arbetet inte behöver göras om. Att välja en inbyggd knapp kostar ingenting dag ett. Att byta ut en hemmabyggd efter lanseringen innebär att rätta komponenten och sedan testa om varje sida som använde den, på varje språk och i varje tema som webbplatsen levererar. Utvärdering följer samma logik. Verktyg hjälper, men WAI säger rakt ut att inget verktyg på egen hand kan avgöra om en webbplats uppfyller riktlinjerna, och att det krävs en kunnig människa som utvärderar. En regelmotor läser vad uppmärkningen säger. En person med tangentbord och skärmläsare tar reda på vad sidan gör. ## Så ser det ut i praktiken Från tre olika håll visar sidor på den här webbplatsen hur arbetet går till. Sidan om att [rätta elva fel som webbläsaren kallade friska](/sv/portfolio/fixed-11-accessibility-defects-the-browser-called-healthy-131/) utgår från en webbplats som klarade sina automatiska tillgänglighetsregler och ändå hade elva fel, vart och ett en egenskap hos hur sidan renderades snarare än hos vad uppmärkningen sade. Åtta länkar i sidfoten låg kvar i tabbordningen bakom en egenskap som tar bort pekarinteraktion och ingenting annat, så att ett tangentbord kunde landa på länkar som var osynliga på skärmen. Två av felen satt i själva kontrollerna. Varje fönster som layoutkontrollen öppnade var niohundra pixlar högt, så på en telefon i liggande läge på 852 × 393 hamnade två element sju pixlar från varandra utan att någon tittade. Tillgänglighetskontrollen i sin tur prövade bara sjuttio av de hundrafem regler som regelmotorn har. Fyra regler kom ut ur arbetet, bland dem att en kontroll som testar en axel försvarar en axel och att synlighet bevisas i pixlar snarare än i dokumentet. När layoutkontrollen öppnades på rätt sätt igen fallerade den hundratjugoåtta gånger på tre språk. Sidan om att [namnge alla sjutton kontroller med enbart ikon](/sv/portfolio/named-all-seventeen-interface-icons-for-screen-readers-159/) flyttar från en webbplats till en applikation byggd med SwiftUI. En systemsymbol utan tillgänglighetsetikett läses upp med sitt interna namn, så skicka-knappen presenterade sig som ”arrow up circle, button”, och varje annan kontroll med enbart ikon gjorde likadant på sitt sätt: sjutton stycken beskrev sin grafik i stället för sin funktion. Var och en har nu en etikett som namnger handlingen, och där betydelsen beror på tillstånd följer etiketten tillståndet. Ett lintverktyg kräver en etikett inom åtta rader från varje konstruktion som skapar en kontroll med enbart ikon, en medvetet grov regel som valdes genom mätning, så en artonde kontroll kan inte läggas till utan en. Sidan anger också regelns gräns: en etikett på en närliggande vy kan uppfylla den, så den visar närhet och inte korrekthet, och huruvida etiketten stämmer avgörs fortfarande av någon som lyssnar. [Sidan om beredskap för AI-agenter](/sv/ai-ready/) lägger till en nyare läsare. Många agenter som styr en webbläsare läser en sida på samma sätt som en skärmläsare gör, genom tillgänglighetsträdet, så de riktiga knapparna, de märkta formulären, rubrikerna i ordning och landmärken som gör en webbplats användbar utan mus är samma arbete som låter en agent hitta ett formulär och fylla i det. ## Var det går fel **En hemmabyggd rullgardinsmeny fungerar med mus och stänger ute alla andra.** En `div` med en klickhanterare har ingen roll, tar inte emot tangentbordsfokus och rapporterar inget öppet eller stängt tillstånd, så en skärmläsare läser upp ren text och Tab-tangenten hoppar förbi. Börja från det inbyggda elementet, `select`, `button` eller `details`, som tar med sig roll, fokus och tillstånd. När en design verkligen behöver en egen widget, följ dess mönster i ARIA Authoring Practices Guide och testa den sedan med tangentbord och skärmläsare. **Alt-texten beskriver bilden när läsaren behövde veta vad den gör.** 1.1.1 Non-text Content kräver ett textalternativ som fyller samma syfte, och en länkad logotyp som beskrivs som ”blue hexagon logo” berättar ingenting för en skärmläsaranvändare om vart länken leder. Skriv alternativet utifrån bildens uppgift: målet för en länkad bild, slutsatsen för ett diagram, orden för en bild av text. Ge rent dekorativa bilder ett tomt `alt=""` så att hjälpmedlen hoppar över dem. **Fokus faller till toppen av sidan när en dialog stängs.** När en dialog stängs eller vyn byts i en ensidesapp försvinner elementet som hade fokus, fokus faller tillbaka till dokumentets `body`, och den som använder tangentbord eller skärmläsare tappar bort sig. Lämna tillbaka fokus till kontrollen som öppnade dialogen. Efter ett vybyte på klientsidan, flytta fokus till den nya vyns huvudrubrik, försedd med `tabindex="-1"` så att den kan ta emot fokus, så läser skärmläsaren upp var användaren har hamnat. **En röd ram är hela felmeddelandet.** 1.4.1 Use of Color kräver att färg inte är det enda visuella sättet att förmedla information, och 3.3.1 Error Identification kräver att ett upptäckt inmatningsfel identifieras och beskrivs för användaren i text. En röd kontur gör ingetdera för den som inte kan skilja rött från grått eller inte ser fältet alls. Skriv ett kort meddelande bredvid fältet om vad som är fel och hur det rättas, koppla det med `aria-describedby` så att en skärmläsare läser upp båda tillsammans, och behåll färgen som en andra signal. ## Läs mer - [Introduction to Web Accessibility](https://www.w3.org/WAI/fundamentals/accessibility-intro/) — WAI:s definition, vilka som har nytta av den och varför utvärdering kräver människor och inte bara verktyg. - [How People with Disabilities Use the Web](https://www.w3.org/WAI/people-use-web/) — berättelser om användare, hindren de möter och verktygen och teknikerna de förlitar sig på. - [The Business Case for Digital Accessibility](https://www.w3.org/WAI/business-case/) — räckvidd, innovation, varumärke och juridisk risk, framlagt för dem som godkänner budgeten. - [Evaluating Web Accessibility Overview](https://www.w3.org/WAI/test-evaluate/) — från enkla kontroller till en fullständig utvärdering av överensstämmelse, med verktyg och rapportering. - [ARIA Authoring Practices Guide](https://www.w3.org/WAI/ARIA/apg/) — mönster för egna widgets, med de roller, tillstånd och det tangentbordsbeteende som var och en behöver. - [Digital tillgänglighet, Digg](https://www.digg.se/kunskap-och-stod/digital-tillganglighet) — DOS-lagen och tillgänglighetslagen, vem som har tillsyn och standarden EN 301 549.