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 Underkänd

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

Konto-alternativet I huvudnavigeringen innehåller en lista med alternativ, men ul-elementet saknar li-element.

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 Godkänd

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.

Motivering till bedömning av punkten

Redigera/skapa informationsblad. Här kan man underlätta för användaren genom att lägga till kortkommandon för hur man använder WYSIWYG-editorn för de som navigerar med tangentbordet eller med en skärmläsare.

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 förekommer bilder som ska ha alt-texter men som saknar det. Se problembeskrivning.

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

I editorn och i prologmallen har man inga tomma alt-texter på dekorativa bilder. Se problembeskrivning.

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 Godkä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

De filmer som hittats finns i informationsblad, prolog och epilog. Där presenteras dom med en rubrik.

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

Video som används läggs till utav den som skapar en föreställning. Här behöver man informera användaren om att videon man lägger till ska vara textad. Yttersta ansvaret ligger på den som skapar innehållet till föreställningen.

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

Videospelare som används är Youtube. Det finns textremsor, captions, till video, exempelvideo i epilog. Det går inte att få textremsan uppläst.

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

Motivering till bedömning av punkten

Det finns ingen syntolkad version utav de filmer som finns.

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

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.

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

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.

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

iframe-element hittat är för video-klipp. Exempelvis i en epilog, prolog och informationsblad. Där saknar iframe-elementet title-attributet. Redaktörens ansvar: se till så att videon har en kort beskrivning i title-attributet. Utvecklarens ansvar: se till så att redaktören vet hur den ska kunna göra det och ge redaktören en möjlighet att skapa tillgängligt innehåll.

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

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å.

Motivering till bedömning av punkten

I editorn, där alla noder ligger, kan ytan för alla noder tolkas som en klientbaserad bildkarta eftersom det är en bild där man kan klicka på objekt. Informationen i bildkartan återges inte på något annat sätt.

Individuella problem rapporterade på den här punkten

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

Editorn saknar H1. I besökarens gränssnitt inleds vissa vyer med H6. (Sidorna med Karaktär i övre högra hörnet). Testkörningen inleds med en H6.

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

Det hoppas över rubriknivåer en hel del. Se problembeskrivning.

Individuella problem rapporterade på den här punkten

U304: Använd inte radbrytningar eller tomma stycken för att skapa luft i texterna Godkä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”.

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

I informationsbladet, där man just nu använder en mall, listar man stegen för hur en Techformance går till. Denna ordnade visuella lista är inte en lista. I editorn är Fixlist inte en lista. Konto-alternativet i huvudnavigeringen är inte korrekt kodat som en lista. li-elementen saknas.

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 Inte aktuell

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.

U308: Rad- och kolumnrubriker i tabeller kodas med elementet th och ska ha scope eller headers angivet i koden Godkänd

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 Godkänd

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 Underkänd

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.

Motivering till bedömning av punkten

På en techformance sida presenterar man inte tabellen med ett caption-element eller med en rubrik. Se problembeskrivning.

Individuella problem rapporterade på den här punkten

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

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

Det finns felmeddelanden som inte beskriver vad som gick fel.

Individuella problem rapporterade på den här punkten

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

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

Det finns felmeddelanden som är korrekt kopplade till sina inmatningsfält. Men det förekommer också felmeddelanden som inte är kopplade till sitt inmatningsfält. Se problembeskrivningen.

Individuella problem rapporterade på den här punkten

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

Förklaring

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

Motivering till bedömning av punkten

Man använder inte fieldset-elementet för att gruppera vissa formulärobjekt.

Individuella problem rapporterade på den här punkten

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

Det finns ledtexter som inte är kopplade till sina respektive inmatningsfält. Se problembeskrivning.

Individuella problem rapporterade på den här punkten

U319: Element i html-koden är placerade i en logisk ordning Underkä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.

Motivering till bedömning av punkten

I editorn finns en knapp, Fixlist, som ligger högt upp på sidan visuellt, men ligger längst ned i HTML-strukturen. Eftersom man har lagt den högt upp visuellt tolkar jag det som att den funktionen är viktig och den borde därför ligga högre upp i HTML-strukturen.

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.

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

Förklaring

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

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

Motivering till bedömning av punkten

Fixlist i editorn visar och döljer innehåll men saknar aria-expanded attributet.

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

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.

Motivering till bedömning av punkten

I användarens gränssnitt under en föreställning uppdateras innehållet när man utför en action utan att sidan laddas om. I det här fallet innebär det att användare med skärmläsare inte får information om det uppdaterade innehållet.

U325: Alla relationer som skapas genom hur innehållet är presenterat finns också angivet i koden Underkä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.

Motivering till bedömning av punkten

