Test en leveringsadressedialog med tastaturet
Et gennemarbejdet eksempel viser fokusrækkefølge, annullering og lagring i en adressedialog, så tastaturfejl kan genskabes.
En dialog til leveringsadressen skal kunne betjenes fuldt ud med tastaturet. Test hele forløbet fra åbning til tilbagevenden til siden. At kunne nå Gem-knappen er ikke nok.
Eksemplet er opdigtet: Adresse D-17 i kundeportalen er “Hafenweg 8”. Personen vil ændre husnummeret til 10. Dialogen indeholder gade og husnummer samt “Annuller” og “Gem adresse”. Det er en manuel funktionstest, ikke en fuldstændig tilgængelighedsvurdering.
Beskriv fejlen som et forløb
I den antagne starttilstand åbner dialogen, men fokus bliver på “Skift leveringsadresse” bag den nedtonede flade. Tab fører derefter til links i sidefoden. De synlige adressefelter springes over. En musetest kunne let have overset fejlen.
Notér startside, udløsende knap, anvendte taster og det element, der faktisk får fokus. Udviklingen kan så genskabe samme problem. Brug et sikkert miljø med testdata; ændr ikke en rigtig kundeadresse som forsøg.
Fastlæg den forventede adfærd
I denne korte dialog er Gade en fornuftig første fokusposition. Lange dialoger eller dialoger med væsentlige konsekvenser kan kræve en anden. WAI’s dialogmønster beskriver forskellene.
Handling | Forventet resultat i eksemplet |
|---|---|
Nå knappen med Tab, og tryk Enter | Dialogen åbner; fokus er synligt i Gade. |
Gå frem med Tab | Gade, husnummer, Annuller, Gem adresse; derefter Gade igen. |
Gå tilbage med Shift+Tab | Samme elementer i modsat rækkefølge; intet spring bag dialogen. |
Indtast husnummer 10, og brug Escape før lagring | Dialogen lukker; fokus vender tilbage til knappen; D-17 forbliver Hafenweg 8. |
Åbn igen, og gem 10 | Succes vises først efter bekræftet lagring; D-17 viser Hafenweg 10. |
Lagring afvises af forretningsregler | Forståelig fejl; indtastninger bevares; det berørte område kan nås. |
Tab-rækkefølgen gælder denne konkrete opbygning. Din grænseflade kan indeholde flere elementer.
Ret årsagen det rigtige sted
Brug rigtige knapper til handlinger og korrekt navngivne felter. En specialbygget dialog kræver et tilgængeligt navn og korrekt fokushåndtering. role="dialog" eller aria-modal="true" alene blokerer ikke baggrunden og giver ikke tastaturbetjening.
Udviklingen skal behandle åbning, fastholdelse af fokus i den aktive modale dialog og lukning samlet. Her findes den udløsende knap stadig efter lukning. Fjerner et andet forløb den, kræves en anden logisk returposition. Styling må ikke fjerne den synlige fokusindikator.
Test lukning under lagring
Escape trækker ikke automatisk en allerede afsendt serveranmodning tilbage. I eksemplet må vinduet også lukkes under behandlingen. Siden viser fortsat “Adresseændring behandles” for D-17. Et bekræftet svar opdaterer adressen; et usikkert resultat forbliver uafklaret. “Ændring kasseret” ville være forkert i den situation.
Gentag den rettede test i understøttede browsere og med en passende skærmlæseropsætning. Notér observationer og åbne fejl. Det rettede tastaturforløb siger intet om alle andre sider, kontraster eller indhold.
Kilder
Læs videre
Alle artikler
Design & UX med ASES
Brugeroplevelse, brugerflader og brandets udtryk