U101: Lösningen är skapad med tillgängliga tekniker (exempelvis html, css och JavaScript) Godkänd

Förklaring

Teknikerna som används måste kunna hålla tillgänglig information, exempelvis måste bilder kunna beskrivas med text. De ska också kunna tolkas av hjälpmedel.

Det här kravet matchar inte något enskilt krav i WCAG men är en förutsättning för att kunna möta kraven i WCAG.

U102: Koden följer standarden korrekt Godkänd med undantag

Förklaring

Observera att det här kravet i WCAG 2.1 inte längre kontrolleras av Digg i Sverige. Kravet är också borta ur WCAG 2.2. Vi rekommenderar fortfarande att koden följer standard så långt som möjligt, men det är alltså inte längre ett krav för att möta lagkraven i Sverige.

Motivering till bedömning av punkten

Vanligt förekommande på webbsidor som använder ett CMS att style-elementet ligger på fel ställe.

U103: Tillgänglighetsfunktioner är möjliga att aktivera på ett tillgängligt sätt och fungerar som de ska Inte aktuell

Förklaring

Om gränssnittet har funktioner som tillgängliggör information eller funktioner för grupper med användare så måste dessa gå att aktivera för de användare de är tänkta. Exempelvis måste en skärmläsare för gravt synskadade användare kunna startas utan att man ser. Ett annat exempel är en knapp för att aktivera ett högkontrastläge, den knappen måste ha samma höga kontrast som den aktiverar i gränssnittet i övrigt.

I första hand ska gränssnittet stödja operativsystemets inställningar och tillgänglighetsfunktioner, men om gränssnittet har egna funktioner så ska dessa gå att aktivera på ett tillgängligt sätt.

U104: Gränssnittet kräver inte att användaren kan använda en specifik biometrisk teknik Inte aktuell

Förklaring

Det måste gå att använda gränssnittet även om användaren inte kan använda en specifik biometrisk teknik, exempelvis fingeravtrycksavläsning. Alternativet kan vara en annan biometrisk teknik eller en icke-biometrisk teknik.

Kravet gäller enbart för själva appen/programmet, inte för operativsystemet eller enheten.

U105: Funktioner och verktyg för att skapa och redigera innehåll stödjer tillgänglighet Inte aktuell

Förklaring

Om gränssnittet ger användaren möjlighet att lägga in och redigera innehåll som visas för andra användare ska verktyget stötta användaren i att skapa tillgängligt innehåll.

Det här gäller inte för publiceringsverktyg som enbart är åtkomligt för anställda inom organisationen, det handlar istället om funktioner och verktyg som ger externa användare möjlighet att skapa och redigera innehåll i gränssnittet som sedan kan visas av andra användare. Har inte gränssnittet sådan funktionalitet är inte punkten aktuell. Notera att publiceringssystem förstås också bör vara tillgängliga precis som alla interna system.

U106: Omvandling av information eller kommunikation bevarar tillgängligheten Inte aktuell

Förklaring

Om gränssnittet används för att omvandla information eller kommunikation från ett format till ett annat format, eller en form till en annan så bevaras tillgänglighet vid omvandlingen så långt målformatet har stöd för det och så länge informationen inte är upphovsrättsskyddad eller skyddad på något annat sätt som gör att den inte får överföras.

U110: Röst- och videosamtal har tillräckligt hög kvalitet Inte aktuell

Förklaring

För användare med nedsatt hörsel eller syn är ljud- och bildkvalitet avgörande vid kommunikation. Därför ska ljud förmedlas med ett frekvensområde som har en övre gräns på som lägst 7 kHz. Detta krav gäller för tvåvägs röstkommunikation, alltså inte för poddar eller videor, men vi rekommenderar att säkerställa en hög kvalitet även i de situationerna.

För video gäller att det ska finnas ett läge som minst erbjuder en upplösning på 320x240 pixlar och en frekvens på minst 20 bilder per sekund vid bra nätverksförhållanden. Kravet gäller för videosamtal, alltså inte för videor generellt men vi rekommenderar att säkerställa en hög kvalitet även i vanliga videor i gränssnittet.

U111: Det finns möjlighet till realtidstextning vid röstkommunikation Inte aktuell

Förklaring

Om gränssnittet erbjuder användarna att prata med andra (tvåvägs röstkommunikation) med eller utan bild, så ska det också finnas möjlighet att skriva till varandra i realtid. Det innebär att användarna ska kunna se varje tecken som skrivs, när det skrivs. det skiljer realtidstextning från vanliga chattfunktioner där användaren först skriver och sedan skickar meddelandet.

Det ska då också vara möjligt att förstå vem som skrivit vad, både visuellt och för skärmläsaranvändare.

U112: Användaren behöver bara mata in information en gång i en process (ny i WCAG 2.2) Inte aktuell

Förklaring

Användaren ska inte behöva skriva in samma information flera gånger i en process. Om en tidigare inmatad uppgift behövs igen ska den antingen fyllas i automatiskt eller finns tillgänglig för användaren att välja.

Notera att kraven bara gäller inom en process. Det innebär inte att applikationen behöver lagra uppgifter som kan återanvändas i andra sessioner eller tjänster.

Undantag från det här kravet är om

• det är nödvändigt att informationen skrivs in två gånger
• informationen krävs för att garantera innehållets säkerhet
• den tidigare inmatade informationen inte längre är giltig.

”Nödvändigt” innebär att funktionen blir meningslös om informationen fylls i automatiskt, exempelvis i ett spel eller prov som går ut på att testa minnesfunktionen.

Ett exempel på säkerhetsundantaget är när man skapar eller byter lösenord. Eftersom det man skriver in vanligtvis inte går att läsa, kan applikationen kräva att man skriver in det lösenordet två gånger för att minska risken för felskrivning.

Engångskoder för autentisering är ett exempel på information som inte längre är giltig vid den andra inmatningen.

Att informationen ska finnas ”tillgänglig för användaren att välja” kan vara uppfyllt på flera olika sätt, till exempel om användaren kan

• välja ett värde i en rullgardinslista
• markera text på sidan, kopiera den och klistra in den i fältet
• kryssa i en kryssruta för att återanvända information, till exempel för att ange att faktureringsadressen är densamma som leveransadressen.

Informationen måste i så fall finnas på samma sida; helst synlig och nära fältet där den ska matas in på nytt. Men kravet är uppfyllt även om den finns långt ifrån fältet och ligger i ett utfällbart område.

Kravet gäller information som användaren ska skriva in, men inte information som användaren tillhandahåller på andra sätt (till exempel genom att ladda upp en fil).

U201: Alla meningsbärande bilder och andra grafiska element har ett textalternativ som ger en likvärdig beskrivning till användare som inte ser bilden Underkänd

Förklaring

Ett meningsbärande grafiskt objekt är exempelvis foton, illustrationer och ikoner som används för att ge information eller visa något på sidorna. För användare som inte ser är det viktigt att få samma information om vad bilderna visar. Exakt var gränsen för meningsbärande bilder går kan vara svår att definiera, men om du använder bilder för att förstärka informationen bör de nästan alltid vara beskrivna.

Det finns undantag från detta, exempelvis om du har en utskriftsikon och texten "Skriv ut" i direkt anslutning till ikonen. Att då beskriva ikonen också skulle innebära dubbel information vilket kan bli tjatigt.

Använd alt-attributet på img-elementet när det är möjligt.

Du kan använda aria-label om det inte är möjligt att använda alt-attributet, om det exempelvis är en bild som lagts in med svg-elementet eller på något annat alternativt sätt.

Det viktiga är att all information som ges i form av grafik också är inlagd som text och nåbar för användare som inte kan se bilderna.

Motivering till bedömning av punkten

Det är alldeles för många bilder som ska ha en bildbeskrivning som inte har det, eller så har de otillräckliga bildbeskrivningar.

