Test av digital tillgänglighet – WCAG 2.1 nivå AA

Testet/lathunden är publicerad av Erik Jansson på Statens tjänstepensionsverk (tidigare Boalgsverket) och lagd på webbplatsen DelaDigitalt.se, vilket innebär att endast de med mejladress inom offentlig sektor kan komma åt materialet. Därför återpubliceras detta fina material här på Webperf. Innehållet lyder under CC-licensen BY-NC-SA, vilket även denna HTML-version gör.

Erik skriver på Deladigitalt.se att:

"På Bolagsverket hade vi svårt att få loss IT-resurser till den omfattande inventering vi skulle genomföra med anledning av nya lagen om tillgänglighet till digital offentlig service.

Vi som jobbar med tillgänglighet bestämde oss därför för att ta fram ett underlag som skulle göra det möjligt för vem som helst i huset att inventera. Det underlaget tror vi kan vara användbart för andra som står inför samma uppgift som vi gjorde.

Underlaget är dels en checklista baserad på WCAG-kriterierna såsom de presenteras på webbriktlinjer.se. Den är dock ordnad efter hur man granskar en sida och indelad i kategorier så att det går smidigare att inventera."

Här kommer det omnämnda underlaget.

Introduktion

Den här lathunden är tänkt som en visualiserad guide för granskning av tillgängligheten i webbplatser, e-tjänster och appar. Den kompletterar checklistan för WCAG 2.1 AA (Excel-fil, 50 Kb) som används vid granskning och test av webbtillgänglighet samt vid upphandling.

I checklistan finns en kolumn som heter Ordning i lathunden och med checklistan sorterad i den ordningen blir granskningen enklare.

Varje kriterium i lathunden har en eller två symboler i marginalen:

Vissa kriterium kräver både redaktionell och teknisk kontroll.

Förberedelser och verktyg

För att kunna utföra alla granskningsmoment som beskrivs i lathunden krävs att du använder följande verktyg.

Webbläsare

Firefox

Plugins

Verktyg som installeras i Firefox och som används som komplement till din granskning.

Bookmarklets

JavaScript som körs på den aktuella sidan I webbläsaren tills du laddar om eller lämnar sidan.

Support

Om du behöver hjälp så kan du skicka ett mejl till erik.jansson@spv.se och hoppas att han har tid att försöka hjälpa till.


Innehåll

Lathund för test av digital tillgänglighet – WCAG 2.1 AA

Introduktion

Förberedelser och verktyg

Störande

Struktur

Tangentbord

Storlek och skärm

Färg och form

Bilder

Formulär

Ljud och video

Kod


Störande

Tekniskt kriteriumRedaktionellt kriterium1.4.2 – Ge användaren möjlighet att pausa, stänga av eller sänka ljud

Ljud som spelas upp automatiskt så går att pausa, stoppa eller sänka volymen på.

Tekniskt kriteriumRedaktionellt kriterium2.2.2 – Ge användarna möjlighet att pausa eller stänga av rörelser

Inget innehåll rör sig, blinkar, skrollar eller uppdateras automatiskt. Om sådant innehåll finns kan användaren pausa, stoppa eller dölja det. Ett undantag här är ”laddsnurror” och förloppsindikatorer (Figur 1) eftersom dessa hjälper användaren genom att visa att en tom sida inte har ”frusit” utan att innehållet håller på att laddas.

Figur 1 Förloppsindikator.

Redaktionellt kriterium2.3.1 – Orsaka inte epileptiska anfall genom blinkande innehåll

Ingen del av innehållet blinkar mer än 3 gånger under en 1-sekundsperiod.

Tekniskt kriterium2.2.1 – Ge användarna möjlighet att justera tidsbegränsningar

Det finns ingen tidsgräns för hur användaren interagerar med sidan. Om tidsgräns finns kan användaren stänga av, anpassa eller utöka den till minst 10 gånger ursprungsvärdet.

Struktur

Redaktionellt kriteriumTekniskt kriterium1.3.2 – Presentera innehållet i en meningsfull ordning för alla

Allt innehåll kommer i en meningsfull logisk ordning oavsett hur användaren tar del av det. Redaktionellt: Det viktigaste innehållet – eller en kort sammanfattning – kommer högst upp. Det finns en röd tråd så att det är lätt att hänga med. Informationen kommer i rätt ordning så att ingen del av texten förutsätter kunskap om något som finns längre ner.

