Mengapa ujian kebolehcapaian automatik terlepas separuh daripada masalah anda

Kebenaran yang tidak selesa tentang ujian kebolehcapaian automatik

Ujian kebolehcapaian automatik ialah salah satu tabiat terbaik yang boleh dibina oleh pasukan web. Ia menangkap label borang yang hilang, teks berkontras rendah, ARIA yang tidak sah, ID pendua, butang kosong, dan kecacatan lain yang tidak sepatutnya sampai ke produksi.

Ia juga sering disalahfahami.

Laporan kebolehcapaian automatik yang lulus tidak bermakna halaman itu boleh dicapai. Ia bermakna alat tersebut tidak menemui subset masalah yang ia tahu cara mengesannya. Subset itu bernilai, tetapi terhad. Banyak kegagalan kebolehcapaian bergantung pada makna, susunan, niat, konteks, dan interaksi manusia. Perisian boleh memeriksa markup. Ia tidak boleh memahami dengan boleh dipercayai sama ada pengalaman itu berfungsi untuk seseorang yang menggunakan pembaca skrin, papan kekunci, pembesaran, kawalan suara, kapsyen, atau sokongan kognitif.

Inilah sebabnya dakwaan bahawa ujian automatik terlepas kira-kira separuh daripada masalah anda bukanlah sinis. Ia malah murah hati. Sesetengah kategori isu sangat boleh diautomasikan. Yang lain hampir tidak boleh diautomasikan langsung.

Jawapan praktikalnya bukan meninggalkan alat automatik. Jawapannya ialah meletakkannya di tempat yang betul: awal, kerap, dan sebagai sebahagian daripada aliran kerja ujian yang lebih luas.

Perkara yang ujian automatik lakukan dengan baik

Alat automatik sangat baik dalam mencari kegagalan deterministik. Jika sesuatu peraturan boleh dinyatakan sebagai syarat yang boleh dibaca mesin, pengimbas biasanya boleh menyemaknya dengan cepat dan konsisten.

Contoh biasa termasuk:

• Imej dengan atribut alt yang hilang
• Input borang tanpa label berkaitan
• Butang tanpa nama boleh dicapai
• Teks yang gagal melepasi ambang kontras
• Atribut atau peranan ARIA yang tidak sah
• Tahap tajuk yang dilangkau dengan cara yang mencurigakan
• Landmark yang hilang atau diduplikasi
• Pautan dengan nama boleh dicapai yang kosong
• Jadual tanpa struktur asas

Semakan ini wajar diautomasikan kerana manusia tidak bagus melakukan pemeriksaan berulang. Tiada siapa patut mengimbas setiap halaman secara manual untuk mencari label yang hilang jika alat boleh menangkapnya dalam milisaat.

Semakan automatik juga menjadikan kebolehcapaian lebih mudah dibincangkan dalam aliran kerja kejuruteraan. Ujian yang gagal dalam CI adalah konkrit. Amaran dalam pull request tepat pada masanya. Garis arah aliran merentas templat memberi pasukan sesuatu untuk diperbaik.

Masalah bermula apabila pasukan menganggap semakan ini sebagai bukti kebolehcapaian, bukannya bukti kebersihan asas.

Di mana automasi mula gagal

Kebolehcapaian bukan sekadar sifat kod. Ia ialah sifat penggunaan.

Alat boleh memberitahu anda sama ada imej mempunyai teks alt. Biasanya ia tidak boleh memberitahu anda sama ada teks alt itu berguna. Imej produk mungkin memerlukan huraian terperinci pada halaman produk, tiada huraian dalam hero hiasan, dan huraian yang sama sekali berbeza dalam artikel bantuan. Jawapan yang betul bergantung pada konteks. Itulah sebabnya pasukan memerlukan panduan editorial seperti pendekatan pragmatik terhadap teks alt imej, bukan hanya peraturan linter.

Masalah yang sama muncul di mana-mana.

