Pertanyaan Perbedaan nyata antara UIAccessibilityLayoutChangedNotification dan UIAccessibilityScreenChangedNotification?


Saya mencoba memastikan apa yang sebenarnya terjadi secara berbeda ketika mengeposkan UIAccessibilityLayoutChangedNotification, dan a UIAccessibilityScreenChangedNotification. Dari apa yang bisa saya lihat, saya dapat menggunakannya secara bergantian di mana-mana dan tidak ada yang berbeda terjadi.

Dokumentasi Apple hanya mengatakan untuk digunakan LayoutChanged ketika (misalnya) suatu elemen telah disembunyikan atau ditampilkan, dan digunakan ScreenChanged jika seluruh layar berubah, tetapi saya tertarik dengan apa yang MEREKA lakukan ketika saya memberikan informasi ini, dan apa yang seharusnya saya lihat secara berbeda saat menggunakan satu atau yang lain.

Adakah yang bisa memberikan penjelasan yang jelas tentang perbedaan implementasi antara keduanya?


32
2018-01-06 11:18


asal


Jawaban:


Kedua pemberitahuan ini untuk konten dinamis pada tampilan, dan mengkomunikasikan perubahan ini ke VoiceOver untuk pengguna layar. Ada sedikit perbedaan antara dua pemberitahuan ini, kecuali untuk perilaku default mereka, dan "bip boop" kecil konyol untuk pemberitahuan ScreenChange.

Dalam kedua contoh, argumen

UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, arg);

Mewakili string yang akan dibaca, atau elemen pada layar, yang VoiceOver akan mengalihkan fokusnya ke. Dalam hal perubahan konteks dramatis, penting untuk mengirim fokus ke tempat yang masuk akal, atau mengumumkan bahwa perubahan tersebut telah terjadi. Salah satu pendekatan dapat diterima dari sudut pandang aksesibilitas, meskipun saya lebih memilih pendekatan yang melibatkan paling sedikit perubahan yang mungkin. Dalam hal perubahan tata letak sederhana, hampir selalu terbaik hanya untuk mengumumkan perubahan konteks, dan meninggalkan fokus di tempat itu. Meskipun kadang-kadang, elemen yang menyebabkan perubahan konteks disembunyikan, dan kemudian jelas diperlukan untuk mengarahkan sulih suara untuk menyoroti konten baru, karena perilaku default dalam kasus ini tidak terdefinisi, atau mungkin deterministik, tetapi ditentukan oleh kerangka kerja yang benar-benar tidak tahu apa-apa. tentang aplikasi Anda!

Perbedaan antara dua peristiwa, mengingat keduanya melakukan hal yang persis sama, ada dalam perilaku default mereka. Jika Anda menyediakan nil ke UIAccessibilityLayoutChangedNotification seolah-olah Anda tidak melakukan apa-apa. Jika Anda memberikan argumen nil ke UIAccessibilityScreenChangedNotification itu akan mengirim fokus ke UIObject pertama dalam hierarki tampilan Anda yang ditandai sebagai accessibilityElement, setelah semua perubahan hierarki tampilan dan gambar selesai.

UIAccessibilityLayoutChangedNotification

Contoh kasus penggunaan yang bagus untuk UIAccessibilityLayoutChangedNotification adalah untuk bentuk-bentuk dinamis. Anda ingin memberi tahu pengguna bahwa, berdasarkan keputusan yang mereka buat dalam formulir, opsi baru tersedia. Misalnya, jika dalam bentuk Anda memilih bahwa Anda adalah Veteran, area tambahan dari formulir dapat muncul untuk memberikan lebih banyak masukan, tetapi area ini mungkin telah disembunyikan ke pengguna lain yang tidak mempedulikannya. Jadi Anda bisa mengalihkan fokus ke elemen-elemen ini setelah interaksi pengguna:

UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, firstNewFormElement);

Yang akan mengalihkan fokus ke elemen yang disediakan, dan mengumumkan itu accessibilityLabel.

Atau beri tahu mereka bahwa elemen formulir baru ada di sana:

UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, @"Veterans form elements available");

Yang akan meninggalkan fokus di mana itu, tetapi VoiceOver akan mengumumkan "elemen bentuk Veteran tersedia".

Catatan: Perilaku khusus ini disadap iPad saya (8.1.2).

Atau akhirnya Anda bisa melakukan ini:

UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, nil);

Yang benar-benar tidak ada :). Serius, saya bahkan tidak berpikir kerangka backend peduli. Baris kode khusus ini benar-benar sia-sia!

UIAccessibilityScreenChangedNotification

Contoh use case yang bagus untuk UIAccessibilityScreenChangedNotification adalah situasi penjelajahan tab yang disesuaikan. Ketika seluruh layar, dengan pengecualian area navigasi Anda, berubah. Anda ingin membiarkan sulih suara mengetahui bahwa pada dasarnya seluruh layar berubah, tetapi TIDAK untuk memfokuskan elemen pertama (tab pertama Anda) tetapi untuk memfokuskan elemen konten pertama.

UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, firstNonGlobalNavElement);

Yang akan memainkan suara "boop beep" dan kemudian mengalihkan fokus ke tepat di bawah bar navigasi global Anda. Atau Anda bisa melakukan ini:

UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, @"You're on a new tab");

