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

Οι ετικέτες ARIA είναι για ονόματα, όχι για δικαιολογίες

Το ARIA είναι χρήσιμο, αλλά συχνά χρησιμοποιείται ως μπάλωμα για ασαφές HTML. Εκεί είναι που οι ομάδες μπαίνουν σε μπελάδες.

Το πιο συνηθισμένο παράδειγμα είναι το aria-label. Φαίνεται ακίνδυνο: προσθέτεις ένα string, ικανοποιείς ένα linter και συνεχίζεις. Όμως ένα προσβάσιμο όνομα δεν είναι διακόσμηση. Είναι το όνομα που πολλές υποστηρικτικές τεχνολογίες εμφανίζουν στους χρήστες όταν πλοηγούνται με κουμπιά, συνδέσμους, πεδία φόρμας, επικεφαλίδες, ορόσημα και στοιχεία ελέγχου.

Αν αυτό το όνομα είναι αόριστο, διπλότυπο, παρωχημένο ή διαφορετικό από την ορατή ετικέτα, η διεπαφή γίνεται πιο δύσχρηστη. Μερικές φορές ακόμη χειρότερα: το aria-label μπορεί να υπερισχύσει καλύτερου κειμένου που υπήρχε ήδη στο DOM.

Ο στόχος δεν είναι να προσθέσουμε περισσότερο ARIA. Ο στόχος είναι να κάνουμε σαφές το όνομα, τον ρόλο, την κατάσταση και τον σκοπό κάθε στοιχείου της διεπαφής.

Το προσβάσιμο όνομα, με απλά λόγια

Τα περισσότερα διαδραστικά στοιχεία έχουν ένα προσβάσιμο όνομα. Οι αναγνώστες οθόνης χρησιμοποιούν αυτό το όνομα για να ανακοινώσουν τι είναι το στοιχείο.

Για παράδειγμα:

<button>Save changes</button>

Ένας αναγνώστης οθόνης μπορεί να ανακοινώσει κάτι όπως: “Save changes, button.” Ο ρόλος προκύπτει από το εγγενές στοιχείο button. Το όνομα προκύπτει από το κείμενο μέσα σε αυτό.

Αυτή είναι η ιδανική περίπτωση: το ορατό κείμενο και το προσβάσιμο όνομα ταιριάζουν.

Τα χαρακτηριστικά επισήμανσης ARIA γίνονται χρήσιμα όταν η ορατή διεπαφή δεν παρέχει πλήρες όνομα ή όταν το όνομα πρέπει να προέρχεται από άλλο στοιχείο. Τα κύρια χαρακτηριστικά είναι:

• aria-label: παρέχει ένα string απευθείας στο στοιχείο.
• aria-labelledby: δείχνει σε ένα ή περισσότερα στοιχεία των οποίων το κείμενο γίνεται το όνομα.
• aria-describedby: δείχνει σε υποστηρικτικό κείμενο περιγραφής, όχι στο κύριο όνομα.

Αυτά τα τρία σχετίζονται, αλλά δεν είναι εναλλάξιμα.

Πρώτος κανόνας: προτιμήστε εγγενές HTML και ορατές ετικέτες

Αν μπορείτε να βάλετε ορατό κείμενο στο στοιχείο ελέγχου, κάντε πρώτα αυτό.

Αυτό είναι καλύτερο:

<button>Delete invoice</button>

Από αυτό:

<button aria-label="Delete invoice">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

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

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

Πότε το aria-label είναι το σωστό εργαλείο

Χρησιμοποιήστε το aria-label όταν ένα στοιχείο χρειάζεται προσβάσιμο όνομα και δεν υπάρχει κατάλληλο ορατό κείμενο για αναφορά.

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

<button aria-label="Search">
  <svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">
    <!-- icon -->
  </svg>
</button>

Αυτό είναι λογικό. Το ορατό εικονίδιο υποδηλώνει αναζήτηση, αλλά το ίδιο το SVG path δεν παρέχει αξιόπιστο όνομα. Το aria-label παρέχει ένα.

Άλλες καλές περιπτώσεις περιλαμβάνουν:

• Ένα κουμπί κλεισίματος που αναπαρίσταται μόνο με ένα “X”.
• Ένα ορόσημο πλοήγησης που χρειάζεται πιο συγκεκριμένο όνομα, όπως aria-label="Product".
• Ένα επαναλαμβανόμενο στοιχείο ελέγχου όπου το ορατό συμφραζόμενο δεν αποτελεί μέρος του κειμένου του κουμπιού.

Για παράδειγμα:

<nav aria-label="Primary">
  ...
</nav>

<nav aria-label="Footer">
  ...
</nav>

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

Πότε το aria-label είναι το λάθος εργαλείο

Μην προσθέτετε aria-label απλώς επειδή ένα τεστ λέει ότι ένα στοιχείο χρειάζεται ετικέτα. Διορθώστε πρώτα το markup.

Κακό:

<div role="button" tabindex="0" aria-label="Submit">Submit</div>

