De fire principper for webtilgængelighed

1. Opleveligt design

Med Opleveligt design mener EU, at al ikke-tekstindhold nu skal have tekstbaserede alternativer, der kan fortolkes af skærmlæsere. F.eks. at billeder skal have en alt-tekst, og at videoer og lydindhold skal tekstes, så blinde kan få læst op, hvad indholdet er.

Kravene inkluderer:

• Alt-tekster. Anvend alternativ tekst (ALT-tekst) på alle billeder og illustrationer, der har et formål (minimum 150 tegn). Billeder der blot bruges dekorativt behøver ikke have en alt-tekst.
• Undertekster og transskriptioner. Videoer og lydinhold, især instruktionsvideoer skal tekstes.
• Rigtig kontrastfarve. Sørg for god kontrast mellem for- og baggrund. Farvedesign skal opfylde kontrastkravet 4.5:1 for normal tekst (dvs. tekst under 18 punkt eller fed tekst under 14 punkt) og 3:1 for store tekster (dvs. fra 18 punkt eller fed 14 punkt og opefter). Dekorativ tekst eller logoer er ikke omfattet af kontrastkrav. Der findes flere værktøjer til at beregne kontrastforhold mellem farver, f.eks. WebAIM Contrast Checker, Google Material Design Color Tool eller Chrome DevTools.

2. Anvendelig interface design

At gøre hjemmesiden anvendelig via flere inputmetoder betyder, at man skal gøre alle funktioner på hjemmesiden tilgængelige, så de kan tilgås uden brug af mus.

Nøgleelementerne inkluderer:

• Tastaturnavigation med logisk fokusrækkefølge. En bruger skal kunne navigere gennem et digitalt interface (f.eks. en hjemmeside eller en app) ved kun at bruge tastaturet, og at rækkefølgen af interaktive elementer (links, knapper, formularfelter osv.) skal være logisk og forudsigelig bygget op. Det indebærer:
  • Brugeren skal kunne navigere ved hjælp af Tab, Shift + Tab, Enter, Mellemrum, og piletaster.
  • Når brugeren trykker på Tab, skal fokus bevæge sig i en logisk rækkefølge (fra venstre mod højre og oppefra og ned, ligesom læseretningen på en side).
  • At det element, der er valgt af brugeren skal være synligt, f.eks. med en markeret kant eller baggrund.
  • At ingen interaktive elementer må springes over uden grund, og brugeren skal kunne tilgå alle funktioner uden mus.
    
• Tidsbegrænsninger skal kunne deaktiveres eller forlænges. Dette gælder for alle situationer, hvor en bruger har en begrænset tid til at udføre en handling, f.eks. automatisk timeout på et login via netbank eller webshop, udfyldelse af formularer med en tidsbegrænsning, interaktive quizzer eller tests med en tidsgrænse, billedslideshows der skifter automatisk eller tilbud og rabatter der udløber efter en bestemt tid.
  
• Fejlhåndtering med forslag ved formularfejl. Hjemmesiden skal give brugeren klare fejlmeddelelser og forslag til, hvordan fejlen kan rettes, når der opstår en fejl i en formular.
  • Forklar hvad der er galt (f.eks. „E-mailadressen er ikke gyldig„, „Adgangskoden skal være mindst 8 tegn lang‟ eller „Kortnummeret mangler et ekstra ciffer”).
  • Hvis en fejl opstår, må formularen ikke nulstille sig selv, så brugeren er tvunget til at starte forfra.
  • Husk at placere fejlmeddelelsen tæt på det berørte felt, og at bruge både farve og tekst (ikke kun rød farve), så farveblinde også kan forstå fejlen.

Mobil apps skal desuden understøtte:

