| Innehållsförteckning |
|---|
Exempel
| Iframe | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Designspecifikation
Formulärfält har generellt blå ram och ljusblå fyllnad. Hörnradie 10 px.
När ett fält är i aktivt läge får den en innerskugga.
Om formulärfält behöver vara placerade på en färgad bakgrund (tex. ljusblå) har fälten vit fyllnad men i övrigt samma ram och skuggningar etc. som de vanliga formulärfälten.
Fält som signalerar felmeddelande har röd streckad ram och ljusrosa fyllnad.
Disablade fält har grå ram, stone-clear, och vit fyllnad. Texten är kursiv och har färgen stone-base.
Do’s and Don’ts
-
Tillgänglighet
...
När felmeddelanden läggs in i formuläret så måste det knytas till formulärsobjektet eller gruppen det är menat att tillhöra. Detta är för att det inte bara ska synas visuellt utan vara kopplat så att alla användare kan uppfatta det.
När inmatningsfällt används så ska även autocomplete tas i beaktning, mer om detta du läsa här:
Viktigt att tänka på när det gäller obligatoriska fält kan du läsa om här: Obligatoriska fält
Tillgängliga datepickers (<input=date>)
Tvinga inte användare att bara använda en datepicker, ett inputfält för text kan passa vissa användare bättre. Se till att den har korrekt koppling med <label> och en beskrivning som är tydlig.
Gör det möjligt att navigera med ett tangentbord. Till exempel genom att tabba till kalendern och använda piltangenterna för att välja rätt datum.
Dölj inte kalenderknappen från skärmläsare. Vissa användare av skärmläsare använder en kombination av syn- och skärmläsare, så att gömma kalenderknappen och kalendervyn för skärmläsare kommer att skada deras användarupplevelse.
Se till att ikoner och knappar tolkas på ett bra sätt av skärmläsare genom exempelvis <label>’s. Ett exempel på detta är att datumen i månaden inte bara ska läsas som "1", "2 ″ etc. De borde läsas" 1 mars, torsdag "eller något liknande. Detta kan du lösa med en aria-label.
Tillgänglig tidskomponent (<input=time>)
Se till att användaren kan använda tidskomponenten med tangentbord. Ex. komma åt komponenten och sedan höja och sänka värdet med piltangenterna eller manuellt skriva in värdet som önskas.
Se till att komponenten har beskrivande labels som tydligt kopplar den till sammanhang.
Användare som inte kan se värdena måste kunna få informationen programmatiskt så att de också kan använda komponenten. Det vill säga att det ska i kod gå att utläsa värdena så att en skärmläsare kan tolka komponenten.
Tillgänglig slider (<input=range>)
Se till att användaren kan använda slidern med tangentbord. Ex. Komma åt slidern med tabb och sedan höja och sänka värdet med piltangenterna.
Se till att slidern har beskrivande labels som tydligt kopplar slidern till sammanhang.
Användare som inte kan se värdena måste kunna få informationen programmatiskt så att de också kan använda slidern. Det vill säga att det ska i kod gå att utläsa värdena så att en skärmläsare kan tolka slidern.
Research på komponenten
-
Relaterade resurser/komponenter
Status
...
Status
...
Ett inmatningsfält för kortare text, exempelvis namn, e-postadress eller telefonnummer.
Innehållsförteckning
| Innehållsförteckning |
|---|
Komponentkällor
1177
Inera
Tillgänglighet
Se till att felmeddelandet som är kopplat till textfältet är läsbart för skärmläsare. Presentera felen i <label> som tillhör fältet som har ett fel. På så sätt får användare med skärmläsare informationen om felet när respektive fält får fokus.
Ett exempel: <label>Vilken dag är det idag? <span>Felaktigt datumformat. Ska vara ÅÅÅÅ-MM-DD</span</label>Gäller både Inera och 1177 css biblioteket: Error meddelandet varnar inte skärmläsaren. Det är först om man använder tangentpilarna som varningen läses upp. Den bör varna användaren när hen är inuti textfältet och inte för att användaren “pilar ner sig” till pratbubblan med error. I css komponenten ”Form Example” verkar felmeddelandet fungera med direkt indikation att det är ogiltig inmatning.
Se till att kontrasten på fokusram, inputfält, felmeddelanden och text är tillräckligt hög (minst 3:1 på icke text och 4,5:1 på liten text).
Det ska gå att navigera till/i textfält/inputfält med tangentbord.
Förtydliga för användaren vilka inputs/textfält som är obligatoriska i formuläret. Använd en bild av en asterisk (*) för att markera ett obligatoriskt fält i ett formulär. Den ska placeras före inmatningsfältet, i label-elementet. Låt bilden ha textekvivalenten alt=”obligatoriskt”. Informera användarna före formuläret genom att skriva till exempel ”Fält markerade med * är obligatoriska och måste fyllas i”. Använd den uppmärkning av obligatoriska fält som fungerar med den html-version du valt.
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 ifor-attributet förlabel-elementet angeidfö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.
1.3.1 Information och relationer
Information, struktur, och relationer som förmedlas genom presentation kan bli automatiskt tydliggjord eller finnas som text. (Nivå A)
Ange i kod vad sidans olika delar har för roll
Öka chansen att informationen presenteras korrekt oavsett mottagarens verktyg, genom att använda html-elementen på rätt sätt.
Exempelvis kan information läsas upp eller förstoras eller presenteras med annan layout. Du som avsändare behöver se till att ingen viktig information går förlorad när presentationen förändras.
Se till att använda rubriker med hjälp av H1-H6, inte med hjälp av större text-storlek eller fetstilt-text.
Se till så det finns kopplingen mellan en ledtext och ett formulärfält.
Utnyttja html-språkets olika element så som de är tänkta, och komplettera med WAI-ARIA och att uttryckligen beskriva med text sådant som inte framgår av kodningen.
2.4.6 Rubriker och ledtexter/etiketter
Rubriker och ledtexter/etiketter beskriver ämne eller syfte. (Nivå AA)
Beskrivande rubriker, ledtexter och etiketter hjälper användarna att förstå en sidas innehåll och syfte. Rubriker och ledtexter behöver inte vara långa. Ofta kan ett enda ord vara tillräckligt för att beskriva innehållet. Använd nyckelord ur texten och skriv det viktigaste orden först.
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)
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
roleelleraria-livevar 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.
Status
Publicerad | 2020-01-18 |
|---|---|
Senast uppdaterad |
...
2022- |
...
02- |
...
24 |