Chosen: Masalah aksesibilitas dengan Terpilih

bagian yang relevan dari diskusi itu:

Terlalu banyak membutuhkan pekerjaan. Tampaknya aksesibilitas belum dipertimbangkan di
semua ada di widget ini, jadi banyak pekerjaan WAI-ARIA dan JS akan diperlukan untuk *
upaya * untuk membuat ini sesuai dengan WCAG 2.0.

Masalah terbesar, dari ulasan 30 detik dengan FF6 / JAWS12 adalah bahwa
komponen direpresentasikan sebagai tipe input = teks diikuti oleh daftar yang tidak berurutan
dari semua opsi (243 untuk negara) yang harus dilalui pengguna untuk menavigasi
bahkan mengabaikan lapangan.

Bidang teks pencarian dapat menggunakan label, sebagai permulaan, tetapi itu mudah diperbaiki.

Masalah yang lebih besar adalah bahwa item daftar yang dihasilkan tidak memiliki jangkar di dalamnya... dapatkah pengguna pembaca layar mengambil tindakan jika mereka tahu untuk apa item daftar itu?

Ini adalah plugin yang sangat bagus! Saya sangat menyukai fungsionalitasnya.
Apakah akan ada pengembangan di masa depan untuk aksesibilitas yang lebih baik? Menambahkan WAI-ARIA agar sesuai dengan WCAG 2.0???

Saya baru saja membaca artikel ini di situs web thefilamentsgroups. Peran ARIA dapat membantu Terpilih:
http://filamentgroup.com/lab/jquery_ipod_style_and_flyout_menus/

Misalnya: UL hasil Terpilih akan menerapkan role="menu" aria-activedescendant="active-menuitem" dan hasil <li> akan memiliki role="menuitem".
Kotak pencarian di drop-down Terpilih mungkin akan membutuhkan semacam peran ARIA juga??

@dotdreaming Anda menunjuk ke dokumentasi yang tepat, tetapi peran yang Anda sebutkan tidak sepenuhnya benar.

Saya pikir peran berikut harus digunakan:

• kotak kombo .
• pilihan

Saya pikir akan sangat keren jika seseorang benar-benar menyelami dokumentasi WAI-ARIA dan menerapkannya pada yang dipilih.

Jika saya dapat menemukan waktu saya dapat melakukan ini sendiri. Sepertinya itu tidak akan terlalu sulit untuk dilakukan.

Adakah gerakan untuk memasukkan ARIA ke dalam proyek ini?

Bahkan jika itu bekerja dengan Teknologi Bantuan, itu juga perlu diuji untuk melihat bahwa itu juga bekerja dengan pengguna keyboard saja.

Btw, ini hanya cara untuk memeriksa buah menggantung rendah untuk peningkatan aksesibilitas, tetapi WAVE mengidentifikasi beberapa hal mendasar yang harus dibersihkan -> http://wave.webaim.org/report?url=http%3A% 2F%2Fharvethq.github.com%2Fchosen%2F&js=2

Apakah salah satu dari masalah aksesibilitas ini telah diatasi? Saya sangat suka menggunakan ini di situs universitas utama kami, tetapi masalah aksesibilitas ini membuat saya bingung

+1 - Kami telah menerima umpan balik dari pengguna tunanetra bahwa daftar tarik-turun Terpilih sulit digunakan dan mereka kesulitan memilih opsi. Mereka menggunakan JAWS 14 sebagai pembaca layar mereka.

Dicoba hanya menggunakan keyboard saja untuk navigasi. Memilih item bekerja dengan sangat baik dan intuitif (bawah untuk membuka daftar item baru, atas/bawah untuk menavigasi daftar, esc untuk menutup daftar, enter untuk memilih). Menghapus item dari multiselect itu mudah (backspace) namun menghapus dropdown satu-pilih menghadirkan lebih banyak tantangan. Sepertinya, setelah memilih item, saya dapat menekan untuk membuka daftar lagi dan kemudian menavigasi ke atas hingga tidak ada opsi yang dipilih (seperti dropdown normal berfungsi jika item pertama Anda kosong seperti contohnya), tapi saya tidak dapat menekan Enter untuk memilih opsi null. Beberapa metode untuk membatalkan pilihan opsi sepenuhnya (atau setidaknya opsi default kosong) akan sangat berguna.

Juga tidak yakin apakah ini bermanfaat, tetapi saya perhatikan bahwa data masih disimpan dalam kontrol pilih yang tersembunyi (saya berasumsi ini adalah cara memasukkannya ke dalam formulir). Mungkin bermanfaat untuk memperbarui dropdown Terpilih ketika pilih diubah juga - Saya berdebat apakah ini akan memenuhi kriteria 4.1.2 dari WCAG, karena UA dapat berinteraksi dengan kontrol pilih secara terprogram dan kami dapat memperlakukan Terpilih sebagai fasad pada di atasnya untuk tujuan aksesibilitas.

untuk bagian kedua, kami membutuhkan untuk memicu listz:updated bahkan ketika Anda mengubah nilai kontrol pilih secara terprogram untuk memperbarui yang dipilih.
Ini diperlukan karena browser tidak memicu suatu peristiwa ketika nilainya diubah secara terprogram untuk memberi tahu Terpilih tentangnya (dan jika mereka melakukannya, kami masih harus menghindari pengulangan tak terbatas karena kami juga mengubahnya secara terprogram)