Individuella problem rapporterade på den här punkten

U202: Grafiska element som enbart är dekorativa eller där en alternativtext skulle innebära onödig upprepning för användarna, har en tom alt-text. Underkänd

Förklaring

Exempelvis ska länkade bilder som även har en text i länken inte upprepa det som står i länktexten (exempelvis en länkad ikon av en skrivare med texten "Skriv ut" i länken, ska inte ha en alt-text).

Använd i första hand css för att lägga in dekorativa bilder. Om bilden ligger i html-koden ska den ha alt-attributet, men det ska då vara tomt. Du kan också använda aria-hidden eller role="presentation" på bilden.

Motivering till bedömning av punkten

Det finns ikoner som endast är dekorativa men de har ingen tom alt-text. Här kan man också funder på om hero-sektionens bilder ska vara dekorativa eller inte.

Individuella problem rapporterade på den här punkten

U203: Det finns en textförklaring tydligt associerad med varje video och animering som förmedlar information Underkänd

Förklaring

Precis som bilder har textalternativ ska det finnas en kort beskrivning av vad en video eller animering innehåller för information för användare som inte kan se. Detta är inte samma sak som en syntolkning av en film eller en fullständig transkribering. Syftet är i stället att användaren ska förstå vad filmen visar för information utan att starta den.

En video som ger en introduktion till tillgänglighet kan exempelvis ha en rubrik ovanför som anger att det är ”Introduktionsfilm om tillgänglighet”.

Motivering till bedömning av punkten

Alla filmer ska ha en förklarande text, som en rubrik som introducerar användaren till innehållet i filmen.

Individuella problem rapporterade på den här punkten

U204: Podcasts och andra ljudklipp har likvärdiga textbeskrivningar Inte aktuell

Förklaring

En länk på sidan är ok, men den måste vara tydligt utpekad så att användarna förstår att det är en länk till en textversion av ljudklippet.

U205: All förinspelad video är textad Underkänd

Förklaring

Språket på textningen ska vara det samma som det talade språket i videon.

Textningen ska inte enbart innehålla dialogen utan all viktig ljudinformation.

Motivering till bedömning av punkten

Det finns filmer som inte är textad.

Individuella problem rapporterade på den här punkten

U206: Live-sänd video är textad Inte aktuell

Förklaring

Detta krav finns med i EN 301 549 och WCAG, men är inte ett krav i Europeisk lagstiftning för tillfället.

U207: Användaren kan välja att få textremsan i videospelare uppläst Underkänd

Förklaring

Om videospelaren erbjuder en textremsa med riktigt text, alltså inte inbränt i bilden, då ska det också vara möjligt för användaren att få textremsan uppläst, antingen med en talsyntes eller med ett separat ljudspår som användaren kan aktivera i videospelaren. Detta ger användare som exempelvis inte ser textremsan eller har lässvårigheter en möjlighet att få textremsan och den eventuella språköversättningen uppläst.

Du kan se exempel på detta för vissa program i SVT Plays app.

Observera att funktionen ska finnas i gränssnittet och inte kräva att användaren har ett hjälpmedel som exempelvis en skärmläsare.

Motivering till bedömning av punkten

Videospelaren erbjuder användare en textremsa som är riktig text men videospelaren erbjuder ingen möjlighet att få textremsan uppläst.

Individuella problem rapporterade på den här punkten

U208: All förinspelad video finns också i en syntolkad version Underkänd

Förklaring

En syntolkning förklarar vad som händer visuellt i videon. Detta görs ofta som en separat video, men kan också göras som ett extra ljudspår som användaren kan välja att slå på och stänga av.

Vanliga exempel på visuell information som kräver syntolkning är textskyltar och namnskyltar.

Om speakerrösten i videon ger all väsentlig information om vad som sker i bild behövs ingen separat syntolkning.

Exempel på syntolkad video https://www.youtube.com/watch?v=O7j4_aP8dWA

U209: Viktig informationen i placeholder-texter återges även på andra sätt Underkänd

Förklaring

Placeholder-texter är problematiska för många användare. Exempelvis är det inte självklart att hjälpmedel för gravt synskadade användare läser upp texten. När användaren väl börjat skriva in text i fältet försvinner texten vilket kan göra det besvärligt om användaren om denne skulle behöva få informationen upprepad.

Tänk också på att placeholder-texter måste uppfylla kontrastkravet på text (se separat krav) vilket samtidigt kan göra att den blir så pass mörk att det kan se ut som att fälten redan är ifyllda.

Detta är inte ett krav som är kopplat mot EN 301 549 eller WCAG, men vi rekommenderar att inte lägga viktig information, som till exempel inmatningsformat, i placeholder-texter. Lägg det hellre som en del av ledtexten/etiketten.

Motivering till bedömning av punkten

Godkänt undantag: Sökfunktionen som finns i menyn för metodboken. Underkänt: Kontaktformuläret har placeholder-text I alla sina inmatningsfält.

Individuella problem rapporterade på den här punkten

<label for="email-input">E-postadress</label>
<input id="email-input" type="email" autocomplete="email" aria-describedby="email-help-text"/>
<p id="email-help-text">Ange din e-postadress. Exempel: example@dindomän.se</p>

U210: Alla interaktiva objekt är beskrivna i text för användare på ett sätt som gör det enkelt att förstå syftet med objektet Godkänd med undantag

Förklaring

Det här gäller formulärobjekt, länkar, knappar och andra interaktiva objekt. Alla sådana objekt måste vara möjliga att förstå även för användare som inte kan se. Exempelvis ska länkar ha tydliga länktexter som förklarar länkens funktion, knappar ska ha tydliga knapptexter, och formulärobjekt ska beskrivas i ledtexter som kopplas med label-element. Om det inte är möjligt så kan även attributet aria-label användas för att ge en beskrivning.

Kravet innebär också att objektets tillstånd ska vara beskrivet om det är relevant, exempelvis om en kryssruta är vald eller inte, om ett expanderbart område är utfällt eller inte.

Den här punkten angränsar till flera andra punkter i checklistan. Syftet här är att fånga upp alla fall som inte tydligt hör in under en annan punkt.

Det är viktigt att du testar alla objektbeskrivningar med en skärmläsare, både på dator och mobil.

Motivering till bedömning av punkten

Kontaktformuläret kan tydliggöra vad meddelande är. Eftersom kontaktformuläret bara går att nås från ordlistan så kan man förtydliga det med en hjälptext.

U211: Alla iframe-element som presenteras för användarna ska ha en kort beskrivning av innehållet i attributet title Underkänd

Förklaring

Iframe används för att visa innehåll från en annan websida i den aktuella webbsidan. Detta görs ofta när man exempelvis vill lägga in en videospelare, ett Twitterflöde eller någon annan form av applikation eller tredjepartslösning.

Gravt synskadade användare kan välja att låta hjälpmedlet tolka innehållet i ramen eller hoppa över den. För att de ska ha en aning om innehållet krävs det då ett title-attribut som förklarar innehållet.

Motivering till bedömning av punkten

Instagramflöde saknar en beskrivande titel.

Individuella problem rapporterade på den här punkten

U212: Det finns alternativa sätt att ta del av information som ges i bildkartor Inte aktuell

Förklaring

Serverbaserade bildkartor är bilder där användaren kan klicka på en punkt i bilden, koordinaterna skickas då till servern som svarar med att uppdatera bilden eller sidan beroende på var i bilden användaren klickade.

Klientbaserade bildkartor är bilder där det finns fördefinierade områden i bilden där användaren kan klicka för att sidan ska uppdateras. Dessa kan också hanteras med tangentbord. Användaren kan tabba mellan de olika områdena i bilden och välja ett område/en länk genom att trycka Enter.

