Datepicker

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

Open

1177

 

Open

Inera

 

Innehållsförteckning

Komponentkällor

Observera att ramverket inte har en egen datepicker, utan endast erbjuder styling för en datepicker.

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

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

Om ni vill använda ett felmeddelande ihop med en datepicker är det något ni måste bygga själva. Felmeddelandet ska 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:  Accessible datepickers | Axess Lab

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.