Tekniskt: Det enklaste sättet att testa detta är att stänga av sidans stilmall (CSS). I Firefox trycker du på ALT-tangenten och väljer i menyn: Visa > Sidstil > Ingen (Figur 2). Då visas innehållet i sin ursprungliga ordning, vilket är den ordning som förmedlas till ett hjälpmedel såsom en skärmläsare. För att uppfylla detta kriterium krävs att innehållets ordning är meningsfull oavsett om du har stilmallen på eller av.

Figur 2 Stäng av sidstil (CSS) i Firefox.

Redaktionellt kriterium2.4.2 – Skriv beskrivande sidtitlar

Detta är del 1 av detta kriterium (del 2 finns i avsnittet Kod). En bra, beskrivande titel sammanfattar sidans ämne eller innehåll. Titeln syns i webbläsarens flikar. Håll muspekaren över fliken för att se hela titeln (Figur 3).

Figur 3 Håll muspekaren över fliken för att se sidans titel.

Varje sida på en webbplats, liksom andra typer av dokument, ska ha en unik titel (Figur 4).

Figur 4 En webbplats med samma titel på alla sidor uppfyller inte 2.4.2.

Först bör istället sidans ämne beskrivas, så att det väsentliga kommer först och så att det inte döljs utanför flikens bredd. En godkänd titel på sidan i Figur 4 skulle vara:

Prislista – Näringslivsregistret – Bolagsverket.

Redaktionellt kriterium2.4.4 – Skriv tydliga länkar

Syftet med alla länkar framgår av länktexten. Användaren ska kunna förstå vart länken leder även när den är lyft ur sitt sammanhang. Tydliga och informativa länkar gör att användaren snabbare hittar den information de söker. De underlättar även för användare med kognitiva begränsningar.

Ett exempel på ett typiskt fel: Klicka här för att logga in!

En bättre variant skulle vara: Logga in.

Redaktionellt kriterium2.4.6 – Skriv beskrivande rubriker och etiketter

Detta är del 1 av detta kriterium (del 2 finns i avsnittet Formulär). Kolla att alla rubriker på sidan beskriver ämnet eller syftet med det avsnitt som följer och alla ledtexter och etiketter beskriver ämnet eller syftet med det element de tillhör.

Detta är enklast att kontrollera med CSS avstängt (Figur 2) men ska även se rätt ut med CSS.

Tekniskt kriterium3.2.3 – Var konsekvent i navigation, struktur och utformning

Navigeringsfunktioner som upprepas på flera av webbplatsens sidor presenteras i samma inbördes ordning.

Tekniskt kriterium2.4.5 – Erbjud användarna flera olika sätt att navigera

Det finns mer än ett sätt att hitta en webbsida inom tjänsten eller webbplatsen, utom när sidan är ett resultat av eller ett steg i en process.

Exempel: sökfunktion, navigeringsmeny, sidkarta, innehållsförteckning, A-Ö.

Redaktionellt kriteriumTekniskt kriterium1.3.1 – Ange i kod vad sidans olika delar har för roll

Detta är del 1 av detta kriterium (del 2 finns i avsnittet Kod). Kontrollera att sidan har korrekt rubrikstruktur. Detta gör du enklast med hjälp av Web Developer (Figur 5).

Figur 5 I Web Developer klickar du på fliken "Information" och väljer sedan "View Document Outline".

Du hamnar då i en ny flik där rubrikstrukturen visualiseras (Figur 6). Om en rubriknivå saknas så indikeras det med gul färg samt texten (Missing heading) där rubriken skulle ha stått. Saknas en rubriknivå så är detta kriterium inte uppfyllt.

Figur 6 Rubrikstruktur där underrubriknivå 3 följer direkt efter huvudrubriken (nivå 1). Den saknade rubriken på nivå 2 indikeras med gult och texten "Missing heading".

Tangentbord

Föreställ dig att du inte kan använda musen. Hur fungerar sidan då? Använd tangentbordet för att utforska sidan. Du tar dig fram och tillbaka bland sidans element med Tab resp. Shift+Tab. När ett element har fokus är Enter-knappen oftast motsvarigheten till att klicka. För att markera kryssrutor används i regel Mellanslag. Inom en grupp av radioknappar används i regel piltangenterna för att flytta fokus.

Tekniskt kriterium2.1.1 – Utveckla systemet så att det går att hantera med enbart tangentbordet

