Kun virheilmoituksesi sulkevat käyttäjät ulos

Hetki, jolloin lomake hajoaa

Kuvittele tilanne: sokea käyttäjä täyttää kassalomakkeen, lähettää sen eikä kuule ruudunlukijaltaan mitään hyödyllistä. Ei ilmoitusta. Ei selitystä. Sivu on merkinnyt visuaalisesti viisi validointivirhettä punaisella, mutta käyttäjällä ei ole siitä aavistustakaan. Hän painaa lähetä-painiketta uudelleen. Ja uudelleen. Lopulta hän poistuu.

Tämä ei ole marginaalinen skenaario. Saavuttamaton virheenkäsittely on yksi yleisimmistä esteistä, joita löydämme todellisissa auditoinneissa, ja se turhauttaa käyttäjiä yleensä pahimmalla mahdollisella hetkellä — kun he yrittävät saattaa ostotapahtuman loppuun tai lähettää jotakin tärkeää.

Hyvä uutinen on, että korjaaminen on pitkälti kiinni siitä, että tietää, miltä “hyvä” näyttää. Epäonnistumiset ovat lähes aina samat muutamat toistuvat mallit.

Miksi virheilmoitukset ovat vaikeita apuvälineteknologian käyttäjille

Näkevät hiiren käyttäjät huomaavat validointivirheet yleensä välittömästi — punaisen reunuksen, varoituskuvakkeen, kentän alle ilmestyvän tekstin. Mutta käyttäjät, jotka luottavat ruudunlukijoihin, näppäimistönavigointiin tai puheohjaukseen, kohtaavat perustavanlaatuisesti erilaisen kokemuksen.

Kun lomake lähetetään ja virheitä ilmestyy:

Ruudunlukijan käyttäjät eivät välttämättä kuule mitään, ellei kohdistus siirry virheeseen tai live-alue ilmoita sitä
Näppäimistön käyttäjien on pystyttävä saavuttamaan jokainen virheilmoitus näppäimistöllä ja ymmärtämään, mihin kenttään se kuuluu
Puheohjauksen käyttäjien on voitava osoittaa kentät näkyvän, oikean selitteen avulla — jos selite on väärä tai puuttuu, he ovat jumissa

Mikään tästä ei tapahdu automaattisesti. Se on rakennettava itse.

WCAG-kriteerit, jotka pätevät

Neljä WCAG 2.2:n onnistumiskriteeriä käsittelee virheenkäsittelyä suoraan:

3.3.1 Virheen tunnistaminen (taso A) — Jos virhe havaitaan automaattisesti, virheellinen kohde tunnistetaan ja kuvataan käyttäjälle tekstinä. Virheitä ei saa välittää pelkän värin avulla.

3.3.2 Selitteet tai ohjeet (taso A) — Tiettyä muotoa vaativien kenttien on kerrottava vaatimus ennen syöttöä tai sen aikana, ei vasta lähetyksen epäonnistuttua.

3.3.3 Virheen korjausehdotus (taso AA) — Jos virhe havaitaan ja korjausehdotukset ovat tiedossa, tarjoa ne. “Virheellinen päivämäärä” ei riitä. “Anna päivämäärä muodossa PP/KK/VVVV” riittää.

3.3.4 Virheiden ennaltaehkäisy (taso AA) — Merkittävissä toimissa (rahansiirrot, oikeudelliset sitoumukset) käyttäjien on voitava tarkistaa, korjata ja vahvistaa tiedot ennen kuin toimi on peruuttamaton.

Lisäksi on 4.1.3 Tilasta kertovat viestit (taso AA), joka koskee dynaamisesti lisättyjä viestejä, jotka eivät saa kohdistusta — apuvälineteknologian on ilmoitettava ne käyttämällä attribuuttia role="status" tai role="alert".

Mitä saavutettava virheilmoitus todella vaatii

Virheilmoitusten saaminen kuntoon vaatii huomiota neljään erilliseen kerrokseen:

1. Ohjelmallinen kytkentä

Jokainen virheilmoitus on sidottava kenttäänsä aria-describedby-attribuutilla. Se kertoo ruudunlukijoille, että virheteksti on luettava ääneen, kun kenttä saa kohdistuksen.

<!-- Before: error text exists visually but is invisible to screen readers -->
<label for="email">Email</label>
<input type="email" id="email" class="error">
<p class="error-text">Enter a valid email address.</p>

<!-- After: programmatic association via aria-describedby -->
<label for="email">Email address</label>
<input
  type="email"
  id="email"
  aria-describedby="email-err"
  aria-invalid="true"
>
<p id="email-err" class="error-text">Enter a valid email address.</p>

Attribuutti aria-invalid="true" kertoo, että kenttä on parhaillaan virheellinen, minkä useimmat ruudunlukijat ilmoittavat, kun kohdistus osuu kenttään.

2. Kohdistuksen hallinta lähetyksen jälkeen

Kun lomake lähetetään ja virheitä on läsnä, kohdistuksen on siirryttävä johonkin hyödylliseen paikkaan. Kaksi yleisintä mallia:

Siirrä kohdistus lomakkeen yläosassa olevaan virheyhteenvetoon, joka listaa kaikki virheet linkkeinä asianomaisiin kenttiin
Siirrä kohdistus ensimmäiseen virheelliseen kenttään

Jos kohdistus jää lähetyspainikkeeseen tai ei minnekään, ruudunlukijan käyttäjien on löydettävä virheet itse navigoimalla lomakkeen läpi — jos he ylipäätään tietävät virheiden olemassaolosta.

