Tillgänglighet i tekniskt genomförande

Vilka tillgänglighetskriterier finns för tekniskt genomförande?

Det som listas upp på denna sida är framgångskriterier för tillgänglighet som riktas till publiceringsteknik och som ska beaktas när man bedömer hur tillgängligheten förverkligas. De tekniska kraven baseras på riktlinjerna för tillgängligt webbinnehåll, WCAG, som upprättats av sammanslutningen W3C.

Den som är ansvarig för webbsidornas teknik ska se till att sidans teknik stöder tillgänglighet och göra det möjligt för webbsidans användare och innehållsproducenter att publicera innehåll i tillgängligt format. Teknik innefattar alla inslag, vars genomförande fastställs i systemets källkod och som användarna inte kan ändra. Sådana egenskaper är bland annat möjlighet att sätta alt-texter för bilder och att uttrycka sidans språk med lang-attribut i <html>-rotelementet.

Man bör helst använda ett lämpligt HTML-element i utförandet av all teknik på sidan, om ett sådant finns. Webbsidans innehåll bör alltid utföras med hjälp av standard HTML-markering. Den rekommenderade nivån för HTML-språket är 5 (HTML5) och man bör använda semantiska element på nivån HTML5 vid utförandet.

Till exempel: för att skapa en knapp ska man använda elementet HTML button och inte ett egengjort div-element med en funktionalitet som skapats med hjälp av CSS-formatering och JavaScript. Standardelementen erbjuder automatiskt rätt funktionalitet och är i regel tillgängliga för tekniska hjälpmedel utan några tilläggsinställningar.

Nedan räknar man upp sådana egenskaper som fortfarande måste kontrolleras manuellt efter att man fått anmälningar om dem i tillgänglighetskontroller (auditering eller automatkontroll) och skickas vidare för korrigering till den som ansvarar för webbplatsens teknik.

Sidans struktur och rätt användning av element (semantik)

  • sidans <title>
  • ange sidans språk med lang-attribut
  • meddela språket för en del av sidan när det finns delar med olika språk (lang-attributet)
  • rätt användning av rubriker (delvis innehållsproducentens ansvar)
  • landmark-element (sidans struktur rekommenderas utformas med hjälp av dessa)
  • <header>, <nav>, <main>, <footer> eller motsvarande ARIA-koderna role=”banner”, role=”navigation”, role=”main”, role=”contentinfo”-listor
  • tabeller
  • iframe-inbäddningar – korrekt HTML

Länkar, navigering och användning av webbplatsen

  • ”Snabblänkar”, länkar direkt till början av elementet <body> i navigeringen, huvudinnehållet och webbkartan
  • länkar:
    • innehåller alltid en maskinläsbar etikett (label) och ett tydligt meddelande om vart länken leder
    • webbplatsens navigerings ska vara enhetlig på alla sidor
  • intern navigering på sidan
    • innehållets ordning/Focus order
    • logisk och felfri övergångsordning mellan element
    • inga positiva tabindex-värden (större än noll)
    • framhäva aktiva element visuellt för att urskilja dem
  • hela webbplatsen kan användas utan mus med enbart tangentbordet
  • alla element följer den allmänna och förväntade funktionaliteten
  • aktivering av element (focus) orsakar inte att innehållet ändras eller att man flyttas till ett nytt innehåll

Bilder och visualitet

  • man kan mata in alt-text för bilder
  • dekorativa bilder har antingen anpassad alt-text eller är dolda från skärmläsare
  • färger och kontraster följer ställda krav
  • textsnitten är läsbara
  • ändringar av sidans storlek uppfyller kraven för framgångskriterierna Reflow och Zoom för positionering av innehållet på sidan
  • anpassbart innehåll, identifiering av position

Multimedia, animationer, rörelse

  • ljudfiler
    • nödvändiga kontroller för upprepning och ljudstyrka kan styras av användaren
    • ljudstyrkan ska kunna justeras oberoende av systemets allmänna ljudstyrka
  • videofiler
    • nödvändiga kontroller för upprepning och ljudstyrka kan styras av användaren
    • möjligt att lägga till textning för videofiler, helst med så kallad Closed captions-teknik där textningen inte är ”inbränd” i bilden utan som en separat maskinläsbar text
  • animationer
    • inga störande stora och kraftiga rörelseeffekter
    • inga kraftiga och kontrasterande färger
    • inget snabbt flimmer (mer än 3 gånger per sekund)

Tidsanpassade funktioner

  • användarna har tillräckligt tid för att genomföra aktiviteten
  • användaren får ett meddelande om att tiden håller på att ta slut och ett enkelt sätt att be om mer tid

Användarinmatning: formulär

  • apparatoberoende inmatning: användaren ska kunna byta inmatningssätt mitt i aktiviteten (mus, tangentbord, pekskärm)
  • alla formulärfält har en synlig etikett (label) som läsbar med program
  • typen för formulärets inmatningsfält motsvarar alltid den information som matas in
  • input type enligt innehållet, varvid enheter med pekskärm kan välja rätt ”on-screen”-knappsats
  • formuläret har tillräckliga och tydliga anvisningar för användaren
  • formulärvalidering (kontroll av inmatning)
    • tydligt meddelande om felaktiga inmatningar och anvisningar om hur man kan korrigera inmatningen
    • synligt och tydligt meddelande till användaren om att sändningen av formuläret har lyckats
    • angivna meddelanden ska ges i ett format som kan uppfattas av skärmläsare
  • man ska undvika CAPTCHA eller erbjuda en tillgänglig version av kontrollen

Custom-kontroller

  • har alla custom-kontroller, skriptkomponenter och dylikt ändamålsenliga ARIA-role och -name-värden som visar kontrollens syfte?