Systemet och alla dess funktioner ska gå att hantera med enbart tangentbord. Den som bara kan eller vill använda tangentbordet (eller hjälpmedel som kopplas till tangentbords-kommandon) är beroende av att systemet inte förutsätter att användaren har till exempel mus eller pekskärm.

Tekniskt kriterium2.1.2 – Se till att markören inte fastnar vid tangentbordsnavigation

Om tangentbordsfokus flyttas till en komponent så kan fokus också flyttas bort från samma komponent via tangentbord.

Tekniskt kriterium2.4.7 – Markera tydligt vilket fält eller element som är i fokus

Det framgår tydligt vilket element på sidan som har tangentbordsfokus. När fokus hoppar långt på sidan ska det uppfattas i ögonvrån. En tjock ram med framträdande färg (Figur 7, markering a), eller en invertering av elementets färger (Figur 7, markering b) är exempel på godkända varianter.

Figur 7 Två godkända varianter av tangentbordsfokus, ram (a) resp invertering (b).

Tekniskt kriterium2.4.3 – Gör en logisk tab-ordning

Allt innehåll som användaren kan navigera till via tangentbord kommer i en logisk navigeringsordning och fokus hoppar inte runt på sidan på ett oförutsägbart sätt. Om 2.4.7 ovan är underkänd och du har svårt att se fokus så blir denna checkpunkt svår att bedöma. Du kan då använda Force focus som beskrivs i avsnittet Förberedelser och verktyg.

Tekniskt kriterium3.2.1 – Utför inga oväntade förändringar vid fokusering

Att en komponent får fokus ändrar inte kontexten. Inget oförutsägbart ska hända då ett element får fokus.

Tekniskt kriterium2.4.1 – Erbjud möjlighet att hoppa förbi återkommande innehåll

Detta är del 1 av detta kriterium (del 2 finns i avsnittet Kod). Det ska finnas genvägar i strukturen, till exempel genom så kallade skipplänkar (Figur 8). Det kan ta lång tid att ta sig till olika delar av ett dokument när man navigerar med tangentbord, eftersom man normalt måste stega sig förbi varje länk. Webbplatser som har ett omfattande och komplext menysystem med många länkar kan försvåra avsevärt för många användare.

Figur 8: Tidigt i tabbordningen får användaren möjlighet att hoppa över navigationen via en skipplänk.

Tekniskt kriterium2.1.4 – Skapa kortkommandon med varsamhet

Det finns inga en-tangentskommandon i tjänsten (stäm av mot kraven). Om det mot förmodan måste finnas en-tangentskommandon så ska det gå att stänga av den funktionen.

Tekniskt kriterium1.4.13 – Popup-funktioner ska kunna hanteras och stängas av alla

Innehåll som dyker upp vid fokus är tillgängligt oavsett zoom och går att stängas/tas bort enkelt (till exempel med ESC). Det kan gälla till exempel undermenyer, tooltips och popup-fönster. Tyvärr skapar sådant innehåll annars ofta tillgänglighetsproblem, till exempel för att användaren inte har aktiverat funktionen med avsikt; användaren inte blir medveten om att det har dykt upp nytt innehåll eller för att det nya innehållet stör användarens förmåga att genomföra en uppgift.

Nu kan du använda musen igen och testa samma sak vid hover, alltså med muspekaren över element. Innehåll som dyker upp vid hover ska förbli synligt tills pekaren förs utanför området eller tills användaren döljer det.

Storlek och skärm

Tekniskt kriterium1.4.4 – Se till att text går att förstora utan problem

Kontrollera att det går att förstora texten till 200 % utan att information eller funktion går förlorad. Det gäller alltså inte zoom av hela sidan, utan zoom av texten. I Firefox trycker du på ALT-tangenten och väljer i menyn: Visa > Zoom > Zooma endast texten (Figur 9).

Figur 9 Kryssa i Zooma endast texten i menyn.

Zooma sedan texten till 200% i snabbmenyn (Figur 10) eller genom att hålla Ctrl nedtryckt och scrolla med musens scrollhjul. Aktuell zoom visas i webbläsarens adressfält. Gå sedan vidare till nästa checkpunkt 1.4.12.

Figur 10 Öka zoom till 200 % i Firefox meny.

Tekniskt kriterium1.4.12 – Se till att det går att öka avstånd mellan tecken, rader, stycken och ord

Om du inte redan gjort det, se till att du har funktionen Text spacing installerad. I avsnittet Förberedelser och verktyg ser du det går till. Med texten fortsatt inzoomad till 200 % aktiverar du Text spacing.

