Tillgänglighet för utvecklare: Bygg inkluderande kod
Utvecklare är tillgänglighetens arkitekter på implementeringsnivå. Medan designers sätter de visuella och interaktiva grunderna är det koden som ytterst avgör om en webbplats fungerar med tangentbordsnavigation, kommunicerar korrekt med skärmläsare och upprätthåller tillgänglighet över webbläsare och enheter.
De goda nyheterna är att de flesta bästa praxis för tillgänglighet sammanfaller med allmänna bästa praxis för ren, semantisk, standardsenlig kod. Att skriva tillgänglig kod handlar inte om att lägga till komplexitet — det handlar om att skriva kod korrekt från början.
Semantisk HTML först
Det enskilt mest effektfulla du kan göra för tillgänglighet är att använda semantiska HTML-element korrekt. HTML5 tillhandahåller ett rikt ordförråd av element som bär inneboende mening och tillgänglighetsfunktioner. Ett <button>-element är automatiskt fokuserbart, aktiverbart med tangentbord och annonseras som en knapp av skärmläsare. En <div> med en onclick-hanterare har ingen av dessa funktioner utan betydande ytterligare arbete.
Använd <nav> för navigationsregioner, <main> för det primära innehållet, <header> och <footer> för sina respektive sektioner, <section> och <article> för innehållsområden, <h1> till <h6> för rubriker i korrekt hierarkisk ordning, <ul> och <ol> för listor, <table> med <th> för tabelldata, <label> med for-attribut för formulärkontroller och nativa <button>- och <a>-element för interaktiva kontroller.
Dessa element skapar ett tillgänglighetsträd som hjälpmedel använder för att presentera ditt innehåll för användare. När du använder dem korrekt hanteras mycket av tillgängligheten automatiskt.
Rubrikstruktur
Rubriker skapar den strukturella dispositionen av din sida. Skärmläsaranvändare navigerar ofta via rubriker för att förstå innehållsorganisationen och hitta specifika avsnitt. Varje sida bör ha exakt en <h1>, och rubriker bör följa en logisk hierarki utan att hoppa över nivåer — en <h3> bör inte följa en <h1> utan en <h2> däremellan.
Använd aldrig rubrikelement för visuell styling. Om du behöver stor fetstilad text som inte är en rubrik, använd CSS på ett annat element. Omvänt, om innehåll fungerar som en rubrik, markera det som en rubrik oavsett dess visuella presentation.
Tangentbordstillgänglighet
All funktionalitet måste vara hanterbar enbart via tangentbordsgränssnitt. Det innebär att varje interaktivt element — länkar, knappar, formulärkontroller, menyer, modaler, skjutreglage, flikar — måste vara nåbart via Tab-tangenten (eller Shift+Tab för omvänd ordning), aktiverbart med Enter eller Mellanslag, och kunna stängas vid behov.
Skapa aldrig tangentbordsfällor där användare kan tabba in i ett element men inte kan tabba ut ur det. Modala dialoger bör fånga fokus inom dialogen medan den är öppen och återföra fokus till det utlösande elementet när den stängs, men att trycka Escape bör alltid stänga dialogen.
Säkerställ att fokusordningen följer en logisk sekvens som matchar den visuella layouten. DOM-ordningen bör generellt matcha den visuella presentationen. Undvik att använda positiva tabindex-värden, som åsidosätter naturlig fokusordning och skapar förvirring. Använd tabindex="0" för att göra icke-interaktiva element fokuserbara vid behov, och tabindex="-1" för element som bara ska kunna fokuseras programmatiskt.
Sidspråk
Ange standardspråket på varje sida med lang-attributet på <html>-elementet. Detta talar om för skärmläsare vilka uttalssregler som ska användas. Om språket ändras inom innehållet — till exempel en fransk fras på en svensk sida — markera ändringen med ett lang-attribut på det omslutande elementet.
Formulärtillgänglighet
Formulär är där användare ger input, och de är en frekvent källa till tillgänglighetsbrister. Varje formulärkontroll måste ha en programmatiskt associerad etikett, vanligtvis genom att använda <label>-elementet med ett for-attribut som matchar kontrollens id. Gruppera relaterade kontroller med <fieldset> och <legend>.
När inmatningsfel upptäcks, identifiera det fältfält som har fel och beskriv felet i text. Ge förslag på korrigering där det är möjligt. För fält som accepterar specifika format, ge tydliga instruktioner om det förväntade formatet. Använd autocomplete-attributet för att aktivera webbläsarens autofyll för vanliga fält som namn, e-post, adress och telefonnummer.
Statusmeddelanden som inte tar emot fokus — som "vara tillagd i kundvagnen" eller "3 resultat hittades" — måste annonseras för skärmläsaranvändare genom ARIA live-regioner eller statusroller.
Alternativtext
Varje icke-dekorativ bild måste ha meningsfull alternativtext som beskriver dess innehåll eller funktion. För informativa bilder, beskriv vad bilden förmedlar. För funktionella bilder (som en logotyp som länkar till startsidan), beskriv funktionen. För dekorativa bilder som inte tillför information, använd ett tomt alt-attribut (alt="") så att skärmläsare hoppar över dem helt.
Komplexa bilder som diagram, grafer eller illustrationer kan behöva längre beskrivningar som tillhandahålls genom en bildtext, angränsande text eller en länkad detaljerad beskrivning.
WAI-ARIA
Specifikationen Accessible Rich Internet Applications tillhandahåller ytterligare semantik för situationer där nativ HTML är otillräcklig. ARIA låter dig kommunicera roller, tillstånd och egenskaper till hjälpmedel för anpassade widgetar och dynamiskt innehåll.
ARIA bör dock användas med omdöme. Den första regeln för ARIA är: om du kan använda ett nativt HTML-element som har den semantik och det beteende du behöver, gör det. ARIA lägger inte till funktionalitet — det lägger bara till semantik. En <div role="button"> behöver fortfarande JavaScript för tangentbordshantering, medan en nativ <button> hanterar det automatiskt.
Använd ARIA-landmärkesroller (eller deras HTML5-motsvarigheter) för att definiera sidregioner. Använd aria-label och aria-labelledby för att tillhandahålla tillgängliga namn där synlig text är otillräcklig. Använd aria-expanded, aria-selected, aria-checked och andra tillståndsattribut för att kommunicera det aktuella tillståndet hos interaktiva widgetar. Använd aria-live-regioner för att annonsera dynamiska innehållsuppdateringar.
Responsiv design och omflöde
Innehåll måste vara presentbart utan informationsförlust vid 320 CSS-pixlars bredd utan att kräva horisontell rullning. Detta säkerställer att användare som zoomar till 400 % på en vanlig skärm fortfarande kan komma åt allt innehåll. Designa dina layouter så att innehåll omflödar till en enda kolumn vid smala bredder snarare än att kräva rullning i två riktningar.
Skip-länkar
Tillhandahåll en mekanism för tangentbordsanvändare att hoppa över upprepade innehållsblock, som navigationsmenyer, och gå direkt till huvudinnehållet. Den vanligaste implementeringen är en "Hoppa till huvudinnehåll"-länk som är det första fokuserbara elementet på sidan och blir synlig när den fokuseras.
Utvecklarens testchecklista
Innan du driftsätter en funktion, verifiera: all funktionalitet fungerar enbart med tangentbord; fokusordningen är logisk; fokus är synligt på alla interaktiva element; alla bilder har lämplig alt-text; alla formulärkontroller har etiketter; sidspråk är satt; rubrikhierarkin är korrekt; ARIA används korrekt och bara när det är nödvändigt; innehåll omflödar vid 320px bredd; och dynamiska innehållsuppdateringar annonseras för skärmläsare.
I det här avsnittet
Är din webbplats tillgänglig?
Skanna din webbplats gratis och få din WCAG-poäng på några minuter.
Skanna din webbplats gratis