Di sebuah workshop sekolah, pengembang menunjukkan fitur baru.
“AI ini bisa membantu semua siswa.”
Seorang murid bertanya:
“Semua?”
“Ya.”
“Kalau aku pakai screen reader?”
Pengembang berhenti.
“Harusnya bisa.”
“Sudah dites?”
Ruangan menjadi lebih sunyi.
Kata “semua” memang mudah diucapkan.
Menguji apakah teknologi benar-benar bisa dipakai semua orang jauh lebih sulit.
AI punya potensi besar membantu anak difabel.
Text-to-speech dapat membuka akses ke teks.
Speech-to-text dapat membantu input.
Caption otomatis membantu video.
Computer vision dapat membantu deskripsi visual.
Adaptive systems dapat menyesuaikan format.
AI bisa membantu guru mengubah materi menjadi beberapa versi lebih cepat.
UNICEF dan UNESCO sama-sama menyoroti peluang AI serta assistive technology untuk memperluas akses pendidikan bagi learners with disabilities.
Tetapi potensi tidak otomatis menjadi inklusi.
Jika anak difabel baru dilibatkan setelah produk selesai, banyak hambatan sudah telanjur masuk desain.
Inclusive design harus dimulai dari awal.
“Untuk semua” harus dibuktikan
Teknologi sering dirancang berdasarkan pengguna imajiner.
Bisa melihat.
Bisa mendengar.
Bisa mengetik cepat.
Bisa menggunakan mouse.
Punya koneksi stabil.
Memahami bahasa interface.
Bisa fokus lama.
Tidak membutuhkan alat bantu.
Padahal pengguna nyata beragam.
Anak difabel juga bukan satu kelompok homogen.
Anak tunanetra punya kebutuhan berbeda dari anak low vision.
Anak Tuli atau hard of hearing berbeda kebutuhan.
Anak dengan keterbatasan motorik berbeda.
Anak neurodivergen berbeda.
Anak dengan disabilitas ganda punya kombinasi kebutuhan sendiri.
Tidak mungkin satu fitur disebut inklusif hanya karena ada satu tombol accessibility.
Desain harus melihat variasi.
Libatkan pengguna sebelum membangun
Prinsip “nothing about us without us” penting.
Kalau membuat AI untuk membantu anak difabel, dengar anak difabel, keluarga, guru, dan pihak yang memahami aksesibilitas.
Bukan hanya untuk testimonial.
Untuk keputusan desain.
Contoh.
Tim ingin membuat chatbot belajar.
Sebelum build:
Apakah chat text cocok?
Apakah perlu voice?
Bagaimana screen reader membaca respons panjang?
Apakah ada shortcut?
Apakah heading terstruktur?
Apakah anak bisa menghentikan audio?
Apakah interface terlalu ramai?
Pertanyaan seperti ini lebih murah dijawab sebelum produk selesai.
Inclusive design bukan patch.
Ia cara membangun.
AI yang pintar tetapi interface tidak accessible tetap tidak inklusif
Bayangkan modelnya hebat.
Jawabannya akurat.
Tetapi tombol send tidak punya label.
Keyboard focus hilang.
Zoom membuat layout berantakan.
Caption tidak tersedia.
Kontras rendah.
Semua kecanggihan di belakang layar menjadi tidak relevan bagi pengguna yang tidak bisa masuk.
W3C WAI menekankan accessibility sebagai kemampuan orang dengan disabilitas untuk mempersepsi, memahami, menavigasi, berinteraksi, dan berkontribusi di web.
AI product tetap software.
Standar accessibility dasar tidak hilang hanya karena ada model cerdas di dalamnya.
Malah semakin penting.
Karena semakin banyak fungsi penting dipindahkan ke AI interface.
Jangan menganggap voice selalu solusi aksesibilitas
“Kalau sulit mengetik, pakai suara.”
Tidak sesederhana itu.
Ada pengguna yang tidak bisa atau tidak nyaman menggunakan suara.
Speech recognition bisa salah memahami cara bicara tertentu.
Lingkungan sekolah bisa bising.
Privasi bisa menjadi masalah.
Anak mungkin tidak ingin berbicara soal tugas di ruang bersama.
Karena itu, multimodal penting.
Text.
Voice.
Keyboard.
Touch.
Alternative input.
Pilihan membantu.
Aksesibilitas bukan mengganti satu default dengan default baru.
Aksesibilitas berarti lebih banyak jalur.
AI bisa membantu membuat materi accessible lebih cepat
Di sisi positif, AI sangat menarik untuk content adaptation.
Guru punya satu dokumen.
AI dapat membantu menghasilkan draft:
plain language version,
audio,
caption,
image description,
glosarium,
pertanyaan bertahap.
UNICEF pada 2026 menyoroti proyek ADT-Studio yang dapat mengubah materi pendidikan menjadi accessible digital textbooks.
Ini contoh bagaimana AI dapat bekerja di belakang layar untuk memperluas akses.
Namun guru perlu quality check.
Image description yang salah bisa membingungkan.
Caption otomatis bisa mengubah istilah.
Simplification bisa menghilangkan konsep penting.
AI mempercepat produksi.
Manusia menjaga makna.
Jangan membuat bantuan terlalu “pintar” sampai mengambil agency
Bayangkan word prediction yang terus menyelesaikan kalimat anak.
Awalnya membantu.
Lama-lama sistem menulis lebih banyak daripada anak.
Atau AI communication aid selalu memilih respons “paling mungkin”.
Anak akhirnya hanya memilih dari apa yang disediakan sistem.
Assistive technology seharusnya memperluas suara pengguna.
Bukan mengganti suara pengguna.
Pertanyaan desain:
Apakah anak bisa menolak saran?
Apakah bisa menulis respons sendiri?
Apakah ada pilihan?
Apakah sistem terlalu sering mengambil alih?
Agency adalah bagian inklusi.
Anak bukan hanya penerima bantuan.
Ia pengguna yang punya preferensi.
Data disabilitas sangat sensitif
Untuk personalisasi, sistem mungkin meminta informasi:
jenis kebutuhan,
profil belajar,
riwayat dukungan,
suara,
video,
data perilaku,
dokumen asesmen.
Jangan mengumpulkan karena “mungkin berguna”.
Gunakan minimum necessary data.
UNICEF menekankan privacy dan data protection dalam AI untuk anak.
Anak difabel tidak boleh menghadapi trade-off:
“Kalau mau akses, serahkan lebih banyak data.”
Desain yang baik mencari cara memberi fungsi tanpa profiling berlebihan.
Sekolah perlu tahu:
siapa yang mengakses data?
apakah vendor menyimpan?
apakah dipakai melatih model?
berapa lama?
bagaimana menghapus?
ada mekanisme koreksi?
Privasi adalah bagian accessibility karena sistem yang tidak dipercaya tidak benar-benar aman digunakan.
Bias bisa membuat alat bantu justru salah pada kelompok yang membutuhkan
AI belajar dari data.
Jika data kurang mewakili pengguna dengan disabilitas, performa bisa buruk.
Speech recognition mungkin kesulitan dengan cara bicara tertentu.
Computer vision mungkin salah pada alat bantu.
Sistem prediksi mungkin menganggap pola interaksi berbeda sebagai masalah.
Ini bukan sekadar bug teknis.
Bisa berdampak pada partisipasi.
Karena itu, evaluasi perlu breakdown.
Jangan hanya:
“Accuracy 94%.”
Tanya:
“94% untuk siapa?”
“Siapa yang paling banyak error?”
“Apakah pengguna dengan assistive technology mengalami kegagalan lebih sering?”
Inclusive testing membutuhkan kelompok beragam.
Rata-rata tidak cukup.
Desain juga harus mempertimbangkan kegagalan
Semua AI bisa salah.
Untuk anak difabel, kesalahan tertentu mungkin punya dampak lebih besar.
Caption salah saat materi penting.
Navigation gagal.
Voice command tidak terbaca.
AI memberi deskripsi visual keliru.
Sistem adaptive salah menurunkan level.
Maka desain perlu safe fallback.
Human assistance.
Manual input.
Alternative format.
Contact.
Retry.
Clear error message.
Jangan membuat AI menjadi satu-satunya pintu.
Kalau pintu AI macet, anak tetap harus bisa belajar.
Guru perlu diberi kontrol
Inclusive AI tidak boleh hanya memberi kontrol ke vendor.
Guru perlu bisa:
mengubah rekomendasi,
memilih format,
menonaktifkan fitur,
mengoreksi materi,
memberi alternatif,
dan melihat ketika anak membutuhkan dukungan manusia.
Human oversight bukan slogan.
Harus ada tindakan yang bisa dilakukan.
Kalau sistem berkata:
“Anak ini harus level lebih mudah,”
guru harus bisa menolak.
Kalau caption salah,
guru bisa edit.
Kalau format tidak cocok,
ada opsi lain.
Teknologi melayani pembelajaran.
Bukan sebaliknya.
Jangan membuat inklusi bergantung pada perangkat mahal
AI accessibility bisa terdengar sangat futuristik.
Smart glasses.
Device khusus.
Subscription premium.
Hardware baru.
Tetapi desain inklusif juga harus memikirkan affordability.
Apakah bisa di ponsel biasa?
Bisa low-bandwidth?
Bisa offline?
Bisa dicetak?
Ada alternatif non-AI?
Kalau solusi hanya bisa dipakai sekolah kaya, kita memecahkan satu hambatan sambil membuat hambatan baru.
Inklusi juga soal ekonomi dan akses.
UNICEF serta UNESCO terus menekankan pentingnya tidak meninggalkan kelompok rentan dalam transformasi digital.
Teknologi harus bekerja di dunia nyata.
Bukan hanya demo.
Selain dokumen vendor, sekolah dapat meminta bukti praktik. Apakah ada hasil pengujian dengan pengguna disabilitas? Apakah bug aksesibilitas punya prioritas? Apakah perubahan interface diuji ulang? Inclusive design bukan sertifikat sekali jadi. Setiap update bisa memperbaiki atau justru merusak accessibility.
Karena itu, pengadaan teknologi perlu melihat kemampuan vendor merespons masalah setelah produk dipakai. Anak tidak boleh terjebak pada sistem yang technically purchased tetapi practically unusable selama berbulan-bulan.
Sekolah bisa meminta accessibility statement dari vendor
Saat memilih tool, tanyakan.
Standar apa yang didukung?
Apakah diuji dengan screen reader?
Keyboard?
Caption?
Zoom?
Contrast?
Alternative input?
Ada dokumentasi?
Ada roadmap perbaikan?
Bagaimana melaporkan accessibility bug?
Vendor yang serius biasanya punya jawaban lebih konkret daripada:
“Platform kami user-friendly.”
User-friendly bukan sama dengan accessible.
Sekolah perlu belajar membedakannya.
Inclusive design juga perlu memikirkan siapa yang mendampingi penggunaan. Tool yang accessible secara teknis belum tentu mudah diterapkan jika guru tidak memahami setting accessibility, cara mengubah mode input, atau cara mematikan fitur yang mengganggu. Pelatihan staf harus menjadi bagian implementasi, bukan dianggap selesai setelah instalasi. Teknologi yang baik membutuhkan lingkungan yang tahu cara menggunakannya secara inklusif.
Sekolah juga sebaiknya menyimpan alternatif non-digital untuk aktivitas penting. Bukan sebagai langkah mundur, tetapi sebagai resilience. Jika sistem gagal, internet putus, atau accessibility rusak setelah update, proses belajar tidak boleh berhenti. Inklusi membutuhkan jalur cadangan yang tetap bermartabat.
Anak difabel perlu ikut menilai sukses
Keberhasilan bukan:
fitur hidup.
Keberhasilan:
anak lebih mudah belajar.
Lebih bisa berpartisipasi.
Lebih sedikit hambatan.
Lebih punya kontrol.
Lebih mandiri sesuai kebutuhannya.
Tanyakan pada pengguna.
“Apakah ini membantu?”
“Bagian mana paling menyulitkan?”
“Apakah kamu ingin pakai lagi?”
Feedback negatif bukan kegagalan anak.
Ia informasi desain.
Jika pengguna harus bekerja ekstra agar tool “membantu”, mungkin desainnya belum cukup baik.
Akses yang konsisten sama pentingnya dengan fitur yang canggih.
Kembali ke workshop
Pengembang tadi menjawab jujur.
“Belum dites cukup dengan screen reader.”
Siswa mengangguk.
“Kalau mau, saya bisa kasih feedback.”
Guru menambahkan:
“Tapi bukan cuma dia. Kita butuh testing yang benar.”
Mereka setuju.
Beberapa minggu kemudian, tool kembali dengan perubahan.
Bukan sempurna.
Tetapi lebih baik.
Itulah inclusive design.
Bukan klaim bahwa produk selesai.
Tetapi proses melibatkan pengguna, menguji hambatan, memperbaiki, dan terus mengevaluasi.
AI memang bisa membantu anak difabel.
Bahkan potensinya sangat besar.
Namun teknologi baru akan benar-benar inklusif ketika anak difabel tidak diperlakukan sebagai pengguna tambahan.
Mereka harus dianggap pengguna sejak awal.
Bukan “edge case”.
Bukan checkbox.
Bukan alasan marketing.
Anak.
Dengan hak yang sama untuk belajar, berpartisipasi, dan menggunakan teknologi tanpa hambatan yang sebenarnya bisa dihilangkan.