Saya akan melihat menambahkan aksesibilitas hari ini. @marklagendijk Saya pikir apa yang Anda sebutkan cara terbaik untuk pergi ke atm. Saya akan memperbarui temuan saya.

Ini mungkin membantu, mungkin tidak, tetapi kami memiliki pedoman aksesibilitas yang ketat untuk diikuti dan dengan versi 1.0.0 penguji aksesibilitas klien kami kembali dengan komentar berikut:

1. 'pilih' yang terkait dengan 'label' memiliki tampilan: tidak ada; dan jadi
   'label' secara efektif menjadi yatim piatu. 'div class="chosen-container-single"' yang membutuhkan
   tempatnya sebagai kontrol formulir tidak memiliki nama atau label yang dapat diakses secara terprogram.

2. Tidak ada fokus yang terlihat pada dropdown palsu.

1. Tidak ada fokus yang terlihat pada tautan di dalam dropdown palsu.

Saya menggunakan ini bersama dengan modul Terpilih Drupal. Kami juga memiliki seorang penguji buta yang mencatat bahwa begitu dia mendapatkan input, dia tidak menyadari bahwa dia dapat mengetik, atau hasilnya kembali, termasuk "Tidak ada hasil yang ditemukan".

@marklagendijk
Setiap kemajuan dalam masalah ini. Saya melihat untuk memperkenalkan kembali masalah untuk menambahkan Terpilih ke inti Drupal dan ini adalah pemblokir utama.

Saya menemukan contoh yang sangat bagus tentang bagaimana ini dapat dilakukan di sini:
http://cookiecrook.com/test/aria/multiselect/listbox.html
Inilah javascriptnya: http://cookiecrook.com/test/aria/multiselect/js/aria.js

Saya percaya bahwa ini memetakan hampir persis dengan fungsi dasar yang dipilih. Terlihat cukup sederhana untuk diimplementasikan menggunakan properti aria listbox dan multiselectable
http://www.w3.org/TR/wai-aria/roles#listbox
http://www.w3.org/TR/wai-aria/states_and_properties#aria -multiselectable

Saya akan membuat tambalan sendiri tetapi saya tidak terlalu mahir di js.

PR saya yang ditautkan di atas memberikan solusi melalui pendekatan yang lebih sederhana yang berpusat di sekitar prinsip peningkatan progresif alih-alih mengambil "penyelaman mendalam" untuk membuat widget yang sepenuhnya dapat diakses dari basis kode Terpilih saat ini. Saya menyambut setiap dan semua umpan balik.

Mengapa fokus pada ARIA ketika masih belum didukung dengan baik oleh IE8? Sayangnya browser berusia 5 tahun ini masih masuk dalam daftar browser umum. Ini berarti bahwa saat menjalani pemindaian aksesibilitas, implementasi yang bergantung pada ARIA akan gagal.

Mengapa tidak menggunakan metode fallback yang hanya menonaktifkan semua yang dipilih dan memberi pengguna pilihan asli? Ini dapat dicapai dengan menambahkan tautan (tersembunyi) yang akan menggunakan sepotong kecil kode javascript yang menonaktifkan yang dipilih.

Sumber daya tentang dukungan IE8 ARIA: http://www.w3.org/TR/WCAG20-TECHS/wai-aria_notes.html

Anda bisa saja melakukan deteksi browser/fitur dan tidak menggunakan Terpilih saat IE8 digunakan.

@ Daniel15 Itu mungkin akan menjadi perbaikan yang lebih mudah. Thanx untuk berbagi pemikiran Anda. Dalam posting saya, saya hanya mencoba untuk menunjukkan bahwa menerapkan ARIA (untuk saat ini) tidak berarti dapat diakses dan siap digunakan pada aplikasi yang harus sesuai dengan WCAG 2.0.

Akan senang melihat ini bekerja. Pembaca layar dan pengguna hanya keyboard benar-benar membutuhkan akses ke bidang ini. Saya tidak begitu peduli dengan IE8 tetapi setidaknya solusi untuk browser modern dapat diterima. Saya cukup menyukai ide mundur IE8. Sepertinya ada dua PR yang bagus - saya ingin melihat salah satu dari mereka bergabung.

tolong beri +1 besar untuk ini

+1 (+) Kita perlu memiliki ini di Terpilih. Ini masalah

aria-label (properti)

Mendefinisikan nilai string yang melabeli elemen saat ini. Lihat juga aria-labelledby.

Tujuan aria-label sama dengan aria-labelledby. Ini memberi pengguna nama objek yang dapat dikenali. Pemetaan API aksesibilitas yang paling umum untuk label adalah properti nama yang dapat diakses.

Jika teks label terlihat di layar, penulis HARUS menggunakan aria-labelledby dan TIDAK HARUS menggunakan aria-label. Mungkin ada kasus di mana nama elemen tidak dapat ditentukan secara terprogram dari konten elemen, dan ada kasus di mana memberikan label yang terlihat bukanlah pengalaman pengguna yang diinginkan. Sebagian besar bahasa host menyediakan atribut yang dapat digunakan untuk menamai elemen (mis. atribut judul dalam HTML [HTML]), namun ini mungkin menampilkan tooltip browser. Dalam kasus di mana label yang terlihat atau tooltip yang terlihat tidak diinginkan, penulis MUNGKIN mengatur nama elemen yang dapat diakses menggunakan aria-label. Agen pengguna mengutamakan aria-labelledby daripada aria-label saat menghitung properti nama yang dapat diakses.