Det ska vara möjligt att ta del av allt innehåll och använda alla funktioner på sidan med dessa inställningar. Kontrollera att inget innehåll döljs eller blir oläsbart. Många användare, till exempel dyslektiker och personer med nedsatt syn, behöver kunna påverka textstorlek, avståndet mellan stycken, rader, ord och tecken för att lättare kunna läsa.

Ladda om sidan och zooma ut till 100 % innan du går vidare!

Tekniskt kriteriumRedaktionellt kriterium1.4.10 – Skapa en flexibel layout som fungerar vid förstoring eller liten skärm

Layouten fungerar på en 320 pixlar bred skärm utan att information eller funktion går förlorad och utan scroll i mer än en riktning. Denna checkpunkt säkerställer i praktiken att sidans design är responsiv. Ett enkelt sätt att testa detta i Firefox är att trycka Ctrl+Shift+M och ställa in fönstret på 320 x 480 (Figur 11: markering a).

Figur 11 Testa responsiv design i Firefox. Värdena (a) går att ändra och fönstret kan roteras (b).

Tekniskt kriterium1.3.4 – Skapa en design som fungerar oavsett skärmens riktning

Klicka på knappen Rotera (Figur 11: markering b) och gör samma kontroll igen (som i 1.4.10 ovan).

Tryck Ctrl+Shift+M igen för att återgå till normalläge!

Tekniskt kriteriumRedaktionellt kriterium2.5.1 – Erbjud alternativ till komplexa fingerrörelser

Kontrollera att all funktionalitet som kräver flera fingrar eller rörelser är också hanterbar med ett enda finger utan rörelser. När du till exempel tittar på en karta i mobilen så kan du zooma med två fingrar genom att dra isär dem, men du kan även (oftast) klicka på en plus-knapp.

Tekniskt kriterium2.5.2 – Gör det möjligt att ångra klick

Funktionalitet som är hanterbar med muspekare eller finger slutförs först när fingret lyfts från mus eller skärm, och ingen del av funktionen utförs dessförinnan. På så sätt går det att ångra sig.

Tekniskt kriterium2.5.4 – Erbjud alternativ till rörelsestyrning

Förmodligen aldrig aktuell för våra webbplatser, tjänster eller appar. Funktionalitet som är hanterbar genom att röra inmatningsenheten eller genom rörelser hos användaren är också hanterbar via användargränssnittskomponenter, och respons på rörelsen går att stänga av för att undvika oavsiktlig aktivering.

Färg och form

Redaktionellt kriterium1.3.3 – Gör inte instruktioner beroende av sensoriska kännetecken

Hänvisningar till komponenter och innehåll är inte enbart beroende av sensoriska kännetecken såsom färg, form, storlek, placering, orientering eller ljud.

Exempel på typiska fel: "Tryck på den röda knappen" (Figur 12) eller "Läs mer till höger".

Figur 12 En person med den vanligaste typen av nedsatt färgseende har svårt att se vilken knapp som är röd. Knapparna i bilden har färgerna röd, gul resp. grön, sett genom ett filter som simulerar deuteranopi.

Redaktionellt kriteriumTekniskt kriterium1.4.1 – Använd inte enbart färg för att förmedla information

Kontrollera att färg inte används som det enda visuella sättet att förmedla information eller särskilja ett visuellt element. Ett vanligt exempel på när detta är viktigt är länkar i löpande text. Om dessa endast skiljer sig i färg är de lätta att missa för vem som helst. En vanlig brist är användning av röd färg som enda sättet att indikera ett fel (Figur 13).

Figur 13 Två sätt att presentera fel samt en simulering av hur de uppfattas av användare med resp. utan fullgott färgseende. A är underkänt eftersom endast färg används som indikator. B är godkänt eftersom form och text kompletterar färg.

Redaktionellt kriteriumTekniskt kriterium1.4.3 – Använd tillräcklig kontrast mellan text och bakgrund

Kolla så att det inte finns någon text på sidan som riskerar vara svårläst på grund av dålig kontrast. Här är Insidans ”Fler nyheter” (Figur 14). Datumen möter inte kontrastkraven. Vid simulering av nedsatt syn blir datumen nästintill omöjliga att läsa, medan övrig text är hjälpligt läsbar.

Figur 14 Datumen i rutan är grå mot grå bakgrund. För användare med nedsatt syn blir de svåra att läsa.

