Sidjämförelse

Datepicker låter användaren välja datum, antingen genom att välja i en kalender eller genom fritext.

Innehållsförteckning

Komponentkällor

Observera att ramverket inte har en egen datepicker, utan endast erbjuder styling för en datepicker från tredjepart. Läs mer i dokumentationen här.

Om komponenten Datepicker

Det finns många sätt att ange datum i en webblösning. Det enklaste ur ett tekniskt perspektiv är att ha ett fält där användaren fyller i datumet enligt ett förutbestämt format, men det är inte så populärt hos användare som är vana med mer förlåtande inmatningssätt.

För att stödja användaren och deras behov vill många tjänster lösa inmatning av datum med en Datepicker. Vi har därför en relativt flexibel datepicker som rekommendation i vårt UX-ramverk, som rekommendation i vårt ramverk, men det är en ganska speciell komponent.

1. UX-ramverkets Datepicker är en tredjepartskomponent som vi adderar styling (utseende) till.

2. Den har begränsningar som alla komponenter har och som skulle kunna justeras genom att man bygger om den, men då det är en tredjepartskomponent finns risken att behöva göra om det arbetet om den uppdateras.

3. Den rekommenderade Datepickern fungerar för de vanligaste fallen så att den är så användbar som möjligt. Det finns inte en komponent som fungerar för alla behov.

4. Digital tillgänglighet är ett ganska svårt område för en Datepicker, och det är i synnerhet den komponent som vi har lagt mest tid på att testa och säkerställa god funktionalitet för vid användning av tekniska hjälpmedel. Trots detta arbete är det ändå en av de komponenter som DIGG har haft mest synpunkter på. UX-ramverkets rekommenderade Datepicker är dock testad med verkliga användare med tekniska hjälpmedel, och vi har fått omdömet "Väldigt bra och tydlig," även om DIGG fortsatt har vissa synpunkter.

Utökad funktionalitet?

När ni har behov av utökad funktionalitet i en Datepicker får ni gärna kontakta oss, men vi har valt att hålla oss till en befintlig Datepicker efter att ha gått igenom väldigt många på marknaden. Denna Datepicker tillhandahåller vi information om och stöd för hur den anpassas till vårt designsystem.

Om denna Datepicker inte fungerar för era behov rekommenderar vi följande:

• Se över om det som saknas enligt er är absolut nödvändigt. Alternativet till vår rekommenderade Datepicker, att ta fram egen, har visat sig vara en ganska kostsam väg för andra projekt.

• Se över om ni inte kan lösa interaktionen på alternativt sätt med andra komponenter eller ett alternativt flöde.

• Bygg om en annan tredjepartskomponent, men se då till att den följer alla regler som finns för grafiska gränssnitt och god digital tillgänglighet (detta behöver testas noggrant).

Tidigare rekommenderade vi en tredjepartskomponent (Duet) men har valt att ta bort rekommendationen efter nedslag i tillgänglighetsgranskning av DIGG.  

Vilken datepicker ska jag använda?

Vi rekommenderar att använda webbläsarens inbyggda funktionalitet för datepicker (dvs. nativefunktionalitet). Det är dock fritt att fortsätta använda Duet, eller annan datepicker från tredje part som ni tycker fungerar för er.  

Oavsett val av datepicker finns krav att förhålla sig till:  

