Pengujian aksesibilitas otomatis

Sejauh ini dalam kursus ini, Anda telah mempelajari aspek individu, bisnis, dan hukum terkait aksesibilitas digital, serta 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, kapan JavaScript penting, dan topik lainnya.

Dalam modul yang tersisa, kita akan beralih dari desain dan pembuatan ke pengujian aksesibilitas. Kami akan membagikan proses pengujian tiga langkah yang mencakup alat dan teknik pengujian otomatis, manual, dan teknologi pendukung. Kita akan menggunakan demo yang sama di seluruh modul pengujian ini untuk meningkatkan kualitas halaman web dari tidak dapat diakses menjadi dapat diakses.

Setiap pengujian, baik otomatis, manual, maupun teknologi pendukung, sangat penting untuk mencapai produk yang paling mudah diakses. Pengujian kami mengandalkan Panduan Aksesibilitas Konten Web (WCAG) 2.1 tingkat kesesuaian A dan AA sebagai standar kami.

Ingatlah bahwa industri, jenis produk, hukum dan kebijakan lokal dan negara, atau sasaran aksesibilitas secara keseluruhan akan menentukan panduan yang harus diikuti dan tingkat yang harus dipenuhi. Jika Anda tidak memerlukan standar tertentu untuk project, sebaiknya ikuti WCAG versi terbaru. Lihat kembali "Bagaimana aksesibilitas digital diukur?" untuk mengetahui informasi umum tentang audit aksesibilitas, jenis/tingkat kesesuaian, WCAG, dan POUR.

Seperti yang Anda ketahui, kesesuaian aksesibilitas bukan satu-satunya hal yang perlu diperhatikan saat mendukung penyandang disabilitas. Namun, ini adalah titik awal yang baik karena memberikan metrik yang dapat Anda gunakan untuk pengujian. Sebaiknya lakukan tindakan berikut selain pengujian kesesuaian, untuk membantu Anda membuat produk yang lebih inklusif:

• Jalankan pengujian kegunaan dengan penyandang disabilitas.
• Rekrut penyandang disabilitas untuk bekerja di tim Anda.
• Konsultasikan dengan individu atau perusahaan yang memiliki keahlian aksesibilitas digital.

Dasar-dasar pengujian otomatis

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

Keuntungan pengujian aksesibilitas otomatis:

• Mengulang pengujian dengan cepat pada berbagai tahap siklus proses produk.
• Hanya perlu beberapa langkah untuk menjalankan pengujian dan hasilnya sangat cepat.
• Tidak memerlukan banyak pengetahuan tentang aksesibilitas untuk menjalankan pengujian atau memahami hasilnya.

Kekurangan pengujian aksesibilitas otomatis:

• Alat otomatis tidak menangkap semua error aksesibilitas dalam produk Anda
• Positif palsu yang dilaporkan (masalah dilaporkan yang bukan pelanggaran WCAG yang sebenarnya)
• Mungkin diperlukan beberapa alat untuk berbagai jenis dan peran produk

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 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 tahun 1996 oleh Center for Applied Special Technology (CAST), yang disebut "The Bobby Report." Saat ini, ada lebih dari 100 alat pengujian otomatis yang dapat dipilih dari.

Implementasi 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 membuat alat otomatis Anda sendiri.

Alat otomatis yang Anda putuskan untuk digunakan dapat bergantung pada banyak faktor, termasuk:

• Standar dan tingkat kesesuaian mana yang Anda gunakan untuk pengujian? Hal ini dapat mencakup WCAG 2.2, WCAG 2.1, Section 508 AS, atau daftar aturan aksesibilitas yang dimodifikasi.
• Jenis produk digital apa yang Anda uji? Produk digital ini dapat berupa situs, aplikasi web, aplikasi seluler native, PDF, kios, atau produk lainnya.
• Bagian mana dari siklus proses pengembangan software yang Anda gunakan untuk menguji produk Anda?
• Berapa lama waktu yang diperlukan untuk menyiapkan dan menggunakan alat? Untuk individu, tim, atau perusahaan?
• Siapa yang melakukan pengujian: desainer, developer, QA, atau orang lain?
• Seberapa sering Anda ingin memeriksa aksesibilitas? Detail apa yang harus disertakan dalam laporan? Apakah masalah harus ditautkan langsung ke sistem tiket?
• Alat mana yang paling cocok di lingkungan Anda? Untuk tim Anda?

Ada banyak faktor tambahan yang juga perlu dipertimbangkan. Lihat artikel WAI's tentang "Selecting Web Accessibility Evaluation Tools" untuk mengetahui informasi selengkapnya tentang cara memilih alat terbaik untuk Anda dan tim Anda.

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 fiktif, Medical Mysteries Club. Situs ini sengaja dibuat tidak dapat diakses untuk demo. Beberapa masalah aksesibilitas ini mungkin terlihat oleh Anda, dan beberapa (tetapi tidak semua) akan terdeteksi 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 membuat demo di CodePen. Lihat dalam mode debug untuk melanjutkan ke pengujian berikutnya. Hal ini penting karena akan menghapus <iframe> yang mengelilingi halaman web demo, yang dapat mengganggu beberapa alat pengujian.

