Tillgänglighetsredogörelse

Tillgänglighet för minsida.pliktverket.se

 

Plikt- och prövningsverket står bakom den här webbplatsen. Vi vill att så många som möjligt ska kunna använda den. Det här dokumentet beskriver hur minsida.pliktverket.se uppfyller lagen om tillgänglighet till digital offentlig service, kända tillgänglighetsproblem och hur du kan rapportera brister till oss så att vi kan åtgärda dem.

Hur tillgänglig är webbplatsen?

Vi har ett stort antal kända brister i tillgängligheten för den här webbplatsen och är medvetna om att delar av webbplatsen inte är helt tillgängliga. Se avsnittet om innehåll som inte är tillgängligt nedan för mer information.

Vad kan du göra om du inte kan använda delar av webbplatsen?

Om du behöver innehåll från minsida.pliktverket.se som inte är tillgängligt för dig, men som är undantaget från lagens tillämpningsområde enligt beskrivning nedan, kan du meddela oss genom att skicka e-post till info@pliktverket.se eller ringa oss på telefon 0771-24 40 30.

Rapportera brister i webbplatsens tillgänglighet

Vi strävar hela tiden efter att förbättra webbplatsens tillgänglighet. Om du upptäcker problem som inte är beskrivna på den här sidan, eller om du anser att vi inte uppfyller lagens krav, meddela oss via kontaktuppgifter ovan så att vi får veta att problemet finns.

Tillsyn

Myndigheten för digital förvaltning har ansvaret för tillsyn över lagen om tillgänglighet till digital offentlig service. Om du inte är nöjd med hur vi hanterar ditt påpekande om bristande webbtillgänglighet eller din begäran om tillgängliggörande av innehåll kan du anmäla till Myndigheten för digital förvaltning.

Teknisk information om webbplatsens tillgänglighet

Den här webbplatsen är inte helt förenlig med lagen om tillgänglighet till digital offentlig service. Otillgängliga delar beskrivs nedan.

Innehåll som inte är tillgängligt

Det innehåll som beskrivs nedan är på ett eller annat sätt inte helt tillgängligt. Vi har gjort en oberoende granskning av minsida.pliktverket.se. Senaste bedömningen gjordes i september 2020.

Inloggningssida

Knappcontainer på inloggningssida saknar role.

1.3.1 (A) Knapparna för att logga in/registrera användare omges av <li>-taggar med angiven role=”tab”. För att detta ska bli semantiskt korrekt behöver omgivande <ul> ha role=”tablist”, vilket inte är fallet som det ser ut nu.

Artikelpuff

<font>-taggar används.

1.3.1 (A) I artikelpuffar används <font>-taggar för att byta färg på länkar. Detta bör istället hanteras med hjälp av CSS.


<u>-taggar används

1.3.1 (A) I artikelpuffar används <u>-taggar för att lägga en understrykning på länkar. Detta bör istället hanteras med hjälp av CSS.

Meddelandeblock

Textfärg i meddelandeblocket

1.4.3 (AA) Den ljusblå bakgrundsfärgen och den mörkblå textfärgen i meddelandeblocket uppnår tillsammans ett kontrastvärde på 3.31. Godkänt kontrastvärde enligt WCAG AA är 4.5.

WAI-ARIA-element från meddelandeblock

1.3.1 (A), 4.1.2 (A) I meddelandeblocket läggs role=”alert” på <li> som omsluter själva meddelandet. Detta blir missvisande då denna syftar till att göra det möjligt för en skärmläsare att utläsa att något är fel, vilket inte är fallet här. Dessutom behövs inte heller aria-atomic=”true” då detta inte är en s.k. ”live region”.

Cookieruta

Färger på knapp i cookieruta.

1.4.3 (AA) Den orange bakgrundsfärgen och den vita textfärgen i cookierutans knapp uppnår tillsammans ett kontrastvärde på 2.51. Godkänt kontrastvärde enligt WCAG AA är 4.5.

Ankarlänk i cookieruta

1.3.1 (A) Cookierutans knapp innehåller en ankarlänk som inte leder någonstans. En ankarlänk ska bara användas om den syftar till att slussa användaren vidare till en viss sektion.

Panelblock

Toggleknappar i panelblocket.

2.1.1 (A), 4.1.2 (A) I panelblocket finns länkar i högerkant som används för att visa mer/mindre av innehållet. Använder man tangentbordet funkar detta en gång innan man sedan hamnar vidare i tabordningen. Man stannar alltså inte kvar på länken, vilket borde vara det önskade beteendet. Länkarna saknar dessutom flera nödvändiga WAI-ARIA-attribut.

Varningsmeddelande

Textfärg i varningsmeddelande.

1.4.3 (AA) Den ljusgula bakgrundsfärgen och den mörkorange textfärgen i varningsmeddelandet som bl.a. varnar för att inloggningstiden håller på att gå ut uppnår tillsammans ett kontrastvärde på 3.37. Godkänt kontrastvärde enligt WCAG AA är 4.5.

Formulär

Beskrivning på formulärsfält.

1.3.1 (A), 3.3.2 (A) De olika fälten i formulärsfälten saknar en beskrivning, vilket är nödvändigt för att en skärmläsare ska kunna utläsa vad fältet är till för.

Textfärg i formulärets felmeddelande.

1.4.3 (AA) Den ljusröda bakgrundsfärgen och den mörkröda textfärgen i formulärets felmeddelande (som uppstår exempelvis om man tar bort e-postadress och trycker på ”Spara”) uppnår tillsammans ett kontrastvärde på 3.93. Godkänt kontrastvärde enligt WCAG AA är 4.5.

