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

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

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

Επίσης, παρεξηγείται συστηματικά.

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

Γι’ αυτό ο ισχυρισμός ότι ο αυτοματοποιημένος έλεγχος χάνει περίπου τα μισά προβλήματά σας δεν είναι κυνικός. Είναι γενναιόδωρος. Ορισμένες κατηγορίες ζητημάτων είναι ιδιαίτερα αυτοματοποιήσιμες. Άλλες είναι σχεδόν καθόλου αυτοματοποιήσιμες.

Η πρακτική απάντηση δεν είναι να εγκαταλείψετε τα αυτοματοποιημένα εργαλεία. Είναι να τα τοποθετήσετε στη σωστή θέση: νωρίς, συχνά και ως μέρος μιας ευρύτερης ροής ελέγχου.

Σε τι είναι καλά τα αυτοματοποιημένα τεστ

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

Συνηθισμένα παραδείγματα περιλαμβάνουν:

• Εικόνες με ελλιπή χαρακτηριστικά alt
• Πεδία φόρμας χωρίς συσχετισμένες ετικέτες
• Κουμπιά χωρίς προσβάσιμα ονόματα
• Κείμενο που δεν περνά τα όρια αντίθεσης
• Μη έγκυρα χαρακτηριστικά ή ρόλους ARIA
• Επίπεδα επικεφαλίδων που παραλείπονται με ύποπτους τρόπους
• Ορόσημα που λείπουν ή είναι διπλότυπα
• Σύνδεσμοι με κενά προσβάσιμα ονόματα
• Πίνακες χωρίς βασική δομή

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

Οι αυτοματοποιημένοι έλεγχοι κάνουν επίσης την προσβασιμότητα ευκολότερη στη συζήτηση μέσα στις ροές εργασίας μηχανικών. Ένα αποτυχημένο τεστ στο CI είναι συγκεκριμένο. Μια προειδοποίηση σε ένα pull request έρχεται τη σωστή στιγμή. Μια γραμμή τάσης σε πρότυπα δίνει στην ομάδα κάτι να βελτιώσει.

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

Πού καταρρέει η αυτοματοποίηση

Η προσβασιμότητα δεν είναι μόνο ιδιότητα του κώδικα. Είναι ιδιότητα της χρήσης.

Ένα εργαλείο μπορεί να σας πει αν μια εικόνα έχει εναλλακτικό κείμενο. Συνήθως δεν μπορεί να σας πει αν αυτό το εναλλακτικό κείμενο είναι χρήσιμο. Μια εικόνα ενός προϊόντος μπορεί να χρειάζεται λεπτομερή περιγραφή σε μια σελίδα προϊόντος, καμία περιγραφή σε ένα διακοσμητικό hero και μια εντελώς διαφορετική περιγραφή σε ένα άρθρο βοήθειας. Η σωστή απάντηση εξαρτάται από το πλαίσιο. Γι’ αυτό οι ομάδες χρειάζονται συντακτική καθοδήγηση όπως μια πραγματιστική προσέγγιση στο εναλλακτικό κείμενο εικόνων, όχι μόνο έναν κανόνα linter.

Το ίδιο πρόβλημα εμφανίζεται παντού.

Ένας σαρωτής μπορεί να επιβεβαιώσει ότι κάθε κουμπί έχει προσβάσιμο όνομα. Δεν μπορεί πάντα να πει αν το όνομα βγάζει νόημα. Μια σελίδα με πέντε κουμπιά που ονομάζονται Υποβολή μπορεί να περνά έναν βασικό κανόνα και παρ’ όλα αυτά να είναι δυσάρεστη για χρήστες αναγνωστών οθόνης. Ένα modal μπορεί να έχει τα σωστά χαρακτηριστικά ARIA αλλά να παγιδεύει την εστίαση λανθασμένα. Ένα προσαρμοσμένο dropdown μπορεί να φαίνεται συμμορφωμένο σε στατικό markup και να αποτυγχάνει τη στιγμή που κάποιος προσπαθεί να το χρησιμοποιήσει με πληκτρολόγιο.

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

• Ταιριάζει η σειρά εστίασης με την οπτική και λογική σειρά;
• Μπορεί κάθε εργασία να ολοκληρωθεί μόνο με πληκτρολόγιο;
• Είναι τα μηνύματα σφάλματος συγκεκριμένα, έγκαιρα και συσχετισμένα με τα πεδία;
• Συνεχίζει η σελίδα να λειτουργεί όταν το κείμενο αλλάζει μέγεθος ή γίνεται zoom;
• Είναι η σειρά ανάγνωσης λογική για την υποστηρικτική τεχνολογία;
• Είναι οι οδηγίες κατανοητές χωρίς να βασίζονται σε χρώμα ή θέση;
• Οι υπότιτλοι, οι απομαγνητοφωνήσεις και οι ετικέτες επικοινωνούν πραγματικά το περιεχόμενο;
• Συμπεριφέρεται ένα component προβλέψιμα σε διαφορετικές καταστάσεις;

