Όταν τα Μηνύματα Σφάλματος Αποκλείουν τους Χρήστες σας

Η στιγμή που η φόρμα χαλάει

Φανταστείτε το εξής: ένας τυφλός χρήστης συμπληρώνει μια φόρμα ολοκλήρωσης αγοράς, την υποβάλλει και δεν ακούει τίποτα χρήσιμο από τον αναγνώστη οθόνης του. Καμία ανακοίνωση. Καμία εξήγηση. Η σελίδα έχει επισημάνει οπτικά πέντε σφάλματα επικύρωσης με κόκκινο, αλλά ο χρήστης δεν έχει ιδέα. Πατά ξανά υποβολή. Και ξανά. Τελικά φεύγει.

Αυτό δεν είναι ένα οριακό σενάριο. Η μη προσβάσιμη διαχείριση σφαλμάτων είναι ένα από τα πιο συνηθισμένα εμπόδια που εντοπίζουμε σε πραγματικούς ελέγχους, και είναι ένα εμπόδιο που τείνει να απογοητεύει τους χρήστες την χειρότερη δυνατή στιγμή — όταν προσπαθούν να ολοκληρώσουν μια συναλλαγή ή να υποβάλουν κάτι σημαντικό.

Τα καλά νέα είναι ότι η διόρθωσή του είναι σε μεγάλο βαθμό θέμα του να ξέρετε πώς μοιάζει το “σωστό”. Οι αποτυχίες είναι σχεδόν πάντα τα ίδια λίγα μοτίβα.

Γιατί τα μηνύματα σφάλματος είναι δύσκολα για τους χρήστες υποστηρικτικής τεχνολογίας

Οι βλέποντες χρήστες ποντικιού συνήθως αντιλαμβάνονται τα σφάλματα επικύρωσης αμέσως — το κόκκινο περίγραμμα, το εικονίδιο προειδοποίησης, το κείμενο που εμφανίζεται κάτω από το πεδίο. Αλλά οι χρήστες που βασίζονται σε αναγνώστες οθόνης, πλοήγηση με πληκτρολόγιο ή φωνητικό έλεγχο αντιμετωπίζουν μια θεμελιωδώς διαφορετική εμπειρία.

Όταν μια φόρμα υποβάλλεται και εμφανίζονται σφάλματα:

• Οι χρήστες αναγνωστών οθόνης μπορεί να μην ακούσουν τίποτα, εκτός αν η εστίαση μετακινηθεί στο σφάλμα ή μια ζωντανή περιοχή το ανακοινώσει
• Οι χρήστες πληκτρολογίου πρέπει να μπορούν να φτάσουν σε κάθε μήνυμα σφάλματος από το πληκτρολόγιο και να καταλάβουν σε ποιο πεδίο ανήκει
• Οι χρήστες φωνητικού ελέγχου πρέπει να απευθύνονται στα πεδία μέσω μιας ορατής, ακριβούς ετικέτας — αν η ετικέτα είναι λανθασμένη ή λείπει, έχουν κολλήσει

Τίποτα από αυτά δεν συμβαίνει αυτόματα. Πρέπει να το κατασκευάσετε.

Τα κριτήρια WCAG που ισχύουν

Τέσσερα κριτήρια επιτυχίας στο WCAG 2.2 καλύπτουν άμεσα τη διαχείριση σφαλμάτων:

3.3.1 Error Identification (Επίπεδο A) — Εάν ένα σφάλμα εντοπίζεται αυτόματα, το στοιχείο με σφάλμα αναγνωρίζεται και περιγράφεται στον χρήστη με κείμενο. Δεν μπορείτε να μεταδίδετε σφάλματα μόνο μέσω χρώματος.

3.3.2 Labels or Instructions (Επίπεδο A) — Τα πεδία που απαιτούν συγκεκριμένη μορφή πρέπει να καθιστούν αυτή την απαίτηση σαφή πριν ή κατά τη διάρκεια της εισαγωγής, όχι μόνο αφού αποτύχει η υποβολή.

3.3.3 Error Suggestion (Επίπεδο AA) — Εάν εντοπιστεί σφάλμα και είναι γνωστές προτάσεις διόρθωσης, παρέχετέ τις. Το “Μη έγκυρη ημερομηνία” δεν αρκεί. Το “Εισαγάγετε την ημερομηνία σε μορφή ΗΗ/ΜΜ/ΕΕΕΕ” αρκεί.

3.3.4 Error Prevention (Επίπεδο AA) — Για υποβολές με σοβαρές συνέπειες (οικονομικές συναλλαγές, νομικές συμφωνίες), δώστε στους χρήστες τη δυνατότητα να ελέγξουν, να διορθώσουν και να επιβεβαιώσουν πριν η ενέργεια γίνει οριστική.

