Hover på skjemakomponenter

[Febakke]

Introduksjon

Inputkomponenter (Skjemakomponenter)

• checkbox
• radio
• textarea
• textfield
• select
• switch

I sammenheng med ny input komponent har vi behov for å løse alle skjemakomponenter likt. Dette har ført til en diskusjon rundt hover. I native inputs er det ikke noe hover state. Det å legge det til vil altså gå utenfor standard oppførsel. Men det er mange som mener at hover er et godt hjelpemiddel for noen med nedsatt syn og/eller motoriske utfordringer. Jeg føler meg ikke komfortabel med å fjerne hover helt uten å ta en diskusjon på hvilken fordeler og ulemper det måtte være for retningen vi tar her.

Hover-tilstand er kun relevant på flater der det finnes en musepeker. Et argument i mot er at man må utforme komponentene (og kontekst) slik at det er tydelig for bruker hva som kan klikkes på. På mobil vil du ikke få hjelp av en eventuelt hover state.

Argumentet for hover er ofte at de som har nedsatt syn eller motoriske utfordringer får ekstra hjelp av hover tilstander i interaktive komponenter. Vi finner ingen artikler eller andre kilder som støtter dette. Gjerne del med oss om du sitter på noe innsikt rundt dette.

Hvordan løser andre systemer det?

Har hover

• Nav Aksel (farge)
• Punkt (farge)
• Jøkul (tykkere border)
• Sparebank 1 (farge)
• DNB (farge og tykkere border på tekstfelt)
• Material UI (veldig svak endring på check og radio)
• Linkedin
• Dell
• Helsinki (farge)
• Spectrum (Adobe) (farge)

Har ikke hover

• Gov uk
• Det Fælles designsystem
• USWDS
• Designsystem.arbetsformedling (se)
• Primer (Github)
• Det finske designsystemet
• Det Italienske designsystem
• Microsoft (Har litt fargeendring på label til radio/check)
• a11y Style guide
• Carbon (IBM)

WCAG 2.2

Det er i dag ingen WCAG krav som går på at en interaktiv komponent må ha hover. (Det er til nå heller ikke lagt til i utkastet av WCAG 3)

Annet

• Reach out gov.uk
• Reach out to other design systems to hear reasoning behind their decision

Svar fra Gov.uk

Gov.uk har ikke hover state på deres skjemakomponenter. De har ikke funnet noe research som tilsier at de med nedsatt syn er avhengig eller får hjelp av hover-states. De viser til en artikkelen fra W3C som beskriver behovene til brukergruppen med nedsatt syn og poengterer at dette ikke er nevnt her. Low-vission needs

De er ikke kjent med utfordringer rundt svimmelhet for noen brukere med overdreven bruk av hover.

De har nylig fått meldt inn et issue fra deres tilgjengelighetsetat som ønsker bedre hover states. 4014

Relevante linker

• Relevant issue hos Gov.uk
• TPGI artikkel
• Forslag om å inkludere hover i WCAG 3
• Reddit: Hover styles on text inputs: yay or nay?

[Camulos]

Det kanskje viktigste er at det gjøres likt på tvers av komponenter, eller at en har et rasjonale rundt det dersom en komponent skal oppføre seg annerledes enn andre.

Hypotese: Noen brukere (som bruker mus for navigering) vil ha nytte av at det er mer visuell tilbakemelding om at musepeker er på området som kan motta aktivering med klikk. Hypotesen er altså at endring av musepekeren til pekefinger, hånd eller input-caret (e.l.) ikke er nok fordi det er ganske få piksler som endrer seg. En kan i samme hypotese foreslå at brukere med nedsatt motorisk funksjon eller med nedsatt syn kan ha spesielt nytte av dette.

Det er kun der musepekeren er, at noe vil endre seg, det er derfor ikke mye endring i siden, selv om det kan være mange elementer i bildet som kunne endret seg.

Samtidig som hypotesen ovenfor foreslår at det kan være nyttig for noen brukere, kan det også tenkes at det for andre brukere vil være forstyrrende.

Kan det være at det grupper av brukere i kategorier av delvis teknologisk eller digitalt utenforskap som kanskje kan ha nytte av litt ekstra visuell hjelp?

[madsmonsen]

Kommentar: Opplever selv at musepekeren forsvinner på skjermen, og er så vant til å overse musepekeren når jeg skriver. Så at den kun endrer utforming, er ikke lett å få med seg. Musepekeren lider samme skjebne som bannere med banner blindness. Setter alltids pris på nettsteder som benytter seg av hover funksjonen, spesielt i knapper.

[Camulos]

Mitt forslag er å ha med hover-state som er en fysisk endring utover kun musepeker, men som er mer subtil enn focus-state endringen.