Αυτές δεν είναι ακραίες περιπτώσεις. Είναι κεντρικές στην προσβασιμότητα.

Η ψευδής ασφάλεια μιας υψηλής βαθμολογίας

Οι βαθμολογίες προσβασιμότητας είναι δελεαστικές επειδή συμπιέζουν ένα ακατάστατο θέμα σε έναν αριθμό. Ένα dashboard λέει 98. Μια αναφορά δείχνει πράσινους ελέγχους. Η έκδοση μοιάζει πιο ασφαλής.

Όμως η βαθμολογία μετρά μόνο αυτό που μετρά το εργαλείο.

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

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

Ο κίνδυνος είναι ιδιαίτερα υψηλός όταν οι ομάδες εκτελούν σαρώσεις μόνο σε στατικές σελίδες. Τα σύγχρονα interfaces έχουν καταστάσεις: τα μενού ανοίγουν, τα drawers γλιστρούν, τα toasts εμφανίζονται, τα μηνύματα επικύρωσης ενημερώνονται, τα tabs αλλάζουν panels, τα φίλτρα ξαναγράφουν περιεχόμενο και ο έλεγχος ταυτότητας αλλάζει τα πάντα. Πολλά σοβαρά ελαττώματα προσβασιμότητας ζουν σε αυτές τις αλληλεπιδράσεις.

Αν ο σαρωτής σας βλέπει μόνο το αρχικό DOM, χάνει το προϊόν.

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

1. Συμπεριφορά πληκτρολογίου και εστίασης

Η πρόσβαση με πληκτρολόγιο είναι ένα από τα καθαρότερα παραδείγματα του γιατί η αυτοματοποίηση δεν αρκεί.

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

Χρειάζεστε έναν άνθρωπο να πατήσει Tab, Shift+Tab, Enter, Space, Escape και τα πλήκτρα βέλους μέσα στην πραγματική ροή εργασίας.

Αυτό είναι ιδιαίτερα σημαντικό για προσαρμοσμένα controls. Τα εγγενή στοιχεία HTML κουβαλούν χρόνια συμπεριφοράς προσβασιμότητας δωρεάν. Το να ξαναχτίζετε κουμπιά, selects, checkboxes, menus και dialogs με divs σημαίνει ότι η ομάδα σας πλέον κατέχει αυτή τη συμπεριφορά. Αν αξιολογείτε διαδραστικά components, ξεκινήστε με μια σύντομη λίστα ελέγχου για προσβάσιμα web buttons και επεκτείνετε την ίδια πειθαρχία σε κάθε προσαρμοσμένο control.

2. Ουσιαστικά ονόματα και περιγραφές

Τα αυτοματοποιημένα εργαλεία μπορούν να ανιχνεύσουν την απουσία. Είναι πολύ χειρότερα στον εντοπισμό της ποιότητας.

Ένας σύνδεσμος με όνομα Διαβάστε περισσότερα μπορεί τεχνικά να έχει προσβάσιμο όνομα. Ένα κουμπί με ετικέτα OK μπορεί να είναι έγκυρο. Μια υπόδειξη φόρμας μπορεί να υπάρχει. Αλλά είναι ουσιαστικά μέσα στο πλαίσιο; Συχνά όχι.

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

3. Χειρισμός σφαλμάτων

Οι φόρμες είναι γεμάτες αποτυχίες προσβασιμότητας που οι σαρωτές εντοπίζουν μόνο μερικώς.

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

Ο καλός χειρισμός σφαλμάτων είναι σχεδιασμός αλληλεπίδρασης. Χρειάζεται χειροκίνητο έλεγχο και, ιδανικά, έλεγχο με χρήστες.

4. Οπτική προσαρμογή

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

Δοκιμάστε zoom 200%. Δοκιμάστε αλλαγή μεγέθους κειμένου στο πρόγραμμα περιήγησης. Δοκιμάστε λειτουργία υψηλής αντίθεσης ή forced colors. Δοκιμάστε στενά πλάτη viewport. Δοκιμάστε reduced motion. Πολλοί ιστότοποι που φαίνονται καλοδουλεμένοι στις προεπιλεγμένες ρυθμίσεις καταρρέουν γρήγορα όταν οι χρήστες επιβάλλουν τις προτιμήσεις τους.

5. Σαφήνεια περιεχομένου

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

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

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

Μια καλύτερη ροή ελέγχου

Μια ισορροπημένη ροή προσβασιμότητας έχει επίπεδα.

