Κατανοητά μηνύματα σφάλματος: Ο πλήρης οδηγός

Το κρυφό κόστος των άχρηστων σφαλμάτων

Σίγουρα το έχετε δει: μια φόρμα που σας εμφανίζει το μήνυμα «Μη έγκυρη εισαγωγή» αφού έχετε πληκτρολογήσει προσεκτικά τον αριθμό τηλεφώνου σας. Μια διαδικασία ολοκλήρωσης αγοράς που επισημαίνει ένα πεδίο με κόκκινο χρώμα χωρίς να δίνει καμία εξήγηση. Ένα μήνυμα σφάλματος που χρησιμοποιεί αινιγματικούς κωδικούς που καταλαβαίνει μόνο ο προγραμματιστής που το έγραψε στις 11 το βράδυ μιας Παρασκευής.

Δεν πρόκειται για ασήμαντα προβλήματα εμπειρίας χρήστη. Για τα 1,3 δισεκατομμύρια άτομα παγκοσμίως που ζουν με κάποια μορφή αναπηρίας, τα κακώς σχεδιασμένα μηνύματα σφάλματος μπορούν να καταστήσουν ένα ψηφιακό προϊόν εντελώς άχρηστο. Για τους χρήστες προγραμμάτων ανάγνωσης οθόνης, ένα μήνυμα σφάλματος που αλλάζει μόνο χρώμα είναι αόρατο. Για τους χρήστες με γνωστικές αναπηρίες, μια ασαφής φράση μίας γραμμής όπως «Κάτι πήγε στραβά» είναι παραλυτική. Για κάποιον που βασίζεται στον φωνητικό έλεγχο, ένα σφάλμα φόρμας που κλέβει το εστιακό σημείο απρόβλεπτα διακόπτει ολόκληρη τη ροή εργασίας.

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

Τι απαιτεί στην πραγματικότητα το πρότυπο

Το WCAG 2.2, που δημοσιεύθηκε τον Οκτώβριο του 2023, αποτελεί το τρέχον πρότυπο για την προσβασιμότητα στον Ιστό και το σημείο αναφοράς για τα περισσότερα νομικά πλαίσια — συμπεριλαμβανομένης της Οδηγίας της ΕΕ για την Προσβασιμότητα στον Ιστό, του Νόμου περί Ισότητας του Ηνωμένου Βασιλείου και του ADA των ΗΠΑ. Αρκετά κριτήρια επιτυχίας ισχύουν άμεσα για τα μηνύματα σφάλματος. Είναι απαραίτητο να κατανοήσετε πλήρως το γράμμα του κάθε κριτηρίου προτού μπορέσετε να προχωρήσετε πέρα από αυτά.

Τι κάνει ένα μήνυμα σφάλματος να είναι καλό

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

Το πλαίσιο της γλώσσας: Έξι κανόνες για τη σύνταξη κειμένων με λάθη

Τα μηνύματα σφάλματος αποτελούν μια μορφή κειμένου UX. Δεν είναι καταχωρήσεις καταγραφής. Δεν είναι σημειώσεις προγραμματιστών. Είναι επικοινωνία μεταξύ ανθρώπων σε κατάσταση πίεσης — γραμμένη για κάποιον που μόλις απέτυχε σε κάτι και πρέπει να πετύχει.

Πραγματικά μηνύματα σφάλματος: Πριν & Μετά

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

Έλεγχος εγκυρότητας υποχρεωτικών πεδίων

Έλεγχος μορφής (ημερομηνία)

Επαλήθευση κωδικού πρόσβασης

Σφάλμα διακομιστή / συστήματος

Τύποι σφαλμάτων και πότε να τα χρησιμοποιείτε

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

Η προσέγγιση δύο επιπέδων για φόρμες πολλαπλών πεδίων

Για φόρμες με τρία ή περισσότερα πεδία, ένα μόνο πρότυπο δεν αρκεί. Τόσο η Υπηρεσία Ψηφιακών Υπηρεσιών της Κυβέρνησης (GDS) όσο και ο Οδηγός Πρακτικών Σύνταξης ARIA συνιστούν ένα σύστημα δύο επιπέδων: μια σύνοψη σφαλμάτων στο πάνω μέρος της φόρμας, καθώς και ενσωματωμένα μηνύματα σφάλματος δίπλα σε κάθε σχετικό πεδίο.

Μοτίβα κώδικα που λειτουργούν

