Pengujian aksesibilitas otomatis

Sejauh ini, Anda telah belajar tentang aspek individu, bisnis, dan hukum dari aksesibilitas digital, dan dasar-dasar kesesuaian aksesibilitas digital. Anda telah mempelajari topik tertentu yang terkait dengan desain dan coding inklusif, termasuk kapan harus menggunakan ARIA versus HTML, cara mengukur kontras warna, ketika JavaScript sangat penting, di antara topik lainnya.

Pada modul lainnya, kami beralih dari mendesain dan mem-build ke pengujian untuk aksesibilitas. Kita akan menggunakan proses pengujian tiga langkah yang mencakup alat dan teknik pengujian teknologi otomatis, manual, dan asistif. Kita akan menggunakan demo yang sama di seluruh modul pengujian ini untuk mengembangkan halaman web dari tidak dapat diakses menjadi dapat diakses.

Setiap pengujian—teknologi otomatis, manual, dan asistif—sangat penting untuk mencapai produk yang paling mudah diakses.

Pengujian kami mengandalkan Web Content Accessibility Guidelines (WCAG) 2.1 tingkat kesesuaian A dan AA sebagai standar kami. Ingatlah bahwa industri, jenis produk, hukum dan kebijakan setempat/negara, atau tujuan aksesibilitas secara keseluruhan akan menentukan panduan mana yang harus diikuti dan level yang harus dipenuhi. Jika Anda tidak memerlukan standar tertentu untuk project, sebaiknya ikuti versi terbaru WCAG. Lihat kembali "Bagaimana aksesibilitas digital diukur?" untuk informasi umum tentang audit aksesibilitas, jenis/level kesesuaian, WCAG, dan POUR.

Seperti yang sekarang Anda ketahui, kesesuaian aksesibilitas bukanlah cerita lengkap untuk mendukung penyandang disabilitas. Tapi, ini adalah titik awal yang baik karena menyediakan metrik yang dapat Anda uji. Sebaiknya Anda mengambil tindakan tambahan di luar pengujian kesesuaian aksesibilitas, seperti menjalankan uji kegunaan dengan difabel, mempekerjakan penyandang disabilitas untuk bekerja di tim Anda, atau berkonsultasi dengan individu atau perusahaan yang memiliki keahlian aksesibilitas digital untuk membantu Anda membuat produk yang lebih inklusif.

Dasar-dasar pengujian otomatis

Pengujian aksesibilitas otomatis menggunakan software untuk memindai produk digital Anda guna menemukan masalah aksesibilitas berdasarkan standar kesesuaian aksesibilitas yang telah ditetapkan.

Kelebihan pengujian aksesibilitas otomatis:

• Pengujian yang mudah diulang pada berbagai tahap siklus hidup produk
• Hanya beberapa langkah untuk dijalankan dan hasil yang sangat cepat
• Sedikit pengetahuan aksesibilitas diperlukan untuk menjalankan pengujian atau memahami hasilnya

Kekurangan pengujian aksesibilitas otomatis:

• Alat otomatis tidak menangkap semua kesalahan aksesibilitas di produk Anda
• Positif palsu yang dilaporkan (masalah yang dilaporkan yang bukan pelanggaran WCAG yang sebenarnya)
• Beberapa alat mungkin diperlukan untuk jenis dan peran produk yang berbeda

Pengujian otomatis adalah langkah pertama yang bagus untuk memeriksa aksesibilitas situs atau aplikasi Anda, tetapi tidak semua pemeriksaan dapat diotomatiskan. Kita akan membahas lebih detail tentang cara memeriksa aksesibilitas elemen yang tidak dapat diotomatiskan dalam modul pengujian aksesibilitas manual.

Jenis alat otomatis

Salah satu alat pengujian aksesibilitas otomatis online pertama dikembangkan pada 1996 oleh Center for Applied Special Technology (CAST), bernama "The Bobby Report". Saat ini, ada lebih dari 100 alat pengujian otomatis yang dapat dipilih.

Penerapan alat otomatis bervariasi mulai dari ekstensi browser aksesibilitas hingga linter kode, aplikasi desktop dan seluler, dasbor online, dan bahkan API open source yang dapat Anda gunakan untuk mem-build alat otomatis Anda sendiri.

Alat otomatis yang Anda gunakan dapat bergantung pada banyak faktor, termasuk:

• Standar dan level kesesuaian manakah yang Anda uji? Ini dapat mencakup WCAG 2.1, WCAG 2.0, U.S. Pasal 508, atau daftar aturan aksesibilitas yang diubah.
• Jenis produk digital apa yang Anda uji? Produk ini dapat berupa situs, aplikasi web, aplikasi seluler native, PDF, kios, atau produk lainnya.
• Di siklus hidup pengembangan perangkat lunak, bagian manakah yang Anda gunakan untuk menguji produk?
• Berapa lama waktu yang diperlukan untuk menyiapkan dan menggunakan alat tersebut? Untuk individu, tim, atau perusahaan?
• Siapa yang melakukan tes: desainer, pengembang, QA, dll.?
• Seberapa sering Anda ingin aksesibilitas diperiksa? Detail apa yang harus disertakan dalam laporan? Haruskah masalah dihubungkan langsung ke sistem tiket?
• Alat apa yang paling cocok di lingkungan Anda? Untuk tim Anda?

Ada banyak faktor tambahan yang juga perlu dipertimbangkan. Lihat artikel WAI tentang "Memilih Alat Evaluasi Aksesibilitas Web" untuk mengetahui informasi selengkapnya tentang cara memilih alat terbaik untuk Anda dan tim.

Demo: Pengujian otomatis

Untuk demo pengujian aksesibilitas otomatis, kita akan menggunakan Lighthouse Chrome. Lighthouse adalah alat open source otomatis yang dibuat untuk meningkatkan kualitas halaman web melalui berbagai jenis audit, seperti performa, SEO, dan aksesibilitas.

Demo kami adalah situs yang dibuat untuk organisasi buatan, Medical Mysteries Club. Situs ini sengaja dibuat tidak dapat diakses untuk demo. Sebagian tidak dapat diakses ini mungkin terlihat oleh Anda, dan beberapa (tetapi tidak semua) akan terperangkap dalam pengujian otomatis kami.

Langkah 1

Menggunakan browser Chrome, instal ekstensi Lighthouse.

Ada banyak cara untuk mengintegrasikan Lighthouse ke dalam alur kerja pengujian Anda. Kita akan menggunakan ekstensi Chrome untuk demo ini.

Langkah 2

Kami telah membuat demo di CodePen. Tampilkan dalam mode debug untuk melanjutkan pengujian berikutnya. Hal ini penting karena menghapus <iframe> yang mengelilingi halaman web demo, yang dapat mengganggu beberapa alat pengujian. Pelajari lebih lanjut mode debug CodePen.

Langkah 3

Buka Chrome DevTools dan buka tab Lighthouse. Hapus centang semua opsi kategori kecuali "Aksesibilitas". Tetap gunakan mode ini sebagai default dan pilih jenis perangkat tempat Anda menjalankan pengujian.

Langkah 4

Klik tombol "Analisis pemuatan halaman" dan beri Lighthouse waktu untuk menjalankan pengujiannya.

Setelah pengujian selesai, Lighthouse akan menampilkan skor yang mengukur seberapa dapat diakses produk yang Anda uji. Skor Lighthouse dihitung berdasarkan jumlah masalah, jenis masalah, dan dampak pada pengguna masalah yang terdeteksi.

Selain skor, laporan Lighthouse menyertakan informasi mendetail tentang masalah yang telah terdeteksi dan link ke berbagai referensi untuk mempelajari lebih lanjut cara memperbaikinya. Laporan ini juga berisi pengujian yang lulus atau tidak berlaku dan daftar item tambahan untuk diperiksa secara manual.

Langkah 5

Sekarang, mari kita lihat contoh setiap masalah aksesibilitas otomatis yang ditemukan dan memperbaiki gaya dan markup yang relevan.

Masalah 1: Peran ARIA

Masalah pertama menyatakan: "Elemen dengan [peran] ARIA yang mengharuskan turunan berisi [peran] tertentu tidak memiliki beberapa atau semua turunan yang diperlukan. Beberapa peran induk ARIA harus berisi peran turunan tertentu untuk menjalankan fungsi aksesibilitas yang diinginkan." Pelajari lebih lanjut aturan peran ARIA.

Dalam demo kami, tombol berlangganan newsletter gagal:

<button role="list" type="submit" tabindex="1">Subscribe</button>

Mari kita perbaiki.