Pengimbas mungkin mengesahkan bahawa setiap butang mempunyai nama boleh dicapai. Ia tidak selalu boleh memberitahu sama ada nama itu masuk akal. Halaman dengan lima butang bernama Submit mungkin lulus peraturan asas tetapi masih menyusahkan pengguna pembaca skrin. Modal mungkin mempunyai atribut ARIA yang betul tetapi memerangkap fokus dengan salah. Dropdown tersuai mungkin kelihatan patuh dalam markup statik dan gagal sebaik sahaja seseorang cuba menggunakannya dengan papan kekunci.

Automasi bergelut dengan soalan seperti:

• Adakah susunan fokus sepadan dengan susunan visual dan logik?
• Bolehkah setiap tugas diselesaikan dengan papan kekunci sahaja?
• Adakah mesej ralat khusus, tepat pada masanya, dan dikaitkan dengan medan?
• Adakah halaman masih berfungsi apabila teks diubah saiz atau dizum?
• Adakah susunan bacaan masuk akal untuk teknologi bantuan?
• Adakah arahan boleh difahami tanpa bergantung pada warna atau kedudukan?
• Adakah kapsyen, transkrip, dan label benar-benar menyampaikan kandungan?
• Adakah komponen berkelakuan boleh diramal merentas keadaan?

Ini bukan kes pinggiran. Ia adalah teras kepada kebolehcapaian.

Keselesaan palsu daripada skor tinggi

Skor kebolehcapaian menggoda kerana ia memampatkan subjek yang berserabut menjadi nombor. Papan pemuka menyatakan 98. Laporan menunjukkan tanda semak hijau. Keluaran terasa lebih selamat.

Tetapi skor hanya mengukur apa yang diukur oleh alat.

Ini serupa dengan ujian prestasi. Laporan Lighthouse boleh mendedahkan masalah penting, tetapi ia tidak sama seperti melihat pengguna sebenar bergelut melalui proses checkout yang perlahan pada telefon kelas pertengahan. Jika pasukan anda sudah menggunakan audit prestasi, pemikiran yang sama terpakai: baca laporan dengan teliti, kemudian utamakan dapatan yang menjejaskan pengguna sebenar. Kami telah menulis tentang perbezaan itu dalam cara membaca laporan Lighthouse tanpa panik.

Laporan kebolehcapaian memerlukan kekangan yang sama. Imbasan automatik yang bersih ialah titik permulaan. Ia bukan sijil.

Risikonya sangat tinggi apabila pasukan menjalankan imbasan hanya terhadap halaman statik. Antara muka moden mempunyai keadaan: menu dibuka, laci meluncur, toast muncul, mesej pengesahan dikemas kini, tab menukar panel, penapis menulis semula kandungan, dan pengesahan mengubah segala-galanya. Banyak kecacatan kebolehcapaian yang serius hidup dalam interaksi tersebut.

Jika pengimbas anda hanya melihat DOM awal, ia terlepas produk sebenar.

Kategori yang paling kerap terlepas

1. Tingkah laku papan kekunci dan fokus

Akses papan kekunci ialah salah satu contoh paling jelas mengapa automasi tidak mencukupi.

Alat boleh mengesan sama ada elemen boleh difokuskan. Ia mungkin menangkap nilai tabindex positif atau perangkap fokus yang jelas. Tetapi ia tidak boleh menilai dengan boleh dipercayai sama ada urutan tab terasa koheren, sama ada fokus bergerak ke tempat yang betul selepas sesuatu tindakan, atau sama ada komponen yang ditutup mengembalikan fokus kepada pencetus.

Anda memerlukan manusia untuk menekan Tab, Shift+Tab, Enter, Space, Escape, dan kekunci anak panah melalui aliran kerja sebenar.

Ini sangat penting untuk kawalan tersuai. Elemen HTML natif membawa bertahun-tahun tingkah laku kebolehcapaian secara percuma. Membina semula butang, select, checkbox, menu, dan dialog dengan div bermakna pasukan anda kini memiliki tingkah laku itu. Jika anda sedang menyemak komponen interaktif, mulakan dengan senarai semak pendek untuk butang web yang boleh dicapai dan perluaskan disiplin yang sama kepada setiap kawalan tersuai.