Undvik serverbaserade bildkartor. Säkerställ att all meningsbärande information som går att få fram i bildkartan också finns som ett textalternativ.

Notera att ”bildkarta” inte är samma sak som en karta. En bildkarta kan vara en bild av vad som helst där det finns olika objekt att klicka på.

U301: Rubrikstrukturen på alla sidor inleds med en rubrik kodad med elementet h1 Underkänd

Förklaring

Rubrikstrukturen ska återspegla informationshierarkin på sidan. Att inte inleda strukturen med en rubrik på nivå H1 innebär att rubrikstrukturen ser trasig ut för gravt synskadade användare.

Detta är inte ett krav i EN 301 549 eller WCAG, men vi rekommenderar starkt att följa det ändå för att användarna ska kunna lita på att strukturen är korrekt och återspeglar informationen på sidan på ett korrekt sätt.

Motivering till bedömning av punkten

Första rubriken på sidan ska vara en H1.

U302: Alla texter som visuellt fungerar som rubriker är också kodade som rubriker med lämplig rubriknivå Godkänd

Förklaring

Använd i första hand html-elementen h1 till h6. Om det inte är möjligt går det att istället använda WAI-ARIA.

U303: Rubrikstrukturen hoppar inte över nivåer Underkänd

Förklaring

H1 ska följas av H1 eller H2. En H2 rubrik ska följas av H1, H2 eller H3 och så vidare. Hoppa exempelvis inte direkt från H1 till H4.

Motivering till bedömning av punkten

På många sidor hoppar man över rubriknivåer.

U304: Använd inte radbrytningar eller tomma stycken för att skapa luft i texterna Underkänd

Förklaring

En bra typografi är viktig för läsbarheten. I det ingår också att ha gott om luft i texterna, inte minst mellan olika stycken och runt rubriker. Luften i texterna ska skapas med hjälp av formateringen, inte genom att lägga in tomma rader eller stycken. Om det känns som att texterna blir för kompakta är det stilmallarna som ska uppdateras.

Tomma rader som skapas med flera radbrytningar eller med tomma stycken läses upp av uppläsande hjälpmedel som ”tom” eller ”blank”.

Motivering till bedömning av punkten

Tomma p-element förekommer ganska frekvent.

Individuella problem rapporterade på den här punkten

U305: Listor skapas med relevanta list-element i koden Underkänd

Förklaring

I html:

• Listor där ordningen inte är viktig kodas med elementen ul och li.
• Listor där elementens ordning påverkar innebörden kodas med elementen ol och li.
• Beskrivningslistor (tidigare definitionslistor) kodas med elementen dl, dt och dd. Det här är situationer där listorna består av termer/begrepp som förklaras.

Motivering till bedömning av punkten

Det förekommer olika typer utav listor där exempelvis ordlistan borde vara kodad som en beskrivningslista och tidslinjen över ett besök ser ut som en lista men inte är det.

Individuella problem rapporterade på den här punkten

U306: Html-elementet blockquote används för fristående citat och q används för citat i meningar Underkänd

Förklaring

Information om blockquote-elementet:

https://www.w3.org/WAI/tutorials/page-structure/content/#blockquote

Information om q-elementet:

https://www.w3.org/TR/WCAG20-TECHS/H49

När du använder blockquote och q ska du inte lägga in egna citationstecken, det ska i stället hanteras av webbläsaren.

Motivering till bedömning av punkten

Korrekt HTML-element används inte för citat.

Individuella problem rapporterade på den här punkten

U308: Rad- och kolumnrubriker i tabeller kodas med elementet th och ska ha scope eller headers angivet i koden Inte aktuell

Förklaring

Th-elementet används för att visa vilka celler som fungerar som rubriker i en tabell. Dessa kan omfatta en kolumn, en grupp med kolumner, en rad eller en grupp med rader Du måste säkerställa att dataceller och rubrikceller är korrekt associerade. Det räcker oftast att använda scope attributet för att göra detta.

Scope kan ha följande värden:

• row = alla celler efter den aktuella cellen i en rad
• col = en kolumn
• rowgroup = alla rader efter den aktuella cellen i ett specifikt tbody-element
• colgroup = alla efterföljande kolumner i en grupp som definierats med ett colgroup-element

I mer komplexa tabeller räcker inte detta. Då behöver du använda attributet headers för att ange vilka rubriker varje specifik cell har. Du kan referera till flera olika rubriker med deras id-värde men ska då separera dem med ett mellanslag.

Exempel:

<th id=”aheading”>En rubrik</th>

<th id=”asecondheading”>En andra rubrik</th>

<td headers=”aheading asecondheading”>Datacell med två rubriker</td>

Notera att rubrikceller också kan ha rubriker så attributet headers kan även behöva användas på th-element.

U309: Uppställningar av information som ser ut som tabeller är också kodade som tabeller med korrekt html-kod Inte aktuell

Förklaring

Använd html-elementen table, thead, tbody, caption, tr, th, td eller om det inte är möjligt, motsvarande WAI-ARIA roller.

U311: Tabelltexter som förklarar tabellens innehåll är inlagda med elementet caption Inte aktuell

Förklaring

Använd <caption>-elementet eller om det inte är möjligt, en H1-H6-rubrik på lämplig nivå för att lägga in en överskrift som anger vad tabellen visar.

U312: Tabeller används till tabelldata och inte för att enbart styra utseendet Inte aktuell

Förklaring

Använd css för att skapa en layout. Använd enbart tabeller för riktig tabelldata.

U314: Typ av formulärobjekt är vald för att underlätta inmatningen av data Godkänd

Förklaring

Undvik exempelvis select-listor för stora datamängder eller när det är få val (2-4 stycken).

Använd radioknappar när endast ett alternativ ska väljas, och använd kryssrutor när användaren kan komma att välja flera alternativ samtidigt.

Använd lämpliga input typer, exempelvis text, password, email, date och time.

U315: Alla fel som uppstår i formulär beskrivs med en text som förklarar vad som gick fel Underkänd

Förklaring

Felmeddelandet måste klargöra var felet återfinns.

Motivering till bedömning av punkten

I kontaktformuläret får man inget felmeddelande som beskriver felet.

U316: Felmeddelanden som avser ett specifikt objekt (exempelvis ett inmatningsfält, eller en kryssruta) är associerat med det objektet i koden Inte aktuell

Förklaring

Detta kan göras genom att lägga felmeddelandet i label-elementet som avser formulärobjektet, eller med exempelvis aria-describedby.

Motivering till bedömning av punkten

Finns inget felmeddelande så just nu är denna inte aktuell.

U317: Grupper med formulärobjekt (exempelvis grupper med radioknappar eller kryssrutor) är grupperade i koden med elementet fieldset och beskrivs i elementet legend Inte aktuell

Förklaring

Tänk på att elementet legend måste vara det första elementet i det fieldset det avser.

U318: Alla beskrivningar/ledtexter är associerade med det formulärobjekt de avser i koden Underkänd

Förklaring

Detta görs primärt genom att lägga ledtexten i ett label-element och associera det med formulärobjektet.

Det kan, om nödvändigt, också göras med aria-label om beskrivningen inte ska synas visuellt.

Motivering till bedömning av punkten

I kontaktformuläret är ledtexten inte kopplat till sitt inmatningsfält.

Individuella problem rapporterade på den här punkten

<label>
Förnamn
<input autocomplete="given-name" type="text"/>
</label>

<label for="f-name">Förnamn</label>
<input id="f-name" autocomplete="given-name" type="text"/>

U319: Element i html-koden är placerade i en logisk ordning Godkänd

Förklaring

Detta är viktigt för skärmläsaranvändare eftersom hjälpmedlets läsordning bestäms av ordningen i koden.