Υπάρχει επίσης το 4.1.3 Status Messages (Επίπεδο AA), που καλύπτει τα δυναμικά εισαγόμενα μηνύματα που δεν λαμβάνουν εστίαση — αυτά πρέπει να ανακοινώνονται από την υποστηρικτική τεχνολογία με χρήση role="status" ή role="alert".

Τι πραγματικά χρειάζεται ένα προσβάσιμο μήνυμα σφάλματος

Η σωστή υλοποίηση των μηνυμάτων σφάλματος απαιτεί προσοχή σε τέσσερα διακριτά επίπεδα:

1. Η προγραμματιστική σύνδεση

Κάθε μήνυμα σφάλματος πρέπει να συνδέεται με το πεδίο του μέσω aria-describedby. Αυτό λέει στους αναγνώστες οθόνης να εκφωνούν το κείμενο του σφάλματος όταν το πεδίο λαμβάνει εστίαση.

<!-- 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>

Το χαρακτηριστικό aria-invalid="true" δηλώνει ότι το πεδίο είναι εκείνη τη στιγμή μη έγκυρο, κάτι που οι περισσότεροι αναγνώστες οθόνης ανακοινώνουν όταν η εστίαση φτάσει σε αυτό.

2. Διαχείριση εστίασης μετά την υποβολή

Όταν μια φόρμα υποβάλλεται και υπάρχουν σφάλματα, η εστίαση πρέπει να μετακινηθεί κάπου χρήσιμα. Τα δύο πιο συνηθισμένα μοτίβα:

• Μετακινήστε την εστίαση σε μια σύνοψη σφαλμάτων στην κορυφή της φόρμας που παραθέτει όλα τα σφάλματα με συνδέσμους προς τα σχετικά πεδία
• Μετακινήστε την εστίαση στο πρώτο πεδίο με σφάλμα

Εάν η εστίαση παραμείνει στο κουμπί υποβολής ή πουθενά, οι χρήστες αναγνωστών οθόνης πρέπει να ανακαλύψουν μόνοι τους τα σφάλματα πλοηγούμενοι μέσα στη φόρμα — αν καν γνωρίζουν ότι υπάρχουν σφάλματα.

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

3. Ανακοινώσεις ζωντανών περιοχών για δυναμικά σφάλματα

Για σφάλματα που εμφανίζονται καθώς ο χρήστης πληκτρολογεί (ενσωματωμένη επικύρωση σε πραγματικό χρόνο), χρησιμοποιήστε ζωντανές περιοχές ARIA, ώστε το μήνυμα να ανακοινώνεται χωρίς να απαιτείται μετακίνηση της εστίασης.

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

Χρησιμοποιήστε role="alert" / aria-live="assertive" για σφάλματα που χρειάζονται άμεση προσοχή. Χρησιμοποιήστε role="status" / aria-live="polite" για λιγότερο επείγουσα ανατροφοδότηση που μπορεί να περιμένει μέχρι ο χρήστης να κάνει παύση.

4. Το ίδιο το μήνυμα σφάλματος

Η γλώσσα έχει σημασία. Τα προσβάσιμα μηνύματα σφάλματος είναι:

• Συγκεκριμένα: λένε τι πάει στραβά, όχι απλώς ότι κάτι πάει στραβά
• Πρακτικά: λένε στον χρήστη τι ακριβώς να κάνει για να το διορθώσει
• Ευγενικά: αποφεύγουν επικριτική γλώσσα όπως “εισαγάγατε μη έγκυρη τιμή”

Μη προσβάσιμο	Προσβάσιμο
”Μη έγκυρη καταχώριση"	"Η διεύθυνση email πρέπει να περιλαμβάνει το σύμβολο @, π.χ. name@example.com"
"Σφάλμα"	"Η ημερομηνία πρέπει να είναι σε μορφή ΗΗ/ΜΜ/ΕΕΕΕ"
"Υποχρεωτικό πεδίο"	"Το ονοματεπώνυμο είναι υποχρεωτικό"
"Μη έγκυρος κωδικός"	"Ο κωδικός πρόσβασης πρέπει να έχει τουλάχιστον 8 χαρακτήρες και να περιλαμβάνει έναν αριθμό”

Μοτίβα για διαφορετικά σενάρια σφαλμάτων

Ενσωματωμένα σφάλματα πεδίων

Το πιο συνηθισμένο μοτίβο. Ένα μήνυμα σφάλματος εμφανίζεται ακριβώς κάτω από το συσχετισμένο πεδίο του. Λειτουργεί καλά για απλές φόρμες. Απαιτεί aria-describedby και aria-invalid για να εκφωνείται σωστά.