I editorn finns en knapp "Fixlist". Den är relaterad till editorn och visuellt har den hög prioritet eftersom att den ligger högt upp på sidan. Men i koden ligger den längst ned under resterande knappar till editorn. Det finns heller ingen koppling mellan knappen och editorn.

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

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 hjälptexter som inte är kopplade till sina respektive inmatningsfält. Se problembeskrivning.

Individuella problem rapporterade på den här punkten

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".

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

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

Felmeddelanden använder bara färg för att skiljas från annat innehåll. Se problembeskrivning.

Individuella problem rapporterade på den här punkten

U404: Länkar skiljer sig från vanlig text med mer än bara färg Underkä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.

Motivering till bedömning av punkten

Länk I tabell för kommande föreställningar.

Individuella problem rapporterade på den här punkten

U406: Formulärobjekt är byggda så att det i koden framgår vad det är för information som efterfrågas Underkä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

Motivering till bedömning av punkten

Autocomplete används inte där det kan användas. Exempelvis i användarinställningar och byte av lösenord.

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 Godkänd

Förklaring

Kontrasten ska vara minst 3.0:1

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

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/

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 Godkänd

Förklaring

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

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 Underkä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.

Motivering till bedömning av punkten

Fokusindikering som används på vissa knappar/länkar, går inte att stoppa eller dölja. Ripple-effekten lyssnar heller inte på prefers-reduced-motion

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 finns en lista med alla produktioner på startsidan.

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 Godkänd med undantag

Förklaring

Använd lang-attributet.

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

Motivering till bedömning av punkten

Man har missat ändra knapptexten på spara-knappen när man ändrar sina uppgifter som inloggad. Felmeddelande när besökare inte valt karaktär: Knappen för att ta bort felmeddelandet har en aria-label på engelska.

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

Ingen sida har en beskrivande titel.

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 Godkänd

Förklaring

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

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.

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

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

Ikoner som inte har kompletterande text har inget utrymme för synlig text. I editorn skulle man kunna lägga till en synlig text tillsammans med "+"-ikonen för att lägga till något nytt.

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..

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

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

Editor: När man sparar uppgifter för en nod får man ingen återkoppling om att uppgifterna sparats.

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 Underkänd

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

Många felmeddelanden framhävs endast med en röd färg.

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) Godkänd

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 Inte aktuell

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

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

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

Vissa delar utav editorn lyssnar på webbläsarens inställningar. Det är möjligt att hantera editorn när man zoomar in till 200% i webbläsaren. Dock finns det vissa delar som inte blir hanterbara. Se problembeskrivning. Det kan finnas argument för att vissa delar utav tjänsten inte ska gå att zooma in. Men man kan argumentera för att just editorn borde gå att zooma in, eftersom denna del utav tjänsten inte är beroende av tidsgränser, så borde vem som helst kunna skapa en techformance.

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 Godkänd

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) Inte aktuell

U510: Gränssnittet/appen lyssnar på användarinställningar och stödjer tillgänglighetsfunktioner i operativsystemet Inte aktuell

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.

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.

Individuella problem rapporterade på den här punkten

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 redigera befintliga noder med tangentbordet eftersom man inte kommer åt dom. Inloggad eller inte så kommer man inte åt alternativen i konto-menyn i huvudnavigeringen.

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 Godkänd

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.

Motivering till bedömning av punkten

Det som visas vid mouse over visas också när man navigerar med tangentbordet. Inte provat med touchskärm. Utanför granskningens scope.

U603: Modala fönster kan stängas med tangentbordet Underkä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.

Motivering till bedömning av punkten

Åtgärdsmenyer som inloggad går inte att stänga med tangentbordet.

U604: Användarna kan tabba genom hela gränssnittet utan att fastna i en specifik yta, exempelvis en videospelare Underkä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.

Motivering till bedömning av punkten

Det finns två komponenter där användare fastnar. Åtgärdsmenyn och i editorn när man ska ladda upp en fil.

Individuella problem rapporterade på den här punkten

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

Både ja och nej. Se problembeskrivningen.

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 Underkä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

Skip-link saknas.

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

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.

Motivering till bedömning av punkten

Den är hanterbar och logisk, för det mesta. Det enda som inte är logiskt är Fixlist knappen som finns i editorn. Den ligger längst ned i HTML-strukturen men högt upp visuellt.

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 Godkänd

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

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.

Motivering till bedömning av punkten

I editorn kan man dra runt noder. Det finns inget alternativt säga att placera noderna om man navigerar med tangentbord.

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 med undantag

Förklaring

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

Motivering till bedömning av punkten

Tidsgränser används i gränssnittet för en besökare. I detta fall är det ett godkänt undantag eftersom syftet med tjänsten är att öka besökarens inflytande av en föreställning live. Då behöver man tidsgränser.

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 Godkä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.

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

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 Godkä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.

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.

U632: Sidans centrala innehåll är placerat i ett main-element Godkä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.

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

Förklaring

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

Motivering till bedömning av punkten

Bara testat på dator.

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