Καλύτερο:

<button>Submit</button>

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

Επίσης, αποφύγετε τη χρήση του aria-label για να μετονομάσετε ορατό κείμενο με τρόπο που αλλάζει το νόημα.

<button aria-label="Delete invoice">Remove</button>

Αυτό φαίνεται ασήμαντο, αλλά μπορεί να μπερδέψει χρήστες που βασίζονται σε φωνητική εισαγωγή. Αν ένα ορατό κουμπί λέει “Remove”, αλλά το προσβάσιμο όνομά του είναι “Delete invoice”, ένας χρήστης που προσπαθεί να πει “click Remove” μπορεί να μην πάρει το αναμενόμενο αποτέλεσμα. Η απαίτηση “label in name” του WCAG υπάρχει ακριβώς για αυτόν τον λόγο: το ορατό κείμενο θα πρέπει γενικά να περιέχεται στο προσβάσιμο όνομα.

Μια καλύτερη εκδοχή:

<button aria-label="Remove invoice">Remove</button>

Συχνά ακόμη καλύτερα:

<button>Remove invoice</button>

Στραφείτε στο aria-labelledby όταν υπάρχει ήδη ορατό κείμενο

Αν το κείμενο της ετικέτας βρίσκεται ήδη στη σελίδα, το aria-labelledby είναι συνήθως καλύτερο από το aria-label.

Παράδειγμα:

<h2 id="billing-title">Billing address</h2>
<section aria-labelledby="billing-title">
  ...
</section>

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

Αυτό είναι ιδιαίτερα χρήσιμο για ομάδες πεδίων φόρμας:

<fieldset aria-labelledby="shipping-speed-title">
  <legend id="shipping-speed-title">Shipping speed</legend>

  <label>
    <input type="radio" name="shipping" value="standard">
    Standard
  </label>

  <label>
    <input type="radio" name="shipping" value="express">
    Express
  </label>
</fieldset>

Σε πολλές περιπτώσεις, το εγγενές legend αρκεί χωρίς ARIA. Το θέμα είναι ότι οι ορατές ετικέτες πρέπει να προηγούνται. Το ARIA πρέπει να συνδέει υπάρχον νόημα, όχι να δημιουργεί μια δεύτερη ιδιωτική εκδοχή του.

Χρησιμοποιήστε το aria-describedby για βοηθητικό κείμενο, όχι για το όνομα

Μια περιγραφή δεν είναι ετικέτα.

Σκεφτείτε αυτό το πεδίο:

<label for="password">Password</label>
<input id="password" type="password" aria-describedby="password-help">
<p id="password-help">Use at least 12 characters.</p>

Το προσβάσιμο όνομα είναι “Password.” Η περιγραφή είναι “Use at least 12 characters.” Ένας αναγνώστης οθόνης μπορεί να ανακοινώσει και τα δύο, αλλά εξυπηρετούν διαφορετικούς σκοπούς.

Μην κάνετε αυτό:

<input type="password" aria-label="Use at least 12 characters">

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

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

<label for="email">Email</label>
<input
  id="email"
  type="email"
  aria-invalid="true"
  aria-describedby="email-error"
>
<p id="email-error">Enter an email address in the format [email protected].</p>

Η ετικέτα παραμένει σταθερή. Το μήνυμα σφάλματος γίνεται υποστηρικτικό συμφραζόμενο.

Τα επαναλαμβανόμενα στοιχεία ελέγχου χρειάζονται μοναδικά ονόματα

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

Κακό:

<button>Delete</button>
<button>Delete</button>
<button>Delete</button>

Ένας χρήστης αναγνώστη οθόνης που πλοηγείται ανά κουμπιά μπορεί να ακούσει “Delete, button” τρεις φορές χωρίς συμφραζόμενα.

Καλό:

<button aria-label="Delete report: Q4 revenue">Delete</button>
<button aria-label="Delete report: Hiring plan">Delete</button>
<button aria-label="Delete report: Vendor list">Delete</button>

Αυτή είναι νόμιμη χρήση του aria-label: το ορατό κείμενο παραμένει σύντομο, ενώ το προσβάσιμο όνομα περιλαμβάνει το αντικείμενο.

Αλλά χρησιμοποιήστε αυτό το μοτίβο προσεκτικά. Αν το όνομα του αντικειμένου είναι ορατό κοντά, το aria-labelledby μπορεί να είναι πιο συντηρήσιμο:

<article>
  <h3 id="report-q4">Q4 revenue</h3>
  <button aria-labelledby="delete-q4 report-q4" id="delete-q4">Delete</button>
</article>

Το προσβάσιμο όνομα γίνεται “Delete Q4 revenue.” Έτσι αποφεύγεται η αντιγραφή του τίτλου της αναφοράς σε ένα attribute.

Μην βάζετε ετικέτα στα πάντα

Δεν χρειάζεται κάθε στοιχείο ετικέτα ARIA.

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