Pelajari lebih lanjut tentang mode debug CodePen.

Langkah 3

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

Langkah 4

Klik Analyze page load dan beri waktu kepada Lighthouse untuk menjalankan pengujiannya.

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

Selain skor, laporan Lighthouse menyertakan informasi mendetail tentang masalah yang terdeteksi dan link ke resource untuk mempelajari lebih lanjut cara mengatasinya. Laporan ini juga mencakup pengujian yang lulus atau tidak berlaku dan daftar item tambahan yang harus diperiksa secara manual.

Langkah 5

Sekarang, lihat contoh setiap masalah aksesibilitas otomatis yang ditemukan dan perbaiki gaya serta markup yang relevan.

Masalah 1: Peran ARIA

Masalah pertama menyatakan: "Elemen dengan [role] ARIA yang mewajibkan turunannya berisi [role] tertentu tidak memiliki beberapa atau semua turunan yang diperlukan. Beberapa peran induk ARIA harus memuat peran turunan tertentu agar dapat menjalankan fungsi aksesibilitas yang diinginkan." Pelajari lebih lanjut tentang 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 memiliki peran ARIA yang salah. Dalam hal ini, peran tersebut dapat dihapus sepenuhnya.

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

Masalah 2: ARIA tersembunyi

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 lebih lanjut aturan aria-hidden.

<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". Menambahkan atribut ini akan menyembunyikan elemen (dan semua elemen yang berada di dalamnya) 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 agar orang yang menggunakan teknologi pendukung dapat mengakses dan memasukkan informasi ke dalam 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 lebih lanjut aturan nama tombol.

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

Mari kita perbaiki.

Saat Anda menghapus peran ARIA yang tidak akurat dari elemen tombol dalam masalah 1, kata "Berlangganan" akan menjadi nama tombol yang dapat diakses. Fungsi ini dibuat 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 lebih lanjut aturan teks alternatif gambar.

<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 tersebut disebut gambar yang dapat ditindaklanjuti dan memerlukan informasi teks alternatif tentang tujuan gambar. Biasanya, gambar pertama di halaman adalah logo, sehingga Anda dapat berasumsi bahwa pengguna AT Anda akan mengetahui hal ini, dan Anda dapat memutuskan untuk tidak menambahkan informasi kontekstual tambahan ini 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 dapat dikenali. Teks link (dan teks alternatif untuk gambar, saat digunakan sebagai link) yang mudah dilihat, unik, dan dapat difokuskan akan meningkatkan kualitas pengalaman navigasi bagi pengguna pembaca layar. Pelajari lebih lanjut aturan teks link.

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

Mari kita perbaiki.

Semua gambar yang dapat ditindaklanjuti di halaman harus menyertakan informasi tentang tempat link mengirim pengguna. Salah satu metode untuk mengatasi masalah ini adalah dengan menambahkan teks alternatif ke gambar tentang tujuannya, seperti yang Anda lakukan pada gambar logo dalam contoh. Metode 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 yang menargetkan SVG, menambahkan informasi di antara tag <a> dan <svg>, lalu menyembunyikannya secara visual dari pengguna, menambahkan ARIA yang didukung, atau opsi lainnya. Bergantung pada lingkungan dan batasan kode Anda, satu metode mungkin lebih disukai daripada metode lainnya.

Gunakan opsi pola paling sederhana dengan cakupan teknologi pendukung terbanyak, 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 cukup. Teks yang memiliki kontras rendah akan sulit atau tidak mungkin dibaca oleh kebanyakan pengguna. Pelajari lebih lanjut aturan kontras warna.

Dua contoh dilaporkan.

Mari kita perbaiki.

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

Untuk judul halaman, teks berwarna teal harus memenuhi persyaratan kontras warna 3:1 karena merupakan teks berukuran besar dengan ukuran 24 piksel. Namun, tombol teal dianggap sebagai teks berukuran normal dengan ukuran 16 piksel tebal, sehingga harus memenuhi persyaratan kontras warna 4,5:1.

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

Semua teks abu-abu di latar belakang putih juga gagal untuk kontras warna, kecuali dua judul terbesar di halaman. Teks ini harus digelapkan untuk 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>) dimuat dalam induk <ul> atau <ol> agar dapat diucapkan dengan tepat.

Pelajari lebih lanjut aturan daftar.

<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 berurutan, bukan menggunakan tag <ul>. Saat kita menulis kode ini dengan tidak benar, kita menghapus fitur HTML semantik bawaan yang ada di tag ini. Dengan mengganti class dengan tag yang sebenarnya <ul> dan mengubah CSS terkait, kita dapat mengatasi 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 menunjukkan pengurutan navigasi eksplisit. Walaupun secara teknis valid, hal ini sering menciptakan pengalaman yang membingungkan bagi pengguna yang mengandalkan teknologi pendukung. Pelajari lebih lanjut aturan tabindex.

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

Mari kita perbaiki.

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

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

Langkah 6

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

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

Langkah berikutnya

Selamat. Anda sudah belajar banyak hal, tetapi kita belum selesai. Selanjutnya, kita akan membahas pemeriksaan manual, seperti yang dijelaskan dalam modul pengujian aksesibilitas manual.