Gesaan dan konteks
Carian, simpan dan muat naik selesai tanpa navigasi atau memindahkan fokus. Pengguna visual melihat “Menyimpan”, “Disimpan”, atau “Gagal menyimpan”, manakala kemas kini mungkin berlaku di luar kawalan yang difokuskan. Matlamatnya adalah pengumuman yang pendek dan boleh diambil tindakan yang tidak mengganggu input, dengan sandaran untuk papan kekunci, tanpa skrip dan kegagalan rangkaian.
Perkara yang diuji oleh penemu duga
Jawapan harus membezakan status nasihat, ralat dan amaran mendesak; mewujudkan live region sebelum kemas kini; mengawal pengumuman pendua, keadaan perlumbaan (race conditions) dan pergerakan fokus; serta menyertakan hasil pelayan, tindakan cuba semula dan ujian dan bukannya hanya menambah satu atribut aria-live.
Soalan untuk penjelasan
- Kemas kini yang manakah berbentuk nasihat, dan yang manakah menyekat tindakan seterusnya?
- Bolehkah pengguna mencetuskan permintaan serentak, dan adakah respons membawa nombor jujukan?
- Adakah kegagalan mempunyai tindakan cuba semula sebaris, buat asal (undo) atau butiran?
- Patutkah fokus kekal dalam editor selepas berjaya, dan ke manakah ia harus pergi jika berlaku ralat?
- Adakah penyerahan borang biasa, penggunaan papan kekunci, zum dan warna paksaan (forced colors) diperlukan?
Jawapan 30 saat
Saya akan memaparkan kawasan role="status" kosong dalam DOM awal dan menulis mesej kemajuan serta penyelesaian biasa ke dalamnya. Tingkah lakunya yang sopan (polite) tidak sepatutnya mencuri fokus. Ralat yang boleh diambil tindakan mendapat teks yang kelihatan dan laluan pemulihan berhampiran kawalan; hanya peristiwa yang benar-benar mendesak menggunakan amaran (alert). Saya akan menyahduplikasi dan mendikit pengumuman, menolak respons lapuk mengikut nombor jujukan, dan menguji papan kekunci, pembaca skrin, kegagalan rangkaian serta permintaan serentak.
Jawapan mendalam langkah demi langkah
Langkah 1: Modelkan keadaan secara eksplisit
Asingkan idle, pending, success, error, dan cancelled. Kawasan status menyatakan hasil semasa, seperti “Menyimpan”, “Disimpan”, atau “Gagal menyimpan; cuba semula”, dan bukannya nama permintaan dalaman atau setiap peratusan. Simpan ralat medan, tindakan cuba semula dan perkaitan kawalan secara berasingan.
Langkah 2: Cipta live region terlebih dahulu
W3C dan MDN mengesyorkan mencipta live region sebelum menukar kandungannya. role="status" sesuai untuk maklumat nasihat dan mempunyai aria-live="polite" tersirat; jangan tambah atribut hanya apabila kemas kini berlaku.
<p id="save-status" role="status" aria-atomic="true"></p>
<button type="submit">Save</button>Langkah 3: Kawal kekerapan pengumuman
Jangan tulis teks yang sama berulang kali atau mengumumkan setiap ketukan kekunci semasa carian. Lakukan debounce pada hasil berfrekuensi tinggi dan umumkan ringkasan yang bermakna seperti “Keputusan dikemas kini”. Penyelesaian, kegagalan dan tindakan yang diperlukan harus menyatakan langkah seterusnya. aria-live="assertive" mengganggu pertuturan dan sepatutnya jarang digunakan.
Langkah 4: Kendalikan perlumbaan dan pembatalan
Beri setiap permintaan jujukan yang meningkat atau AbortController. Hanya respons terbaharu daripada komponen yang dilekapkan (mounted) boleh mengemas kini status. Permintaan yang dibatalkan bukan pengumuman kegagalan; permintaan baharu menggantikan mesej tertangguh sebelumnya.
Langkah 5: Selaraskan fokus dan ralat
Jangan alihkan fokus untuk kejayaan biasa; biarkan pengguna meneruskan. Untuk kegagalan, paparkan teks yang kelihatan dan kaitkannya dengan kawalan menggunakan aria-describedby; kegagalan peringkat halaman memerlukan ringkasan yang boleh difokuskan dan butang cuba semula. Pilih satu saluran utama supaya lompatan fokus dan pengumuman langsung tidak menduplikasi antara satu sama lain.
Langkah 6: Kekalkan laluan sandaran
Pelayan masih perlu menerima penyerahan borang biasa dan mengembalikan hasil berstruktur. Apabila berlaku kegagalan JavaScript, tamat masa, atau kebenaran tamat tempoh, teks harus menyatakan status dan tindakan, seperti “Gagal menyimpan; cuba lagi”, bukannya membiarkan pemutar (spinner). Jangan padamkan input pengguna.
Pertukaran dan sempadan
status, alert, dan ralat yang kelihatan
status adalah untuk pemberitahuan sopan; alert mengganggu dan tidak seharusnya menggantikan setiap ralat. Ralat yang kelihatan tetap perlu kerana pertuturan bukan satu-satunya saluran. Warna, ikon dan animasi melengkapkan teks.
Butiran kemajuan berbanding hingar (noise)
Tunjukkan peratusan muat naik secara visual, tetapi umumkan hanya permulaan, fasa penting dan penyelesaian. Mengemas kini live region setiap satu peratus menimbulkan hingar; tentukur pendikit dengan peranti dan pengguna sebenar.
Pelan pelancaran dan bukti
Kontrak komponen dan API
Pusatkan teks mesej, penyahduplikasian dan semakan jujukan dalam satu komponen status. API mengembalikan medan berstruktur success, retryable, dan fieldErrors; komponen memetakan medan tersebut ke bahasa pengguna dan bukannya mendedahkan kod pelayan.
Matriks pengesahan
Selesaikan carian, simpan dan muat naik menggunakan papan kekunci serta sahkan satu pengumuman dalam NVDA dan VoiceOver. Lindungi rangkaian perlahan, tamat masa, dwiklik, respons tidak mengikut urutan, pembatalan, nyahmuat, warna paksaan dan zum 200%. Automatikkan semantik DOM, kemudian sahkan susunan pertuturan secara manual.
Kesilapan lazim dan tindakan susulan
Kesilapan: menambah aria-live secara dinamik
Kekalkan nod dan atribut sedia ada, kemudian kemas kini teksnya; jika tidak, sesetengah teknologi bantuan mungkin terlepas perubahan pertama.
Kesilapan: memindahkan fokus kepada teks kejayaan
Tindakan itu mengganggu penyuntingan. Kekalkan fokus melainkan pengguna mesti menangani ralat atau memeriksa hasil.
Kesilapan: menjadikan setiap ralat sebagai asertif (assertive)
Pertuturan berkeutamaan tinggi mengganggu pembacaan. Khaskannya untuk perhatian yang benar-benar mendesak dan sediakan pemulihan yang kelihatan.
Tindakan susulan: menghalang respons lapuk
Bandingkan jujukan monotonik, atau gabungkan pembatalan dengan semakan jujukan; pembatalan sahaja tidak membuktikan bahawa panggilan balik tidak boleh dijalankan.
Tindakan susulan: membuktikan keberkesanan
Bawakan pemerhatian pembaca skrin, aliran papan kekunci, kegagalan rangkaian dan bukti keadaan perlumbaan dan bukannya hanya hasil imbasan automatik.