2. Nama dan huraian yang bermakna

Alat automatik boleh mengesan ketiadaan. Ia jauh lebih lemah dalam mengesan kualiti.

Pautan bernama Read more mungkin secara teknikal mempunyai nama boleh dicapai. Butang berlabel OK mungkin sah. Petunjuk borang mungkin wujud. Tetapi adakah semuanya bermakna dalam konteks? Selalunya tidak.

Nama boleh dicapai patut memberitahu pengguna apa yang akan berlaku atau apa yang diwakili oleh elemen tersebut. Itu memerlukan pertimbangan. Ia juga memerlukan ujian dengan antara muka, bukan hanya kod.

3. Pengendalian ralat

Borang penuh dengan kegagalan kebolehcapaian yang hanya sebahagiannya ditangkap oleh pengimbas.

Alat mungkin menandakan medan tanpa label. Ia mungkin tidak menangkap bahawa mesej pengesahan muncul terlalu lewat, hilang terlalu cepat, tidak diumumkan kepada pembaca skrin, atau menyatakan Invalid input sedangkan ia sepatutnya menyatakan Password must be at least 12 characters.

Pengendalian ralat yang baik ialah reka bentuk interaksi. Ia memerlukan ujian manual dan, sebaik-baiknya, ujian pengguna.

4. Penyesuaian visual

WCAG merangkumi keperluan sekitar pengubahan saiz teks, reflow, kontras, jarak, dan tidak bergantung pada satu isyarat deria. Sebahagiannya boleh disemak secara automatik, tetapi soalan sebenar ialah sama ada antara muka kekal boleh digunakan dalam keadaan yang berubah.

Cuba zum 200%. Cuba pengubahan saiz teks pelayar. Cuba mod kontras tinggi atau warna paksa. Cuba lebar viewport yang sempit. Cuba gerakan dikurangkan. Banyak laman yang kelihatan kemas pada tetapan lalai cepat rosak apabila pengguna menegaskan keutamaan mereka.

5. Kejelasan kandungan

Tiada alat kebolehcapaian automatik boleh menilai sepenuhnya sama ada kandungan boleh difahami.

Ia boleh menandakan tajuk yang hilang atau teks pautan yang kabur. Ia tidak boleh tahu sama ada halaman menerangkan proses dengan jelas, sama ada label sepadan dengan jangkaan pengguna, atau sama ada salinan yang padat mewujudkan beban kognitif yang boleh dielakkan.

Kebolehcapaian bukan hanya tentang keserasian teknologi bantuan. Ia juga tentang mengurangkan geseran untuk orang yang berada dalam tekanan, menggunakan bahasa yang tidak biasa, berdepan kekangan perhatian, atau menavigasi tugas yang kompleks.

Aliran kerja ujian yang lebih baik

Aliran kerja kebolehcapaian yang seimbang mempunyai lapisan.

Jalankan semakan automatik secara berterusan

Gunakan ujian automatik dalam pembangunan, pull request, pratonton komponen, dan CI. Ia patut membosankan, pantas, dan tidak boleh dirunding. Label baharu yang hilang dan ARIA yang tidak sah tidak sepatutnya memerlukan audit suku tahunan untuk ditemui.

Anggap kegagalan ini seperti kegagalan linting. Matlamatnya bukan kepahlawanan; matlamatnya ialah mencegah regresi.

Tambahkan ujian papan kekunci manual

Untuk setiap aliran pengguna yang bermakna, uji tanpa tetikus. Ini termasuk navigasi, carian, penciptaan akaun, checkout, penapisan, modal, menu, dan penghantaran borang.

Sekurang-kurangnya, sahkan:

• Setiap elemen interaktif boleh dicapai
• Fokus kelihatan pada setiap masa
• Susunan fokus adalah logik
• Kekunci yang dijangka berfungsi
• Escape menutup tindihan yang boleh ditutup
• Fokus diurus selepas membuka dan menutup komponen
• Tiada perangkap papan kekunci wujud