En bra utgångspunkt är att innehållet ska vara logiskt och begripligt även när css stängts av i webbläsaren.

U320: Beskrivningen som ges till hjälpmedel, exempelvis skärmläsare, inkluderar även den synliga texten som beskriver det interaktiva objektet Godkänd

Förklaring

Om det finns en synlig text som beskriver ett interaktivt objekt på sidan så ska den texten också inkluderas i den beskrivning som tillgängliggörs för hjälpmedel.

Motivering till bedömning av punkten

Huvudnavigeringens länkar går inte att komma åt för VoiceOver i macOS, Chrome. Man kan välja att inte fördjupa sig i det här felet då andelen VoiceOver + Chrome användare är så otroligt liten.

U321: Knappar och länkar som fäller ut/fäller ihop innehåll på sidan kodas med aria-expanded Inte aktuell

Förklaring

Aria-expanded="true" anger att ytan är utfälld.

Aria-expanded="false" anger att ytan är ihopfälld.

U323: Statusmeddelanden och annat, automatiskt uppdaterat innehåll beskrivs för skärmläsare Inte aktuell

Förklaring

Det här kravet handlar om uppdateringar av innehåll som sker utan att sidan laddas om.

Användarna måste uppmärksammas på förändringar/uppdateringar som sker, men detta måste göras på ett sätt så att det inte blir störande för användarna. Viktiga uppdateringar och meddelanden måste förmedlas så fort som möjligt, medan mindre viktiga uppdateringar kanske inte alls ska förmedlas till användaren.

Attributet aria-live kan användas för en del sådana här situationer.

Du kan också överväga att använda WAI-ARIA rollerna "status", "alert" och "alertdialog" för att markera meddelanden som ska avbryta användaren.

U325: Alla relationer som skapas genom hur innehållet är presenterat finns också angivet i koden Godkänd

Förklaring

Ett exempel kan vara en chat.

Du ser att meddelanden som ligger till vänster i ytan är från den andra parten i chatten. Meddelanden till höger är dina.

Den här informationen måste också finnas i koden så att en användare som inte ser presentationen förstår vilka meddelanden som kommer från vilken part i chatten.

U326: Hjälptexter och instruktioner för specifika formulärobjekt är associerade med dem i koden Inte aktuell

Förklaring

Detta handlar inte om vanliga ledtexter/etiketter utan om hjälptexter och fördjupade beskrivningar. Om användaren ska mata in sitt personnummer och det under fältet framgår på vilket format det ska göras så är det den typen av information som den här punkten avser.

Du kan använda aria-labelledby eller aria-describedby för att koppla samman en hjälptext med ett formulärsobjekt.

Använd aria-labelledby när beskrivningen ger en fullständig beskrivning av syftet med formulärsobjektet.

Använd aria-describedby när hjälptexten ger en utökad beskrivning, och där det redan finns en korrekt kopplad ledtext.

Motivering till bedömning av punkten

Det finns inga hjälptexter eller instruktioner i kontaktformuläret.

U402: Instruktioner kräver inte att användaren kan se eller höra Godkänd

Förklaring

Undvik instruktioner som "klicka på knappen till höger" och liknande.

Du kan använda riktning, form, storlek och färg i dina instruktioner, men du måste ha något mer, exempelvis "Klicka på knappen 'Ja' till höger".

Motivering till bedömning av punkten

Enda riktningen som har hittats är ovanför, och det fungerar. Notering: När skärmläsare kommer till en video läses beskrivningen till videon "Klippet ovan..." upp innan de är inne i själva videospelaren. Här kan man fundera på om det verkligen behöver stå "ovan" i beskrivningen.

U403: Färg används inte som det enda sättet att förmedla information eller särskilja objekt Godkänd med undantag

Förklaring

För användare med nedsatt syn eller kognitiva svårigheter är det viktigt att information, status och interaktion inte enbart förmedlas visuellt med färg, det behövs något mer, synligt, som framhäver statusen/informationen/interaktionen.

Det här rör exempelvis diagram, markering av felmeddelanden, länkar i löptext och status på interaktiva objekt.

Motivering till bedömning av punkten

I kontaktformuläret används en röd stjärna för att indikera att ett formulärsobjekt är obligatoriskt.

Individuella problem rapporterade på den här punkten

U404: Länkar skiljer sig från vanlig text med mer än bara färg Godkänd

Förklaring

Du kan använda understrykning, ikoner, fetad text eller andra metoder som du enbart använder på länkar.

Det räcker inte med understrykning när muspekaren hovrar över länken. Alla interaktiva element ska vara enkla att identifiera utan att peka med musen på dem eller tabba till dem med tangentbordet.

U406: Formulärobjekt är byggda så att det i koden framgår vad det är för information som efterfrågas Godkänd

Förklaring

Så långt möjligt ska formulärobjekts syften vara tydliggjorda i koden. Använd formulärobjekt som matchar den data du ber användaren välja eller fylla i.

I html används attributet autocomplete för att underlätta för hjälpmedel och webbläsare att hjälpa användaren att fylla i information. De vanligaste uppgifterna som användare brukar fylla i har fördefinierade autocomplete-värden. Genom att använda dem gör man det tydligt för webbläsare och hjälpmedel att det är just den informationen som ska matas in. Information om attributet och möjliga värden finns här: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete

U408: Grafik som används för att visa interaktiva objekt, visa status, eller för att förmedla information (exempelvis diagram) har tillräckliga kontraster mot bakgrunden Underkänd

Förklaring

Kontrasten ska vara minst 3.0:1

https://developer.paciellogroup.com/resources/contrastanalyser/

Motivering till bedömning av punkten

Fokusindikeringen är borttagen på vissa sidor. Fokusindikeringen för hela sidan, där den inte är borttagen, är webbläsarens egna.

Individuella problem rapporterade på den här punkten

U409: All text har tillräckliga kontraster mot bakgrunden Underkänd

Förklaring

Vanlig text: > 4.5:1

Stor, fet text större än 18.67px: > 3.0:1

Stor text större än 24px: > 3.0:1

Mät kontrasterna på den punkt som har sämst kontrast.

https://developer.paciellogroup.com/resources/contrastanalyser/

Motivering till bedömning av punkten

På en nyhet så finns det text som inte har tillräcklig kontrast mot sin bakgrund.

Individuella problem rapporterade på den här punkten

U410: Undvik att lägga text mot en bakgrund som skiftar mycket i färg och nyans Underkänd

Förklaring

Det gör texterna svåra att läsa även om kontrasterna i sig är bra nog.

Motivering till bedömning av punkten

Det förekommer ofta att text ligger ovanpå en bild. I vissa fall händer det för mycket i bilden där texten förekommer.

Individuella problem rapporterade på den här punkten

U411: Använd riktig text, inte bilder som föreställer text Godkänd

Förklaring

I komplex grafik, exempelvis diagram, kan viss text vara en del av bilden. Det är även godkänt med exempelvis logotyper.

U412: Undvik innehåll som rör sig, blinkar eller skrollar automatiskt som exempelvis karuseller och animationer, om det finns sådana element måste de gå att pausa Godkänd

Förklaring

Allt innehåll som rör sig, blinkar eller skrollar och som startar automatiskt, varar mer än fem sekunder och presenteras i närheten av annat innehåll, går att pausa, stoppa eller dölja för alla användare.

U413: Innehåll på sidan och i videor blinkar aldrig mer än 3 gånger per sekund Godkänd

Förklaring

Undvik saker som flimrar i gränssnittet. Det kan exempelvis handla om animationer och innehåll i videor. Om något flimrar får det aldrig flimra snabbare än 3 gånger per sekund under någon tid. Detta är viktigt för att minska risken för att framkalla epileptiska anfall hos användarna.

Vi rekommenderar att ni varna användarna om det förekommer flimmer i filmer, innan användaren startat filmen. Det är dock inte ett krav i WCAG eller EN 301 549.

