Satuan 10 / 11

Kecerdasan Buatan dalam Aksesibilitas dan Desain Inklusif

Keuntungan:

  • Kemampuan untuk mengontrol dan meningkatkan kontras warna, teks alternatif, akses keyboard, dan kriteria WCAG dengan dukungan kecerdasan buatan
  • Kemampuan untuk menghasilkan dan memverifikasi teks aksesibilitas seperti pengalaman pembaca layar, teks alternatif, dan membentuk label dengan kecerdasan buatan
  • Memahami batasan validasi rekomendasi aksesibilitas AI dengan teknologi bantuan nyata dan pengujian pengguna

Aksesibilitas (disingkat a11y) adalah kemampuan suatu produk untuk digunakan oleh semua orang, termasuk individu penyandang disabilitas: pengguna tunanetra dapat bernavigasi dengan pembaca layar (perangkat lunak tambahan yang mengubah teks menjadi ucapan), pengguna dengan kesulitan motorik dapat melakukan apa pun dengan keyboard, orang buta warna dapat menerima informasi tanpa bergantung pada warna. Desain inklusif memiliki arti yang lebih luas: desain inklusif mengutamakan keberagaman manusia, termasuk usia, bahasa, budaya, disabilitas sementara (patah lengan) atau disabilitas kontekstual (di bawah sinar matahari). Aksesibilitas bukanlah suatu “ekstra” namun merupakan tanggung jawab mendasar dan persyaratan hukum di sebagian besar negara. AI adalah penyaring awal dan generator draf yang kuat di bidang ini; namun aksesibilitas sebenarnya hanya dikonfirmasi oleh teknologi pendukung dan pengujian pengguna yang sebenarnya.

WCAG dan area kendali utama

WCAG (Pedoman Aksesibilitas Konten Web) adalah seperangkat kriteria aksesibilitas yang diterima secara internasional; Level AA umumnya ditargetkan. Ini memiliki empat prinsip: konten harus dapat dipahami, antarmuka harus dapat digunakan, informasi harus dapat dipahami dan masuk akal secara teknis. Area kontrol yang paling umum dalam praktiknya adalah:

  • Kontras warna: Apakah perbedaan antara teks dan latar belakang cukup? (Untuk AA, setidaknya rasio 4,5:1 dalam teks normal.)
  • Teks alternatif (teks alternatif): Apakah gambar memiliki padanan teks yang menjelaskannya kepada pembaca layar?
  • Akses keyboard: Adakah yang bisa dilakukan tanpa mouse? Apakah urutan fokusnya masuk akal?
  • Informasi hanya warna: Frasa seperti "Isi kolom merah" mengecualikan pengguna buta warna.
  • Label formulir: Apakah setiap kolom masukan memiliki label yang akan dibaca oleh pembaca layar?
  • Target sentuh: Apakah tombolnya cukup besar untuk ditekan dengan nyaman menggunakan jari?

AI dapat melakukan pemindaian awal dengan cepat di banyak area berikut: Anda dapat memberikan beberapa teks dan bertanya "apakah kontrasnya cukup?", memberikan deskripsi gambar dan bertanya "sarankan teks alternatif", berikan deskripsi antarmuka dan tanyakan "apa masalah akses keyboard".

Perhatian: Hanya karena AI mengatakan "tampaknya dapat diakses" bukan jaminan aksesibilitas. Pemeriksaan otomatis hanya menangkap beberapa kesalahan WCAG; Sisanya akan muncul dengan penggunaan sebenarnya.

Teks alternatif: rahasia teks alternatif yang baik

Teks alternatif menggantikan gambar untuk pengguna tunanetra. Teks alternatif yang baik menyampaikan fungsi dan makna gambar, bukan detail dekoratifnya. Teks alternatif untuk ikon "tambahkan ke troli" haruslah "Tambahkan ke troli" dan bukan "gambar keranjang belanja" karena tindakan itulah yang penting bagi pengguna. AI pandai menghasilkan kerangka subteks, tetapi karena tidak mengetahui konteksnya, AI mungkin menghasilkan teks yang terlalu deskriptif atau tidak relevan. Anda menanyakan setiap teks alternatif “mengapa gambar ini ada di sini?” Pangkas dengan pertanyaan.

visual

Subteks yang lemah

Subteks yang kuat

Ikon keranjang (tombol)

"Ikon keranjang, warna abu-abu"

"Tambahkan ke troli"

foto produk

"gambar"

"Mantel musim dingin biru, tampak depan"

garis dekoratif

"Garis hiasan"

(biarkan kosong — dekoratif)

Grafik

"Gambar grafis"

"Penjualan 2024: meningkat setiap kuartal"

Bahasa dan cakupannya inklusif

Aksesibilitas tidak terbatas pada kontrol teknis; Bahasa juga inklusif. Teks yang mengasumsikan gender (“pengguna dan pasangannya”), dikecualikan berdasarkan kemampuan (“sekilas”, “mudah mendengar”), atau berisi asumsi budaya akan mengecualikan beberapa pengguna. AI dapat memindai teks dari perspektif ini, tetapi Anda harus memastikan bahwa bahasa “netral” yang disarankannya tetap alami dan dapat dimengerti; Koreksi yang berlebihan dapat membuat teks menjadi canggung.

tiga kasus mini

Kasus 1 — Kesalahan kontras diketahui lebih awal. Sebuah tim meminta AI memindai warna teks di 20 layar dan menentukan bahwa kontrasnya berada di bawah ambang batas AA di 7 tempat. Koreksi dilakukan tanpa melakukan pengembangan; biaya koreksi selanjutnya dapat dihindari. Namun tim masih tidak melewatkan tes pembaca layar yang sebenarnya.