// After validation fails, move focus to the error summary
const summary = document.getElementById('error-summary');
summary.setAttribute('tabindex', '-1');
summary.focus();

3. Live-alueiden ilmoitukset dynaamisille virheille

Kirjoittamisen aikana ilmestyville virheille (reaaliaikainen inline-validointi) käytä ARIA-live-alueita, jotta viesti ilmoitetaan ilman, että kohdistuksen tarvitsee siirtyä.

<p role="alert" aria-live="assertive" id="password-err">
  Password must be at least 8 characters.
</p>

Käytä role="alert" / aria-live="assertive" virheille, jotka vaativat välitöntä huomiota. Käytä role="status" / aria-live="polite" vähemmän kiireelliselle palautteelle, joka voi odottaa käyttäjän taukoa.

4. Itse virheilmoitus

Kielellä on merkitystä. Saavutettavat virheilmoitukset ovat:

Täsmällisiä: kerro, mikä on vialla, älä vain että jokin on vialla
Toimintaan ohjaavia: kerro käyttäjälle tarkalleen, mitä korjaamiseksi pitää tehdä
Kohteliaita: vältä syyllistävää kieltä, kuten “syötit virheellisen arvon”

Saavuttamaton	Saavutettava
”Virheellinen syöte"	"Sähköpostiosoitteessa on oltava @-merkki, esim. nimi@esimerkki.fi"
"Virhe"	"Päivämäärän on oltava muodossa PP/KK/VVVV"
"Pakollinen kenttä"	"Koko nimi on pakollinen tieto"
"Salasana virheellinen"	"Salasanassa on oltava vähintään 8 merkkiä ja yksi numero”

Mallit eri virheskenaarioihin

Kenttäkohtaiset inline-virheet

Yleisin malli. Virheilmoitus näkyy suoraan siihen liittyvän kentän alla. Toimii hyvin yksinkertaisissa lomakkeissa. Vaatii aria-describedby- ja aria-invalid-attribuutit, jotta ilmoitus luetaan oikein.

Virheyhteenvetopalkit

Pitkissä lomakkeissa, joissa on useita virheitä, sijoita yläosaan yhteenveto, joka listaa kaikki ongelmat linkkeinä asianomaiseen kenttään. Siirrä kohdistus tähän epäonnistuneen lähetyksen jälkeen. Tämä on GOV.UK:n käyttämä malli, jota suositellaan laajalti monimutkaisille lomakkeille.

Toast-ilmoitukset

Lyhytikäiset viestit, jotka ilmestyvät ruudun reunaan, ovat yleisimmin käytetyistä malleista saavuttamattomimpien joukossa. Ne katoavat ennen kuin ruudunlukijan käyttäjät ehtivät niihin, niitä ei usein ilmoiteta lainkaan, eivätkä ne tarjoa mitään korjauspolkua. Vältä toast-ilmoitusten käyttöä virheisiin. Jos käytät niitä, yhdistä ne pysyvään virhetilaan itse lomakkeessa.

Järjestelmävirheet

Kun jokin menee pieleen palvelinpuolella, kerro käyttäjälle selkokielellä, mitä tapahtui ja mitä hän voi tehdä seuraavaksi. “Jokin meni pieleen” ilman lisäohjeita jättää käyttäjät oman onnensa nojaan.

<div role="alert" aria-live="assertive">
  <p>We couldn't save your changes due to a network error.
  Please check your connection and try again.</p>
</div>

Testauksen tarkistuslista

Kun virheenkäsittely on toteutettu, tarkista nämä manuaalisesti — automaattiset työkalut eivät havaitse useimpia niistä:

Tyhjän pakollisen lomakkeen lähettäminen siirtää kohdistuksen virheyhteenvetoon tai ensimmäiseen virheelliseen kenttään
Jokainen virheilmoitus on yhdistetty kenttäänsä aria-describedby-attribuutilla
Virheellisissä kentissä on aria-invalid="true"
Virheilmoitukset luetaan ääneen, kun kohdistus osuu kyseiseen kenttään
Reaaliaikainen validointi käyttää live-alueita
Virheilmoituksissa käytetään täsmällistä, toimintaan ohjaavaa kieltä — ei pelkkää “virheellinen”
Väri ei ole ainoa tapa osoittaa virheitä (kuvake tai tekstiselite punaisen rinnalla)
Virheeseen pääsee sarkaimella näppäimistöltä
Kohdistusjärjestys lähetyksen jälkeen on looginen eikä hypi arvaamattomasti
Toast-viestit on yhdistetty pysyvään virhetilaan

Miksi automaattiset työkalut eivät havaitse suurinta osaa tästä

Automaattinen skanneri voi tarkistaa, osoittaako aria-describedby olemassa olevaan elementtiin ja onko aria-invalid paikallaan. Se ei voi tarkistaa, siirtyykö kohdistus oikein lähetyksen jälkeen, onko virheteksti paikkansapitävä tai katoaako toast-ilmoitus ennen kuin sen ehtii lukea. Manuaaliset saavutettavuusauditointimme sisältävät lomakekohtaisen testauksen todellisella apuvälineteknologialla — ainoa luotettava tapa varmistaa, että virheenkäsittely todella toimii alusta loppuun.

Jos et ole varma, missä lomakkeesi ovat tällä hetkellä, suorita ilmainen skannaus tuodaksesi ensin esiin automaattisesti havaittavat ongelmat, ja etene siitä.