U414: Det finns mer än ett sätt att hitta information i gränssnittet Godkänd

Förklaring

Tillhandahåll exempelvis en meny och en sökfunktion. Notera att kravet gäller alla sidor (som inte är en del av ett flöde, exempelvis ett steg i en e-tjänst).

Motivering till bedömning av punkten

Det förekommer endast ett sätt att hitta information på flertalet sidor.

Individuella problem rapporterade på den här punkten

U415: Rubriker, ledtexter och knappar ger tydlig information om syftet och innehållet Godkänd

Förklaring

För att användarna snabbt ska få en bild över var de finner olika funktioner och information på en sida är det viktigt att rubriker, etiketter och knappar är tydligt beskrivna.

U416: Huvudsakligt språk är angivet i koden på alla sidor Godkänd

Förklaring

Använd lang-attributet på html-elementet.

U417: Innehåll på andra språk än sidans huvudsakliga språk markeras i koden Inte aktuell

Förklaring

Använd lang-attributet.

Det kan användas på alla html-element, exempelvis div, span och p-element.

U418: Alla sidor har en beskrivande titel Underkänd

Förklaring

Detta gäller också på "single page applications". Sidans titel måste då dynamiskt uppdateras för att återspegla informationen/vyn på sidan.

Motivering till bedömning av punkten

Man borde göra sidornas titlar tydligare.

Individuella problem rapporterade på den här punkten

U419: Listor med länkar eller funktioner som upprepas på flera sidor presenteras i samma relativa ordning Godkänd

Förklaring

Det kan finnas situationer där det blir förvirrande för användaren och då ska det här kravet ignoreras.

U420: Samma funktionalitet beskrivs konsekvent i gränssnittet Godkänd

Förklaring

Exempelvis ska du använda samma terminologi genom hela gränssnittet. Om ni exempelvis kallar det självservice, byt inte till e-tjänst på andra ställen.

Kravet gäller även ledtexter i formulär. Ber ni användaren att ange en e-postadress i ett formulär ska ni inte kalla det mejladress i ett annat.

U421: Hjälpfunktioner är konsekvent placerade i gränssnittet (ny i WCAG 2.2) Inte aktuell

Förklaring

Om någon eller några av nedanstående hjälpfunktioner finns på flera webbsidor inom en webbplats ska de förekomma i samma ordning i förhållande till övrigt sidinnehåll (såvida inte användaren gjort en förändring).

• Kontaktinformation, som telefonnummer, e-postadress, öppettider.
• Kontaktfunktioner, som kontaktformulär, chatt, sociala medier.
• Självhjälp, som vanliga frågor (FAQ), supportdokumentation.
• Automatiserad hjälp, som chattbot.

Funktionerna kan antingen finnas direkt på sidan eller vara länkade. Notera att kravet inte innebär att dessa hjälpfunktioner måste finnas, utan bara de ska vara konsekvent placerade om de finns.

Kravet på konsekvent placering gäller innehållsordningen, inte presentationen. Innehållsordningen är ordningen i HTML-koden och den ordning som en skärmläsare presenterar innehållet i. Presentationsordningen är innehållets visuella ordning på skärmen, något som kan styras med hjälp av CSS.

Länkar till hjälpfunktioner kan ha olika visuell placering I exempelvis mobilvy och fullskärmsvy. Om användaren förändrar vyn, exempelvis genom att zooma eller att ändra orienteringen på en mobil enhet, kan alltså placeringen förändras, men den ska då vara konsekvent så länge användaren inte förändrar vyn igen.

U422: Alla objekt som kräver att användaren väljer eller matar in information har en synlig beskrivning Godkänd

Förklaring

Alla objekt/element som kräver att användaren väljer något (exempelvis genom att användaren ska klicka på ett objekt) eller kräver att användaren fyller i något, har en synlig beskrivning som förklarar vad användaren förväntas göra.

Om syftet med fältet är uppenbart för seende krävs ingen synlig ledtext, exempelvis för ett enstaka fält i anslutning till en beskrivande knapp. Då kan det räcka det med en dold ledtext eller exempelvis aria-label som förmedlar informationen till hjälpmedel.

Det räcker inte med en placeholder-text för att möta kravet.

U423: Beskrivningar av objekt som kräver att användaren väljer eller matar in information innehåller information om vad som ska göras och vilka format som ska användas Underkänd

Förklaring

Detta inkluderar information om ett fält är obligatoriskt eller inte.

Motivering till bedömning av punkten

Inte tillräckligt tydligt att ett fält är obligatoriskt i kontaktformuläret. Fältet för meddelande behöver mer information.

Individuella problem rapporterade på den här punkten

U424: Fel beskrivs med en text som även informerar om hur felet kan korrigeras om det är möjligt Underkänd

Förklaring

För användarna är det inte enbart viktigt att förstå när något blivit fel, och var det blivit fel, utan även hur de kan korrigera felet. Skriv därför inte enbart att något har blivit fel, försök hjälpa användaren att korrigera felet. Om användaren exempelvis angett ett personnummer utan de första två siffrorna i århundradet (19 eller 20) meddela användaren att det är detta som verkar vara fel.

Ändra aldrig värden som användaren angett utan att meddela användaren vad som skett. Om användaren angett ett värde utanför ett efterfrågat spann får ni inte ändra det till innanför spannet utan att samtidigt meddela användaren vad som ändrats. Föreslå gärna ändringar, men gör dem inte automatiskt. Detta gäller inte om ändringen enbart handlar om formatering. Exempelvis, om systemet automatiskt lägger in eller tar bort bindestreck i telefonnummer eller datum.

Motivering till bedömning av punkten

De fel som kan uppstå i kontaktformuläret beskriver inte vad som gick fel eller hur de kan korrigeras.

Individuella problem rapporterade på den här punkten

U425: Viktiga formulär låter användaren se en översikt och ger denne möjlighet att ändra sig innan formuläret skickas Inte aktuell

Förklaring

Detta gäller alla formulär som innebär juridiska eller ekonomiska åtgärder.

U426: Undvik att använda ikoner utan tillhörande, synlig text Godkänd med undantag

Förklaring

Även relativt välkända ikoner är svåra att tolka för en del användare.

Motivering till bedömning av punkten

Det finns en ikon utan tillhörande, synlig text. Notering: Även om många känner igen ikonen för menyn, så kan det finnas de som inte vet, eller kommer ihåg, vad ikonen betyder. Sedan får man mer klickyta om man lägger till text med ikonen. Detta hjälper de med motoriska svårigheter att klicka på knappen.

U427: Använd inte förkortningar om det inte är nödvändigt och skriv ut förkortningar första gången de används på en sida Godkänd

Förklaring

Även välkända förkortningar kan vara besvärliga för en del användare. Dessutom skapar oftast förkortningar en mikropaus när användaren läser. Det finns också risk för att hjälpmedlen läser upp dem på ett felaktigt sätt. Därför bör du bara använda förkortningar när det är nödvändigt, och alltid undvika förkortningar av vanliga ord, så som ex., o.s.v., fr. och m.m..

Motivering till bedömning av punkten

Har inte stött på någon förkortning.

U428: Användaren får relevant återkoppling när denne utför något i gränssnittet Godkänd med undantag

Förklaring

Exempelvis ett meddelande som anger att informationen sparats när användaren klickat på en spara-knapp.

Motivering till bedömning av punkten

När man skickar ett meddelande får man information att formuläret är skickat. Notering: Eftersom det är ett meddelande man skickar så borde det stå att meddelandet är skickat. Man kan också tydliggöra den feedback man får med lite designelement. Sedan borde man uppdatera sidans titel så att den speglar innehållet på sidan. Eftersom sidan laddas om är det sidans titel som skärmläsare kommer läsa upp först efter de skickat in formuläret. Det man förväntar sig efter att man skickat in ett formulär är feedback på om man lyckades eller inte.