Για εικόνες, χρησιμοποιήστε το μοντέλο που αφορά ειδικά τις εικόνες: οι ουσιαστικές εικόνες χρειάζονται χρήσιμο alt· οι διακοσμητικές εικόνες χρειάζονται κενό alt="". Μην χρησιμοποιείτε ετικέτες ARIA ως υποκατάστατο για καλό κείμενο εικόνας. Αν η ομάδα σας μπερδεύει αυτές τις έννοιες, επιστρέψτε στον πρακτικό οδηγό για image alt text και διαχωρίστε τις εναλλακτικές εικόνων από τα ονόματα στοιχείων ελέγχου.

Ένα συνηθισμένο λάθος είναι να δίνετε σε κάθε SVG ένα aria-label. Αν το SVG βρίσκεται μέσα σε ένα κουμπί και το κουμπί έχει ήδη όνομα, το εικονίδιο συνήθως πρέπει να είναι κρυφό από τις υποστηρικτικές τεχνολογίες:

<button aria-label="Open menu">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

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

Ελέγξτε το υπολογισμένο όνομα, όχι μόνο τον κώδικα

Τα σφάλματα προσβασιμότητας συχνά επιβιώνουν από το code review επειδή το markup φαίνεται εύλογο.

Τα σύγχρονα εργαλεία προγραμματιστή των browser μπορούν να δείξουν το υπολογισμένο δέντρο προσβασιμότητας. Σε Chrome, Edge, Firefox και Safari, επιθεωρήστε το στοιχείο και αναζητήστε πληροφορίες προσβασιμότητας όπως ρόλο, όνομα και περιγραφή. Ελέγχετε τρία πράγματα:

1. Είναι ο ρόλος αυτός που περιμένετε;
2. Είναι το προσβάσιμο όνομα σαφές και συγκεκριμένο;
3. Είναι η περιγραφή χρήσιμη χωρίς να αντικαθιστά το όνομα;

Στη συνέχεια, δοκιμάστε μερικές ροές με έναν πραγματικό αναγνώστη οθόνης. Δεν χρειάζεται να γίνετε ειδικός πλήρους απασχόλησης στις υποστηρικτικές τεχνολογίες για να εντοπίσετε τα βασικά. Σε macOS, το VoiceOver είναι ενσωματωμένο. Σε Windows, το NVDA χρησιμοποιείται ευρέως και είναι δωρεάν. Σε mobile, δοκιμάστε με VoiceOver σε iOS και TalkBack σε Android όπου είναι σχετικό.

Τα αυτοματοποιημένα εργαλεία είναι χρήσιμα, αλλά δεν μπορούν να κρίνουν αξιόπιστα αν τα “Open,” “Read more,” ή “Delete” έχουν επαρκή συμφραζόμενα. Αντιμετωπίστε τον αυτοματισμό ως δίχτυ, όχι ως κριτή. Αυτό μοιάζει με τον έλεγχο απόδοσης: μια αναφορά μπορεί να σας δείξει ύποπτες περιοχές, αλλά πρέπει ακόμη να ερμηνεύσετε τον αντίκτυπο. Η ίδια ψύχραιμη προσέγγιση που προτείνουμε για την ανάγνωση μιας αναφοράς Lighthouse χωρίς πανικό ισχύει και εδώ.

Μια πρακτική λίστα ελέγχου για review

Πριν δημοσιεύσετε ετικέτες ARIA, ρωτήστε:

• Θα μπορούσε αυτό να είναι εγγενές HTML αντί για κάτι άλλο;
• Υπάρχει ορατό κείμενο που θα πρέπει να χρησιμοποιηθεί ως ετικέτα;
• Αν υπάρχει ορατό κείμενο, το προσβάσιμο όνομα το περιλαμβάνει;
• Είναι τα επαναλαμβανόμενα στοιχεία ελέγχου μοναδικά όταν γίνεται πλοήγηση εκτός οπτικού συμφραζομένου;
• Είναι το βοηθητικό κείμενο συνδεδεμένο με aria-describedby και όχι πιεσμένο μέσα στην ετικέτα;
• Είναι τα διακοσμητικά εικονίδια κρυφά από τις υποστηρικτικές τεχνολογίες;
• Έχει ελέγξει κάποιος το υπολογισμένο προσβάσιμο όνομα στα browser dev tools;
• Έχει γίνει τουλάχιστον ένα πέρασμα με πραγματικό αναγνώστη οθόνης για την κρίσιμη ροή;

Αυτή η λίστα ελέγχου εντοπίζει τα περισσότερα προβλήματα ετικετών πριν γίνουν προβλήματα χρηστών.

Η ήσυχη πειθαρχία του καλού ARIA

Η καλή δουλειά με ARIA σπάνια είναι δραματική. Είναι κυρίως αυτοσυγκράτηση.

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

Η πλατφόρμα του ιστού δίνει στους προγραμματιστές πολλά δωρεάν όταν τη χρησιμοποιούμε άμεσα. Το ARIA υπάρχει για τα κενά. Η δεξιότητα είναι να ξέρεις πότε υπάρχει πράγματι κενό.