Tombol "berlangganan" di samping kolom input menerapkan peran ARIA yang salah. Dalam hal ini, peran tersebut dapat dihapus sepenuhnya.

<button type="submit" tabindex="1">Subscribe</button>

Masalah 2: ARIA disembunyikan

Elemen "[aria-hidden="true"] berisi turunan yang dapat difokuskan. Turunan yang dapat difokuskan dalam elemen [aria-hidden="true"] mencegah elemen interaktif tersebut tersedia bagi pengguna teknologi pendukung seperti pembaca layar. Pelajari aturan aria-hidden lebih lanjut.

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>

Mari kita perbaiki.

Kolom input memiliki atribut aria-hidden="true" yang diterapkan. Menambahkan atribut ini akan menyembunyikan elemen (dan semua yang bertingkat di bawahnya) dari teknologi pendukung.

<input type="email" placeholder="Enter your e-mail address" tabindex="-1" required>

Dalam hal ini, Anda harus menghapus atribut ini dari input untuk mengizinkan orang yang menggunakan teknologi pendukung mengakses dan memasukkan informasi ke kolom formulir.

Masalah 3: Nama tombol

Tombol tidak memiliki nama yang dapat diakses. Jika tombol tidak memiliki nama yang dapat diakses, pembaca layar akan mengucapkannya sebagai "tombol", sehingga tidak dapat digunakan oleh pengguna yang mengandalkan pembaca layar. Pelajari aturan nama tombol lebih lanjut.

<button role="list" type="submit" tabindex="1">Subscribe</button>

Mari kita perbaiki.

Jika Anda menghapus peran ARIA yang tidak akurat dari elemen tombol pada masalah 1, kata "Berlangganan" akan menjadi nama tombol yang dapat diakses. Fungsi ini dibangun ke dalam elemen tombol HTML semantik. Ada opsi pola tambahan yang perlu dipertimbangkan untuk situasi yang lebih kompleks.

<button type="submit" tabindex="1">Subscribe</button>

Masalah 4: Atribut alt gambar

Elemen gambar tidak memiliki atribut [alt]. Elemen informatif harus memberikan teks alternatif yang singkat dan deskriptif. Elemen dekoratif dapat diabaikan dengan atribut alt kosong. Pelajari aturan teks alternatif gambar lebih lanjut.

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png">
</a>

Mari kita perbaiki.

Karena gambar logo juga merupakan link, Anda tahu dari modul gambar bahwa gambar ini disebut gambar yang dapat ditindaklanjuti dan memerlukan informasi teks alternatif tentang tujuan gambar tersebut. Biasanya, gambar pertama di halaman adalah logo, sehingga Anda dapat berasumsi bahwa pengguna AT akan mengetahui hal ini, dan Anda dapat memutuskan untuk tidak menambahkan informasi kontekstual tambahan ini ke deskripsi gambar.

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png"
    alt="Go to the home page.">
</a>

Masalah 5: Teks link

Link tidak memiliki nama yang jelas. Teks link (dan teks alternatif untuk gambar, saat digunakan sebagai link) yang terlihat, unik, dan dapat difokuskan akan meningkatkan pengalaman navigasi bagi pengguna pembaca layar. Pelajari aturan teks link lebih lanjut.

<a href="#!"><svg><path>...</path></svg></a>

Mari kita perbaiki.

Semua gambar yang dapat ditindaklanjuti di halaman harus menyertakan informasi tentang tujuan link akan mengarahkan pengguna. Salah satu metode untuk memperbaiki masalah ini adalah dengan menambahkan teks alternatif ke gambar tentang tujuan tersebut, seperti yang Anda lakukan pada gambar logo pada contoh di atas. Ini berfungsi sangat baik untuk gambar yang menggunakan tag <img>, tetapi tag <svg> tidak dapat menggunakan metode ini.

Untuk ikon media sosial, yang menggunakan tag <svg>, Anda dapat menggunakan pola deskripsi alternatif yang berbeda yang menargetkan SVG, menambahkan informasi antara tag <a> dan <svg>, lalu menyembunyikannya secara visual dari pengguna, menambahkan ARIA yang didukung, atau opsi lainnya. Bergantung pada lingkungan dan pembatasan kode Anda, satu metode mungkin lebih disukai daripada yang lain. Mari kita gunakan opsi pola paling sederhana dengan cakupan teknologi yang paling asistif, yaitu menambahkan role="img" ke tag <svg> dan menyertakan elemen <title>.