U429: Ljud som startar automatiskt kan stoppas Inte aktuell

Förklaring

Kravet gäller enbart när ljud varar minst tre sekunder.

U431: Innehåll som uppdateras automatiskt kan pausas Inte aktuell

U432: Länktexter är beskrivande och begripliga i den kontext där de ligger Godkänd

Förklaring

Länktexter bör vara korta, men samtidigt beskrivande och ge all väsentlig information som användaren behöver för att förstå vad som kommer att hända om denne klickar på länken.

En text i samma paragraf, lista, tabellcell eller kopplad tabellrubrik kan också användas för att beskriva syftet, men så långt som möjligt ska länktexten själv ge all relevant information.

U433: Felmeddelanden är designade så att de är enkla att se och särskilja från annan information Godkänd med undantag

Förklaring

Felmeddelanden är oftast viktiga för användaren. Det är därför viktigt att de tydligt skiljer sig från annan information, är enkla att uppfatta men samtidigt inte heller är för "fientliga"/"alarmerande" designade.

Detta är inte ett krav i EN 301 549 eller WCAG 2.1, men något som ändå är viktigt för användarna. Du kan möta lagkraven utan att följa det här kravet, men vi rekommenderar starkt att även inkludera det här kravet.

Motivering till bedömning av punkten

Det finns inga egendesignade felmeddelanden. Webbläsarens felmeddelanden skiljer sig från annat innehåll och är relativt enkla att urskilja från övrig information.

U440: Eventuella supporttjänster och dokumentation är tillgänglig Inte aktuell

Förklaring

Det finns inget krav på att det måste finnas dokumentation eller supporttjänster, men om det finns ska dokumentationen inkludera information om hur eventuella tillgänglighetsfunktioner och inställningar kan användas. Detta inkluderar eventuella instruktioner för hur gränssnittet ska användas med hjälpmedel och vilka eventuella begränsningar som finns.

Supporttjänsterna och dokumentationen ska finnas i ett tillgängligt format. Det behöver inte vara webbaserat.

U450: Autentiseringsprocesser kan fullföljas utan kognitiva funktionstest (ny i WCAG 2.2) Inte aktuell

Förklaring

Inget steg i en autentiseringsprocess, till exempel inloggning, får kräva ett kognitivt funktionsprov, med undantag för om det finns ett alternativt sätt att autentisera sig utan kognitivt funktionsprov eller om det finns sätt för användaren att få hjälp att utföra provet.

Autentisering är situationer där du bekräftar att det är du, exempelvis inloggning och signering. Det här inkluderar även autentisering som inte är direkt knutet till dig som person, exempelvis inloggning med användarnamn och lösenord.

Ett ”kognitivt funktionsprov” innebär att användaren behöver kunna minnas, modifiera eller transkribera information. Ett exempel är att behöva komma ihåg samt skriva in användarnamn (med undantag för det egna namnet, personnumret, e-postadressen eller telefonnumret), lösenord och PIN-koder. Andra exempel är att skriva in text, att stava korrekt, att utföra matematiska beräkningar eller att lösa gåtor och problem.

Kognitiva funktionsprov kan utestänga användare med nedsatt närminne eller med olika typer av kognitiva nedsättningar.

Kravet gör undantag på AA-nivå för kognitiva funktionsprov som innebär att användaren ska känna igen bilder, filmer eller ljud. Det finns också ett undantag för prov som går ut på att identifiera en bild, en film eller ett ljudklipp som användaren själv laddat upp i tjänsten.

U501: Layouten anpassar sig efter skärmstorleken Godkänd

Förklaring

Allt innehåll bör vara responsivt men det finns situationer där det är tillåtet med undantag. Det gäller situationer där det är svårt eller omöjligt att bibehålla funktionaliteten om storleken förändras för mycket, exempelvis för att en verktygsrad måste få plats. Exempel på undantag är komplexa tabeller, kartor, spel och videospelare.

U502: Gränssnittet fungerar även när användaren ändrar inställningar för avstånd i texter Godkänd med undantag

Förklaring

Om användaren ändrar inställningar för avstånd mellan tecken, ord, rader och stycken så ska det inte leda till att text blir oläslig.

Du kan verifiera detta med:

https://codepen.io/stevef/pen/YLMqbo/

För att möta kravet ska det gå att visa innehållet med följande avstånd:

• Radhöjd på minst 1,5 gånger font-storleken
• Avstånd efter stycken på minst 2 gånger font-storleken
• Avstånd mellan bokstäver på minst 0,12 gånger font-storleken
• Avstånd mellan ord på minst 0,16 gånger font-storleken

Motivering till bedömning av punkten

Texter i mobilen tas upp i U503.

U503: Användaren tillåts att zooma texten minst 200 procent Underkänd

Förklaring

Det är viktigt för många användare att kunna anpassa textens storlek så att den blir lättare att läsa. Det är inte enbart användarens syn som avgör utan även ljusförhållanden, storleken på skärmen, upplösningen och vad det är för typ av text.

För att möta kraven i WCAG och EN 301 549 räcker det visserligen att det finns ett sätt att förstora texten 200%, men för användaren har det stor påverkan hur detta fungerar och hur man kan förstora texten. Blockera inte användares möjlighet att zooma direkt i webbläsaren. Sträva efter att låta enhetens inställningar (operativsystemet och webbläsaren när det är relevant) styra över textstorleken. För att möta just det här kravet om textförstoring i WCAG och EN 301 549 måste du inte lyssna på inställningarna, men det finns ett eget krav i EN-standarden som innebär att du måste anpassa gränssnittet efter användarens inställningar av exempelvis färg och textstorlek, läs mer under U510.

Notera att du inte behöver ha en funktion i gränssnittet för textförstoring. Det är mycket bättre att i första hand låta användarens inställningar slå igenom, och att inte blockera zoom i webbläsarna.

Motivering till bedömning av punkten

Webbsidan tar inte hänsyn till text eller zoom inställningarna i mobilen.

Individuella problem rapporterade på den här punkten

U504: Formulär är designade med en vertikal layout som inte tvingar användaren att flytta fokus sidledes mer än nödvändigt Godkänd

U505: Tabeller är designade så att de underlättar läsningen Inte aktuell

Förklaring

Använd olika bakgrundsfärg eller linjer för att hjälpa användarna att följa raderna och/eller kolumnerna.

U506: Gränssnittet kan användas oberoende av skärmens orientering (liggande/stående) Godkänd med undantag

Motivering till bedömning av punkten

I mobilen, liggande, när man öppnar innehållsförteckningen för medotboken så finns det ingen knapp för att stänga ned menyn.

U510: Gränssnittet/appen lyssnar på användarinställningar och stödjer tillgänglighetsfunktioner i operativsystemet Godkänd med undantag

Förklaring

Gränssnittet måste stödja de användarinställningar som finns i operativsystemet när det gäller exempelvis högkontrastläge, textstorlek och avstängning av animationer.

Vanliga webbplatser kommunicerar mot webbläsaren och inte mot operativsystemet och berörs alltså inte av den här punkten.

Motivering till bedömning av punkten

I iOS lyssnar Safari på tillgänglighetsinställningar i operativsystemet. Det betyder att inställningar för högkontrastläge och textstorlek appliceras i Safari. Högkontrastläget fungerar.

U511: Webbplatsen respekterar användarinställningar i webbläsaren Underkänd

Förklaring

När gränssnittet är webbsidor som visas i en webbläsare ska de respektera användarens inställningar i webbläsaren när det gäller storlekar, färger, kontraster, typ av teckensnitt och textstorlek.

Motivering till bedömning av punkten