Om du misstänker att en text har för låg kontrast så kan du enkelt kontrollera det med hjälp av kontrastverktyget (Figur 15) i Wave. Du kan läsa om installation av Wave i avsnittet Förberedelser och verktyg.

Figur 15 Använd Wave för att kontrollera kontrast för text.

Mycket riktigt har datumen för låg kontrast (Figur 16).

Figur 16 Wave indikerar att kontrastvärdet är för lågt.

Använd tillägg såsom Wave endast som komplement när du bedömer kontrasten. Wave kan till exempel missa problem med text som ligger över en bakgrundsbild (Figur 17).

Figur 17 Knappens text har godkänd kontrast mot vit bakgrund men inte mot bakgrundsbilden. Denna brist kan automatiska verktyg såsom Wave inte upptäcka.

Tänk också på att textens bakgrund kan variera beroende på fönstrets storlek, eller om den visas med mobiltelefon. Det finns säkra, manuella sätt att mäta kontrast i de fall du är osäker. Kontakta erik.jansson@spv.se för att få hjälp!

Redaktionellt kriteriumTekniskt kriterium1.4.11 – Använd tillräckliga kontraster i komponenter och grafik

Text är ofta det huvudsakliga informationsbärande innehållet på en sida, men även grafik kan vara informationsbärande (Figur 18). Då måste även den möta kontrastkraven.

Figur 18 Informationsbärande grafik, till exempel ett diagram, måste möta kontrastkraven.

Detsamma gäller komponenter, såsom knappar och formulärfält samt indikatorn för tangentbordsfokus (Figur 19).

Figur 19 Textfält, knappar och indikator för tangentbordsfokus. Alla med för låga kontrastvärden.

Bilder

Tekniskt kriteriumRedaktionellt kriterium1.1.1 – Beskriv med text allt innehåll som inte är text

Detta är del 1 av detta kriterium (del 2 finns i avsnittet Ljud och video).

Det enklaste sättet att granska tillgängligheten hos bilder är att stänga av sidans stilmall (Figur 2 på sida 3). Då framträder alla förgrundsbilder och bakgrundsbilder visas inte.

Kontrollera att alla bilder som visas har alt-attributet. Här är verktyget Web Developer (Figur 20) hjälpsamt genom att lyfta fram den relevanta koden.

Figur 20 För att visa alt-texter klickar du på Web Developer > Images > Display Alt Attributes

Eftersom endast förgrundsbilder visas så ska nu alla bilder du ser ha alt-attributet. Det ska vara ifyllt om bilden är innehållsbärande; och tomt för dekorativa bilder.

Att en bild är innehållsbärande (Figur 21, Figur 23 resp. Figur 24) innebär att den förmedlar relevant information som inte återfinns i den omkringliggande texten. Tänk på att bilder ofta är innehållsbärande även om de inte föreställer text!

Figur 21 En innehållsbärande bild med sin alt-text som verktyget Web Developer lyfter fram.

Att en bild är dekorativ (Figur 22) innebär att den kan tas bort utan att sidinnehållets betydelse påverkas. Den ska då ha ett tomt alt-attibut: alt=""

Figur 22 En dekorativ bild med tomt alt-attribut som verktyget Web Developer lyfter fram.

I Figur 23 ser du ett exempel på ett avsnitt med bild som har underkänd alt-text. Eftersom avsnittets text inte innehåller informationen i bilden och eftersom bilden inte är enbart dekorativ ska den ha en ifylld alt-text.

Figur 23 Ett underkänt exempel. Vilka är värdeorden? Utan alt-text till bilden är detta avsnitt inkomplett.

I Figur 24 ser du ett exempel på en bra alt-text eftersom den förmedlar samma information som bilden.

Figur 24 En bra alt-text. Alt-texten beskriver inte bilden utan förmedlar samma information som bilden. De två streckade pilarnas innebörd förmedlas av texten ”… i båda företagen.”

Redaktionellt kriterium1.4.5 – Använd text, inte bilder, för att visa text

Kontrollera så att all text utgörs av text och inte bild av text. Logotyper är undantagna, men Bolagsverkets logga ska ha alt-texten ”Bolagsverket” (Figur 21) för att följa riktlinje 1.1.1 ovan. För att testa om en text utgörs av text så kan du försöka markera texten (Figur 25).

Figur 25 Siffran ”11” består av en text som ligger ovanpå en bild. Med texten markerad blir detta tydligt.

Formulär

Redaktionellt kriterium2.4.6 – Skriv beskrivande rubriker och etiketter

