Pengujian aksesibilitas otomatis

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

Di modul lainnya, kami beralih dari mendesain dan membangun ke pengujian untuk aksesibilitas. Kita akan menggunakan proses pengujian tiga langkah yang mencakup alat dan teknik pengujian teknologi otomatis, manual, dan pendukung. Kita akan gunakan demo yang sama di seluruh modul pengujian ini untuk mengembangkan halaman web dari tidak dapat diakses dan diakses.

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

Pengujian kami didasarkan pada Pedoman Aksesibilitas Konten Web (WCAG) 2.1 tingkat kesesuaian A dan AA sebagaimana standar. Ingatlah bahwa industri, tipe produk, hukum setempat/negara dan kebijakan, atau tujuan aksesibilitas keseluruhan akan menentukan pedoman mana yang diikuti dan level yang harus dipenuhi. Jika Anda tidak memerlukan standar khusus untuk proyek, rekomendasinya adalah mengikuti WCAG versi terbaru. Lihat kembali "Bagaimana cara pengukuran aksesibilitas digital?" untuk informasi umum tentang audit aksesibilitas, jenis/tingkat kesesuaian, WCAG, dan POUR.

Seperti yang Anda ketahui, kesesuaian aksesibilitas bukanlah cerita lengkap ketika untuk mendukung para difabel. 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 tes {i>usability<i} dengan penyandang disabilitas, mempekerjakan orang-orang dengan disabilitas untuk bekerja dalam tim Anda, atau berkonsultasi dengan individu atau perusahaan dengan 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 aksesibilitas terhadap standar kesesuaian aksesibilitas yang telah ditentukan sebelumnya.

Kelebihan pengujian aksesibilitas otomatis:

• Pengujian ulang yang mudah pada berbagai tahap siklus hidup produk
• Tinggal beberapa langkah lagi dan hasilnya sangat cepat
• Sedikit pengetahuan aksesibilitas diperlukan untuk menjalankan pengujian atau memahami hasilnya

Kekurangan pengujian aksesibilitas otomatis:

• Alat otomatis tidak mendeteksi semua error aksesibilitas dalam produk Anda
• Positif palsu yang dilaporkan (masalah yang dilaporkan 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 apakah situs atau aplikasi Anda aksesibilitas, tetapi tidak semua pemeriksaan bisa 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 yang pertama dikembangkan di tahun 1996 oleh Pusat untuk Teknologi Khusus Terapan (CAST), yang disebut "Laporan Bobby." Saat ini, terdapat lebih dari 100 alat pengujian otomatis untuk dipilih dari!

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

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

• Standar dan tingkat kesesuaian mana yang Anda uji? Hal ini mungkin termasuk WCAG 2.1, WCAG 2.0, US. Pasal 508, atau daftar aturan aksesibilitas yang dimodifikasi.
• Jenis produk digital apa yang Anda uji? Dapat berupa situs web, web aplikasi, aplikasi seluler native, PDF, kios, atau produk lain.
• Bagian mana dari siklus hidup pengembangan perangkat lunak yang digunakan untuk menguji produk Anda?
• Berapa lama waktu yang diperlukan untuk menyiapkan dan menggunakan alat ini? Untuk individu, tim, atau perusahaan?
• Siapa yang melakukan tes: desainer, pengembang, QA, dll.?
• Seberapa sering Anda ingin memeriksa aksesibilitas? Detail apa yang harus disertakan dalam laporan? Apakah permasalahan terkait langsung dengan proses penjualan tiket sistem operasi?
• Alat apa yang paling cocok di lingkungan Anda? Untuk tim Anda?

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

Demo: Pengujian otomatis

Untuk demo pengujian aksesibilitas otomatis, kita akan menggunakan Mercusuar. Lighthouse adalah alat sumber terbuka otomatis yang dibuat untuk meningkatkan kualitas laman web melalui berbagai jenis audit, seperti kinerja, SEO, dan aksesibilitas.

Demo kami adalah situs yang dibuat untuk organisasi buatan, yakni Medical Mysteries Klub. Situs ini sengaja dibuat tidak dapat diakses untuk demo. Beberapa di antaranya aksesibilitas mungkin terlihat oleh Anda, dan beberapa (tetapi tidak semua) akan terjebak pengujian otomatis kami.

Langkah 1

Menggunakan browser Chrome, instal Ekstensi Lighthouse.

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

Langkah 2

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

Langkah 3

Buka Chrome DevTools dan arahkan ke tab Lighthouse. Hapus centang semua opsi kategori kecuali "Aksesibilitas." Biarkan mode sebagai default dan pilih jenis perangkat yang Anda untuk menjalankan pengujian.

Langkah 4

Klik bagian "Analisis pemuatan halaman" dan memberi Lighthouse waktu untuk menjalankan pengujiannya.

Setelah pengujian selesai, Lighthouse menampilkan skor yang mengukur dapat diakses dari produk yang Anda uji. Tujuan Skor Lighthouse dihitung dari jumlah masalah, jenis masalah, dan dampaknya terhadap pengguna masalah yang terdeteksi.

Selain skor, laporan Lighthouse menyertakan informasi rinci tentang apa yang masalah yang telah dideteksi dan tautan ke referensi untuk mempelajari lebih lanjut cara memperbaikinya mereka. Laporan ini juga mencakup pengujian yang lulus atau tidak berlaku, dan daftar item tambahan yang harus diperiksa secara manual.

Langkah 5

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

Masalah 1: Peran ARIA

Masalah pertama menyatakan: "Elemen dengan [peran] ARIA yang mewajibkan anak-anak untuk berisi [peran] tertentu tidak memiliki beberapa atau semua turunan yang diperlukan. Beberapa peran induk ARIA harus berisi peran turunan tertentu agar dapat menjalankan perannya 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.

"Berlangganan" tombol di samping kolom masukan memiliki peran ARIA yang salah yang diterapkan padanya. 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. Dapat difokuskan turunan dalam elemen [aria-hidden="true"] mencegah elemen elemen yang tidak tersedia bagi pengguna teknologi alat bantu seperti pembaca. Pelajari aria-hidden aturan 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 ke kolom tersebut. Menambahkan atribut ini menyembunyikan elemen (dan segala sesuatu yang ada di bawahnya) dari teknologi asistif/bantuan.

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

Dalam hal ini, Anda harus menghapus atribut ini dari input untuk memungkinkan orang menggunakan {i>assistive technology<i} untuk mengakses dan memasukkan informasi ke dalam bidang formulir.

Masalah 3: Nama tombol

Tombol tidak memiliki label aksesibilitas. Bila tombol tidak memiliki nama yang mudah diakses, pembaca layar akan mengucapkannya sebagai "{i>button<i}," sehingga tidak dapat digunakan untuk pengguna yang mengandalkan pembaca layar (screen reader). 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 di masalah 1, kata "Berlangganan" menjadi tombol yang dapat diakses nama. Fungsi ini di-build ke dalam elemen tombol HTML semantik. Ada adalah 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 mengarah untuk teks alternatif yang deskriptif dan singkat. Elemen dekoratif dapat diabaikan dengan atribut alt kosong. Pelajari teks alternatif gambar lebih lanjut aturan.

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

Mari kita perbaiki.

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

<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 tautan (dan teks alternatif untuk gambar, saat digunakan sebagai link) yang terlihat jelas, unik, dan dapat difokuskan meningkatkan pengalaman navigasi yang baik 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 tersebut harus menyertakan informasi tentang posisi tautan akan mengirim pengguna. Salah satu metode untuk mengatasi masalah ini adalah dengan menambahkan ke gambar tentang tujuannya, seperti yang Anda lakukan pada gambar logo di contoh di atas. Ini berfungsi dengan baik untuk gambar yang menggunakan tag <img>, tetapi <svg> tag tidak dapat menggunakan metode ini.

Untuk ikon media sosial, yang menggunakan tag <svg>, Anda dapat menggunakan pola deskripsi alternatif yang berbeda menargetkan SVG, tambahkan informasi antara tag <a> dan <svg>, lalu menyembunyikannya secara visual dari pengguna, menambahkan ARIA yang didukung, atau opsi lainnya. Bergantung terhadap batasan kode dan lingkungan Anda, satu metode mungkin lebih disukai daripada lain. Mari kita gunakan opsi pola yang paling sederhana dengan cakupan teknologi, yaitu menambahkan role="img" ke tag <svg> dan termasuk 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.

Dua contoh telah dilaporkan.

Mari kita perbaiki.

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

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

Dalam hal ini, kita bisa menemukan warna hijau kebiruan yang cukup gelap untuk memenuhi 4,5:1, atau kita bisa meningkatkan ukuran teks tombol menjadi 18,5px {i>bold<i} dan mengubah nilai warna hijau kebiruan. Metode mana pun akan tetap sesuai dengan desain estetika.

Semua teks abu-abu pada latar belakang putih juga gagal dalam kontras warna, kecuali untuk dua judul terbesar pada halaman. Teks ini harus digelapkan untuk 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 induk <ul> atau <ol> akan diumumkan 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.

Kita menggunakan class CSS dalam demo ini untuk menyimulasikan daftar yang tidak diurutkan, menggunakan tag <ul>. Jika kita menulis kode ini dengan tidak benar, kita menghapus atribut fitur HTML semantik yang di-build ke dalam tag ini. Dengan mengganti class dengan <ul> dan mengubah CSS terkait, kita akan 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 yang eksplisit. Meskipun secara teknis valid, hal ini sering menciptakan pengalaman yang menjengkelkan bagi pengguna yang mengandalkan teknologi pendukung. Pelajari aturan tabindex lebih lanjut.

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

Mari kita perbaiki.

Kecuali ada alasan tertentu untuk mengganggu urutan tabulasi alami di web halaman, tidak perlu memiliki bilangan bulat positif pada atribut tabindex. Kepada mempertahankan urutan tab alami, kita dapat mengubah tabindex menjadi 0 atau menghapus atribut sepenuhnya.

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

Langkah 6

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

Kami telah menerapkan semua pembaruan aksesibilitas otomatis ini ke CodePen.

Langkah berikutnya

Anda hebat. Anda telah mencapai banyak hal, tetapi kita belum selesai! Berikutnya kita akan beralih ke pemeriksaan manual, seperti yang dijelaskan modul pengujian aksesibilitas manual.

Menguji pemahaman Anda

Uji pengetahuan Anda tentang pengujian aksesibilitas otomatis