Perintah dan konteks
Pencarian, penyimpanan, dan pengunggahan selesai tanpa navigasi atau pemindahan fokus. Pengguna visual melihat "Menyimpan", "Tersimpan", atau "Gagal menyimpan", sementara pembaruan mungkin terjadi di luar kontrol yang sedang difokuskan. Tujuannya adalah pengumuman yang singkat dan dapat ditindaklanjuti yang tidak mengganggu input, dengan fallback untuk keyboard, tanpa skrip, dan kegagalan jaringan.
Hal yang diuji oleh pewawancara
Jawaban harus membedakan status informasi, kesalahan, dan peringatan mendesak; membuat live region sebelum pembaruan; mengontrol pengumuman duplikat, race condition, dan pergerakan fokus; serta menyertakan hasil server, tindakan coba lagi, dan pengujian daripada hanya menambahkan satu atribut aria-live.
Pertanyaan untuk klarifikasi
- Pembaruan mana yang bersifat informasi, dan mana yang memblokir tindakan berikutnya?
- Bisakah pengguna memicu permintaan bersamaan, dan apakah respons membawa nomor urut?
- Apakah kegagalan memiliki tindakan coba lagi inline, urungkan (undo), atau detail?
- Haruskah fokus tetap berada di editor setelah berhasil, dan ke mana fokus harus berpindah jika terjadi kesalahan?
- Apakah pengiriman formulir biasa, penggunaan keyboard, zoom, dan warna paksa (forced colors) diperlukan?
Jawaban 30 detik
Saya akan merender region role="status" kosong di DOM awal dan menulis pesan progres serta penyelesaian biasa ke dalamnya. Perilakunya yang sopan (polite) tidak boleh merebut fokus. Kesalahan yang dapat ditindaklanjuti mendapatkan teks yang terlihat dan jalur pemulihan di dekat kontrol; hanya peristiwa yang benar-benar mendesak yang menggunakan peringatan (alert). Saya akan menghapus duplikasi dan membatasi (throttle) pengumuman, menolak respons usang berdasarkan nomor urut, serta menguji keyboard, pembaca layar, kegagalan jaringan, dan permintaan bersamaan.
Jawaban mendalam langkah demi langkah
Langkah 1: Modelkan status secara eksplisit
Pisahkan status idle, pending, success, error, dan cancelled. Region status menyampaikan hasil saat ini, seperti "Menyimpan", "Tersimpan", atau "Gagal menyimpan; coba lagi", bukan nama permintaan internal atau setiap persentase. Simpan kesalahan field, tindakan coba lagi, dan keterkaitan kontrol secara terpisah.
Langkah 2: Buat live region terlebih dahulu
W3C dan MDN merekomendasikan pembuatan live region sebelum mengubah kontennya. role="status" cocok untuk informasi konsultatif dan memiliki aria-live="polite" implisit; jangan menambahkan atribut hanya ketika pembaruan terjadi.
<p id="save-status" role="status" aria-atomic="true"></p>
<button type="submit">Save</button>Langkah 3: Kontrol ritme pengumuman
Jangan menulis teks yang identik berulang kali atau mengumumkan setiap penekanan tombol selama pencarian. Terapkan debounce pada hasil berfrekuensi tinggi dan umumkan ringkasan yang bermakna seperti "Hasil diperbarui". Penyelesaian, kegagalan, dan tindakan yang diperlukan harus menyebutkan langkah berikutnya. aria-live="assertive" memotong ucapan dan harus jarang digunakan.
Langkah 4: Tangani race condition dan pembatalan
Beri setiap permintaan urutan yang meningkat atau AbortController. Hanya respons terbaru dari komponen yang terpasang (mounted) yang boleh memperbarui status. Permintaan yang dibatalkan bukanlah pengumuman kegagalan; permintaan baru menggantikan pesan tertunda sebelumnya.
Langkah 5: Koordinasikan fokus dan kesalahan
Jangan memindahkan fokus untuk keberhasilan biasa; biarkan pengguna melanjutkan. Untuk kegagalan, render teks yang terlihat dan kaitkan dengan kontrol menggunakan aria-describedby; kegagalan tingkat halaman memerlukan ringkasan yang dapat difokuskan dan tombol coba lagi. Pilih satu saluran utama agar lompatan fokus dan pengumuman langsung tidak saling menduplikasi.
Langkah 6: Pertahankan jalur fallback
Server harus tetap menerima pengiriman formulir biasa dan mengembalikan hasil terstruktur. Pada kegagalan JavaScript, batas waktu habis (timeout), atau izin kedaluwarsa, teks harus menyatakan status dan tindakan, seperti "Gagal menyimpan; coba lagi", daripada membiarkan spinner. Jangan menghapus input pengguna.
Trade-off dan batasan
status, alert, dan kesalahan yang terlihat
status digunakan untuk pemberitahuan yang sopan (polite); alert menginterupsi dan tidak boleh menggantikan setiap kesalahan. Kesalahan yang terlihat tetap diperlukan karena ucapan bukan satu-satunya saluran. Warna, ikon, dan animasi melengkapi teks.
Detail progres versus kebisingan (noise)
Tampilkan persentase pengunggahan secara visual, tetapi umumkan hanya awal, fase-fase penting, dan penyelesaian. Memperbarui live region setiap satu persen menimbulkan kebisingan; kalibrasi pembatasan (throttling) dengan perangkat dan pengguna nyata.
Rencana peluncuran dan bukti
Komponen dan kontrak API
Pusatkan teks pesan, deduplikasi, dan pemeriksaan urutan dalam satu komponen status. API mengembalikan field terstruktur success, retryable, dan fieldErrors; komponen memetakannya ke bahasa pengguna alih-alih mengekspos kode server.
Matriks verifikasi
Selesaikan pencarian, penyimpanan, dan pengunggahan menggunakan keyboard dan konfirmasikan satu pengumuman di NVDA dan VoiceOver. Cakup jaringan lambat, batas waktu habis, klik ganda, respons di luar urutan, pembatalan, unload, warna paksa, dan zoom 200%. Otomatiskan semantik DOM, lalu verifikasi urutan yang diucapkan secara manual.
Kesalahan umum dan tindak lanjut
Kesalahan: menambahkan aria-live secara dinamis
Biarkan node dan atribut tetap ada, lalu perbarui teksnya; jika tidak, beberapa teknologi asistif dapat melewatkan perubahan pertama.
Kesalahan: memindahkan fokus ke teks berhasil
Hal itu mengganggu pengeditan. Pertahankan fokus kecuali pengguna harus mengatasi kesalahan atau memeriksa hasil.
Kesalahan: membuat setiap kesalahan menjadi tegas (assertive)
Ucapan berprioritas tinggi menginterupsi pembacaan. Simpan hanya untuk perhatian yang benar-benar mendesak dan sediakan pemulihan yang terlihat.
Tindak lanjut: mencegah respons usang
Bandingkan urutan monotonik, atau gabungkan pembatalan dengan pemeriksaan urutan; pembatalan saja tidak membuktikan bahwa callback tidak dapat berjalan.
Tindak lanjut: membuktikan efektivitas
Bawa observasi pembaca layar, alur keyboard, kegagalan jaringan, dan bukti race condition daripada hanya hasil pemindaian otomatis.