<a href="#!">
  <svg role="img">
    <title>Connect on our Twitter page.</title>
    <path>...</path>
  </svg>
</a>

Masalah 6: Kontras warna

Warna latar belakang dan latar depan tidak memiliki rasio kontras yang memadai. Teks yang memiliki kontras rendah akan sulit atau tidak mungkin dibaca oleh kebanyakan pengguna. Pelajari aturan kontras warna lebih lanjut.

Ada dua contoh yang dilaporkan.

Mari kita perbaiki.

Ada banyak masalah kontras warna yang terdeteksi di halaman web. Seperti yang Anda pelajari dalam modul warna dan kontras, teks berukuran biasa (kurang dari 18 pt / 24 piksel) memiliki persyaratan kontras warna 4,5:1, sedangkan teks berukuran besar (setidaknya 18 pt / 24 piksel atau 14 pt / 18,5 piksel) dan ikon penting harus memenuhi persyaratan 3:1.

Untuk judul halaman, teks berwarna hijau kebiruan harus memenuhi persyaratan kontras warna 3:1 karena merupakan teks berukuran besar, yaitu 24 piksel. Namun, tombol hijau kebiruan dianggap teks berukuran biasa dengan ketebalan 16 piksel, sehingga harus memenuhi persyaratan kontras warna 4,5:1.

Dalam hal ini, kita dapat menemukan warna hijau kebiruan yang cukup gelap untuk mencapai 4,5:1, atau kita dapat meningkatkan ukuran teks tombol menjadi 18,5 piksel tebal dan mengubah nilai warna hijau kebiruan sedikit. Kedua metode tersebut akan tetap sesuai dengan estetika desain.

Semua teks abu-abu pada latar belakang putih juga gagal mendapatkan kontras warna, kecuali untuk dua judul terbesar di halaman. Teks ini harus digelapkan agar memenuhi persyaratan kontras warna 4,5:1.

Masalah #7 - struktur daftar

Item daftar (<li>) tidak dimuat dalam elemen induk <ul> atau <ol>. Pembaca layar mengharuskan item daftar (<li>) untuk dimuat dalam <ul> atau <ol> induk agar dapat diucapkan dengan benar.

Pelajari aturan daftar lebih lanjut.

<div class="ul">
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</div>

Mari kita perbaiki.

Kami menggunakan class CSS dalam demo ini untuk menyimulasikan daftar yang tidak diurutkan, bukan menggunakan tag <ul>. Jika menulis kode ini dengan tidak benar, kami menghapus fitur HTML semantik yang melekat pada tag ini. Dengan mengganti class dengan tag <ul> asli dan mengubah CSS terkait, kami menyelesaikan masalah aksesibilitas ini.

<ul>
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</ul>

Masalah #8 - tabindex

Beberapa elemen memiliki nilai [tabindex] yang lebih besar dari 0. Nilai yang lebih besar dari 0 menyiratkan pengurutan navigasi secara eksplisit. Meskipun secara teknis valid, hal ini sering menciptakan pengalaman yang menjengkelkan bagi pengguna yang mengandalkan teknologi alat bantu. Pelajari aturan tabindex lebih lanjut.

<button type="submit" tabindex="1">Subscribe</button>

Mari kita perbaiki.

Kecuali ada alasan khusus untuk mengganggu urutan tab alami di halaman web, Anda tidak perlu memiliki bilangan bulat positif di atribut tabindex. Untuk mempertahankan urutan tab yang alami, kita dapat mengubah tabindex menjadi 0 atau menghapus atribut sekaligus.

<button type="submit">Subscribe</button>

Langkah 6

Setelah Anda memperbaiki semua masalah aksesibilitas otomatis, buka halaman mode debug baru. Jalankan audit aksesibilitas Lighthouse lagi. Skor Anda harus jauh lebih baik daripada saat pertama kali dijalankan.

Kami telah menerapkan semua update aksesibilitas otomatis ini ke CodePen baru.

Langkah berikutnya

Anda hebat. Anda telah mencapai banyak hal, tapi kita belum menyelesaikannya! Selanjutnya, kita akan beralih ke pemeriksaan manual, seperti yang dijelaskan dalam modul pengujian aksesibilitas manual.

Menguji pemahaman Anda

Uji pengetahuan Anda tentang pengujian aksesibilitas otomatis