Tabiat tunggal ini menangkap banyak kelas isu yang terlepas oleh imbasan automatik.

Uji dengan sekurang-kurangnya satu pembaca skrin

Anda tidak perlu menjadi pengguna pembaca skrin pakar untuk mempelajari perkara berguna. Anda memang memerlukan kerendahan hati. Ujian pembaca skrin mempunyai keluk pembelajaran, dan pemula boleh tersilap mendiagnosis masalah.

Namun begitu, ujian asas dengan VoiceOver, NVDA, atau JAWS boleh mendedahkan nama yang rosak, susunan bacaan yang mengelirukan, kemas kini yang tidak diumumkan, dan masalah landmark yang mungkin tidak ditangkap oleh pengimbas.

Padankan ini dengan HTML semantik. Semakin banyak elemen natif yang anda gunakan, semakin kurang rapuh kebolehcapaian anda.

Semak kandungan dan keadaan

Semak keadaan kosong, keadaan memuat, keadaan ralat, keadaan dilumpuhkan, mesej berjaya, dan kegagalan kebenaran. Pepijat kebolehcapaian sering bersembunyi di luar laluan lancar.

Semak juga perkataan sebenar. Label, tajuk, arahan, dan mesej ralat ialah sebahagian daripada antara muka.

Libatkan pengguna kurang upaya apabila pertaruhannya tinggi

Untuk aliran kritikal, semakan pakar manual tidak mencukupi. Ujian pengguna dengan peserta kurang upaya menemui masalah yang tidak dijangka oleh pasukan. Ini amat penting untuk perkhidmatan awam, penjagaan kesihatan, kewangan, pendidikan, dan sebarang aliran yang pengecualian membawa akibat serius.

Ujian automatik boleh diskalakan. Ujian manusia memahami.

Cara mentafsir keputusan automatik secara bertanggungjawab

Jangan tanya, Adakah kita lulus?

Tanya soalan yang lebih baik:

• Kategori isu apa yang boleh dikesan oleh alat ini?
• Templat dan keadaan mana yang diimbas?
• Adakah ia berjalan selepas interaksi, atau hanya pada pemuatan awal?
• Adakah pelanggaran dikumpulkan mengikut punca akar atau dikira berulang kali?
• Kegagalan mana yang menghalang pengguna daripada menyelesaikan tugas?
• Apa yang masih memerlukan semakan manual?

Pembingkaian ini mengubah perbualan. Alat automatik menjadi bukti, bukan autoriti.

Ia juga membantu pasukan mengelakkan kerja sibuk. Membetulkan satu komponen boleh menghapuskan ratusan pelanggaran berulang. Sebaliknya, halaman dengan hanya satu isu yang dilaporkan mungkin masih mengandungi perangkap papan kekunci yang teruk. Kiraan bukan impak.

Piawaian praktikal: automasikan yang jelas, uji pengalaman secara manual

Pasukan kebolehcapaian terbaik bukan anti-alat. Mereka anti-fantasi.

Mereka mengautomasikan perkara yang boleh dikesan mesin dengan boleh dipercayai. Mereka menguji secara manual perkara yang bergantung pada tingkah laku dan makna. Mereka menggunakan piawaian seperti WCAG sebagai garis dasar bersama, bukan sebagai pengganti kepada penggunaan produk.

Jika proses semasa anda hanyalah imbasan automatik sebelum pelancaran, perbaikannya dalam urutan ini:

1. Tambahkan semakan automatik lebih awal dalam pembangunan.
2. Uji aliran teras secara manual dengan papan kekunci.
3. Semak nama, label, ralat, dan arahan.
4. Uji komponen biasa dengan pembaca skrin.
5. Libatkan ujian pakar dan pengguna untuk perjalanan berisiko tinggi.

Itu bukan proses yang sempurna. Ia proses yang realistik. Dan ia akan menemui jauh lebih banyak daripada apa yang pernah diberikan oleh skor kebolehcapaian hijau.