• Touch-gestures med alternativ stemmestyring. Det betyder, at brugeren skal kunne udføre handlinger, der normalt kræver berøring (touch-gestures), ved hjælp af stemmekommandoer eller indbyggede stemmestyringssystemer som f.eks. Apple Voice Control (iOS), Google Voice Access (Android), Siri eller Bixby. Stemmestyring af interaktive elementer kan f.eks. være: Sig „Tryk på Login‟ i stedet for at trykke på knappen eller at sige „Scroll ned‟ i stedet for at swipe.
  
• Gyroskop-funktioner der kan deaktiveres. En bruger skal have mulighed for at slå funktioner fra, der afhænger af enhedens bevægelse (gyroskop eller accelerometer). Eks. skal man i stedet for at vippe telefonen for at skifte billede, kunne trykke på en knap. Der skal være en tænd/sluk-indstilling for bevægelsesstyrede funktioner i appens indstillinger – f.eks. så en bruger kan slå „Ryst for at fortryde‟ fra i indstillingerne.
  
• Haptisk feedback. Vibrationer og andre berøringsbaserede signaler skal kunne erstatte lydnotifikationer, så personer med hørenedsættelse stadig kan modtage vigtige beskeder og feedback fra deres enhed. Det kan f.eks. være en svag vibration, når man trykker på en knap og en kraftigere vibration ved en fejl (f.eks. forkert adgangskode).

3. Forståelig informationsarkitektur

Med forståelig informationsarkitektur ligger der krav til en konsistent og forudsigelig navigationsstruktur på ens hjemmeside.

Det kræver:

• Semantisk HTML5 med brug af ARIA-labels skal forskellige elementer og indhold beskrives, så koden er lettere at forstå for skærmlæsere. Det bruges typisk til elementer, der ikke har en synlig tekst, men hvor en beskrivelse stadig er nødvendig for tilgængelighed. F.eks. skal en knap, der lukker en menu have en <button aria-label=‟Luk menu‟> kode.
  
• Sprogangivelse i meta-tags for skærmlæsere. Hjemmesiden skal i koden angive hvilket sprog indholdet er skrevet på, så skærmlæsere, søgemaskiner og browsere kan forstå og gengive teksten korrekt. <html lang=‟da‟> fortæller f.eks. en skærmlæser, at siden er på dansk, og den vil derfor udtale teksten korrekt på dansk i stedet for med f.eks. engelsk udtale.
  
• Læsevenlighed. Hold LIX-tallet nede (maksimum LIX på 40) og sætninger korte, så ordblinde har lettere ved at læse og bruge hjemmesiden.

Mere komplekse dataprodukter skal desuden tilbyde:

• Dynamiske indholdsfortolkninger. Grafiske og dynamiske elementer, som diagrammer, grafer og visuelle datarepræsentationer, skal kunne fortolkes og præsenteres i alternative formater, såsom lyd, tekst eller taktil feedback. F.eks. skal et en graf kunne læses op som lyd, hvor værdier oversættes til forskellige toner eller rytmer eller grafen skal suppleres med en detaljeret tekstbeskrivelse af, hvad den viser. Grafer og diagrammer skal desuden kunne navigeres med tastatur og skærmlæser. En interaktiv graf bør have en funktion, hvor brugeren kan trykke på en knap og få oplysninger læst op (f.eks. „Grafen viser, at salget steg med 20% fra januar til februar„).
  
• Interaktive tutorials med flere læringsmodaliteter. Instruktionsindhold (vejledninger, guides, kurser, onboarding-processer osv.) skal præsenteres på forskellige måder, så de kan tilpasses brugernes forskellige behov. En god interaktiv tutorial bør inkludere flere af disse modaliteter:
  • Visuel modalitet (Billeder, infografikker, videoer, animationer, brug af ikonografi for at gøre instruktioner lettere at forstå samt skærmoptagelser med trin-for-trin-gennemgang)
  • Auditiv modalitet (tekst-til-tale eller stemmeoptagelser, Voice-over i videoer og interaktive præsentationer samt mulighed for at lytte til forklaringer i stedet for at læse)
  • Tekstbaseret modalitet (Detaljerede trin-for-trin-beskrivelser, sammendrag eller skriftlige noter der kan downloades samt læs-let-versioner for personer med kognitive udfordringer eller ordblindhed)
    