Lyssnar på högkontrastläge. Lyssnar inte på mörkt läge. Lyssnar inte på ändrat typsnitt. Lyssnar inte på ändrad textstorlek.

U601: All interaktion som användaren kan göra med mus eller pekskärm ska också gå att göra med tangentbordet Underkänd

Förklaring

En grundläggande faktor för att ett gränssnitt ska kunna vara tillgängligt är att det fungerar att styra allt med enbart tangentbordet. Många alternativa styrsätt bygger på tangentbordskommandon. Även exempelvis röststyrning baserar sig delvis på tangentbordskommandon. För gravt synskadade användare på PC och Mac finns inget alternativ till tangentbordsnavigation.

Tangentbordsnavigation bygger på att man flyttar fokus mellan interaktiva objekt som länkar, knappar och formulärsfält genom att trycka på tab-tangenten. Genom att sedan använda mellanslag, enter eller pilar, beroende på situationen kan du ändra värden eller aktivera länkar/knappar.

• Tabbar du till en knapp kan du aktivera den med mellanslag.
• En länk kan du följa genom att trycka Enter.
• Flikar och radioknappar väljer du med pil-tangenterna.

Tangentbordsnavigation ska även fungera i mobilgränssnitt och appar. Framförallt användare med motoriska funktionsnedsättningar har problem med pekskärmar och använder ofta tangentbord anslutna med Bluetooth till mobilen.

Motivering till bedömning av punkten

Man kan inte öppna eller stänga, (med knappen), innehållsförteckningen för metodboken och manualen med tangentbordet.

Individuella problem rapporterade på den här punkten

U602: Innehåll som visas vid mouse over kan också visas enkelt för användare som navigerar med pekskärm eller tangentbord Inte aktuell

Förklaring

Det ska också vara möjligt att dölja innehållet igen, utan att fokus flyttas från det objekt som triggade att innehållet visades.

U603: Modala fönster kan stängas med tangentbordet Godkänd

Förklaring

Förse det modala fönstret med en tydlig "Stäng"-knapp. Vi rekommenderar även att Esc tangenten kan användas för att stänga fönstret, men det är inte tillräckligt att enbart erbjuda det sättet att stänga det modala fönstret. Att Esc fungerar är alltså inte ett krav men en rekommendation.

U604: Användarna kan tabba genom hela gränssnittet utan att fastna i en specifik yta, exempelvis en videospelare Godkänd

Förklaring

För att kravet ska vara juridiskt underkänt krävs att det inte är möjligt att ta sig ur med tangentbordet. Om du exempelvis måste tabba igenom alla dagar i en månad för att komma ur en datumväljare är det inte underkänt även om det inte är speciellt användarvänligt.

U605: Interaktiva objekt markeras tydligt visuellt när de får fokus vid tangentbordsnavigation Underkänd

Förklaring

Det är viktigt att användare som navigerar med tangentbordet och är seende tydligt ser var de har fokus.

Tänk också på att, om färg eller ramar används för att visa vilket objekt som har fokus måste deras kontrast mot omgivningen, och skillnaden i kontrast mellan fokus och inte fokus, vara minst 3.0:1 för att möta kontrastkraven i WCAG 2.1, WCAG 2.2 och EN 301 549 (se även U408). Formellt sett kan den här punkten i checklistan vara uppfylld bara fokusmarkeringen är synlig, men för dåliga kontraster skulle innebära att kontrastkravet blir underkänt.

I iOS så styr du inte över vilken färg markeringen vid tangentbordsnavigation ska ha. Istället kan användaren välja mellan 5-6 olika färger i inställningarna. Som utvecklare måste man säkerställa att appen stöder dessa inställningar korrekt. Det är också viktigt att säkerställa att åtminstone en av de valbara färgerna har tillräcklig kontrast mot bakgrunden för alla fokuserbara objekt. Användaren ska inte behöva byta fokusmarkeringsfärg för att se den i enskilda vyer i appen.

På Android bör du kunna styra färgen på fokusmarkeringen med följande kod:

<item name="android:colorControlHighlight">@color/selected_item_focus</item>

Du behöver testa att det här verkligen fungerar korrekt. Du måste också säkerställa att markeringen blir tydlig i alla situationer. Välj en färg som alltid har god kontrast mot bakgrunden i appen.

Motivering till bedömning av punkten

Sidan använder webbläsarens inbyggda fokusmarkering. Det betyder att vid olika interaktiva objekt så har den otillräcklig kontrast mot sin bakgrund. Vid vissa interaktiva objekt är fokusmarkeringen borttagen.

Individuella problem rapporterade på den här punkten

U606: Objekt som får focus vid tangentbordsnavigering döljs inte av annat innehåll (ny i WCAG 2.2) Godkänd

Förklaring

Det är viktigt att användare som navigerar med tangentbordet och är seende tydligt ser var de har fokus. När det finns innehåll som lägger sig ovanpå eller bakom annat innehåll kan fokuserbara element bli skymda – helt eller delvis. Om elementet och dess fokusmarkering täcks helt och hållet blir effekten att användaren inte längre har någon aning om var fokus är.

Det är inte fullständigt klart vad som kommer att anses vara tillräckligt för att möta kravet när det blir en del av lagstiftningen, men vi rekommenderar starkt att alla objekt som får fokus är väl synliga så att användaren inte enbart ser fokus, utan även kan se vad det är för objekt som har fokus.

Länkar i stil med ”Hoppa till innehållet” som normalt sett brukar vara dolda ska visas visuellt när de får fokus för att fungera även för seende användare. Om en sådan länk är dold genom att ligga utanför skärmen är de strängt taget inte omfattade av kravet i riktlinjerna eftersom länken inte är ”skymd”, medan den om den döljs genom att ligga bakom ett annat objekt, exempelvis logotypen, tekniskt sett måste anses omfattas av kravet i riktlinjerna och då alltså måste bli synlig till viss del när den får fokus. Vi rekommenderar att den dyker upp visuellt när den får fokus. Då är man också säker på att följa kravet i riktlinjerna.

Det finns andra punkter i checklistan som rör att fokuserbara element har en fokusmarkering över huvud taget, med tillräcklig kontrast mot intilliggande färger. Syftet här är att säkerställa att objektet och fokusmarkeringen inte skyms helt av annat innehåll.

U608: Det finns en länk för att hoppa över navigationen för användare som navigerar med tangentbordet Godkänd

Förklaring

Länken bör hållas dold tills den får fokus och då visas visuellt.

Motivering till bedömning av punkten

En så kallad skip-link finns endast på sidan Nyheter.

Individuella problem rapporterade på den här punkten

U609: Ordningen vid tangentbordsnavigation är hanterbar och logisk Godkänd

Förklaring

För att möta kravet i EN 301 549 och WCAG måste tabbordningen bevara betydelse och hanterbarhet. Det innebär exempelvis att den inte ska hoppa fram och tillbaka mellan två olika komplexa komponenter, eller att ordningen gör att en användare missförstår syftet med länkar och knappar.

Vi rekommenderar dock att tabbordningen även är logisk och konsekvent för att underlätta för användarna.

Normalt sett innebär det att tabbordningen går radvis från det övre vänstra hörnet ner till det nedre högra hörnet, men i specifika situationer kan undantag vara mer logiska för användarna.

Kravet gäller inte enbart tabbordningen, utan även annan tangentbordsnavigation. Ett exempel skulle kunna vara om piltangenterna används för att navigera i en trädvy. Även då är det viktigt att ordningen gör komponenten hanterbar, och vi rekommenderar att den även ska upplevas som logisk.

U611: Det finns alternativ till gester som kräver att mer än ett finger rör skärmen samtidigt och till gester som innebär att användaren måste följa ett specifikt mönster Inte aktuell