Kasus 2 — Hanya informasi terkait warna yang diperbaiki. Satu formulir menunjukkan bidang kesalahan hanya dengan batas merah. AI menandai ini; Tim juga menambahkan teks dan ikon untuk setiap kesalahan. Pengguna buta warna sekarang dapat melihat kesalahan tersebut. Pelajaran: warna saja tidak dapat menyampaikan informasi.

Kasus 3 — AI menyesatkan persetujuan. Seorang desainer melewatkan pengujian pembaca layar karena dia menyebut AI “dapat diakses.” Pada pengujian sebenarnya ternyata urutan fokusnya kacau dan beberapa tombol tidak terbaca sama sekali. Pelajaran: konfirmasi otomatis adalah permulaan; pengujian teknologi bantu yang sebenarnya adalah wajib.

Perintah yang dapat disalin

Pra-pindai deskripsi antarmuka ini untuk mengetahui aksesibilitas: 1) apakah ada informasi yang dibawa hanya berdasarkan warna? 2) apakah ada label teks untuk setiap elemen yang dapat diklik? 3) apakah ada elemen yang tidak dapat diakses melalui keyboard? 4) apakah urutan fokusnya masuk akal? Cantumkan setiap masalah dan saran. Tambahkan catatan "Diperlukan tes nyata".Resep: <<teks>>

Sarankan teks alternatif untuk gambar ini. Aturannya: sampaikan FUNGSI/makna gambar, bukan detail dekoratifnya. Tulis tindakan untuk ikon tombol. Untuk gambar dekoratif, ucapkan "teks alternatif harus dikosongkan". Deskripsi konteks dan gambar: <<list>>

Periksa teks-teks berikut untuk mengetahui bahasa yang inklusif: apakah ada asumsi gender, bahasa eksklusif berdasarkan kemampuan (seperti “melihat,” “mendengar”), asumsi budaya? Sarankan alternatif yang tetap alami; jangan mengoreksi secara berlebihan. Teks: <<daftar>>

Tulis kesalahan yang dapat diakses dan beri label teks untuk formulir ini: label yang terlihat untuk setiap bidang, deskripsi untuk pembaca layar, dan pesan yang menjelaskan kesalahan, apa pun warnanya (teks + ikon). Suara dan nada: <<kartu>>Bidang formulir: <<daftar>>

Perintah lemah / Perintah kuat

Lemah: "Tulis teks alternatif untuk gambar ini."

Hasilnya: “Sebuah gambar” atau teks yang terlalu deskriptif sehingga tidak memiliki fungsi.

Kuat: "Sarankan teks alternatif untuk gambar-gambar ini; sampaikan fungsi/makna gambar; tulis tindakan untuk ikon tombol; tandai yang dekoratif sebagai 'harus dikosongkan'."

Hasilnya: subteks yang kontekstual, berorientasi fungsi, dan akurat.

Perbedaan: prompt kuat menghadirkan fokus fungsional + konvensi tombol + perbedaan dekoratif.

Kesalahan umum

  • Mengira persetujuan kecerdasan buatan sebagai jaminan aksesibilitas. Ini bukanlah pengganti pengujian yang sebenarnya.
  • Hanya memuat informasi ke dalam warna. Pengguna buta warna kehilangan informasi.
  • Menjelaskan gambar, bukan fungsinya, di teks alt. Suatu tindakan harus ditulis untuk ikon tombol.
  • Meninggalkan aksesibilitas untuk yang terakhir. Jika tidak dimulai pada tahap wireframe, akan mahal untuk menambalnya nanti.
  • Bahasa yang dikoreksi secara berlebihan. Bahasa inklusif yang kehilangan kealamiannya juga mengganggu pemahaman.

Singkatnya

Aksesibilitas berarti produk tersedia untuk semua orang; Hal ini bukan merupakan hal tambahan, namun merupakan hal yang penting dan, di banyak tempat, merupakan tanggung jawab hukum. AI berguna sebagai generator preflight dan draf yang cepat untuk kontras, teks alternatif, akses keyboard, dan pemindaian bahasa inklusif. Namun persetujuan otomatis hanya menangkap beberapa kesalahan WCAG; Aksesibilitas aktual dikonfirmasi melalui pengujian dengan pembaca layar dan pengguna teknologi bantu nyata. Gunakan model sebagai browser depan, dapatkan bukti dari pengujian nyata.

Tugas aplikasi

  1. Pra-pindai deskripsi antarmuka untuk aksesibilitas pada perintah pertama.
  2. Perbaiki hanya informasi berdasarkan warna atau item yang tidak berlabel.
  3. Hasilkan teks alternatif berorientasi fungsi untuk visual di layar Anda dengan perintah kedua.
  4. Periksa teks Anda untuk bahasa inklusif dengan perintah ketiga.
  5. Jika memungkinkan, coba tes sebenarnya dengan pembaca layar dan catat apa yang terlewatkan oleh pemindaian otomatis.

daftar periksa

  • [ ] Saya melakukan pra-pindaian kontras, akses keyboard, dan label.
  • [ ] Saya tidak meninggalkan informasi hanya berdasarkan warna.
  • [ ] Saya menulis subteksnya secara fungsional dan membiarkan subteks dekoratifnya kosong.
  • [ ] Saya membuat kontrol bahasa yang inklusif, saya menjaga kealamiannya.
  • [ ] Saya tidak menganggap persetujuan otomatis sebagai jaminan aksesibilitas.
  • [ ] Saya merencanakan/mengimplementasikan pengujian teknologi bantu yang sebenarnya.