@Natshah Bisakah Anda melakukan permintaan tarik dengan perubahan?

@Natshah sebenarnya, dapatkah Anda meninjau https://github.com/harvethq/chosen/pull/2047 untuk melihat apakah itu mengimplementasikannya dengan cara yang benar?

Hai,

Saya telah memperbaiki ini untuk kasus saya di tautan ini
https://www.drupal.org/node/2384865

Terima kasih.

Menghargai :)

Ya. Itu apa yang seharusnya seperti pada kode berikut. .

      if (this.is_multiple) {
        this.container.html('<ul class="chosen-choices"><li class="search-field"><input type="text" aria-label="' + this.form_field_jq.parents("label") +'" value="' + this.default_text + '" class="default" autocomplete="off" style="width:25px;" /></li></ul><div class="chosen-drop"><ul class="chosen-results"></ul></div>');
      } else {
        this.container.html('<a class="chosen-single chosen-default" tabindex="-1"><span>' + this.default_text + '</span><div><b></b></div></a><div class="chosen-drop"><div class="chosen-search"><input type="text" aria-label="' + this.form_field_jq.parents("label") +'"  autocomplete="off" /></div><ul class="chosen-results"></ul></div>');
      }

Tapi kita bisa menggunakan kode ini:

        $(".views-exposed-widget").each(function( index, element ) {
           $(this).find('.form-type-select .chosen-container input').attr("aria-label" ,$.trim($(this).find('label').text()));
        });

Terima kasih.

Menghargai :)

Ada pembaruan tentang ini? Kami baru-baru ini menerapkan pilihan, dan mendapat umpan balik dari pengguna yang menggunakan teknologi bantu "Jaws" bahwa mereka tidak dapat menggunakan bidang pilihan sama sekali.

Sepertinya masalah penting untuk diperhatikan. Apakah ada gerakan di bagian depan ini?

Tidak ada yang saya ketahui, sayangnya sangat sulit untuk mereplikasi masalah mengingat kombinasi besar teknologi bantu dengan browser dan OS ... Biasanya selama Anda dapat menavigasi keyboard + Anda memiliki implementasi ARIA yang benar, itu akan berfungsi di sebagian besar kasus.

Untuk perbaikan cepat, saya terpaksa memastikan bahwa pembaca layar setidaknya dapat menggunakan bidang pilih asli. Untuk ini, alih-alih menyembunyikan elemen pilih, saya menambahkan kelas screenreaders-only dan aria-hidden:true pada wadah terpilih yang dihasilkan.

Jadi, di chosen.jquery.js baris 599 to 605 terlihat seperti ini:

container_props = {
        'class': container_classes.join(' '),
        'style': "width: " + (this.container_width()) + ";",
        'title': this.form_field.title,
        // hide widget for screen-readers
        'aria-hidden': 'true'
};

Dan baris 616 terlihat seperti ini:

      // instead of hiding the original select field, adding the .sr-only class to keep it accessible for screen readers
      this.form_field_jq.addClass('sr-only').after(this.container);

Ini bukan solusi sempurna, karena pilihan tersembunyi dan widget dapat difokuskan pada keyboard, tetapi jauh lebih baik daripada memiliki widget yang tidak dapat diakses.

Ini berhasil untuk saya.
Saya mengikuti semua saran di atas dan saya mengubah baris berikut:

this.container.bind('mousedown.chosen', function(evt)   // around line 630

ke:

this.container.bind('mousedown.chosen keydown.chosen', function(evt)

Terima kasih

Coba jika berhasil. Strukturnya harus seperti ini. :)

Saya mencoba menambahkan beberapa elemen ARIA berdasarkan pekerjaan yang telah dilakukan @kirstenmalin . Pekerjaan itu adalah dorongan yang bagus menuju A11Y, tetapi kehilangan beberapa item yang saya tambahkan.

Saya memiliki cabang yang tersedia di sini yang melakukan hal berikut:

Label ARIA dan Atribut Bermanfaat Lainnya

• Menambahkan elemen aria berikut ke kotak input pencarian
  
  
  
  • peran = "kotak kombo"
  
  
  • Digunakan untuk menunjukkan bahwa pengguna dapat mengetik untuk memilih opsi atau menambahkan elemen baru ke daftar
  
  
  • aria-haspopup (tersirat saat menggunakan peran kotak kombo)
  
  
  • Digunakan untuk menunjukkan bahwa kotak ini memiliki menu terkait
  
  
  • aria-diperluas
  
  
  • Diperlukan saat menggunakan kotak kombo, menunjukkan bahwa daftar hasil terlihat atau disembunyikan
  
  
  • Status perlu diperbarui secara dinamis karena bidang yang dipilih diaktifkan/dinonaktifkan
  
  
  • aria-activedescendant="id_of_highlighted_option"
  
  
  • Digunakan untuk menunjukkan opsi mana yang merupakan nilai yang dipilih saat ini
  
  
  • Ini perlu diperbarui karena opsi baru dipilih
  
  
  • aria-owns="id_of_list_of_options"
  
  
  • Menunjukkan daftar pilihan yang terkait dengan kotak pencarian ini
  
  
  • aria-autocomplete="daftar"
  
  
  • "Jika seorang penulis menetapkan nilai kotak kombo dari aria-autocomplete ke 'daftar', agen pengguna HARUS mengekspos perubahan pada atribut aria-activedescendant pada kotak kombo sementara kotak kombo tetap fokus. Jika perubahan pada atribut aria-activedescendant terjadi saat kotak kombo terfokus, teknologi bantu HARUS mengingatkan pengguna tentang perubahan itu, misalnya, dengan mengucapkan alternatif teks dari elemen turunan aktif yang baru. Penulis HARUS mengaitkan bidang teks kotak kombo dengan kotak daftarnya menggunakan aria-owns."
  
  
  • aria-labeledby="id_of_field_label"
  
  
  • Ini adalah ID dari elemen label formulir yang dipilih untuk diganti
  
  
• Menambahkan atribut berikut ke daftar opsi
  
  
  
  • Indo
  
  
  • ID sederhana berdasarkan ID bidang formulir yang akan ditargetkan oleh atribut aria-owns di kotak input pencarian
  
  
  • peran = "kotak daftar"
  
  
  • "Sebuah widget yang memungkinkan pengguna untuk memilih satu atau lebih item dari daftar pilihan."
  
  
• Menambahkan atribut berikut ke setiap opsi individu dalam daftar opsi
  
  
  
  • Indo
  
  
  • ID sederhana berdasarkan indeks opsi dalam daftar dan ID bidang formulir yang akan digunakan oleh aria-activedescendant yang menunjukkan elemen yang dipilih saat ini
  
  
  • peran = "pilihan"
  
  
  • Item yang dapat dipilih dalam daftar pilih.
  
  
  • aria-sibuk
  
  
  • Alasan kita membutuhkan ini adalah bahwa ketika Terpilih diinisialisasi pada suatu bidang, ia _tidak_ membangun daftar opsi sampai bidang tersebut pertama kali diaktifkan.
  
  
  • Ini adalah masalah untuk teknologi assitif, serta pemindai yang mencari masalah aksesibilitas. Karena kotak telusur (role="combobox") sekarang dihapus, ia memiliki kotak daftar (aria-owns="id_of_list_of_options"), kotak daftar (daftar hasil kami) _harus_ memiliki opsi di dalamnya ATAU dihapus sebagai sibuk untuk mematuhi spesifikasi.
    
    
    
    
    
    • Saya bahkan tidak 100% yakin bahwa ini adalah langkah yang benar. Ini tentu saja mencegah bidang ditandai oleh pemindai, tetapi ini tidak sepenuhnya sibuk, kami hanya belum membuat opsi.
    
    
    
  
  
  • Saya berharap seseorang dengan lebih banyak pengalaman A11Y dapat mempertimbangkan hal ini.
  
  
  • Saya juga mempertimbangkan pendekatan yang lebih radikal, yang melibatkan pembuatan daftar hasil saat bidang pertama kali diaktifkan, tetapi itu melibatkan penambahan pemicu baru ke Terpilih.
    
    
    
    
    
    • Pemicu ini pada dasarnya melewati metode winnow_results, yang membangun hasil pencarian (masih tersembunyi), tetapi membuat pemindai senang.
    
    
    
  
  

Mengelola Negara

• Mengelola atribut aria-expanded
  
  
  
  • Untuk menunjukkan kapan hasil pencarian harus relevan dengan teknologi assitive, kita perlu mengaktifkan atribut aria-expanded saat bidang diaktifkan/dinonaktifkan.
  
  
  • Cara termudah untuk melakukannya (AFAIK) adalah menyesuaikan atribut selama metode close_field dan activate_field .
  
  
  • Peralihan sederhana dari true ke false atau false ke true di masing-masing metode ini cukup untuk membuat status diperbarui
  
  

Saya akan mulai menggunakan versi ini pada beberapa proyek kami, dan akan terus memperbarui cabang saya dengan perubahan saat kami melihat lebih detail proyek kami dari tampilan A11Y.

Terima kasih kepada semua yang membaca sejauh ini, saya tahu ini banyak dan tolong, jika Anda memiliki umpan balik, beri tahu saya! Saya ingin mendorong ini sejauh mungkin.

@cooperfellows silakan buka permintaan tarik dengan perubahan Anda

@stof Selesai, tetapi seperti yang saya katakan, saya bukan ahli A11Y, dan saya berencana untuk melakukan beberapa pengujian lagi. Saya hanya ingin berbagi tentang stable pass pertama saya di sini.

Apakah ada pembaruan "resmi" dengan ini? Apakah ada perubahan yang dibuat berdasarkan upaya @cooperfellows ?

Alasan saya bertanya adalah bahwa kami mendapatkan peningkatan jumlah pengguna Jaws yang melaporkan widget sebagai tidak dapat digunakan, secara efektif membuat formulir yang mereka lihat tidak dapat digunakan.

Kami dapat mereplikasi, sangat senang untuk membantu / berbagi contoh jika itu membantu?

Permintaan tarik dibuat (ada beberapa masalah kecil yang telah diselesaikan setelah fakta) tetapi belum ada yang terjadi. Cabang yang saya gunakan dalam produksi sekarang ada di sini:

• https://github.com/cooperfellows/chosen/tree/a11y-updates

Saya ingin beberapa umpan balik lainnya. Saya tidak punya Jaws, jadi saya mengandalkan audit dari berbagai alat online.

Jadi cabang itu pada dasarnya adalah produksi saat ini ditambah perubahan Anda, atau versi sebelumnya dengan perubahan terbaru yang belum digabungkan?

(Terima kasih BTW)

Ya, itu benar @wcndave. Meskipun PR benar-benar bisa menggunakan beberapa mata lain untuk ditinjau.

@cooperfellows Saya senang membantu dengan pengujian aksesibilitas karena saya perlu

Adakah pembaruan pada permintaan tarik Anda?

Pertanyaan konyol - apakah Anda memiliki versi JavaScript terkompilasi yang dapat saya unduh?
Atau apakah saya perlu menginstal coffeescript dan mengkompilasi sendiri?

@KITSKevinBonett Terima kasih atas bantuannya!

Terlampir adalah zip versi jquery dan tipe proto, baik terkompresi maupun tidak terkompresi.

dikompilasi-a11y-dipilih-jquery-proto.zip

@cooperfellows Itu cepat. Saya akan menambahkan ke proyek kami, melakukan beberapa pengujian, dan memberi tahu Anda...

@KITSKevinBonett Ya, saya ingin lebih memperhatikannya, karena saya bukan ahli A11Y. Jadi setiap umpan balik (keras dan positif) dihargai.

Hai @cooperfellows - Saya telah meninjau implementasi Anda - memang sangat bagus.

Ada beberapa masalah yang mungkin tidak (dengan mudah) diselesaikan karena pembaca layar/browser tidak kompatibel.

Saya telah mendokumentasikan temuan saya dalam lampiran. Saya telah membuat 1 atau 2 rekomendasi kecil yang saya harap bermanfaat bagi Anda.

_MEMPERBARUI_

1. Beberapa komentar saya menyebutkan fungsionalitas yang bersifat lokal untuk implementasi kami - saya telah menghapusnya.
2. Masalah dengan mengetik di dalam "kotak kombo" dan menekan ENTER - pengiriman formulir kami tidak diaktifkan - sekali lagi, ini adalah masalah implementasi lokal.
3. ZIP di bawah ini telah diperbarui untuk menghapus (1) dan (2).

aria-chosen-plugin.zip

Hai @cooperfellows - apakah audit saya masuk akal?

Hai @KITSKevinBonett Saya sudah pergi berlibur selama seminggu. Saya akan melihat ini segera setelah saya menyelesaikan pekerjaan saya yang lain. Terima kasih atas umpan baliknya, saya yakin itu membantu.

@KITSKevinBonett Terima kasih atas auditnya, ini tampaknya cukup menyeluruh. Saya telah membagi pemikiran saya berdasarkan bagian audit saat Anda menjelaskannya.

Markup HTML yang dihasilkan oleh plugin

• Apakah ada umpan balik di sini? Atau apakah Anda hanya menunjukkan apa yang dihasilkan?

Perilaku Hanya Keyboard

• "Namun, ketika opsi telah dipilih, fokus keyboard hilang saat tab kembali."
  
  
  
  • Saya pikir ini dapat diselesaikan dengan mengaktifkan dan menonaktifkan atribut aria-hidden saat elemen itu dibuat terlihat/disembunyikan?
  
  
  • Saya akan melihat ke dalam pendekatan ini.
  
  
• "Masalah CSS Dinonaktifkan"
  
  
  
  • Pilihan standar terlihat
  
  
  • Saya tidak dapat membuat ulang ini, dapatkah Anda memberi saya tangkapan layar atau pemeran layar atau sesuatu?
  
  
  • Tidak ada isyarat yang terlihat saat menyorot hasil dengan keyboard.
  
  
  • Kita dapat membungkus teks dari item yang saat ini disorot dalam tag <em> , yang dicetak miring (setidaknya di Chrome).
    
    
    
    
    
    • Masalah potensial di sini adalah bahwa pencarian juga menggunakan <em> untuk menunjukkan kecocokan teks, jadi saya khawatir itu akan berpotensi konflik satu sama lain.
    
    
    
  
  

Pembaca Layar

• Saya tidak memiliki akses ke JAWS, jadi saya tidak akan dapat melakukan banyak hal di sini. Saya akan melakukan percobaan ketika saya mendapatkan lebih banyak waktu untuk melihat apa yang dapat saya temukan.
• Pembaca layar adalah area yang saya akan sangat menghargai bantuan lebih lanjut, jadi terima kasih atas perinciannya.

Pikiran Aria

• Saya dapat menghapus atribut haspopup, seperti yang Anda catat, itu berlebihan.
• Alasan saya menambahkan aria-busy, adalah karena secara default, Terpilih tidak menghasilkan elemen daftar apa pun di div tersembunyi hingga fokus ditempatkan.
  
  
  
  • Ini berarti bahwa elemen role="listbox" tidak memiliki opsi secara default, yang memberi saya masalah saat memindai ini dengan alat. Dengan menambahkan elemen aria-busy di awal, itu diabaikan oleh alat-alat itu.
  
  
  • Alasan untuk masalah ini adalah bahwa elemen kotak daftar _harus memiliki_ elemen opsi ( sumber )
  
  
  • Itu akan dihapus saat pertama kali daftar diisi, jadi bagi saya sepertinya situasi yang tidak berbahaya.
  
  
• Menambahkan aria-selected sepertinya langkah yang jelas, tidak percaya saya melewatkannya. Terima kasih telah menangkapnya.
  *Pikiran Penutup*
  Apakah Anda menulis sendiri HTML untuk audit ini, atau apakah alat yang membuat ini untuk Anda? Ini sangat membantu jadi terima kasih sekali lagi.

@cooperfellows - jawaban atas pertanyaan Anda:

markup HTML

• Hanya menunjukkan apa yang dihasilkan selama setiap fase perilaku plugin.

Perilaku keyboard

• "Fokus yang hilang" hanya ada di Firefox. Anda dapat menambahkan tabindex="-1" untuk mencegah fokus, lalu menghapusnya lagi. Maka Anda tidak perlu ARIA.

CSS dinonaktifkan

• Pada dasarnya, SELECT asli terlihat di halaman dan dapat digunakan dengan UP | Panah BAWAH karena perilaku browser default menunjukkan berbagai opsi saat Anda menavigasinya.
• HTML yang dirender plugin juga terlihat, tetapi tarik-turun tidak menunjukkan "opsi" mana yang disorot.
• Anda menyarankan menggunakan EM. Gunakan KUAT sebagai gantinya - ini memiliki makna semantik lebih dari EM di HTML5. Lihat http://html5doctor.com/ib-em-strong-element/
• Tapi saya tidak berpikir ini adalah masalah besar karena pengguna masih dapat menggunakan SELECT.
• Lihat tangkapan layar

Pembaca layar

• Ini sulit karena hasilnya bervariasi tergantung pada kombinasi browser dan pembaca layar yang digunakan, dan versi mana.
• Apa yang akan saya katakan adalah bahwa pembaruan aksesibilitas Anda ke plugin dalam hal peran / status / properti ARIA selaras dengan rekomendasi W3C / WAI. Jadi itu kabar baik. :)
• Terserah produsen browser & pembaca layar untuk memastikan perangkat lunak mereka mematuhi ini.

