Search

Search är en komponent som används specifikt för sök, med specifik placeholdertext och ikon med förstoringsglas.

Open

1177

Open

Inera

Innehållsförteckning

Komponentkällor

1177

Inera

Designspecifikation

Observera att sökfältet ser olika ut i mobil. Inputfältet och knappen är fortfarande separerade, men för att få plats med mer innehåll finns ingen ikon med förstoringsglas.

Tillgänglighet

Allmänt:

• För många användare så ses sökfunktionen som det enklaste sättet att hitta något på en webbplats.

• Det är vanligt att användare förväntar sig att hitta sökfunktionen högt upp på sidan. Den vanligaste placeringen är högt upp till höger på sidan. Därför är det viktigt att sökfältet tydligt framgår om den inte är placerad på uppe i högra hörnet där många användare förväntar sig att hitta sökfältet. Om sökfältet inte syns tydligt så finns risken att användaren tror att webbplatsen saknar sökfunktion. Användaren ska kunna skriva ett eller flera sökord och aktiverasökningen med en knapp som heter "Sök".

• I mobilgränssnitt kan det ibland vara aktuellt att gömma sökfunktionen bakom en knapp. Undvik detta på stor skärm, eftersom det gör sökfunktionen svårare att hitta.

WCAG-kriteriet 2.4.7

• Fokusram ska vara tydlig med tillräcklig kontrast 3,0:1.

WCAG-kriteriet 1.4.11

• Kontrast på icke-textobjekt ska uppnå minst 3.0 i kontrastvärde.

WCAG-kriteriet 1.4.3

• Kontrast på text mot bakgrund ska ha minst 4.5 i kontrastvärde för liten text och minst 3.0 för stor text.

WCAG-kriteriet 2.5.3

• Knappen ska ha ett namn som stämmer överens med uppmärkningen i koden.

WCAG-kriteriet 3.2.3

• Knapparna ska ha en konsekvent placering på hela webbplatsen/formulären så användaren lätt hittar dom.

• Man ska exempelvis inte heller byta ordningen på ‘skicka’ och ‘avbryt’ knappar.

WCAG-kriteriet 2.5.2

• Det ska gå att ångra eller avbryta processen av att klicka på en interaktiv komponent.  Funktionalitet bör inte aktiveras i och med att användaren klickar ner eller vidrör skärmen, i stället bör händelsen aktiveras när användaren släpper upp musknappen eller tar bort fingret från skärmen.

• Om någon funktionalitet måste ske redan när användaren klickar ner, så ska det finnas möjlighet att ångra händelsen om inte hela vitsen med funktionaliteten går förlorad.

• För användare som inte kan se knapparna är det viktigt att man inte döljer information. Med användning av aria-disabled kan man indikera att knappar är inaktiverade så att användare med skärmläsare får till sig den informationen.

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)

• Sammanfatta felen och använd en layout som tydligt separerar felmeddelanden från resten av webbplatsens design.

• Skriv välformulerade felmeddelanden så ökar chansen att användarna gör rätt från början.

• Markera fel och felmeddelanden med WAI-ARIA så att de uppfattas tydligt av användare med hjälpmedel.

• Spara det som inte är fel.

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)

• Genom att i kod (med hjälp av for-attributet på label-elementet) koppla etiketten till fältet kan användare markera fältet även genom att klicka på etiketten, vilket ökar den klickbara ytan. Genom kopplingen blir det även möjligt för en person som saknar en visuell presentation att veta vilken etikett som hör till vilket fält, eftersom skärmläsare läser upp etiketten när fältet får fokus. Koppla etiketten till rätt inmatningsfält genom att i for-attributet för label-elementet ange id för fältet den ska kopplas till.

• Skriv tydliga och informativa fältetiketter

• Koppla ihop fältetikett och inmatningsfält så att även etiketten blir klickbar.

• Placera fältetiketterna där användarna lätt ser dem.

• Skriv utförliga instruktioner före formuläret, när sådana behövs.

• Undvik att göra lösningen beroende av title-attribut och placeholder-texter.

3.3.3 Förslag vid felhantering

Om ett inmatningsfel upptäcks automatiskt och det finns kända korrigeringsförslag så ges förslagen till användaren, utom om det skulle äventyra säkerheten eller syftet med innehållet. (Nivå AA)

• Hjälp användaren att undvika misstag, men försök också att hjälpa användaren att rätta till misstag när ett inmatningsfel upptäcks. Det kan du göra genom att ge exempel på inmatning som har det förväntade formatet i felmeddelandet, eller genom att föreslå en annan stavning som liknar det som användaren angivit.

4.1.2 Namn, roll, värde (A)

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)

4.1.3 Status Messages (AA)

• Se till att de som använder tekniska hjälpmedel som exempelvis skärmläsare och förstoringsprogram kan göras uppmärksamma på viktiga meddelanden även om de presenteras utanför det område på sidan som användaren har i fokus.

• Ange med hjälp av attributen role eller aria-live var viktiga meddelanden kan förekomma, så får hjälpmedel kännedom om dessa och kan presentera dem för användaren vid ett lämpligt tillfälle.

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.