Εκτελείτε αυτοματοποιημένους ελέγχους συνεχώς

Χρησιμοποιήστε αυτοματοποιημένα τεστ στην ανάπτυξη, στα pull requests, στις προεπισκοπήσεις components και στο CI. Πρέπει να είναι βαρετά, γρήγορα και αδιαπραγμάτευτα. Νέες ελλιπείς ετικέτες και μη έγκυρο ARIA δεν πρέπει να χρειάζονται τριμηνιαίο audit για να ανακαλυφθούν.

Αντιμετωπίστε αυτές τις αποτυχίες όπως τις αποτυχίες linting. Ο στόχος δεν είναι οι ηρωισμοί· είναι η αποτροπή παλινδρομήσεων.

Προσθέστε χειροκίνητο έλεγχο με πληκτρολόγιο

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

Κατ’ ελάχιστον, επαληθεύστε:

• Κάθε διαδραστικό στοιχείο είναι προσβάσιμο
• Η εστίαση είναι πάντα ορατή
• Η σειρά εστίασης είναι λογική
• Τα αναμενόμενα πλήκτρα λειτουργούν
• Το Escape κλείνει επικαλύψεις που μπορούν να κλείσουν
• Η εστίαση γίνεται σωστά μετά το άνοιγμα και το κλείσιμο components
• Δεν υπάρχει παγίδα πληκτρολογίου

Αυτή η μία συνήθεια εντοπίζει μια μεγάλη κατηγορία ζητημάτων που οι αυτοματοποιημένες σαρώσεις χάνουν.

Δοκιμάστε με τουλάχιστον έναν αναγνώστη οθόνης

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

Παρόλα αυτά, βασικός έλεγχος με VoiceOver, NVDA ή JAWS μπορεί να αποκαλύψει σπασμένα ονόματα, μπερδεμένη σειρά ανάγνωσης, ενημερώσεις που δεν ανακοινώνονται και προβλήματα οροσήμων που ένας σαρωτής μπορεί να μην εντοπίσει.

Συνδυάστε το με σημασιολογικό HTML. Όσο περισσότερα εγγενή στοιχεία χρησιμοποιείτε, τόσο λιγότερο εύθραυστη γίνεται η προσβασιμότητά σας.

Ελέγξτε περιεχόμενο και καταστάσεις

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

Ελέγξτε επίσης τις πραγματικές λέξεις. Οι ετικέτες, οι επικεφαλίδες, οι οδηγίες και τα μηνύματα σφάλματος είναι μέρος του interface.

Συμπεριλάβετε ανάπηρους χρήστες όταν το διακύβευμα είναι υψηλό

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

Ο αυτοματοποιημένος έλεγχος κλιμακώνεται. Ο ανθρώπινος έλεγχος κατανοεί.

Πώς να ερμηνεύετε υπεύθυνα τα αυτοματοποιημένα αποτελέσματα

Μην ρωτάτε: Περάσαμε;

Κάντε καλύτερες ερωτήσεις:

• Ποιες κατηγορίες ζητημάτων μπορεί να ανιχνεύσει αυτό το εργαλείο;
• Ποια πρότυπα και ποιες καταστάσεις σάρωσε;
• Έτρεξε μετά από αλληλεπιδράσεις ή μόνο στην αρχική φόρτωση;
• Οι παραβιάσεις ομαδοποιούνται ανά βασική αιτία ή μετρώνται επαναλαμβανόμενα;
• Ποιες αποτυχίες εμποδίζουν τους χρήστες να ολοκληρώσουν εργασίες;
• Τι εξακολουθεί να απαιτεί χειροκίνητη αξιολόγηση;

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

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

Το πρακτικό πρότυπο: αυτοματοποιήστε το προφανές, ελέγξτε χειροκίνητα την εμπειρία

Οι καλύτερες ομάδες προσβασιμότητας δεν είναι κατά των εργαλείων. Είναι κατά της φαντασίωσης.

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

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

1. Προσθέστε αυτοματοποιημένους ελέγχους νωρίτερα στην ανάπτυξη.
2. Ελέγξτε χειροκίνητα με πληκτρολόγιο τις βασικές ροές.
3. Αξιολογήστε ονόματα, ετικέτες, σφάλματα και οδηγίες.
4. Δοκιμάστε κοινά components με αναγνώστη οθόνης.
5. Εντάξτε έλεγχο από ειδικούς και χρήστες για διαδρομές υψηλού κινδύνου.

Δεν είναι μια τέλεια διαδικασία. Είναι μια ρεαλιστική διαδικασία. Και θα βρει πολύ περισσότερα από όσα θα βρει ποτέ μια πράσινη βαθμολογία προσβασιμότητας.