• Kontekstuel hjælpefunktion i realtid. Brugeren skal kunne få relevant hjælp, mens de navigerer eller udfører handlinger, uden at skulle forlade siden eller gætte sig frem. Det kan f.eks. løses gennem hjælpetekster og værktøjstip, hvor når brugeren holder musen over et felt eller klikker i en formular, så vises en kort forklaring (eks. „Din adgangskode skal være mindst 8 tegn og indeholde et tal„.), eller hvor brugeren får øjeblikkelig feedback, hvis en formular f.eks. udfyldes forkert („Din e-mailadresse ser ikke rigtig ud. Tjek om der mangler et ‚@‛.„) eller gennem livechat eller chatbots, hvor brugeren kan stille spørgsmål i realtid via en chatfunktion eller hvor AI-drevne chatbots kan foreslå løsninger baseret på brugerens handlinger.

4. Robust teknologikompatibilitet

Det sidste princip under webtilgængelighedskravene skal sikre kompatibilitet med nuværende og fremtidige hjælpeteknologier.

Kritiske implementeringer inkluderer:

• Valideret HTML/CSS. Hjemmesidens HTML- og CSS-kode skal overholde de officielle webstandarder, som er fastlagt af World Wide Web Consortium (W3C). Dette kan f.eks. gøres gennem W3C-validator.
• Progressive enhancement (PE). PE er en design- og udviklingsfilosofi for hjemmesider, hvor man starter med en simpel, grundlæggende version af hjemmesiden, som fungerer på alle enheder og browsere. Derefter tilføjer man så mere avancerede funktioner. F.eks. kan man starte den grundlæggende version (baselag) ved at bygge siden med simpel HTML og CSS, og hvor man sikrer, at indholdet kan læses på alle enheder (inkl. ældre browsere, skærmlæsere og lavhastighedsforbindelser). Først derefter tilføjer man forbedringer (mellemlag), hvor man tilføjer responsivt design, interaktive elementer og bedre styling – f.eks. en dropdown-menu. Til sidst kan man så tilføje mere avancerede funktionaliteter (toplag) som animationer, AJAX-indlæsning, WebGL-grafik, avancerede API’er osv.
• Cross-browser testing. Her skal man teste hjemmesiden på tværs af forskellige browsere (Chrome, Firefox, Edge, Safari osv.) ved hjælp af skærmlæsere, så man sikrer, at brugere med synshandicap kan navigere korrekt og forstå indholdet uanset platform og browser.  NVDA (NonVisual Desktop Access), JAWS (Job Access With Speech) og VoiceOver kan bl.a. bruges til dette.

Har du API-integrationer skal de have:

• OAuth 2.0 med skærmlæserkompatible godkendelsesflows. Dette indebærer, at OAuth-login-sider skal være kompatible med skærmlæsere, hvilket kræver korrekt brug af ARIA og Semantisk HTML. Derudover skal brugeren skal kunne navigere loginflowet med Tab-tasten. Der må heller ikke være Captcha uden tilgængelige alternativer, da visuelle Captcha’er kan blokere blinde brugere fra at bruge API’en.
• WebSocket-kommunikation med tekstbaserede alternativer. WebSockets gør det muligt for en hjemmeside at opdatere data i realtid uden at genindlæse siden (f.eks. chatapps, live-aktiekurser, multiplayer-spil) og minimere samtidig forsinkelser, da serveren push’er data direkte til klienten i stedet for, at klienten konstant spørger serveren. Hvis en hjemmeside har WebSocket, skal den også tilbyde tekstbaserede alternativer, så brugere med skærmlæsere, langsomme forbindelser eller enheder uden WebSocket-understøttelse stadig kan få adgang til det samme indhold via tekstbaserede løsninger.