Sain hiljattain eräässä käytettävyystestissä todistaa sitä, kuinka hikiseen tilanteeseen voi johtaa pelkästään se, että käyttäjän saamaan palautteeseen ei olla uhrattu suunnitteluvaiheessa kahta sekuntia enempää. Tai ehkä olikin: kyllähän käyttäjä jotain viestejä sai, mutta ei vain löytänyt tai ymmärtänyt niitä. Kenkuimpia ovat ehkä ne tilanteet, jossa käyttäjä ei itse asiassa ole tehnyt mitään virhettä, mutta palautteen puuttuessa luulee, että jotain pitäisi vielä täydentää tai muuttaa. Tuloksena turhautunutta klikkailua, lisää virhetilanteita ja pahimmassa tapauksessa koko järjestelmän jumittaminen.

Paitsi että niin virhe- kuin vahvistusviestin oikeaoppinen ulkoasu ja sanamuotojen ymmärrettävyys on tärkeää, yhtä lailla tärkeää on se, mitä konepellin alla hyrisee. Näistä kaikista kertoo Communicating error messages accessibly. Koodiesimerkkejäkin on. Tässä vielä yhteenveto siitä sitä, minkälainen hyvän ja saavutettavan virheilmoituksen pitäisi olla (lihavoinnit allekirjoittaneen):

1. Error messages should be accessible for as many users as possible regardless of culture, age and impairment.
2. It should be easy to understand that an error has occurred.
3. It should be clear what the user has to do to correct the error.
4. It should be clear for the user where the error was found in the form.
5. It should be possible to be notified about errors before submitting the form, especially if it is a complex form that takes time to process on the server.
6. All errors should be displayed at the same time. No one wants to re-submit the form to find a new error.