Detta är del 2 av detta kriterium (del 1 finns i avsnittet Struktur). Kontrollera att alla ledtexter och etiketter beskriver ämnet eller syftet med det element de tillhör (Figur 26).

Figur 26 Formuläret Kontakta oss på bolagsverket.se.

Tekniskt kriteriumRedaktionellt kriterium3.2.4 – Benämn funktioner konsekvent

Allteftersom du granskar fler delar av webbplatsen och så kommer du stöta på samma komponenter på flera sidor. Jämför då namn, ledtext/etikett, textalternativ så att de är konsekventa.

Om till exempel ett fält för inmatning av personnamn har ledtexten Namn på en sida så ska den inte ha ledtexten För- och efternamn på en annan.

Tekniskt kriteriumRedaktionellt kriterium3.3.2 – Skapa tydliga och klickbara fältetiketter

Detta är del 1 av detta kriterium (del 2 finns i avsnittet Kod)

Kontrollera att …

 

Figur 27 Placeras ledtexten ovanför sitt fält blir tillhörigheten tydligare.

 

Figur 28 Del av ett visuellt grupperat formulär. Rutan Beställare resp. Beställning är så kallade fieldset. Vad vill du beställa? är ett fieldset underordnat Beställning.

Tekniskt kriterium3.2.2 – Utför inga oväntade förändringar vid inmatning

Testa att inget överraskande händer, till exempel att kontexten helt ändras, då du ändrar värdet i ett element. Ett vanligt exempel på detta är att en kryssruta eller radioknapp byter ut påföljande innehåll (Figur 29). I vissa fall, som i exemplet, är detta rätt förutsägbart beteende och därför ok. I mer komplexa fall kan det vara mycket förvirrande för många användare.

Figur 29 Ett godkänt sätt att förändra kontext vid inmatning.

Tekniskt kriterium1.3.5 – Märk upp vanliga formulärfält i koden

Detta är del 1 av detta kriterium (del 2 finns i avsnittet Kod). Kontrollera att vanliga typer av inmatningsfält erbjuder automatisk komplettering av inmatningen där det är önskvärt.

Exempel: namn, adress, telefonnummer (läs mer på webbriktlinjer.se)

Tekniskt kriteriumRedaktionellt kriterium3.3.1 – Visa att ett fel uppstått och beskriv det tydligt

Detta är del 1 av detta kriterium (del 2 finns i avsnittet Kod). Testa att mata in felaktigheter och/eller lämna obligatoriska fält tomma i tjänsten. Om inmatningsfel upptäcks automatiskt så ska det som är fel markeras och felet beskrivas för användaren med text (Figur 30).

Figur 30 Fel vid inmatning presenteras vid fältet och beskrivs i text. I mer omfattande formulär kan detta kompletteras med en sammanställning av fel högst upp på sidan. På så vis ser användaren felet även om fältet är långt ner, utanför skärmen.

Tekniskt kriteriumRedaktionellt kriterium3.3.3 – Ge förslag på hur fel kan rättas till

Kolla så att om inmatningsfel upptäcks automatiskt och det finns kända korrigeringsförslag så ges förslagen till användaren, utom om det skulle äventyra säkerheten eller syftet med innehållet.

Redaktionellt kriteriumTekniskt kriterium3.3.4 – Ge möjlighet att ångra, korrigera, eller bekräfta vid viktiga transaktioner

För sidor som innebär att användare ingår rättsliga åtaganden, utför ekonomiska transaktioner, ändrar/raderar användarstyrda data et c. ska minst ett av följande gälla:

Figur 31 Användaren får en sammanställning av vad som kommer att skickas in.

Ljud och video

Tekniskt kriteriumRedaktionellt kriterium1.1.1 – Beskriv med text allt innehåll som inte är text

Detta är del 2 av detta kriterium (del 1 finns i avsnittet Bilder). Kontrollera att ljud- och videoinnehåll som du stöter på har ett textalternativ som åtminstone beskriver innehållet samt att det är ljud eller video. Textalternativet kan finnas på samma sida eller via en länk.

Figur 32 Podcasten Skatteskolan från verksamt.se.

Varje Skatteskolan-avsnitt har en text som beskriver vad avsnittet handlar om (Figur 33). Det är en tolkningsfråga vad som krävs för att beskrivningen ska vara tillräcklig, men det måste i alla fall finnas en sammanfattande beskrivning. Om klippet inte tillför information så ska det anges.

Figur 33 Beskrivning av innehållet i ett av Skatteskolans avsnitt.