Hjälp användaren att rätta till sina misstag

3.3.3 (AA) När ett fel uppstår i ett formulärsfält bör förslag på hur detta kan rättas till presenteras för användaren.

Label i formulär saknar text

4.1.2 (A) I formuläret för ansökan till utbildning finns en länk för att skicka en verifieringskod via e-post. Till denna länk finns en <label>, som dock är tom på text.

Frågebatteri

Bakgrundsfärg på knapp-fokus

1.4.3 (AA) När man klickar på knappen för att starta ansökan till en utbildning får texten en grå färg som syns väldigt dåligt mot den mörkblå bakgrunden.

Bakgrundsfärg i progressbar

1.4.3 (AA) Den grå bakgrundsfärgen och den vita textfärgen i formulärets progressbar uppnår tillsammans ett kontrastvärde på 3.24. Godkänt kontrastvärde enligt WCAG AA är 4.5.

Länkfärg i frågebatteriformulär

1.4.3 (AA) Den blå bakgrundsfärgen och den vita textfärgen i länkar uppnår tillsammans ett kontrastvärde på 1.78. Godkänt kontrastvärde enligt WCAG AA är 4.5.

Stäng-funktion i popup fungerar inte

1.4.13 (AA) Om man trycker på ”Avbryt” i frågebatteriet visas en popup som frågar användaren om hen vill avbryta processen. I denna finns en länk i det övre högra hörnet som till synes är till för att stänga popupen. Denna funktion verkar dock vara trasig.

Ramverk

Aria-label på nav-element

1.3.1 (A) På sajten finns flera ej namngivna <nav>-element. Utan någon sorts benämning kan användaren ha svårt att veta skillnaden på dem.

Funktion för att hoppa över innehåll

2.4.1 (A) På sajten finns en funktion för att hoppa över innehåll. Den går att navigera sig till med hjälp av tangentbordet, men den syns inte.

Tabbordning

2.4.3 (A) När man använder tangentbordet för att navigera på sajten hamnar man väldigt tidigt på en loader som ligger placerad nere i footern. Denna bör man aldrig kunna navigera sig till då den inte leder användaren någonstans.

Lägg till fokus-styles

2.4.7 (AA) När man använder tangentbordet för att navigera på sajten är det viktigt att det är tydligt vilket element som är i fokus. På sajten finns det fokus-styles tillagda, men det är inte alltid de är så tydliga (se ex. footern) och dessutom finns flera varianter av fokus-styles vilket kan upplevas rörigt. Det finns också flera fall av att det inte syns att ett element är i fokus.

Allt innehåll går inte att nå med hjälp av tangentbordet

2.4.7 (AA) Enligt WCAG måste allt innehåll kunna nås via tangentbordsnavigation, vilket inte är fallet just nu. Se mobilmenyn m.m.

Överflödig role i huvudmenyn

4.1.2 (A) Huvudmenyn omges av en <nav>-tagg med role=”navigation” angivet. Eftersom <nav> och role=”navigation” gör samma sak blir därmed det senare attributet överflödigt.

Role i huvudmenyn (<li>)

4.1.2 (A) Alternativen i huvudmenyn omges av <li>-element med role=”presentation”, vilket är ett attribut som syftar till att ta bort den semantiska betydelsen av ett element. I det här fallet är detta inte detta nödvändigt då menyn är uppbyggd på ett semantiskt korrekt sätt.

Role i huvudmenyn (<a>)

4.1.2 (A) Länkarna i huvudmenyn omges av <a>-element med role=”menuitem”. I det här fallet är detta inte detta nödvändigt då menyn är uppbyggd på ett semantiskt korrekt sätt.


Överflödig role i sajtfoten

4.1.2 (A) Sajtfoten omges av en <footer>-tagg med role=”contentinfo” angivet. Eftersom <footer> och role=”contentinfo” gör samma sak blir därmed det senare attributet överflödigt.

Aria-label på logotyp i huvudmenyn

2.4.4 (A), 4.1.2 (A) Eftersom logotypen i huvudmenyn länkar till startsidan behöver detta på något sätt kunna förmedlas till en användare som använder sig av en skärmläsare.

Se till att text går att förstora utan problem

1.4.4 (AA) På sajten är vissa fontstorlekar angivna i pixlar, vilket kan innebära problem för en användare med nedsatt syn som behöver kunna förstora text för att kunna läsa den. För detta krävs att alla fontstorlekar är angivna i en skalbar enhet.

All kod validerar inte

4.1.1 (A) Vid valideringstest av HTML på sajten uppstår vissa fel och varningar. Se https://validator.w3.org/

Se över rubriker

2.4.6 (A) Som koden är strukturerad nu finns det flera <h1>-taggar på vardera sida. Best practice vore att ha endast en huvudrubrik per sida som består av sidans namn.

<b>-taggar används för att formatera text

1.3.1 (A) Här och var på sajten används <b>-taggen på flera ställen för att fetmarkera text. Denna tagg stöds inte i skärmläsare och behöver därför ändras.

Filtyp och filstorlek i panelblock

2.4.4 (A) Vissa av panelblocket består av en fillistning där datum, namn och ikon för varje fil presenteras. Däremot saknas information om filstorlek, vilket rekommenderas då det ger användaren ett hum om hur lång tid det skulle ta att öppna/ladda ned filen. Ikonen som visar vilket filformat det rör sig om är dessutom inte möjlig att uppfatta för en skärmläsare, vilket gör det lämpligt att även lägga till filformat i länktexten.