U612: Funktionalitet baserad på drag-och-släpp kan också utföras med enkla klick (ny i WCAG 2.2) Inte aktuell

Förklaring

Det finns alternativ till dra-och-släpp, som går att utföra utan att använda flera fingrar och utan att dra. Om dra-och-släpp är nödvändigt för att kunna skapa funktionen är det ett acceptabelt undantag. Likaså om det är webbläsaren eller operativsystemet som tillhandahåller dra-och-släpp-funktionaliteten, och den inte modifierats av gränssnittet.

Det här kravet gäller funktioner som webbsidan eller appen tillhandahåller, alltså inte funktioner som behövs för att styra webbläsaren eller ett hjälpmedel.

Det finns en annan punkt i checklistan som rör gester som kräver att mer än ett finger rör skärmen samtidigt eller beror på vilken väg användaren för fingret mellan start- och slutpunkterna. Syftet här är att täcka in dra-och-släpp, som inte omfattas av den punkten.

Det finns också en punkt i checklistan som rör att funktioner som går att utföra med mus eller pekskärm också ska gå att utföra med tangentbord. Syftet här är att funktionen ska gå att utföra även utan tangentbord, till exempel med en pekskärm.

Dra-och-släpp innebär att användaren trycker ned en musknapp, eller trycker med fingret på en pekskärm, medan pekaren eller fingret befinner sig över ett element, och sedan flyttar pekaren eller fingret för att till sist släppa upp musknappen eller lyfta fingret från skärmen. Endast rörelsens start- och slutpunkter har betydelse; inte vilken väg användaren rör pekaren eller fingret mellan de två punkterna.

Dra-och-släpp kan vara svårt eller omöjligt att utföra för användare med nedsatt synförmåga, rörlighet eller finmotorik, och med alternativa inmatningssätt som styrkula, ögonstyrning eller röststyrning.

U613: Om gränssnittet kan påverkas genom rörelsesensorer så finns det även alternativa sätt att uppnå samma effekt i gränssnittet Inte aktuell

Förklaring

Om det exempelvis visas specifik information på en mobil när du skakar den ska den informationen även gå att få fram utan att flytta mobilen, om möjligt.

U614: Undvik om möjligt tidsgränser, om de används måste användaren om möjligt kunna styra tidsgränsen Godkänd

Förklaring

Om tidsgränser används ska användarna om möjligt kunna stoppa dem, förlänga tiden eller justera tidsgränserna.

U615: Användare som navigerar med tangentbordet kan navigera genom gränssnittet utan att oväntade förändringar eller avbrott uppstår och utan att fokus flyttas oväntat Godkänd

U616: Ändringar i formulärobjekt och andra inställningar flyttar inte fokus och ändrar inte innehållet på ett oväntat sätt Godkänd

Förklaring

Syftet med kravet är att inte sammanhanget för användaren ska ändras oväntat bara för att denne matar in information eller ändrar inställningar.

Det här kan handla både om att fokus flyttas oväntat eller att sidan laddas om eller att innehållet uppdateras signifikant.

Sådana ändringar kan vara väntade och utgör då inget problem. Om användaren fått information om beteendet i förväg kan det också vara godkänt.

Undvik att posta formulär enbart för att användaren matat in alla värden. Undvik också att ändra innehåll och funktioner ovanför den punkt där användaren gör inställningar eller matar in information, om det inte är tydligt för användaren att det kommer att ske.

U617: Komponenter som ska fungera som modala dialoger hindrar användaren från att komma åt innehåll i bakgrunden Underkänd

Förklaring

Modala dialoger är ytor som lägger sig ovanpå det vanliga innehållet på sidan och där användaren förväntas ta del av innehållet innan denne återgår till sidans vanliga innehåll. Dessa ska i html kodas med aria-modal=”true”.

En viktig aspekt här är att användare som navigerar med tangentbordet och användare med skärmläsare ska behålla fokus i den modala dialogen tills de tagit ställning till innehållet och aktivt stängt den. Därför ska man inte av misstag kunna få fokus i bakgrunden.

Motivering till bedömning av punkten

I en av två modala fönster kan man komma åt innehållet som ligger bakom modalen.

Individuella problem rapporterade på den här punkten

U618: Snabbkommandon för tangentbordsanvändare baserar sig inte på att användaren trycker ner en enskild alfanumerisk- eller symbol-tangent Inte aktuell

Förklaring

Alla snabbkommandon ska kräva att användaren samtidigt trycker ner minst en modifieringstangent, exempelvis Alt, Shift eller Ctrl.

U619: Objekt som kan aktiveras med mus eller pekskärm är stora nog för att det ska vara rimligt enkelt att komma åt dem (ny i WCAG 2.2) Godkänd

Förklaring

Storleken på klickbara objekt är minst 24 gånger 24 pixlar (CSS pixlar) för att möta kravet i standarderna. Det finns några tillåtna undantag:

• Avstånd: Objekt mindre än gränsvärdet är placerade så att cirklar med diametern 24 pixlar som centreras över objekten inte överlappar andra klickbara objekt eller cirklarna för andra objekt mindre än gränsvärdet.
• Ekvivalent: Funktionen går att utföra med en annan kontroll på samma sida som uppfyller detta krav.
• Inline: Målobjektet finns i en mening eller dess storlek begränsas av radhöjden för omgivande text.
• Webbläsarstyrt: Objektets storlek styrs av webbläsaren och är inte modifierat av användaren.
• Nödvändigt: En specifik presentation av objektet är nödvändig eller ett juridiskt krav.

U620: Händelser aktiveras inte när användaren klickar ner utan när användaren släpper musknappen igen Godkänd

Förklaring

Händelser aktiveras inte när användaren klickar ner utan när användaren släpper musknappen igen.

Detta gäller också vid touch, användaren ska kunna trycka på skärmen men händelsen ska inte aktiveras förrän användaren lämnar skärmen med fingret.

U630: Allt innehåll på sidan bör ligga i något landmärke Underkänd

Förklaring

Det blir enklare för användare som inte kan se att uppfatta sidans struktur och hitta allt innehåll om det ligger i landmärken som nav, header, main och footer.

Motivering till bedömning av punkten

Sidans huvudinnehåll ligger inte i rätt element, main-elementet. Innehållsförteckning är ett alternativt sätt att navigera på och borde därför ligga i ett nav-element. Paginering är ett sätt att navigera och borde ligga i ett nav-element.

Individuella problem rapporterade på den här punkten

U631: Menyn är placerad i ett nav-element Godkänd

Förklaring

Nav-elementet används för att tala om för gravt synskadade användare att de här länkarna är en del av webbplatsens navigation/meny.

I Sverige kräver inte Digg att landmärken används, men om de används ska de användas korrekt för att strukturera sidornas innehåll.

Motivering till bedömning av punkten

Sidans huvudmeny ligger i ett nav-element.

U632: Sidans centrala innehåll är placerat i ett main-element Underkänd

Förklaring

<main>-elementet används för att markera det centrala innehållet på sidan. Det gör det enkelt för gravt synskadade användare att snabbt hitta det viktiga på sidan.

I Sverige kräver inte Digg att landmärken används, men om de används ska de användas korrekt för att strukturera sidornas innehåll.

Motivering till bedömning av punkten

Sidans huvudinnehåll ligger inte i ett main-element.

U701: Gränssnittet är testat med skärmläsare, både på desktop och mobil för att verifiera att allt innehåll är nåbart och fungerar korrekt Godkänd med undantag

Förklaring

Använd åtminstone VoiceOver på iOS och NVDA med Firefox och Chrome i Windows.

Motivering till bedömning av punkten

VoiceOver på iOS (Safari), macOS (Safari, Chrome & Firefox).

U702: Gränssnittet är testat med användare, inklusive användare med funktionsnedsättningar Inte aktuell