Tekniskt kriteriumRedaktionellt kriterium1.2.1 – Erbjud alternativ om en inspelning enbart består av ljud eller video

Ljud och video är tidsberoende medan text och bilder är tidsoberoende. Kolla att …

Redaktionellt kriteriumTekniskt kriterium1.2.2 – Texta inspelad rörlig media (video, ljud, animationer)

Kontrollera att produktioner där ljud är en av komponenterna har en textversion av ljudinnehållet. Ett exempel kan vara en online-föreläsning med informativa bilder och en berättarröst (Figur 34).

Figur 34 Om det som sägs innehåller information som inte finns i bilderna så ska ett textalternativ till ljudspåret erbjudas.

Redaktionellt kriteriumTekniskt kriterium1.2.4 – Texta direktsändningar

Det finns textbeskrivningar till allt direktsänt innehåll. Digital video ska ha undertexter och för annat ljud bör en textversion erbjudas.

Tekniskt kriteriumRedaktionellt kriterium1.2.3 – Erbjud alternativ till videoinspelningar

Inspelad digital video ska ha undertexter (kallas även textbeskrivningar eller textremsa), utom när videon är ett mediealternativ till text (men då ska det tydligt framgå).

Kontrollera att videoinspelningar har alternativ: syntolkning (ljudbeskrivning) eller presenterad som text. Videon ”Film om verklig huvudman för dig som är företagare” har ett textalternativ (Figur 35).

Figur 35 Textad video: ”Film om verklig huvudman för dig som är företagare”.

Symbolerna som indikerar textning kan variera. De kan till exempel se ut som i Figur 36

Tre symboler för textning

Figur 36 Tre exempel på symboler för textning.

Tekniskt kriteriumRedaktionellt kriterium1.2.5 – Syntolka videoinspelningar

Kontrollera att videoinspelningar är syntolkade (Figur 37).

Illustration: TV-skärm med två pratbubblor

Figur 37 Texten i den övre pratbubblan (“Ada står vänd mot kameran”) visar exempel på syntolkning, medan den nedre bubblan (Ringsignal. “Hej det är jag!”) representerar det ordinarie ljudspåret.

Syntolkning heter audio description på engelska och symboliseras ofta av någon av ikonerna i Figur 38

symboler för syntolkning

Figur 38 Två exempel på symboler för syntolkning.

För många videor så räcker det med att vi ser till att den befintliga berättarrösten beskriver allt väsentligt. Vi behöver inte lägga på ett ytterligare ljudspår. Våra originalvideor kan vara tillgängliga utan större ansträngning om vi gör rätt från början.

Kod

Följande kriterier kräver fördjupad kunskap om HTML5 och WAI-ARIA för att utvärdera.

Tekniskt kriterium4.1.1 – Se till att koden validerar

Verifiera att koden validerar utan allvarliga fel. Använd Web Developer (Figur 39). Varningar och vissa fel kan vara ok beroende på kontext. Behöver du hjälp med bedömningen kan du mejla erik.jansson@spv.se.

Figur 39 Med Web Developer kan du validera koden även på interna webbplatser och i testmiljö med Validate Local HTML. OBS! Data skickas till då extern validator så tänk på GDPR och informationssäkerhet!

Tekniskt kriterium1.3.1 – Ange i kod vad sidans olika delar har för roll

Kontrollera att allt innehåll är uppmärkt med semantiskt korrekt HTML och, där det behövs, aria-attribut för att förmedla struktur, relationer och betydelse. Bland mycket annat ska rubrikstrukturen vara korrekt. Det testar du enkelt med Wave (Figur 40).

Figur 40 Granska rubrikstrukturen med Wave. Den gula ikonen indikerar bristande struktur då en nivå har hoppats över.

Övrig granskning för detta kriterium måste göras manuellt i källkoden. HTML5-specifikationen och WAI-ARIA Authoring Practices är bra att ha till hands.

Tekniskt kriterium2.4.1 – Erbjud möjlighet att hoppa förbi återkommande innehåll

Detta är del 2 av detta kriterium (del 1 finns i avsnittet Tangentbord). Kontrollera att sidan använder korrekt HTML5-struktur: <header>, <nav>, <main>, <aside>, <footer> et c. och att den kompletterats med aria-landmärken där det behövs; eller att det finns skipplänkar för att hoppa över innehåll som upprepas på flera av webbplatsens sidor (Figur 8 på sida 6).

