Apakah Semua Orang Bisa Menggunakan Aplikasi Buatan AI-mu? Panduan Sederhana Soal Aksesibilitas
Aksesibilitas aplikasi berarti semua orang — orang yang memperbesar layarnya, yang mengetuk dengan satu ibu jari, atau yang tidak bisa membedakan merah dari hijau — bisa benar-benar menggunakan aplikasimu, bukan hanya kamu. Tiga pengecekan cepat mengungkap sebagian besar celah — zoom, warna, dan pembaca layar.
Saat kamu membangun aplikasi dengan AI, kamu mengujinya dengan cara kamu sendiri menggunakannya: layarmu, matamu, genggaman dua tanganmu yang mantap di laptop. Masalahnya, sebagian besar orang yang akan membuka aplikasimu tidak menggunakannya seperti itu. Ada yang memperbesar teks di ponselnya jadi dua kali lipat ukuran normal. Ada yang tidak bisa membedakan pesan error merahmu dari teks hitam di sekitarnya. Ada yang sedang menggendong bayi sambil mengetuk layar dengan satu ibu jari. Aksesibilitas aplikasi sederhananya adalah soal apakah orang-orang itu tetap bisa menggunakannya — dan ini pertanyaan yang hampir tidak pernah diajukan pada kebanyakan aplikasi buatan AI.
Kamu tidak perlu gelar sarjana atau tim kepatuhan untuk mengurus ini. Kamu hanya perlu tahu empat atau lima titik di mana aplikasi biasanya mengunci sebagian orang, dan bagaimana memintanya diperbaiki ke builder-mu. Mari saya tunjukkan contoh-contoh umum lewat cerita, karena akan lebih mudah dikenali begitu kamu pernah melihatnya.
Kenapa tata letak aplikasiku berantakan saat seseorang memperbesar layar?
Karena kebanyakan aplikasi buatan AI dirancang dengan satu ukuran teks tetap, jadi ketika seseorang memperbesar teks di ponsel atau browsernya — sesuatu yang dilakukan banyak orang, terutama siapa pun di atas enam puluh tahun — tombol-tombol jadi tumpang tindih, kolom-kolom kolaps jadi tumpukan yang berantakan, dan kontrol-kontrol saling menutupi.
Seorang pembuat aplikasi yang saya kenal membangun aplikasi janji temu yang rapi untuk salon rambut ibunya. Kelihatannya bagus. Lalu ibunya membuka aplikasi itu, dan hal pertama yang dia lakukan — seperti kebanyakan orang di atas enam puluh — adalah mencubit layar untuk memperbesar teks. Tata letaknya langsung berantakan. Tombol-tombol tumpang tindih, tombol “Pesan” tergeser ke bawah menu, dan kolom daftar jam berubah jadi tumpukan acak yang tidak terbaca.
Ini adalah celah aksesibilitas paling umum pada aplikasi buatan AI, dan tidak terlihat sampai seseorang memperbesar layarnya. Minta ke builder-mu: “Pastikan tata letak tetap berfungsi ketika teks diperbesar hingga 200%. Tidak boleh ada yang tumpang tindih atau terpotong.” Lalu uji sendiri — di ponselmu, naikkan ukuran font sistem ke pengaturan terbesar dan buka aplikasimu. Kalau berantakan, itulah perbaikan pertamamu.
Kenapa aplikasiku sebaiknya tidak memakai warna saja untuk menunjukkan status?
Karena sekitar satu dari dua belas pria melihat warna secara berbeda, paling umum antara merah dan hijau — jadi status yang ditampilkan murni sebagai titik merah versus titik hijau terlihat sama saja bagi mereka, dan mereka benar-benar tidak bisa membedakan “lunas” dari “jatuh tempo.”
Seorang pekerja lepas membangun pelacak faktur yang menunjukkan status murni lewat warna — titik hijau, titik merah. Salah satu kliennya, yang kebetulan buta warna merah-hijau, terus-menerus membayar faktur yang sebenarnya sudah lunas karena kedua titik itu terlihat identik baginya. Informasinya ada di sana. Hanya saja tidak ada baginya.
Solusinya adalah kebiasaan, bukan fitur: jangan pernah memakai warna sebagai satu-satunya cara untuk menyampaikan sesuatu. Tambahkan kata, ikon, atau bentuk di sampingnya. “Jatuh tempo” di sebelah warna merah. Tanda centang di sebelah warna hijau. Tanda bintang dan kata “wajib diisi”, bukan cuma garis tepi merah. Warna boleh tetap ada — hanya saja tidak boleh membawa pesan itu sendirian.
Kenapa pembaca layar hanya mengatakan “tombol” alih-alih menyebut namanya?
Karena tombol ikon tanpa label — tempat sampah, pensil, kaca pembesar tanpa kata apa pun — tidak punya teks untuk diumumkan oleh pembaca layar (perangkat lunak yang digunakan orang dengan gangguan penglihatan atau tunanetra untuk mendengarkan isi layar), sehingga yang terdengar, secara harfiah, adalah “tombol.” Bukan “Hapus.” Bukan “Edit.” Cuma “tombol.”
Builder AI suka tombol ikon yang bersih karena terlihat modern. Tapi bayangkan menggunakan aplikasi di mana setiap kontrol dinamai “tombol” dan kamu harus menebak-nebak sendiri. Kamu tidak perlu menambahkan teks yang terlihat pada setiap ikon — kamu perlu memastikan setiap kontrol punya nama di baliknya, bahkan yang tak kasatmata sekalipun yang bisa diumumkan pembaca layar. Minta ke builder-mu: “Beri label aksesibilitas pada setiap tombol ikon — ikon tempat sampah harus diumumkan sebagai ‘Hapus,’ ikon pensil sebagai ‘Edit.’” Ini perubahan kecil, tapi jadi pembeda antara aplikasi yang bisa dijelajahi pengguna tunanetra dan yang hanya berupa tembok tombol-tombol tanpa nama.
Seberapa besar seharusnya target ketukan pada aplikasi mobile?
Aturan kasar yang dipakai desainer adalah bahwa apa pun yang bisa diketuk sebaiknya berukuran sekitar 44 piksel — kira-kira seukuran ujung jari — dengan jarak yang cukup supaya dua elemen yang bisa diketuk tidak berdempetan.
Perhatikan seseorang memakai aplikasimu dengan satu tangan di dalam bus. Ibu jari itu lebar dan kurang presisi, bus sedang bergerak, dan tombol “X” untuk menutup hanya titik kecil 16 piksel di pojok. Dia meleset dua kali, tanpa sengaja menekan elemen di baliknya sekali, lalu menyerah. Target ketukan yang kecil dan berdesakan adalah masalah aksesibilitas, bukan sekadar gangguan kecil — ini paling berdampak pada orang dengan tremor, jari yang lebih besar, atau berada di lingkungan yang bergerak. Minta ke builder-mu: “Buat target ketukan minimal 44 piksel dan tambahkan jarak di antaranya supaya orang tidak salah menekan.” Lalu uji sendiri: buka aplikasimu di ponsel dan coba lakukan aksi utamanya dengan satu tangan sambil berjalan. Kalau kamu terus salah menekan, orang lain juga begitu.
Bagaimana cara menguji aksesibilitas aplikasiku dalam lima menit?
Kamu bisa menemukan sebagian besar masalah ini sendiri tanpa alat apa pun, dengan tiga pengecekan cepat pada layar yang paling sering dipakai orang:
- Perbesar layarnya. Naikkan teks ponsel atau browsermu ke pengaturan terbesar dan buka layar utama. Ada yang tumpang tindih, menghilang, atau terpotong?
- Kuras warnanya. Lihat setiap tempat di aplikasimu yang memakai warna untuk menyampaikan makna — status, error, kolom wajib. Kalau kamu bayangkan semuanya jadi abu-abu, apakah kamu masih bisa tahu apa yang sedang terjadi? Kalau tidak, tambahkan kata atau ikon.
- Nyalakan pembaca layar selama dua menit. Baik iPhone (VoiceOver) maupun Android (TalkBack) sudah punya fitur ini bawaan. Nyalakan, pejamkan mata, dan coba lakukan hal utama yang menjadi tujuan aplikasimu. Kamu akan langsung dengar tombol mana saja yang tanpa nama.
Semua ini tidak mengharuskan kamu jadi developer. Yang dibutuhkan hanyalah berhenti menguji sebagai dirimu sendiri selama lima menit, dan menguji sebagai seseorang yang tangan, mata, atau layarnya tidak sama denganmu.
Kamu tidak harus memperbaiki semuanya sekaligus. Pilih satu layar yang paling sering dipakai orang — formulir pemesanan, pendaftaran, daftar utama — dan buat layar itu berfungsi baik saat diperbesar, dikuras warnanya, dan dibacakan lantang. Satu layar itu saja, kalau dikerjakan dengan benar, mencakup lebih banyak orang daripada audit aksesibilitas menyeluruh di sudut-sudut yang tidak pernah dikunjungi siapa pun. Mulai dari situ, dan orang berikutnya yang membuka aplikasimu dengan satu ibu jari dan layar yang diperbesar akan menjadi pengguna, bukan yang langsung kabur.