ARIA

• Penjelasan Anda untuk "aria-sibuk" masuk akal. Bahkan jika itu usang, itu tidak akan menyebabkan masalah apa pun di sana.
• Mengaudit HTML. Kerajinan tangan. Saya telah membangun perpustakaan komponen UI/panduan gaya hidup untuk perusahaan tempat saya bekerja, jadi saya hanya menggunakan komponen dari sana. Tidak butuh waktu lama sama sekali. Bagian tersulit adalah mendengarkan kembali semua keluaran pembaca layar untuk memastikan saya telah menangkap semuanya dengan benar.

Semoga ini semua membantu dengan permintaan tarik Anda. Anda telah melakukan pekerjaan yang hebat dengan A11Y. :)

Halo,

saya buta. Saya telah menguji karya @cooperfellows dengan JAWS. Ini bekerja dengan sempurna. Opsi yang dipilih diucapkan saat saya panah melalui opsi.

Adakah berita tentang menggabungkan ini di master?

Dalam pekerjaan sehari-hari saya, saya menggunakan MISP (Malware Information Sharing Platform - https://github.com/MISP/MISP), yang pengembangnya baru-baru ini memutuskan untuk menggunakan "terpilih" untuk kotak kombo pelengkapan otomatis. Ini telah menjadi mimpi buruk bagi saya.

Terima kasih sebelumnya atas bantuan Anda.

Setelah beberapa pengujian, saya dapat mengonfirmasi bahwa versi kompilasi (arsip .zip) yang diposting di atas (pada 1 Juli 2016) berfungsi.

Namun, ketika saya mencoba cabang @cooperfellows , atau ketika saya mengkloning cabang @cooperfellows dan kemudian bergabung dengan harvesthq/master, opsi menu diucapkan dengan benar oleh JAWS tetapi tombol ENTER tidak mengirimkan formulir.

Hai @obert01 , terima kasih banyak telah melihat ini menggunakan JAWS, itu adalah bagian besar yang saya lewatkan selama pekerjaan saya.

Cabang ini sudah ketinggalan zaman dari cabang harvesthq/master saat ini, saya mungkin perlu meninjau perubahan dan menyesuaikan PR saya untuk mengembalikan semuanya ke status kerja.

Saya akan mencoba untuk mencapai ini sebelum akhir bulan, saya cukup didukung di tempat kerja sekarang.

Saya ingin melihat salah satu kontributor melihatnya lagi setelah diperbarui, jadi saya akan melakukan ping ke @stof (yang melihat penarikan awal pada tahun 2016) setelah saya memperbaruinya.

Terima kasih banyak.

Sekadar informasi, saya dapat menguji dengan semua kombinasi pembaca layar JAWS dan NVDA, dengan browser berikut: Internet Explorer 11, Google Chrome, Firefox ESR, Firefox Standard, Microsoft Edge.

Ada kemajuan dalam hal ini?

Saya minta maaf untuk bersikeras, tetapi pekerjaan sehari-hari saya menderita karena kurangnya aksesibilitas ini.

Selain itu, menambahkan dukungan aksesibilitas akan memungkinkan Terpilih untuk digunakan di situs web sektor publik/administrasi, karena regulasi di semakin banyak negara berjalan dengan cara ini.

Terima kasih

Hai,
Kami memiliki aplikasi yang telah dipilih dan sekarang kami perlu mendukung aksesibilitas tetapi melalui ini yang dapat saya lihat adalah ini belum digabungkan. Akan sangat membantu jika @cooperfellows dapat menyelesaikan ini dan menggabungkannya.

Hai @obert01 dan @csmuthukuda ,

Saya baru saja membuat pembaruan untuk mempercepat PR saya dengan Chosen versi terbaru, silakan lihat di sini:
https://github.com/harvethq/chosen/pull/2596

Anda bisa mendapatkan salinan repositori bercabang saya dan mengujinya di pihak Anda. Saya akan menyukai beberapa umpan balik kehidupan nyata.

Itu melewati semua pemeriksaan TravisCI, tapi saya rasa itu tidak mencakup masalah A11Y. Biarkan aku tahu apa yang kamu pikirkan.

Hai @cooperfellows ,
Terima kasih, banyak atas dedikasi Anda untuk menjaga ini tetap hidup. Saya akan menguji ini dan memberi tahu Anda umpan baliknya. Saya sangat berharap pemilik akan mempertimbangkan untuk menggabungkan ini dengan master. Ini adalah persyaratan wajib sekarang.

Terima kasih @csmuthukuda Saya akan senang jika itu digabungkan ....

@pfiller @stof @tjschuck @koenpunt ,

Hai @cooperfellows ,

Saya telah menguji karya mengagumkan Anda dengan browser web terkini dan pembaca layar JAWS dan NVDA. Terima kasih !

Panah melalui opsi dengan keyboard berfungsi dengan baik: ucapan dan umpan balik braille sempurna, artinya semua atribut ARIA didefinisikan dengan baik. Namun, ketika saya menekan ENTER untuk memilih opsi, tidak ada yang terjadi. Saya tidak cukup berpengalaman dengan JavaScript untuk menentukan apakah masalah berasal dari Terpilih, atau apakah ada dalam aplikasi yang menggunakannya.

Untuk mereproduksi, coba pilih opsi di kotak kombo Terpilih hanya menggunakan keyboard: TAB untuk memfokuskan kotak kombo, tombol panah untuk menelusuri daftar, ENTER untuk memilih.

Sekali lagi, terimakasih banyak.

Terima kasih atas informasinya @obert01. Saya akan melihat dan melihat apa yang dapat saya temukan.

@obert01 Bisakah Anda mencoba menggunakan biola JS ini untuk mengonfirmasi bahwa itu berfungsi/tidak berfungsi? Biola ini sedang memuat versi jQuery yang dikompilasi dari komit terbaru saya.

• https://fiddle.jshell.net/cfellows/r5kp1udb/8/show/light/

Saya dapat menavigasi tarik-turun itu menggunakan keyboard saya (Chrome Terbaru), tetapi saya TIDAK menjalankan pembaca layar.

Biarkan aku tahu apa yang kamu pikirkan.

Hai @cooperfellows ,

Tidak ada masalah dengan JS Fiddle Anda. Jadi saya kira masalahnya adalah karena cara Terpilih digunakan di MISP (https://www.misp-project.org/).

Saya akan memeriksa ini dengan tim proyek MISP.

Terima kasih

Terima kasih @obert01. Tolong beri tahu saya apa yang Anda temukan. Ini bisa menunjukkan ketidakcocokan dengan pengaturan tertentu dari Terpilih, jadi jika ada cara bagi saya untuk melihat bagaimana MISP menggunakannya, saya dapat mencoba untuk melihat implementasinya.

Apakah dipilih digunakan di suatu tempat umum?

@cooperfellows dapatkah Anda memberi saya build baru dengan perubahan terbaru. Saya tidak tahu cara membuatnya.

@obert01 @cooperfellows Saya baru saja mencoba Fiddle dengan NVDA, tampaknya navigasi keyboard berfungsi dengan baik (termasuk memilih dengan tombol ENTER). Namun, ketika saya menavigasi dengan tombol panah atas dan bawah, pembaca layar membaca, "________tidak dipilih", yaitu "Bermuda tidak dipilih". Apakah ini perilaku yang diharapkan?

Saya memiliki masalah yang sama dengan @woenlee. Hal ini tidak begitu berbahaya. Tapi mungkin, cara atribut "terpilih" diatur pada item yang dipilih harus diperiksa.

Apa perilaku yang diharapkan ketika Anda "masuk" dan "keluar" item daftar? Kapan
Anda menavigasi ke bawah ke item baru, jika itu membacakan yang baru dipilih
barang? Apakah itu juga mengumumkan apa yang TIDAK lagi dipilih? @obert01 @woenlee

Pada Sun, 25 Agustus 2019 di 12:18 Olivier Bert [email protected]
menulis:

Saya memiliki masalah yang sama dengan @woenlee https://github.com/woenlee . Bukan itu
sangat berbahaya. Tapi mungkin, cara atribut "terpilih" diatur pada
item yang dipilih harus diperiksa.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/harvethq/chosen/issues/264?email_source=notifications&email_token=ABT3ZTIESGLX6IYW4BF2QCLQGKWDVA5CNFSM4AATGGB2YY3PNVWWK3TUL52HS4DFVREXG43VMWS2ZW63D5NMVXHJKT5DNS
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ABT3ZTMH2KUYYE7HNO2UGH3QGKWDVANCNFSM4AATGGBQ
.

--
~Cooper

@cooperfellows Setelah menjalankan beberapa tes aksesibilitas kapak, sepertinya saya telah menemukan bug di PR Anda, yang menjelaskan mengapa ia melakukan itu. Pada baris 342 dari Abstract-chosen.coffee, input memiliki 2 peran yang ditetapkan padanya, "kotak kombo" dan "kotak daftar".

<input class="chosen-search-input" type="text" autocomplete="off" aria-expanded="false" aria-haspopup="true" role="combobox" aria-autocomplete="list" autocomplete="off" role="listbox" /> </div> <ul class="chosen-results"></ul>

Setelah memberikan

Membayar pelanggan Harvest di sini, dan menguji agar dapat diakses secara internal mengalami hal ini. Aksesibilitas adalah suatu keharusan, dan kami akan pindah dari Harvest jika ini tidak ditangani, jika pengelola Harvest tidak menunjukkan dukungan untuk ini segera.

@obert01 Bisakah Anda mencoba menggunakan biola JS ini untuk mengonfirmasi bahwa itu berfungsi/tidak berfungsi? Biola ini sedang memuat versi jQuery yang dikompilasi dari komit terbaru saya.

• https://fiddle.jshell.net/cfellows/r5kp1udb/8/show/light/

Saya dapat menavigasi tarik-turun itu menggunakan keyboard saya (Chrome Terbaru), tetapi saya TIDAK menjalankan pembaca layar.

Biarkan aku tahu apa yang kamu pikirkan.

@cooperfellows
Saya sedang menguji JS Fiddle ini dengan JAWS 2019 dan mengalami sesuatu yang sedikit berbeda saat menavigasi opsi dengan tombol panah atas dan bawah.
Di Google Chrome 71.0.3578.98:
JAWS tidak akan membaca nilai yang disorot saat ini kecuali daftar melakukan beberapa gulir/perenderan. yaitu Jika daftar ditampilkan

<option selected="selected" value="United States">United States</option>
<option value="Afghanistan">Afghanistan</option>
<option value="Albania">Albania</option>
<option value="Algeria">Algeria</option>
<option value="American Samoa">American Samoa</option>
<option value="Andorra">Andorra</option>
<option value="Angola">Angola</option>
<option value="Anguilla">Anguilla</option>
<option value="Antarctica">Antarctica</option>

9 opsi, JAWS tidak membaca opsi yang disorot saat menekan hingga Anda mencapai opsi ke-10 diAntigua dan Barbuda . Kotak melakukan sedikit gulir otomatis untuk menyorot Antigua dan Barbuda dan kemudian membaca opsi.

Pada IE 11.0.9600.19463: Menavigasi dengan tombol panah tampaknya membaca opsi yang disorot saat ini naik dan turun dengan benar. Tidak memerlukan semacam render.

Ingin tahu apakah ada orang lain yang pernah mengalami ini. @obert01 @woenlee

Halo dan terima kasih atas pekerjaan Anda.

Sayangnya, ini tidak berfungsi dengan baik. Sangat sulit untuk dijelaskan, karena perilaku berubah dalam fungsi browser atau pembaca layar yang digunakan.

Saya pikir beberapa properti aria tidak ada atau tidak diperbarui. Di sini masalah umum yang saya temui:

• Masalah pengguliran: ketika saya panah ke bawah dan mencapai akhir daftar item yang terlihat, saya harus menekan dua kali panah bawah untuk memfokuskan item berikutnya.
• Saat saya menekan ENTER untuk memilih item, fokus tidak dilepaskan. Perilaku yang diharapkan adalah pembaca layar kembali ke mode navigasi cepat dan membiarkan saya membaca halaman web lainnya. Sebaliknya, tombol panah masih mengontrol pilihan saya dalam daftar.
• Skrip saat ini tidak memungkinkan untuk mengetahui apakah proposal ditampilkan dan berapa jumlahnya. Di plugin pilihan yang paling mudah diakses yang saya tahu, JAWS/NVDA mengumumkan berapa banyak hasil yang cocok dengan string yang dimasukkan dalam input teks.
• Akhirnya, saya mendapat kesan JAWS tidak mengerti jika daftar dikolaborasikan atau diperluas. Terkadang, setelah membuat pilihan dengan ENTER dan mencoba membaca sisa halaman, JAWS masih membaca proposal terbaru yang telah ditampilkan.

Poin bagus:

• Bagian pelengkapan otomatis berfungsi dengan baik. Jika saya memasukkan "fra", JAWS mengucapkan "France", dan saya dapat menekan ENTER untuk memilih.
• Item dibaca dengan benar saat saya panah dalam daftar.

Sayangnya saya tidak tahu banyak hal tentang ARIA, JavaScript dan web secara umum. Saya menyarankan Anda untuk memastikan maksimum properti ARIA diatur dan diperbarui dengan benar.

Temukan di bawah demo dan kode plugin JQuery yang berinteraksi sempurna dengan pembaca layar:
https://a11y.nicolas-hoffmann.net/autocomplete-list/

Mohon maaf belum bisa bantu lebih.

Jangan ragu untuk memposting demo baru dari karya Anda. Saya senang menguji Anda.