Tekniskt kriterium2.4.2 – Skriv beskrivande sidtitlar

Kontrollera i koden att <title>-elementet har ett innehåll som beskriver den specifika sidan.

Se 2.4.2 del 1 i avsnittet Struktur för detaljer och bildexempel.

Tekniskt kriterium3.1.1 – Ange sidans språk i koden

Kolla att det språk som sidans huvudinnehåll är skrivet i är angivet i ett lang-attribut i <html>-elementet. Detta är viktigt för bland andra användare med skärmläsare.

För svenska sidor är både lang="sv-SE" och lang="sv" godkända varianter.

Tekniskt kriteriumRedaktionellt kriterium3.1.2 – Ange språkförändringar i koden

Språket är angivet för varje avsnitt eller fras som är på ett annat språk än omgivande text genom lang-attribut. Då slipper hjälpmedelsanvändaren plötsliga inslag av svengelska!

Exempel från en tänkt svensk sida: <h2 lang="en-US">Accessibility</h2>

Tekniskt kriterium3.3.2 – Skapa tydliga och klickbara fältetiketter

Detta är del 2 av detta kriterium (del 1 finns i avsnittet Formulär).

Kontrollera att …

Tekniskt kriterium1.3.5 – Märk upp vanliga formulärfält i koden

Detta är del 2 av detta kriterium (del 1 finns i avsnittet Formulär). Kolla så att vanliga typer av inmatningsfält har attributet autocomplete med förväntat innehåll angivet. Lista på möjliga värden finns i HTML5-specifikationen.

Tekniskt kriterium3.3.1 – Visa att ett fel uppstått och beskriv det tydligt

Detta är del 2 av detta kriterium (del 1 finns i avsnittet Formulär). Om ett inmatningsfel upptäcks automatiskt så ska det som är fel markeras och felet beskrivas för användaren med text. Fältet markeras med attributet aria-invalid. Om valideringen sker med JavaScript ska behållaren för felmeddelandet vara en live region.

Felmeddelandet bör ligga i ett <strong>, antingen inuti ledtexten eller mellan ledtext och fält. Fältet bör referera till felmeddelandet med aria-errormessage. Här följer ett kodexempel:

<label for="age">Ålder
<strong id="age-err">Fyll i ålder mellan 0 och 120</strong></label>

<input name="age" type="number" required min="0" max="130" id="age"
aria-invalid="true" aria-errormessage="age-err">

Tekniskt kriterium4.1.2 – Se till att skräddarsydda komponenter fungerar i hjälpmedel

Kontrollera att alla komponenter som till exempel skapats i JavaScript i användargränssnittet har ett namn och en roll som hjälpmedel kan komma åt.

Många användare behöver hjälpmedel såsom skärmläsarprogram, förstoringsprogram punktdisplay med mera. Dessa hjälpmedel kommunicerar med operativsystemets tillgänglighets-API. För att det ska fungera behöver varje del av en webbsida eller applikation vid varje tillfälle exponera sitt namn, sin roll och sitt aktuella värde. Då kan hjälpmedlet presentera applikationen på ett korrekt sätt för användaren.

Tekniskt kriterium2.5.3 – Möjliggör röststyrning av knappar och kontroller

Kontrollera att text som är synlig på knappar och andra gränssnittskontroller också finns i, och överensstämmer med, den maskinläsbara etikett som representerar kontrollen i exempelvis program för röststyrning.

Den som använder röststyrning säger vanligtvis det som står på en knapp för att använda knappen. Detta fungerar om det som står på knappen motsvarar den maskinläsbara texten. Upplevelsen för seende som använder skärmläsare blir också bättre om uppläst text matchar det som visas på skärmen.

Tekniskt kriterium4.1.3 – Se till att hjälpmedel kan presentera meddelanden som inte är i fokus

Kontrollera att statusmeddelanden som presenteras i realtid (med JavaScript) kan bli automatiskt tydliggjorda genom role-attribut, aria-live eller liknande, utan att först få fokus.

Se till att de som använder tekniska hjälpmedel som exempelvis skärmläsare och förstoringsprogram kan göras uppmärksamma på viktiga meddelanden även om de presenteras utanför det område på sidan som användaren har i fokus. Berörda användare riskerar annars att missa varningar, upplysningar och felmeddelanden.


Ikonen i toppen av inlägget kommer från Icons8 och du som vill ladda ner denna text som HTML kan gå till följande länk till HTML-koden som textfil, den lyder under BY-NC-SA.