Η κατανόηση της θεωρίας είναι το μισό της δουλειάς. Παρακάτω παρατίθενται πρότυπα έτοιμα για χρήση σε παραγωγικό περιβάλλον για τα πιο συνηθισμένα σενάρια, με σχολιασμό σχετικά με τα κριτήρια WCAG που πληροί κάθε χαρακτηριστικό.

Ενσωματωμένος έλεγχος εγκυρότητας πεδίου

<!-- The label is always present and always linked -->
<div class="field-group">
  <label for="email">
    Email address
    <span class="required-indicator" aria-label="required"> *</span>
  </label>

  <input
    type="email"
    id="email"
    name="email"
    autocomplete="email"
    aria-required="true"
    aria-invalid="true"     <!-- set when invalid -->
    aria-describedby="email-hint email-error"
  />

  <!-- Hint text always shown (WCAG 3.3.2) -->
  <p id="email-hint" class="field-hint">
    We'll send your confirmation here.
  </p>

  <!-- Error message (shown only on error) -->
  <p
    id="email-error"
    class="field-error"
    role="alert"
    aria-live="assertive"
  >
    <!-- inject error text here -->
    Enter a complete email address — for example, [email protected]
  </p>
</div>

Σύνοψη σφαλμάτων (φόρμες πολλαπλών πεδίων)

<!-- Inject this above the form on submission, then focus #error-summary -->
<div
  id="error-summary"
  role="alert"
  aria-labelledby="error-summary-title"
  tabindex="-1"   <!-- allows programmatic focus -->
  class="error-summary"
>
  <h2 id="error-summary-title">
    There are 2 errors. Fix these to continue.
  </h2>
  <ul>
    <li><a href="#email">Email address: enter a complete email</a></li>
    <li><a href="#dob">Date of birth: use DD/MM/YYYY format</a></li>
  </ul>
</div>

<!-- JavaScript: move focus to summary after injection -->
<script>
  const summary = document.getElementById('error-summary');
  summary.focus(); // fires after DOM update
</script>

Σφάλματα δυναμικού περιεχομένου / AJAX (χωρίς ανανέωση της σελίδας)

Όταν τα σφάλματα επιστρέφονται ασύγχρονα — για παράδειγμα, από μια κλήση API — δεν μπορείτε να βασιστείτε στη φόρτωση της σελίδας για να τα εμφανίσετε. Το πρότυπο «ζωντανής περιοχής» (live region) του ARIA είναι απαραίτητο σε αυτή την περίπτωση.

// Set up the live region once on page load (empty, hidden)
// <div id="live-error" role="alert" aria-live="assertive" aria-atomic="true"></div>

async function submitForm(data) {
  try {
    const res = await fetch('/api/save', { method: 'POST', body: data });
    if (!res.ok) throw new Error(await res.text());
    announceStatus('Your changes have been saved.', 'polite');
  } catch (err) {
    announceStatus(
      'We couldn\'t save your changes. Try again or contact support.',
      'assertive'
    );
  }
}

function announceStatus(message, urgency = 'polite') {
  const region = document.getElementById('live-error');
  region.setAttribute('aria-live', urgency);
  // Clear first to re-trigger announcement if same message
  region.textContent = '';
  requestAnimationFrame(() => {
    region.textContent = message;
  });
}

Ο κατάλογος ελέγχου για τον έλεγχο προσβασιμότητας

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

Οπτική παρουσίαση & περιεχόμενο

Προγραμματισμός & AT

Εστίαση & πληκτρολόγιο

Πώς φτάσαμε εδώ: Μια σύντομη χρονολογική αναδρομή

Τα μηνύματα σφάλματος ως καθρέφτης των αξιών του προϊόντος σας

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

Ένα κόκκινο περίγραμμα χωρίς κείμενο δεν αποτελεί μήνυμα σφάλματος. Μια απλή απεικόνιση κώδικα δεν αποτελεί μήνυμα σφάλματος. Μια αόριστη φράση όπως «κάτι πήγε στραβά» δεν αποτελεί μήνυμα σφάλματος. Ένα προσβάσιμο μήνυμα σφάλματος είναι μια σαφής, ευγενική και πρακτική επικοινωνία που απευθύνεται σε όλους — συμπεριλαμβανομένου του 26% των χρηστών που αντιμετωπίζουν κάποια μορφή αναπηρίας, του 15% που βασίζονται στην πλοήγηση μέσω πληκτρολογίου και του 100% των χρηστών που θα αντιμετωπίσουν κάποιο σφάλμα κάποια στιγμή.

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

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