Yang akan menunggu tab baru dimuat, memutar suara "bip boop", mengumumkan "Anda berada di tab baru" di sulih suara, lalu mengalihkan fokus ke elemen pertama di layar, lalu mengumumkan AccessLabel untuk elemen itu. (PHEW! Itu banyak! Ini menggelegar bagi pengguna pembaca layar. Hindari skenario ini, kecuali benar-benar diperlukan).

Dan akhirnya Anda tentu saja bisa melakukan ini:

UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, nil);    

Yang setara dengan:

UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, firstA11yElement);

Keduanya akan memutar suara "bip boop", menggeser fokus VoiceOver ke elemen pertama di layar, dan kemudian mengumumkannya.

Akhirnya

Dalam komentar seseorang menyebutkan caching, dan saya kadang-kadang berkomentar tentang jawaban saya tentang hal-hal yang mungkin tidak diperhatikan atau tidak diperhatikan oleh Backend A11y. Meskipun tentu saja mungkin bahwa ada beberapa keajaiban backend yang terjadi, saya tidak percaya pada kedua keadaan ini, ujung belakang peduli sama sekali. Alasan saya mengatakan ini karena:

Jika Anda pernah menggunakan UIAccessibilityContainer protokol, Anda dapat menyaksikan penampung pandangan Anda ditanya. Tidak ada caching yang sedang berlangsung. Bahkan itu accessibilityElementCount properti melakukan ping setiap kali VoiceOver mengubah fokus ke AccessibilityElement baru dalam penampung Anda. Kemudian ia melewati proses pengecekan elemen mana, meminta elemen berikutnya, dan seterusnya. Ini dirancang pada intinya untuk menangani situasi yang dinamis. Jika Anda memasukkan elemen baru ke dalam wadah Anda setelah interaksi, itu masih akan melalui semua pertanyaan ini dan baik-baik saja tentang itu! Selanjutnya, jika Anda mengganti properti protokol UIAccessibility, untuk memberikan petunjuk dan label yang dinamis, Anda juga dapat melihat bahwa fungsi-fungsi ini dipanggil setiap saat! Karena itu, saya yakin bahwa A11y Framework mendukung informasi yang TIDAK BENAR-BENAR ZERO dari pemberitahuan ini. Satu-satunya informasi yang VoiceOver butuhkan untuk melakukan tugasnya adalah Elemen Aksesibilitas yang saat ini difokuskan, dan elemen ini Container Aksesibilitas. Notifikasi hanya ada untuk Anda agar aplikasi Anda lebih bermanfaat untuk pengguna VoiceOver.

Bayangkan jika ini tidak terjadi berapa kali Safari akan memposting pemberitahuan ini !!!! :)

Pernyataan-pernyataan khusus ini hanya dapat dikonfirmasi oleh seseorang dengan pengetahuan backend kerangka kerja, yang bekerja dengan kode, dan harus dilihat sebagai dugaan. Bisa jadi kasus ini sangat bergantung pada versi / implementasi. Pasti terbuka untuk diskusi tentang poin-poin ini! Sisa dari posting ini cukup konkret.

Untuk referensi Anda

Sebagian besar ini berasal dari pengalaman bekerja dengan kerangka kerja, tetapi di sini adalah referensi yang berguna jika Anda ingin menggali lebih jauh.

https://developer.apple.com/documentation/uikit/accessibility/uiaccessibility

https://developer.apple.com/documentation/uikit/uiaccessibilitylayoutchangednotification

https://developer.apple.com/documentation/uikit/uiaccessibilityscreenchangednotification

Dan akhirnya, repo open source dari aplikasi kecil konyol yang saya kumpulkan untuk menguji semua hal ini.

https://github.com/chriscm2006/IOS-A11y-Api-Test


42
2018-02-05 20:54



UIAccessibilityScreenChangedNotification adalah untuk menunjukkan bahwa seluruh layar telah berubah dan VoiceOver harus diatur ulang.

UIAccessibilityLayoutChangedNotification adalah untuk menunjukkan bahwa satu atau lebih, tetapi tidak semua, elemen di layar telah berubah.

ketika UI Anda berubah secara dramatis. Biasanya ketika pengguna pindah ke bagian yang berbeda dari aplikasi Anda (menavigasi ke layar yang berbeda). VoiceOver memberi tahu pengguna dengan nada, dan menghapus cache dan melakukan persiapan lain untuk menangani serangkaian data aksesibilitas baru. Ini memberi tahu VoiceOver bahwa layar telah berubah dan mungkin ada elemen baru di layar sehingga VoiceOver akan membangun kembali indeks elemen aksesibilitasnya.

UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, nil);

Jika beberapa bagian dari UI Anda berubah, tetapi pengguna belum tentu melompat ke bagian aplikasi Anda yang sepenuhnya berbeda. (Contoh: di aplikasi iTunes Store, mengetuk label harga ($ 0,99, dll.) Di sebelah lagu mengubahnya menjadi tombol "Beli".) Pemberitahuan ini memberi tahu VoiceOver untuk membaca kembali status saat ini dari semua item yang dapat diakses yang ada di layar, dan dengan melakukan hal ini, angka akan berubah dan menginformasikan pengguna tentang perubahan tersebut. Ini memberi tahu VoiceOver bahwa tata letak telah berubah dan indeks saat ini sudah kedaluwarsa karena item di layar telah mengatur ulang sendiri.

UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, nil);

-1
2018-02-04 23:52