Μπάνερ σύνοψης σφαλμάτων

Για μεγάλες φόρμες με πολλαπλά σφάλματα, τοποθετήστε μια σύνοψη στην κορυφή που παραθέτει όλα τα προβλήματα ως συνδέσμους που οδηγούν στο σχετικό πεδίο. Μετακινήστε την εστίαση εδώ μετά από μια αποτυχημένη υποβολή. Αυτό είναι το μοτίβο που χρησιμοποιεί το GOV.UK και συνιστάται ευρέως για σύνθετες φόρμες.

Ειδοποιήσεις toast

Τα σύντομης διάρκειας μηνύματα που εμφανίζονται στην άκρη της οθόνης είναι από τα πιο μη προσβάσιμα μοτίβα σε κοινή χρήση. Εξαφανίζονται πριν οι χρήστες αναγνωστών οθόνης προλάβουν να τα φτάσουν, συχνά δεν ανακοινώνονται καθόλου και δεν προσφέρουν καμία διαδρομή ανάκαμψης. Αποφύγετε τη χρήση toast για σφάλματα. Αν παρ’ όλα αυτά τα χρησιμοποιείτε, συνδυάστε τα με μια μόνιμη κατάσταση σφάλματος πάνω στην ίδια τη φόρμα.

Σφάλματα συστήματος

Όταν κάτι πάει στραβά στην πλευρά του διακομιστή, πείτε στον χρήστη με απλή γλώσσα τι συνέβη και τι μπορεί να κάνει στη συνέχεια. Το “Κάτι πήγε στραβά” χωρίς περαιτέρω καθοδήγηση αφήνει τους χρήστες αβοήθητους.

<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>

Η λίστα ελέγχου δοκιμών

Αφού υλοποιήσετε τη διαχείριση σφαλμάτων, επαληθεύστε τα εξής χειροκίνητα — τα αυτοματοποιημένα εργαλεία δεν θα εντοπίσουν τα περισσότερα από αυτά:

• Η υποβολή μιας κενής υποχρεωτικής φόρμας μετακινεί την εστίαση σε μια σύνοψη σφαλμάτων ή στο πρώτο πεδίο με σφάλμα
• Κάθε μήνυμα σφάλματος συνδέεται με το πεδίο του μέσω aria-describedby
• Τα πεδία με σφάλμα έχουν aria-invalid="true"
• Τα μηνύματα σφάλματος εκφωνούνται όταν η εστίαση φτάνει στο επηρεαζόμενο πεδίο
• Η επικύρωση σε πραγματικό χρόνο χρησιμοποιεί ζωντανές περιοχές
• Τα μηνύματα σφάλματος χρησιμοποιούν συγκεκριμένη, πρακτική γλώσσα — όχι απλώς “μη έγκυρο”
• Το χρώμα δεν είναι ο μοναδικός τρόπος επισήμανσης των σφαλμάτων (εικονίδιο ή ετικέτα κειμένου μαζί με το κόκκινο)
• Ο χρήστης μπορεί να φτάσει στο σφάλμα με tab από το πληκτρολόγιο
• Η σειρά εστίασης μετά την υποβολή είναι λογική και δεν μεταπηδά απρόβλεπτα
• Τα μηνύματα toast συνδυάζονται με μια μόνιμη κατάσταση σφάλματος

Γιατί τα αυτοματοποιημένα εργαλεία χάνουν τα περισσότερα από αυτά

Ένας αυτοματοποιημένος σαρωτής μπορεί να ελέγξει αν το aria-describedby δείχνει σε υπαρκτό στοιχείο και αν υπάρχει το aria-invalid. Δεν μπορεί να ελέγξει αν η εστίαση μετακινείται σωστά μετά την υποβολή, αν το κείμενο του σφάλματος είναι ακριβές ή αν μια ειδοποίηση toast εξαφανίζεται πριν προλάβει να διαβαστεί. Οι χειροκίνητοι έλεγχοι προσβασιμότητας που πραγματοποιούμε περιλαμβάνουν δοκιμές ειδικά για φόρμες με πραγματική υποστηρικτική τεχνολογία — ο μόνος αξιόπιστος τρόπος να επαληθεύσετε ότι η διαχείριση σφαλμάτων λειτουργεί πραγματικά από άκρη σε άκρη.

Εάν δεν είστε σίγουροι σε τι κατάσταση βρίσκονται οι φόρμες σας, εκτελέστε μια δωρεάν σάρωση για να αναδείξετε πρώτα τα αυτοματοποιήσιμα προβλήματα, και συνεχίστε από εκεί.