I praksis kan det bety (men kan og være andre måter å gjøre det på):

• Lenker får tykkere understrek ved hover
• Komponenter med ramme får tykkere ramme på bunnen ved hover
• Komponenter uten naturlig ramme å gjøre endring på får understrek på label

En mulig utfordring med en slik løsning er blitt påpekt at kan ha med hva folk forbinder med understrek på tekst, altså lenker. Men kan det hende at når det kun er ved hover det skjer, at det vil fungere likevel?

[mrosvik]

Her er noen potensielle nei-argumenter.

• Input-elementer er ikke klikkbare i samme forstand som en lenke eller button som trenger hover for å vise at klikker du her, så skjer det noe - da kreves hover for å veilede brukeren. Men på input så utløser ikke brukeren en handling - de gjør klar for å fylle inn data, men blir stående på siden. Brukeren er mindre avhengig av at elementet får hover, siden klikk ikke fører til endringer.

• Det finnes ikke noe tydelig etablert konvensjon for at input har hover - verken i operativsystem eller noen av de store internasjonale designsystemene. De som har implementert hover, har gjort det så subtilt at det er mer en estetisk effekt mer enn et UU-tiltak.

• Input-elementer oppstår ofte i grupper, og dekker større deler av siden enn f.eks. knapper. Det er vanlig at brukere "scanner / utforsker" siden med musepekeren for å bli kjent med innholdet, og om store deler av siden da har hover kan det bli mye blinking.

• På input vil focus alltid vises når brukeren klikker på elementet. Dersom det i tillegg er en hover-tilstand på input, kan dette gjøre det vanskelig for noen brukere å forstå om endringen er hover eller focus? Tenker da spesielt på brukere som zoomer mye inn, har nedsatt syn eller er fargeblinde. Noen som har testet på slike grupper?

• For berøringsskjermer må vi uansett designe komponenter som ikke er avhengige av hover. Focus er en tilstand input-elementer vil ha uansett enhet, operativsystem eller assisterende teknologi, så det er viktig at denne er tydelig, og ikke blir forstyrret av en eventuell hover.

[madsmonsen]

"Det er vanlig at brukere "scanner / utforsker" siden med musepekeren for å bli kjent med innholdet, og om store deler av siden da har hover kan det bli mye blinking." Har du noe referanser til innsikt om dette?

Det jeg fant av referanser sa det motsatte.
Bruk av muse peker til å skanne tekst er svært sjeldent brukt: https://pub.kirsh.co.il/Kirsh2020_Pointer_Assisted_Reading.pdf
Det meste av research viser til studier hvor brukere visuelt skanner sidene https://www.sciencedirect.com/science/article/abs/pii/S0003687018300188
https://www.codecademy.com/article/how-users-scan

[mrosvik]

Takk for nyttige referanser!

[Camulos]

W3 wai aria eksempler foreslår hover for å gjøre det tydelig hvor en kan klikke for å aktivere en komponent, men de gjør det ikke konsekvent over alle typer komponenter:

Switch, Checkbox og Radio foreslås hover med begrunnelsen nedenfor, eksempler med button og listen i en dropdown er også vist med hover. Også andre komponenter har forskjellige varianter av hover, feks slider-komponenten. Men det er også komponenter hvor det ikke forslås hover i eksemplene.

Fra Checkbox (likt på liknende type komponenter):
"To make it easier to perceive that clicking either the label or checkbox will activate the checkbox, when a pointer hovers over either the checkbox or label, the background color changes, a border appears, and the cursor changes to a pointer."
https://www.w3.org/WAI/ARIA/apg/patterns/

Kan være at det er uheldig at det ikke er konsekvent brukt hos dem, men argumentet er muligens viktigere for noen komponenter enn andre.

[mrosvik]

Relevant: https://youtu.be/8KI04qkW4d4?feature=shared&t=2007

"Have the element convey its state"

[Camulos]

Vi har konkludert med at vi i Brønnøysundregistrene ønsker vi å tilby en tydelig hover på alle typer klikkbare elementer. Altså mer enn bare en fargeendring og inkludert skjemakomponenter. Vi anser det som at det er sterkere argumenter for å gå den veien enn det er for noe annet med den kunnskapen som finnes i dag.

Vi kommer til å se på hva andre gjør de neste par ukene og deretter validere de ulike metodene vi har funnet eller kommet på.
Vi lager noen krav til hover-stil, foreløpig vet vi at vi ønsker at det skal være vesentlig annerledes enn focus og vi vil unngå stiler som fører til at ting flytter på seg eller liknende.

Vi kommer også til å muligens måtte se på andre states senere, feks active.