Alert

Alert kan användas på en sida för tillfällig information eller för att meddela status i en tjänst eller funktion.

Fyra olikfärgade alertrutor, för information, attention, success och error.
1177

 

Fyra olikfärgade alertrutor, för information, attention, success och error.
Inera

 

Innehållsförteckning


Komponentkällor


1177

 

 

Inera

 

 

Designspecifikation


Ge kontextuell återkoppling till användaren med flexibla meddelanden.
 Meddelanden kan användas på en sida för tillfällig information eller för att meddela status i en tjänst eller funktion till exempel systemvarningar. De är avsedda att märkas och uppmana användare att vidta åtgärder eller få information.

 När texten är för lång för det tillgängliga horisontella utrymmet, radbryter den till en ny rad.

Olika färger och användingsområden

Vi använder fyra olika färger för alerts, med olika betydelser för respektive färg.

Blå/grå (Information)

Inkludera en länk till mer information om den är tillgänglig. Håll meddelandet kort och inkludera endast relevant information.

  • Låt användaren veta vad som händer eller kommer hända.

  • Kom till saken direkt, håll det relevant.

 

Gul (Uppmärksamma, attention)

Ha empati för användaren. Informera, men skapa inte oro. Om varningen kommer före en handling, kommunicera tydligt vad som kommer att hända om de fortsätter.

  • Sätt dig i användarens perspektiv när dessa tas fram.

  • Se till att du inte pratar om något som redan har inträffat (det borde då vara ett felmeddelande istället).

  • Håll meddelandet kort och inkludera endast relevant information.

 

Grön (Bekräfta, success)

För dessa meddelanden är det bäst att bekräfta resultatet och sedan hålla sig ur användarens väg. Om de precis har skapat något, ge dem visuell feedback på det.

  • Meddelanden som visas oftare bör ta mindre fokus och vara mer kortfattade.

  • Meddelanden som visas efter en större eller mer sällsynt handling kan vara mer omfattande.

 

Röd (Fel, error)

Förklara problemet och ge användaren ett nästa steg eller ett alternativ. Håll meddelandet enkelt och direkt och undvik att förvirra användaren med tekniska detaljer. Om det är vårt fel, erkänn det.

  • Undvik skuld och acceptera om något är vårt fel - "vi har problem med att ansluta" snarare än "du har anslutningsproblem".

  • Låt användaren veta vad som orsakar felet, snarare än att skriva ett generellt felmeddelande som fungerar för ett antal saker.

  • Var tydlig och samtalande genom att tänka på hur du kan förklara ett tekniskt fel för dina icke-tekniska vänner.

Typer av alerts

Det finns fyra olika typer av alerts som går att använda i olika situationer. Alla varianter har en ikon. Alla varianter utom collapsible går att använda som stängbara (kryss i övre högra hörnet).

  • Default: ikon, rubrik och brödtext.

  • Collapsible: ikon och rubrik är alltid synliga, men brödtexten går att fälla in och ut.

  • Compact: utan rubrik.

  • Ribbon: utan rubrik, mindre padding, passar för t ex statusmeddelanden.

 

Ribbon

Ribbon är en alert som passar bra att använda till kortare statusmeddelanden av typen “Ändringar sparade” eller liknande kortfattad feedback på användarens handlingar.

 

 

Riktlinjer för användning av alerts

Alertrutor är till för tillfälliga, tidskritiska meddelanden och bör inte användas för att förmedla information som behöver finnas på en sida under längre tid. Inte heller för att gruppera information riktad mot användare där en färgad bakgrund behövs för att hålla ihop informationen. Där bör istället en fokusruta (utan ikon) användas.

Default alert

Do ✅

Informations-alerts bör användas för tillfällig information, exempelvis att en filtrering inte gav träffar.

 

Don’t ❌

Informations-alerts bör inte användas för att gruppera information, exempelvis vid tidbokning.


 

Attention alert

Do ✅

Attention-alerts bör användas för att informera om tillfälliga, tidskritiska problem. Exempelvis om det finns något fel.

 

Don’t ❌

Attention-alerts bör inte användas för långvarig information, exempelvis en mottagnings erbjudanden.

 

Ribbon alert

Do ✅

Kort feedback.

 

Don’t ❌

Långa informationstexter.

 

Focus card istället för alert

Do ✅

För att gruppera information, exempelvis vid tidbokning.

 

Don’t ❌

Focus cards bör inte användas för långvarig information, exempelvis en mottagnings erbjudanden.

 

Tillgänglighet


WCAG-kriteriet 4.1.3

Statusmeddelanden: 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. Det finns olika typer av roles och aria-live som kan användas för att förmedla en varning till användare med skärmläsare, kolla på följande länk om olika exempel och välj det som är mest passande för situationen: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions

 

WCAG-kriteriet 1.1.1

Beskriv med text det som inte är text: Om bilder eller andra informationsbärande grafiska objekt visas på sidan så ska det finnas en alt-text så även skärmläsare kan förstå vad det är. Om bilden/grafiska objektet enbart är dekorativt och inte förmedlar någon form av information eller är kompletterande till innehållet så behövs inte en alt-text den kan då lämnas tom med: alt=””. (Nivå A)

WCAG-kriteriet 1.4.1

Använd inte enbart färg för att förmedla information: Använd gärna färger, men låt inte färgskillnader vara det enda sättet att urskilja information utan komplettera med exempelvis text, mönster eller någon annan visuell indikation. (Nivå A)

 

WCAG-kriteriet 1.4.11

Kontrast på icke-textobjekt: Grafik, så som ikoner, komponenter och andra informationsbärande grafiska element ska ha kontrast värde på minst 3.0:1. (Nivå AA)

 

WCAG-kriteriet 1.4.3

Kontrast på text: Se till att liten text har ett kontrastvärde av minst 4.5:1 mot bakgrunden, och stor text minst 3.0:1. (Nivå AA)

 

2.4.3 Fokusordning

Om det finns något fokusbart element inuti komponenten: Om man kan navigera stegvis på en webbsida och navigeringsordningen påverkar betydelse eller användning, så ska fokusbara komponenter få fokus i en ordning som bevarar betydelse och användning. (Nivå A) Se till att fokus/tab-ordningen är logisk.

 

2.1.1 Tangentbordsnavigering

Se till att det går att hantera all funktionalitet med enbart tangentbord. . Många gånger kan man navigera med tangentbord till en drop-down meny men sedan så kan inte undermenyalternativen nås, så se till att allt är nåbart och är tillgängliga via tangentbord samt att de inte kan fastna.

  • Kriterium 2.1.2: Se till att markören inte fastnar vid tangentbordsnavigation. Om det går att navigera in i komponenten så ska användaren även kunna navigera ut ur den eller stänga den med enbart tangentbord.

  • Kriterium 2.4.7: Markera tydligt vilket fält eller element som är i fokus. Om det finns något interaktivt element i komponenten (som exempelvis en stängknapp) så ska den visa tydlig fokusram när användaren hovrar eller navigerar med tangentbord till det interaktiva elementet.

  • Kriterium 2.5.8: Om det används klickbara element i komponenten som exempelvis en kryssruta för att stänga meddelandet så bör den uppnå minimum kravet för klickbara element 24 x 24 px. Mer information finns via länken ovan.

 

2.4.6 Rubriker och ledtexter/etiketter

Rubriker och ledtexter/etiketter beskriver ämne eller syfte. (Nivå AA) Beskrivande rubriker, ledtexter och etiketter(labels/headings) hjälper användarna att förstå en sidas innehåll och syfte.

 

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.

Publicerad

Mar 31, 2022

Senast uppdaterad

Sep 30, 2024