• Er datepicker ska se ut och kännas som varumärket ni använder - 1177 eller Inera (riktlinjer för visuell design finns i Figma 

• Den ska testas för att uppfylla krav för tillgänglighet (riktlinjer för tillgänglighet finns i Confluence) 

• Om felvalidering sker ska felmeddelandet följa design för varumärket ni använder - 1177 eller Inera

Designspecifikation

States

En datepicker ska kunna visa tydlig skillnad på dagens datum, det valda datumet och datum användaren hovrar över. 

State	1177	Inera
Hover	Image Added Fyllning: accent/30 Text: accent/on-30	Image Added Fyllning: accent/30 Text: accent/on-30
Valt datum	Image Added Fyllning: accent/40 Text: accent/on-40	Image Added Fyllning: accent/40 Text: accent/on-40
Dagens datum	Image Added Kantlinje: accent/40 Text: neutral/20	Image Added Kantlinje: accent/40 Text: neutral/20

Date range

Om möjligheten finns att välja ett datumintervall (date range) ska det vara tillräcklig visuell skillnad mellan start- och slutdatum och mellanliggande datum.

• Inera: start- och slutdatum har färgen Accent30, mellanliggande datum färgen Accent40. Markeringen för start- och slutdatum ska även ha en vit kantlinje som skiljer de två färgerna åt.

• 1177: start- och slutdatum har färgen Accent30, mellanliggande datum färgen Accent40. Markeringen för start- och slutdatum ska även ha en vit kantlinje som skiljer de två färgerna åt.

Validering

Vi kommer inte kunna bygga in en validering direkt i datepicker-komponenten i IDS-biblioteket eftersom vi inte kan ändra koden och dess beteende (tredje part). Om en tjänst vill använda vårt felmeddelande ihop med datepicker-komponenten så är det något som de måste koda in Om ni vill använda ett felmeddelande ihop med en datepicker är det något ni måste bygga själva. Felmeddelandet ska i så fall se ut som felmeddelandet som används för att validera andra input-element:

Tillgänglighet

Allmänt:

Användaren ska kunna välja att skriva in input direkt i fältet istället för att använda datum-väljaren/tid-väljaren. Det specificerade formatet för inputen bör framgå i labeln för de användare som använder skärmläsare. Dölj inte datum-väljaren för skärmläsare och tangentbord. Det datum som har blivit valt bör framhävas genom en tydlig markering som omger det. Detta hjälper till att förbättra synligheten och tydligheten av det valda datumet.

Det ska enbart gå att mata in det format som förväntas, exempelvis enbart siffror i det format som anges i ledtexten (Ex: ÅÅÅÅ-MM-DD). Det ska inte gå att skriva in datum fel eller använda sig utav bokstäver och specialtecken.

Det bör vara möjligt att styra datumväljaren med hjälp av tangentbordet. Denna styrning ska utföras med piltangenterna på tangentbordet. Det ska vara möjligt att ändra månaden genom att använda upp- och nerpiltangenterna. Dessutom bör användningen av tangenterna "Home" och "End" leda till den första respektive sista dagen i veckan.

När ett datum har valts så ska skärmläsaren informera om det valda datumet för användaren. Den aktuella dagen (till exempel "Måndag", "Torsdag", "Fredag", etc.) bör uppläsas för att informera dem om vilken dag de befinner sig på. Mer info finns här:
https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/datepicker-dialog.html

Råd från Axesslabs för att möta WCAG-kriteriet 3.2.2

• Ta bort aria-pressed attributet så det inte längre är växlingsknappar semantiskt, utan bara "vanliga" knappar. 

• Lägg in information i aria-label för det valda datumet, exempelvis: "Valt datum, fredag 12 maj 2023." 

WCAG-kriteriet 1.1.11

Icke-textinnehåll: All innehåll som inte är textbaserad ska ha ett textalternativ för att kunna erbjuda möjligheten att ha innehållet uppläst för användaren.

WCAG-kriteriet 1.4.11

Kontrast på icke-textobjekt: Det ska vara tillräcklig kontrast mellan bakgrund och komponenter, ikoner, symboler och andra grafiska informationsbärande objekt. Minsta kontrast värdet det ska uppnå är: 3.1. Samt när det gäller text så ska det uppnå 4.5 för liten text och 3.1 för stor text.

WCAG-kriteriet 2.1.1

Tangentbordsnavigering: All funktionalitet ska kunna nås och hanteras med enbart tangentbordsnavigering. (Nivå A)

WCAG-kriteriet 2.4.3

Fokus ordningen: Om en komponent används i flera steg och varje steg påverkar hur komponenten fungerar, måste stegen göras i rätt ordning så att det fortfarande fungerar meningsfullt.

WCAG-kriteriet 2.4.6

Rubriker och ledtexter/etiketter: Rubriker och ledtexter/etiketter/labels beskriver ämne eller syfte. Labels beskriver vad som förväntas av användaren för att göra klart sin input. Det gäller även för ikoner/knappar i datum vyn så skärmläsaren kan läsa upp när användaren hoppar mellan exempelvis månader och dagar så ska det beskrivas för användaren så de vet vilket datum hen står på. Istället för “1, 2 , 3” så säger den Januari, Februari, Mars osv.  (Nivå AA) mer info finns även här:  https://axesslab.com/accessible-datepickers/

WCAG-kriteriet 2.4.7

Fokus: Det ska tydligt framgå vart fokus ligger vid tangentbordsnavigering,  fokus markeringen ska även ha tillräcklig kontrast. (Nivå AA)

WCAG-kriteriet 2.5.3

Text på knappar och kontroller överensstämmer med maskinläsbara etiketter 

Se till att text som är synlig på knappar och andra gränssnitt kontroller också finns i, och överensstämmer med, den maskinläsbara etikett som representerar kontrollen i exempelvis program för röststyrning. (Nivå A)

WCAG-kriteriet 3.3.1

Identifiering av fel: Om ett inmatningsfel upptäcks automatiskt så ska det som är fel markeras och felet beskrivas för användaren med text. (Nivå A)

WCAG-kriteriet 3.3.2

Ledtexter/etiketter eller instruktioner: Det finns Ledtexter/etiketter eller instruktioner när innehåll kräver inmatning från användaren. (Nivå A)

WCAG-kriteriet 4.1.2

Namn, roll, värde: För alla komponenter i ett användargränssnitt (inklusive, men inte begränsat till formulärelement, länkar och komponenter skapade med script), kan namnet och rollen automatiskt tydliggöras. Status, egenskaper och värden som kan anges av användaren kan bli automatiskt tydliggjord, och meddelande om ändringar i dessa komponenter finns åtkomliga för användarprogram, inklusive hjälpmedel. (Nivå A)

Feedback

Hjälp oss att förbättra den här komponenten genom att ge feedback, ställa frågor och lämna andra kommentarer på Inera UX Slacken i kanalen #komponenter_design eller #komponenter_kod alternativt kan du använda vårt formulär.