Gutenberg: Lakukan audit aksesibilitas dan buat posting blog tentang itu

Dibuat pada 3 Okt 2018  ·  86Komentar  ·  Sumber: WordPress/gutenberg

Saat ini ada persepsi bahwa Gutenberg cukup sulit diakses, baik secara umum maupun dibandingkan dengan Editor Klasik. Di bawah ini kurang lebih salinan + komentar yang saya buat di Buat Posting baru-baru ini tentang 5.0 :

Perlu diperhatikan bahwa editor (Klasik) yang ada tidak menyertakan banyak komponen untuk pengembang plugin yang memperluas editor. Editor inti di WordPress dapat diakses karena cukup mendasar (pada dasarnya ini adalah <textarea> ), tetapi juga tergantung pada belas kasihan pengembang plugin untuk memastikan kode mereka dapat diakses. Ini berarti perbedaan antara editor WordPress tanpa dan dengan plugin sangat berbeda – ini seharusnya kurang benar untuk pemasangan Gutenberg dengan 5 atau 500 blok.

Komponen dan blok Core Gutenberg dibangun dengan mempertimbangkan aksesibilitas, dan pembuat blok akan dapat menggunakan komponen ini di blok mereka sendiri dan mendapatkan banyak aksesibilitas bawaan di blok mereka secara gratis. Ini adalah kemenangan besar untuk aksesibilitas editor setelah diperpanjang sama sekali.

Tentu ada aspek (seringkali kode pihak ketiga seperti pemilih warna atau tanggal) yang tidak dapat diakses, meskipun kami telah berupaya untuk memperbaikinya ketika ada solusi yang lebih baik.

Editor Klasik dan editor Gutenberg bukanlah perbandingan apel-ke-apel; satu sangat mendasar dan satu fitur sangat lengkap. Saya berharap yang terakhir membutuhkan lebih banyak pekerjaan agar dapat diakses sepenuhnya, tetapi saat kami berupaya untuk itu (dan mengidentifikasi bug), kami dapat memberikan pengalaman yang lebih baik kepada semua pengguna.


Saya pikir ada anggapan bahwa Gutenberg tidak dapat diakses karena audit aksesibilitas lama yang mengidentifikasi banyak masalah di versi paling awal. Banyak hal telah berubah banyak sejak hari-hari awal, dan ketika plugin diberi label "1.0" itu hampir tidak merupakan produk yang siap dikirim. Saya khawatir bahwa banyak dari sentimen tersebut belum diperiksa ulang dan diperbarui, jadi ada anggapan umum bahwa Gutenberg tidak dapat diakses atau sama sekali kurang dapat diakses daripada Editor Klasik.

Apa yang saya berani adalah bahwa Gutenberg secara selektif kurang dapat diakses, tetapi secara keseluruhan fitur-untuk-fitur lebih mudah diakses. Sesuatu seperti pemilih tanggal atau interaksi tertentu yang tidak dapat diakses tidak membuat seluruh editor tidak dapat diakses. Feature-for-feature, dibandingkan dengan editor klasik dengan kemampuan serupa (mis. Banyak plugin terpasang), saya berani bertaruh * Gutenberg lebih mudah diakses.

Bagaimanapun, saya ingin melihat tentang melakukan putaran baru pengujian aksesibilitas dengan orang-orang komunitas (dan melihat tentang mengakses beberapa sumber Automattic untuk membantu juga).

Setelah itu, akan sangat menyenangkan untuk membuat posting blog dengan data yang dapat menunjukkan status aksesibilitas Gutenberg saat ini. Akan lebih baik untuk menyoroti fitur aksesibilitas bawaan yang juga diperoleh blok pihak ketiga secara gratis, untuk menunjukkan bagaimana blok mengalahkan plugin editor lama untuk aksesibilitas bawaan.

Terinspirasi oleh: https://wordpress.slack.com/archives/C02RQBWTW/p1538599045000200


  • -Satu taruhan kopi, tandatangani aku.
Accessibility (a11y)

Komentar yang paling membantu

Hal yang benar untuk dilakukan di sini adalah mendapatkan audit aksesibilitas independen. WordPress memiliki kebijakan inti untuk memenuhi pedoman aksesibilitas, dan juga bertanggung jawab kepada penggunanya untuk memenuhi pedoman tersebut. Hanya audit aksesibilitas menyeluruh yang dapat menunjukkan apakah ini masalahnya atau tidak. Tim aksesibilitas telah menandai banyak masalah, beberapa di antaranya telah ditangani, yang lainnya belum. Paling tidak, ini harus ditangani.

WordPress adalah antarmuka antara penerbit, database, dan pengunjung. Bagaimana tepatnya penerbit memilih untuk memasukkan atau memanipulasi antarmuka terserah pengguna itu. Tugas WordPress adalah membuat antarmuka dapat diakses untuk modalitas input apa pun yang dipilih oleh pengguna itu. Ini bukanlah hal baru atau kontroversial: Ini adalah fondasi di mana web berdiri.

Semua 86 komentar

Akan sangat keren mengetahui bahwa semua blok yang mereplikasi fungsi editor klasik dapat diakses di Gutenberg.

Hal yang benar untuk dilakukan di sini adalah mendapatkan audit aksesibilitas independen. WordPress memiliki kebijakan inti untuk memenuhi pedoman aksesibilitas, dan juga bertanggung jawab kepada penggunanya untuk memenuhi pedoman tersebut. Hanya audit aksesibilitas menyeluruh yang dapat menunjukkan apakah ini masalahnya atau tidak. Tim aksesibilitas telah menandai banyak masalah, beberapa di antaranya telah ditangani, yang lainnya belum. Paling tidak, ini harus ditangani.

WordPress adalah antarmuka antara penerbit, database, dan pengunjung. Bagaimana tepatnya penerbit memilih untuk memasukkan atau memanipulasi antarmuka terserah pengguna itu. Tugas WordPress adalah membuat antarmuka dapat diakses untuk modalitas input apa pun yang dipilih oleh pengguna itu. Ini bukanlah hal baru atau kontroversial: Ini adalah fondasi di mana web berdiri.

Saya setuju dengan @ mor10. Mempertimbangkan bagaimana Automattic dan tim inti telah berinvestasi dalam proyek ini, dan masih menghadapi masalah, satu-satunya jalan yang benar dan valid untuk maju adalah memiliki audit yang independen dan objektif.

WordPress memiliki kebijakan inti untuk memenuhi pedoman aksesibilitas

Ya persis. Saya ingin kepercayaan dari para pemimpin di proyek w.org yang lebih besar - seperti @afercia dan @rianrietveld - dalam pekerjaan di sini.

Singkatnya, saya yakin Gutenberg _CAN_ dapat diakses, tetapi saya khawatir Gutenberg _CAN_ mungkin tidak dapat dikirim dalam kondisi saat ini berdasarkan 117 item yang dibuka dalam proyek tersebut .

Berharap ini bisa terjadi!

Saya akan mendukung sepenuhnya audit aksesibilitas eksternal dan independen.

Seperti yang Anda sebutkan, ada beberapa masalah persepsi yang menurut saya terkait dengan kurangnya materi dan informasi mengenai pengujian pengguna, dan secara khusus, pengujian ulang seiring dengan kemajuan pengembangan. Alih-alih mengejar hasil pengguna, kami merasa seperti mengejar bug dan regresi.

Saya menghargai kejujuran Anda di sini, dan saya setuju bahwa audit eksternal / independen akan sangat berharga. Tapi, saya khawatir ini secara retroaktif menangani aksesibilitas dari sudut pandang teknis (yaitu, mencentang kotak untuk WCAG 2.x / AA) daripada mencari untuk memberikan pengalaman _ lebih baik_ bagi mereka yang mungkin tidak menggunakan mouse dan keyboard. Untuk aksesibilitas saja, penelitian kualitatif dan kuantitatif dari pengalaman Gutenberg tanpa data yang berhubungan dengan pengalaman saat ini (atau, bahkan lebih baik, produk serupa lainnya) mungkin tidak memberikan cerita yang adil.

Saya pikir transparansi seputar informasi ini akan bertahan lama dengan dukungan komunitas dan meredakan banyak gesekan, baik dari sudut pandang aksesibilitas dan peluncuran Gutenberg yang lebih besar.

Saya tidak terkejut mendengar orang lain mendukung audit eksternal, yang akan sangat bagus untuk dilakukan. 👍 Saya dapat memberi tahu Anda bahwa saya juga menyukainya, dan akan mencari cara untuk memfasilitasi itu selama minggu depan.

Apakah ada agensi / perusahaan berspesialisasi aksesibilitas yang terlibat dengan WordPress yang dapat memprioritaskan waktu mereka untuk menjalankan audit aksesibilitas proyek (mungkin mulai 4.0, yang merupakan rilis besar)? Saya pikir akan berguna untuk menetapkan pemahaman dasar tentang bagaimana Gutenberg dibandingkan dengan Editor Klasik.

Saya yakin akan ada masalah (seperti yang disebutkan di atas, kami memiliki lebih dari 100 masalah aksesibilitas) tetapi saya mencoba mendapatkan tampilan makro aksesibilitas di Gutenberg. Perlu diketahui bahwa kami juga memiliki lebih dari 100 masalah yang diberi label "bug", tetapi ini berkat kami karena tidak ada bug yang terlalu kecil. Kami mencoba mencatat semuanya, tetapi ingat ini berarti 100 masalah aksesibilitas, bukan 100 blok aksesibilitas. Pemblokir aksesibilitas (seperti saat ini) terdapat dalam Gabungkan Milestone yang menjadi bagian dari masalah ini.

Terima kasih kepada mereka yang telah menambahkan suara mereka untuk mendukung audit. Saya akan memberikan daftar aliran yang ingin kami uji dan memastikan berfungsi untuk pengguna sebagai MVP - ketika saya melakukannya, saya akan mempostingnya di sini tetapi saya belum merumuskannya sepenuhnya.

Audit eksternal adalah ide bagus. Saya akan dengan senang hati berkontribusi secara finansial untuk menyewa perusahaan yang memenuhi syarat untuk melakukan audit ini.

Saya juga akan berkontribusi secara finansial, terutama untuk sesuatu yang sebesar dan penting ini.

Saya juga bersedia memimpin cara untuk membantu mengumpulkan uang dari komunitas.

Aku suka ide ini. Untuk perusahaan yang membutuhkan kepatuhan WCAG dalam perangkat lunak mereka, audit dapat membantu mengatasi masalah. Menghasilkan VPAT dari audit juga dapat membantu penyerapan dalam organisasi yang memerlukannya sebagai bagian dari proses kontrak mereka. Lihat Membangun Aksesibilitas ke dalam Kontrak Vendor Teknologi untuk info terkait.

Saya juga mendukung audit aksesibilitas independen eksternal. Saya akan memeriksa sumber daya a11y pekerjaan saya yang sangat baik dan melihat apa yang mereka rekomendasikan. :)

Itu sangat baik! Tetapi kami tidak mencari kontribusi keuangan dari komunitas. Saya akan menghubungi beberapa auditor aksesibilitas dan melihat tentang meminta mereka menjalankan beberapa audit di Gutenberg.

Saya akan melihat jenis biaya dan garis waktu yang terlibat, tetapi jika kita bisa mendapatkan harga yang wajar dengan garis waktu yang akan bekerja untuk 5.0 saya harus bisa meminta Automattic untuk menutupi biaya. 😊

Saya agak tidak yakin dengan dukungan finansial yang dapat saya berikan dari Automattic ketika saya memposting komentar sebelumnya dan saya agak tidak jelas tentang harapan dari komunitas: maaf tentang itu! Saya telah memperbarui komentar dan mengklarifikasi apa yang tidak saya cari. Saat ini saya akan melihat tentang mengatur audit, mungkin perlu waktu beberapa hari setidaknya untuk mempertengkarkan kutipan! Saya akan melaporkan kembali setelah saya tahu lebih banyak 😊

Saya tahu ini mungkin bukan tempat untuk menyatakan ini, tetapi perusahaan saya melakukan audit aksesibilitas. Jadi beri tahu saya jika Anda ingin tahu lebih banyak. Meskipun tidak begitu aktif baru-baru ini, saya telah terlibat dengan WordPress untuk sementara waktu dan telah menyumbangkan ide aksesibilitas ke Gutenberg serta bagian lain dari WP. Jika saya tidak cukup mandiri, saya bekerja dengan mitra tepercaya yang belum pernah menggunakan WordPress.

@ tofumatt Saya pikir permintaan proposal akan menjadi cara yang baik untuk menyatakan dengan tepat apa yang dicari audit dan memberi penyedia layanan kesempatan untuk memberikan garis besar umum tentang bagaimana mereka akan melanjutkan. Apakah ada preseden untuk jenis proses ini di Automattic?

Halo, saya Koordinator Aksesibilitas TI untuk NC State University. Kami menggunakan WordPress untuk situs web kampus kami dan sebagai lembaga negara kami diharuskan untuk mengikuti Bagian 508 dari Rehabilitation Act tahun 1973. Oleh karena itu, alat penulisan kami seperti WordPress harus dapat diakses oleh individu penyandang disabilitas.

Kami memiliki berbagai macam pengguna WordPress termasuk mahasiswa, fakultas, dan staf yang menggunakan blog WordPress dan mengedit situs WordPress atas nama departemen organisasi mereka. Semua itu mengatakan, WordPress harus dapat diakses oleh orang-orang ini.

Sebagai institusi pendidikan tinggi, kami ingin terus mengikuti program dan teknologi baru. Akan merugikan bagi kita jika kita tidak dapat maju dan menggunakan Gutenberg atau melakukan situasi "terpisah dengan setara" di mana penyandang disabilitas dibatasi untuk menggunakan editor klasik sementara orang yang sehat dapat menggunakan Gutenberg.

Itu sangat luar biasa untuk didengar 👍

Saya sangat setuju! Tentu saja, saya ingin menetapkan harapan yang jelas bahwa mungkin ada masalah aksesibilitas yang kami temukan (atau mungkin ketahui) yang tidak dapat kami perbaiki sebelum WordPress 5.0 dirilis.

Ada banyak situs, karena banyak alasan, yang ingin / perlu menggunakan plugin Editor Klasik untuk waktu yang terbatas sementara Gutenberg — atau plugin luar - ditingkatkan. Mungkin akan ada pengguna yang mengalami masalah aksesibilitas – bersama dengan sejumlah masalah lainnya – yang memerlukan plugin Klasik selama beberapa minggu / bulan sementara kami meningkatkan perangkat lunak kami.

Saya ingin masa depan Editor WordPress menjadi luar biasa dan dapat diakses oleh semua orang. Saya mohon maaf sebelumnya untuk pengguna yang gagal pada awalnya, karena alasan apa pun. Tetapi ketahuilah bahwa kami akan berupaya membuat Gutenberg dan WordPress juga mengagumkan untuk mereka, meskipun itu tidak segera terjadi. ❤️

Tentang Audit

Hai semua! Saya masih agak baru menjadi pemimpin rilis dan saya datang dari hampir satu dekade mengerjakan proyek @mozilla di mana kami juga bekerja sangat banyak di tempat terbuka, salah langkah dan semuanya. Saya akan setransparan mungkin tentang apa yang terjadi, termasuk mencoba memberikan pembaruan tepat waktu (karena itu saya tidak yakin dapat membayar untuk audit aksesibilitas sampai memeriksa dengan beberapa orang).

Jenis audit yang ingin saya lakukan mungkin tidak terlalu sesuai dengan hukum / kepatuhan karena saya pertama kali ingin mendapatkan gambaran makro tentang kegunaan WordPress oleh pengguna dengan kebutuhan aksesibilitas. Jika itu termasuk hal-hal kepatuhan: mengagumkan.

Saat ini saya telah berhubungan dengan beberapa anggota komunitas Aksesibilitas @WordPress dan karyawan @automattic berpengetahuan yang telah memberi saya beberapa orang untuk dihubungi tentang audit Aksesibilitas. Saat ini saya ingin itu tidak memihak (agak di luar komunitas WordPress sangat bagus untuk menghindari bias / pengetahuan masa lalu / dll.), Tingkat tinggi, dapat ditindaklanjuti, dan dilakukan agak cepat. Saya tahu saya banyak bertanya 😆

Saya memiliki beberapa orang dalam pikiran saya sekarang danakan menjangkau mereka Saya telah menghubungi beberapa perusahaan yang berspesialisasi dalam audit aksesibilitas. Saya akan memposting pembaruan di sini, tetapi saya tidak akan tahu lebih banyak sampai minggu depan. Untuk saat ini, ada:

  1. tidak perlu menawarkan dukungan finansial (tapi OMG terima kasih banyak kepada mereka yang telah, sangat keren melihat komitmen Anda pada WordPress)
  2. tidak perlu menawarkan layanan Anda (menurut saya kami menginginkan seseorang di luar ekosistem WordPress, tetapi jika Anda ingin membantu dengan bug / pengujian aksesibilitas, lakukan! )
  3. banyak ❤️ dari saya 🙂

Semoga akhir pekan Anda menyenangkan, saya akan mengabari Anda semua! 😄

Jika mencari vendor lebih lanjut untuk audit, saya merekomendasikan WebAIM di Utah State University, yang umumnya dianggap sebagai salah satu sumber daya web terbaik di Amerika Serikat. Tidak berafiliasi dengan mereka dengan cara apa pun selain membaca dokumentasi web mereka yang luar biasa, tetapi saya telah melihat bahwa mereka menawarkan audit.

Meskipun WordPress itu sendiri adalah open source dan masih memiliki banyak tenaga kerja sukarela, itu juga mencapai "waktu besar", seperti dulu, dan tidak dapat lagi mengandalkan, "Tapi kami hanya open source," penopang. Saya pikir audit aksesibilitas penuh dan komitmen untuk meningkatkan di mana WP ditemukan kurang (tidak hanya Gutenberg) akan menjadi sumber pergerakan maju yang hebat dalam hal adopsi WP. Plus, tentu saja, mendemokratisasi penerbitan, dan sebagainya.

Ada banyak situs, karena banyak alasan, yang ingin / perlu menggunakan plugin Editor Klasik untuk waktu yang terbatas sementara Gutenberg — atau plugin luar - ditingkatkan. Mungkin akan ada pengguna yang mengalami masalah aksesibilitas – bersama dengan sejumlah masalah lainnya – yang memerlukan plugin Klasik selama beberapa minggu / bulan sementara kami meningkatkan perangkat lunak kami.

Sentimen ini tidak dapat diterima oleh saya dan saya berharap banyak orang lain yang telah menginternalisasi nilai-nilai WordPress ...

Saya mohon maaf sebelumnya untuk pengguna yang gagal pada awalnya, karena alasan apa pun. Tetapi ketahuilah bahwa kami akan berupaya membuat Gutenberg dan WordPress juga mengagumkan untuk mereka, meskipun itu tidak segera terjadi. ❤️

Apa keuntungan dari mendorong pengalaman yang tidak memenuhi standar semua hal lain di Core? Tenggat waktu tidak sewenang-wenang, tetapi itu tidak berarti Anda mengambil jalan pintas. Setidaknya tidak sesuai dengan nilai-nilai WordPress yang saya pahami. Nilai-nilai ini mungkin berbeda dari apa pun yang dimiliki Mozilla, sebagai pendatang baru di komunitas, saya mendorong Anda untuk memeriksanya.

Secara umum sentimen bahwa sebagian besar bekerja akan cukup menimbulkan risiko yang tidak perlu bagi masyarakat, dan orang pasti bertanya-tanya siapa yang diuntungkan dari itu. Apa keuntungan dari proyek Gutenberg atau WordPress? Bukannya kita membutuhkan bantuan untuk mengidentifikasi masalah.

Karena Automattic tampaknya akan mensponsori dan memahami parameter untuk audit ini, ada kemungkinan munculnya bias dan mereka menilai pekerjaan mereka sendiri. Saya mengusulkan agar komunitas yang lebih besar melanjutkan crowdfunding untuk menyewa spesialis aksesibilitas untuk laporan paralel dari perspektif pengguna sebenarnya. Mungkin Automattic dapat melakukan audit teknis atau apa pun, tetapi saran bahwa aksesibilitas Gutenberg "tidak terlalu buruk" telah dibantah keras oleh para ahli di bidang ini (yaitu, Sina Braham di WordCamp Publishers). Mungkin kami memerlukan sesuatu yang lebih dekat dengan pengujian Mikey di mana kami meminta pengguna buta untuk menavigasi melalui aplikasi dan mengatakan apakah mereka akan menggunakannya lagi.

Ngomong-ngomong, inilah yang telah saya kirimkan ke perusahaan yang telah saya dekati untuk pekerjaan ini. Ini dapat membantu orang lain yang terlibat dalam Aksesibilitas, saya tidak yakin. Setidaknya saya mempostingnya di sini untuk transparansi 🙂


Persyaratan

Serangkaian tes aksesibilitas harus dilakukan menggunakan editor Gutenberg di situs WordPress menggunakan WP-Admin. Pengujian ini harus mencakup, minimal, aliran pengujian berikut:

Alur Penerbitan Inti

  • Buat postingan baru
  • Tambahkan konten umum (paragraf, gambar, daftar, HTML, dan konten tabel; lihat "Menggunakan Blok" di bawah)
  • Publikasikan posting segera dan posting dibuat sebagaimana mestinya
  • Jadwalkan postingan untuk masa mendatang menggunakan pemilih tanggal
  • Tetapkan kategori dan tag untuk memposting
  • Tetapkan gambar unggulan ke posting
  • Bereksperimenlah dengan pengaturan tingkat Dokumen lainnya, dengan waktu yang mengizinkan

Menggunakan Blocks

Ini adalah dua puluh blok yang paling banyak digunakan di WordPress.com dan harus diuji untuk menemukan masalah aksesibilitas apa pun yang belum diajukan dalam daftar masalah aksesibilitas kami :

  1. gugus kalimat
  2. gambar
  3. menuju
  4. daftar
  5. galeri
  6. kutipan
  7. embed / youtube
  8. html
  9. pemisah
  10. lebih
  11. gambar sampul
  12. Kode pendek
  13. tombol
  14. meja
  15. pengatur jarak
  16. menanamkan
  17. blok
  18. embed / twitter
  19. kolom
  20. kode

Blok-blok ini harus diuji dengan teknologi pendukung untuk memastikan tidak ada pemblokir untuk penggunaannya, dan bahwa pengaturan tingkat blok mereka dapat diakses.

Editor Klasik

Kami harus memverifikasi bahwa, dibandingkan dengan Editor Klasik, tidak ada regresi penting terkait aksesibilitas. Membuat postingan dengan jenis konten yang sama yang dapat dibuat dalam konteks barebone Editor Klasik harus dapat dilakukan dengan Gutenberg. Gutenberg tidak mengalami regresi dalam pengalaman pengeditan dibandingkan dengan Editor Klasik adalah tujuan akhir saya untuk mengatakan bahwa kami dapat merekomendasikannya sebagai pengalaman pengeditan default untuk pengguna teknologi pendukung.

Teknologi Pendukung untuk Dipertimbangkan

Karena garis waktu terbatas yang tersedia dan prioritas tindakan daripada ketelitian yang ekstrem, saya lebih suka kombinasi dua-ke-tiga browser + pembaca layar teratas untuk digunakan untuk pengujian . Menggunakan lebih banyak jika waktu memungkinkan benar-benar dapat diakses, tetapi saya lebih suka memulai dengan kombinasi yang paling sering digunakan. Dari pemahaman saya ini adalah:

  • JAWS dengan Internet Explorer / Edge (Windows)
  • NVDA dengan Firefox (Windows)
  • VoiceOver dengan Safari (MacOS)
  • ZoomText

Teknologi bantuan seluler bukan prioritas untuk audit ini. Pengujian VoiceOver di MacOS diharapkan menyertakan beberapa persilangan dengan pengguna iOS VoiceOver. Penggunaan aplikasi seluler mungkin lebih menjadi fokus daripada penggunaan situs web.

Posting Laporan dan Masalah di Tempat Terbuka

Harapan kami adalah bahwa setiap laporan aksesibilitas yang dihasilkan harus diposting secara terbuka ke komunitas WordPress dan tidak mengharuskan saya (atau Ahli Otomasi lainnya) sebagai penjaga gerbang. Masalah harus diposting dengan konteks yang berguna ke GitHub, dengan fokus pada penyebab masalah dan reproduktifitas. Solusi atau pendekatan untuk perbaikan dapat diposting jika ada waktu dalam ruang lingkup atau jika masalahnya sangat kompleks.

@davisshaver Halo, dan saya setuju dengan Anda. Audit yang menyeluruh dan tidak bias sangat penting untuk memastikan bahwa tingkat maksimum a11y ditaati.

Tidak hanya penting untuk memastikan editor dapat diakses, tetapi juga ada landasan untuk memastikan bahwa modifikasi editor juga dapat dengan mudah diakses. Jelas kita tidak bisa memaksakan apa yang orang lakukan sendiri, tapi setidaknya kita bisa memberikan landasan bagi orang untuk menerapkan yang bisa diakses.

@tofumatt Juga senang membantu dengan cara apa pun yang memungkinkan. Saya mungkin memiliki akses ke beberapa sumber daya yang cukup bagus untuk pengujian, khususnya yang lain dengan pengalaman React dan a11y. Ada juga beberapa orang di tim saya yang secara khusus bekerja dengan a11y dalam kesehariannya.

@tofumatt Terima kasih atas pembaruannya. Saya punya beberapa pertanyaan lanjutan:

1) Apakah rencana audit selesai sebelum 5.0 dirilis?
2) Jika audit mengembalikan masalah, apa rencana untuk menanganinya? Akankah rilis 5.0 ditunda sampai ditangani?
3) Apakah ada rencana yang dibuat tentang bagaimana proyek akan menguji aksesibilitas ke depan?

@tofumatt Jika Anda ingin beberapa pengujian oleh pengguna dengan berbagai disabilitas / kecacatan, saya telah melakukan beberapa pekerjaan dengan sebuah perusahaan bernama Hassell Inclusion, dan mereka dapat mengatur pengujian semacam itu. Mereka benar-benar dihapus dari komunitas WordPress. Perusahaan ini dijalankan oleh Jonathan Hassell yang dulunya bertanggung jawab atas aksesibilitas di BBC.

@tofumatt Saya juga sangat prihatin tentang aksesibilitas WordPress dan ingin membantu Anda sukses. Saya dapat meminta organisasi kami melakukan audit aksesibilitas lengkap yang sesuai dengan WCAG-EM ke tingkat standar apa pun yang Anda inginkan, termasuk pengujian teknis dan fungsional, dan menyumbangkan bagian pekerjaan apa pun yang Anda perlukan agar sesuai dengan anggaran Anda.

Saya pikir kita harus melihat baik ATAG dan WCAG AA, dan mungkin WCAG 2.1 daripada 2.0. Kami juga dapat memberikan rekomendasi dan bimbingan untuk membantu Anda memilih cara terbaik dan paling berkelanjutan untuk menutup celah yang ditemukan.

Kami sangat dekat dengan komunitas pengembangan Anda, namun mengenal WordPress dengan baik selama bertahun-tahun. Saya memegang semua sertifikasi IAAP dan telah memimpin lusinan audit semacam itu di platform WordPress, selama bertahun-tahun, baik untuk sektor swasta maupun publik. Silakan periksa bonafid kami di davidberman.com/about untuk memutuskan bagaimana kami dapat memberikan bantuan terbaik.

Menggunakan Blocks

Saya tidak yakin tim yang akan membuat audit harus diinstruksikan atau memiliki pengetahuan tentang apa itu "blok", setidaknya tidak pada awalnya. Mereka harus berada dalam kondisi awal yang sama dengan pengguna yang akan menggunakan Gutenberg untuk pertama kalinya, tanpa instruksi khusus. Pada tahap kedua, ketika membahas teknis, mereka mungkin sudah tahu apa itu blok 🙂

Alur Penerbitan Inti

Tim aksesibilitas setuju bahwa masalah aksesibilitas utama di Gutenberg adalah pengalaman pengguna secara keseluruhan. Saya menyarankan untuk memperluas bagian ini: tidak boleh dibatasi pada aliran _publihsing_, melainkan harus menyertakan lebih banyak tugas, biasanya tugas yang memerlukan navigasi melalui UI dan melompat melalui bagian utama (bilah atas, area pengeditan, bilah sisi , publikasikan panel). Ini lebih terkait dengan desain Gutenberg secara umum, daripada detail implementasi teknis pada berbagai komponen. Faktanya, desain aksesibilitas _is_.

Saya ingin mengusulkan beberapa tugas:

  • buat pos dengan jumlah blok yang besar, katakanlah minimal 20
  • edit salah satu paragraf di tengah postingan
  • ubah ukuran font dan warna font, lalu edit kembali isinya
  • tambahkan blok baru menggunakan penyisipan
  • sisipkan tautan
  • masukkan sebutan
  • ubah tipe blok
  • mengubah sesuatu di pengaturan bilah atas dan kemudian kembali ke blok yang telah diedit
  • lompat ke sidebar, alihkan ke pengaturan Dokumen / Blok, lalu kembali ke blok yang telah diedit
  • edit tautan permanen pos
  • membuat blok yang dapat digunakan kembali
  • menambah dan mengedit blok yang dapat digunakan kembali

Teknologi Pendukung untuk Dipertimbangkan

@tofumatt Saya agak terkejut Anda hanya menyebutkan teknologi pendukung dan, khususnya, hanya pembaca layar. Evaluasi aksesibilitas tidak dapat dibatasi hanya pada pengujian pembaca layar. Aksesibilitas adalah topik yang lebih luas dan tidak terbatas pada kecacatan atau gangguan. Ini tentang membuat web dapat diakses oleh semua orang.

Bahkan jika kita ingin membatasi aksesibilitas bagi penyandang disabilitas dan disabilitas, mereka terlalu banyak untuk dihitung. Hanya untuk beberapa nama: pengguna perangkat lunak pengenalan suara, cacat motorik, penglihatan rendah, gangguan kognitif, gangguan kejang, perangkat input alternatif, gangguan hiperaktif defisit perhatian, disleksia, kehilangan memori jangka pendek, dll., Dll. Bagaimana dengan hal-hal yang dapat tidak diklasifikasikan sebagai "cacat" nyata, misalnya gangguan sementara, gangguan lingkungan, penuaan?

Kondisi manusia sangat tidak stabil, dan saya menyarankan Anda untuk mempertimbangkan _Kita semua hanya untuk sementara waktu_.

too many to count – image courtesy of Denis Boudreau

Saya ingin mengusulkan beberapa tugas:

Daftar tugas yang diperpanjang ini tampaknya bagus dan realistis tentang apa yang perlu dilakukan pengguna.

Sebagai standar Aksesibilitas untuk status

Semua kode baru atau yang diperbarui yang dirilis di WordPress harus sesuai dengan pedoman WCAG 2.0 di level AA.

Oleh karena itu, audit harus memperhitungkan hal tersebut. Hal-hal khusus:

1) Semua fungsionalitas harus bekerja seperti yang diharapkan saat browser diperbesar 200% (perhatikan, ini dapat memicu css seluler) 1.4.4
2) Semua fungsionalitas harus bekerja seperti yang diharapkan hanya dengan menggunakan keyboard 2.1

Penting bagi kami untuk mengingat bahwa yang kami cari di sini adalah bahwa semuanya dapat digunakan oleh semua pengguna. Ini mungkin bukan pengalaman yang hebat bagi beberapa pengguna, itulah versi 1 tetapi standar yang kami miliki adalah tentang memastikan bahwa itu benar-benar dapat digunakan. Semua perangkat lunak dilengkapi dengan bug dan yang terpenting adalah kita mengetahui tentang bug tersebut dan membuat kompromi untuk memperbaikinya vs. tidak memperbaikinya.

Terima kasih @tofumatt karena telah memimpin tugas menyelesaikan audit ini. Saya berharap untuk melihatnya terjadi dan Gutenberg dapat digunakan oleh semua orang.

Berguna, dalam memeriksa audit / serangkaian uji Aksesibilitas, untuk menyusun daftar fungsionalitas Editor Klasik "inti" yang seharusnya tidak mengalami kemunduran di editor baru:

  1. Pembuatan / pengeditan teks paragraf
  2. Pembuatan / pengeditan teks judul
  3. Pembuatan / pengeditan teks yang telah diformat sebelumnya
  4. Pembuatan / pengeditan daftar berpoin
  5. Pembuatan / pengeditan daftar bernomor
  6. Pembuatan / pengeditan kutipan ("Blockquote")
  7. Perataan teks untuk paragraf dan judul
  8. Menambahkan, mengedit, dan menghapus link dari teks di paragraf, judul, dan item daftar
  9. Indentasi / dedentasi daftar / item daftar
  10. Tebal / miring / coret teks dalam paragraf, judul, dan item daftar
  11. Menambahkan garis horizontal / spacer ke konten
  12. Urungkan / Ulangi
  13. Penyisipan komentar "Read More" WordPress (Read More Block di Gutenberg)
  14. Konversi konten paragraf menjadi konten daftar
  15. Konversi isi daftar menjadi isi paragraf

Saya pikir itu saja, jadi itulah yang telah saya kirimkan.

Daftar teknologi saya yang dapat diakses sangat sedikit, setuju. Sebagian dari itu adalah tentang pelingkupan tetapi sebagian karena itu adalah daftar yang sedikit tidak lengkap yang saya harap dapat ditambahkan seiring waktu. Saya telah menambahkan ZoomText ke daftar itu , dan akan memintanya digunakan untuk pengujian juga.

Baru saja meninjau daftar tugas @afercia dan saya setuju: itu daftar yang bagus. Saya akan bekerja untuk memasukkan sebanyak mungkin dari daftar itu ke dalam proyek. Saya tidak akan memperbarui daftar asli saya untuk saat ini tetapi akan memposting daftar tugas yang diselesaikan setelah audit / tes dimulai. Terima kasih! 👍

Membalas beberapa pertanyaan

@bamadesigner :

Rencananya, sekarang, adalah memulai audit secepatnya dan memiliki sebanyak mungkin info sebelum rilis 5.0 untuk mengatasi masalah apa pun yang ditemukan dan menambahkan konteks ke rilis terkait aksesibilitasnya. Dalam hal penundaan rilis: tergantung pada masalahnya, waktu untuk memperbaikinya, dan dampaknya. Pandangan saya adalah bahwa menunda rilis tidak mungkin, tetapi kita harus menyeberangi jembatan itu ketika kita sampai di sana; Saya tidak ingin berspekulasi.

Dalam hal rencana pengujian aksesibilitas ke depan: itu pertanyaan yang lebih besar dan yang tidak terkait dengan rilis atau masalah ini jadi saya tidak akan membahasnya di sini. Untuk saat ini saya memimpin rilis untuk 5.0 dan saya akan fokus di sana; sekali lagi: Saya tidak ingin berspekulasi. Tapi itu adalah sesuatu yang dengan senang hati saya perhatikan setelah kami menarik napas dari WordPress 5.0 😄

@Lukasaputri

Jika Anda memiliki pengalaman melakukan uji aksesibilitas, sebaiknya Anda menguji Gutenberg atau melakukan triase pada masalah aksesibilitas yang ada sehingga kami tahu apa yang masih menjadi masalah dan apa yang perlu fokus. Mengerjakan masalah apa pun di Gabung: Tonggak aksesibilitas juga bagus.

@tofumatt Terima kasih atas jawaban Anda, tetapi jawaban itu mengecewakan.

Gutenberg / 5.0 tidak boleh dirilis sampai audit selesai dan setiap masalah yang ditemukan ditangani. Mudah-mudahan audit kembali dan mengatakan hanya ada beberapa masalah tetapi keputusan haruslah bahwa rilis 5.0 bergantung pada temuan itu dan waktu yang dibutuhkan untuk menyelesaikannya.

Saya tidak mengetahui rahasia apa pun yang mendorong tenggat waktu November ini, tetapi aksesibilitas terlalu penting. Jika Anda meluncurkan sebelum Anda memastikan pangkalan ini tercakup, Anda menetapkan preseden berbahaya bagi seluruh komunitas, dan web secara umum, aksesibilitas itu bukan prioritas # 1 dan bisa menunggu nanti.

WordPress 5.0 belum siap hingga dapat diakses. Tidak ada tenggat waktu lain yang lebih penting. Belum lagi fakta bahwa itu melanggar standar inti untuk aksesibilitas.

WordPress 5.0 belum siap hingga dapat diakses.

@bamadesigner berbicara tentang kebenaran.

Tujuan yang dinyatakan WordPress adalah untuk "mendemokratisasi penerbitan." Itu, dalam arti literal, berarti membuat penerbitan tersedia untuk semua orang. Aksesibilitas adalah inti dari janji ini.

Saya berharap bukanlah suatu keraguan untuk mengatakan bahwa tujuan dan janji tidak sama dan tidak boleh diperlakukan seperti itu. 😄

Seperti disebutkan sebelumnya, saya sangat menyambut baik kontribusi luar apa pun tentang masalah aksesibilitas dan terutama yang ditemukan di Gabung: Milestone aksesibilitas (
https://github.com/WordPress/gutenberg/milestone/43).

Jika dipastikan ada masalah yang merusak aksesibilitas saat rilis, saya nyaman mengunjungi kembali saran @rianrietveld di Trac untuk memperingatkan pengguna tentang teknologi pendukung dari masalah khusus dengan Gutenberg dan menyarankan mereka menggunakan Editor Klasik jika Gutenberg akan mempresentasikannya masalah kegunaan. Saya ingin menyoroti masalah tertentu yang diketahui dan siapa yang akan terpengaruh.

Saya tidak begitu yakin itu akan menjadi panggilan saya dalam hal apa pun, tetapi meskipun itu: Saya tidak melihatnya sebagai keputusan yang baik untuk menunda rilis 5.0 karena masalah aksesibilitas ketika Editor Klasik ada sebagai pengganti . Tujuan / fitur utama 5.0 adalah Gutenberg, pengalaman pengeditan baru. Saya lebih suka merilisnya untuk pengguna yang akan menganggapnya dapat digunakan (yang seharusnya menyertakan banyak-tetapi-tidak-semua pengguna teknologi pendukung), dan menerima bahwa tidak semua orang dapat menggunakan Gutenberg pada Hari Pertama. Itu sudah menjadi kenyataan bagi banyak orang yang menggunakan plugin yang tidak kompatibel. Tidak ada yang memaksa siapa pun untuk menggunakan Gutenberg saat 5.0 diluncurkan 🙂

Editor Klasik ada, tetapi itu bukan bagian dari WordPress , dan itu adalah item penting untuk dikenali. Membutuhkan plugin untuk menyesuaikan sistem manajemen konten agar dapat digunakan adalah solusi yang sangat dipertanyakan. Ini pasti yang saya sarankan kepada orang-orang; tetapi ada banyak situasi yang tidak tercakup dengan baik oleh situasi itu. Yang terpenting, ini berarti bahwa hanya orang yang memiliki kemampuan untuk menginstal plugin yang dapat menentukan apakah situs tersebut akan terus dapat diakses seperti saat ini atau tidak. Untuk skenario di mana seseorang hanya memperbarui situs, kemudian penulis yang perlu menggunakan situs masuk dan tidak lagi dapat mempublikasikan konten, ini tidak memadai. Editor klasik tidak boleh menjadi opsi semua atau tidak sama sekali yang bergantung pada kemurahan hati admin situs untuk memastikan bahwa penyandang disabilitas dapat terus menerbitkan. Inilah alasan mengapa editor klasik tidak menjadi opsi yang tersedia dalam inti WordPress adalah masalah aksesibilitas.

Poin yang sangat bagus @joedolson , yang belum saya pertimbangkan — dan pesan info mungkin juga belum. Terima kasih untuk itu.

Saya lebih suka merilisnya untuk pengguna yang akan menganggapnya dapat digunakan (yang seharusnya menyertakan banyak-tetapi-tidak-semua pengguna teknologi pendukung), dan menerima bahwa tidak semua orang dapat menggunakan Gutenberg pada Hari Pertama.

Ini adalah komentar yang sangat serius, dan posisi ini adalah desain yang buruk dan paling buruk secara aktif. Saya sangat berharap ini bukan solusinya.

@tofumatt Saya menghargai bahwa Anda mencoba melakukan yang benar dan menyeimbangkan banyak masalah, tetapi menurut saya ini sangat mengganggu:

Saya tidak begitu yakin itu akan menjadi panggilan saya dalam hal apa pun, tetapi bahkan jika itu: Saya tidak melihatnya sebagai keputusan yang baik untuk menunda rilis 5.0 karena masalah aksesibilitas ketika Editor Klasik ada sebagai pengganti. Tujuan / fitur utama 5.0 adalah Gutenberg, pengalaman pengeditan baru. Saya lebih suka merilisnya untuk pengguna yang akan menganggapnya dapat digunakan (yang seharusnya menyertakan banyak-tetapi-tidak-semua pengguna teknologi pendukung), dan menerima bahwa tidak semua orang dapat menggunakan Gutenberg pada Hari Pertama.

Anda memberi tahu populasi pengguna yang sudah terpinggirkan bahwa Anda akan membuat WordPress dapat digunakan untuk mereka ... pada akhirnya. Anda lihat bagaimana itu mengasingkan, bukan?

Tapi mungkin rangkaian pertanyaan yang lebih penting adalah ini:

  • Siapa panggilannya untuk memutuskan apakah editor baru secara resmi siap untuk digabungkan menjadi inti?
  • Faktor apa yang mereka pertimbangkan untuk membuat keputusan itu?
  • Apa yang kita, sebagai komunitas, perlu lakukan untuk menjadikan aksesibilitas sebagai pusat proses pengambilan keputusan?

@tofumatt untuk mengklarifikasi: tim aksesibilitas belum meminta untuk menunda rilis. Satu-satunya permintaan resmi adalah menambahkan pemberitahuan bagi pengguna dengan kebutuhan aksesibilitas, memberi tahu mereka bahwa ada masalah yang harus diselesaikan, mengundang mereka untuk mencoba Gutenberg tetapi merekomendasikan Editor Klasik. Proposal ada di https://core.trac.wordpress.org/ticket/44671 yang telah ditutup 🙁

Saya lebih suka merilisnya untuk pengguna yang akan menganggapnya dapat digunakan (yang seharusnya menyertakan banyak-tetapi-tidak-semua pengguna teknologi pendukung), dan menerima bahwa tidak semua orang dapat menggunakan Gutenberg pada Hari Pertama.

Keren, luar biasa, kemampuan hebat di sini. Seperti yang dikatakan @briandeconinck , Anda mengasingkan seluruh grup pengguna hanya karena mereka tidak dapat menggunakan keyboard dan mouse (atau tampilan) dengan benar. Universitas kami telah mengerahkan banyak upaya dan upaya untuk membuat pengalaman WordPress kami dapat diakses dan kami masih mengerjakannya hingga hari ini. Untuk memiliki bagian besar dan penting dari inti WordPress yang berpotensi diluncurkan dan sebaliknya sangat mengecewakan.

@afercia Oh, saya benar-benar tahu itu! Saya tentu tidak bermaksud untuk menyiratkan bahwa posisi Tim Aksesibilitas adalah untuk menunda rilis; beberapa orang di komentar di sini bertanya tentang itu saja. Saya benar-benar minta maaf jika saya salah bicara dan memasukkannya ke dalam tim. ❤️

Masalah itu telah ditutup (sebagian karena ini tentang panggilan "coba" yang akan hilang, mungkin ada beberapa miskomunikasi tentang maksudnya), tetapi seperti yang disebutkan di sini: Saya setuju dengan menerapkan konsepnya untuk memperingatkan pengguna bantuan teknologi jika Gutenberg tidak akan berhasil untuk mereka.

Saya setuju dengan orang lain di utas ini yang mendorong peningkatan aksesibilitas sebelum 5.0. Saya juga akan menambahkan bahwa rilis 5.0 akan ditafsirkan sebagai lampu hijau oleh ekosistem WP lainnya bahwa Gutenberg siap untuk digunakan di dunia nyata. Pada saat itu kita akan melihat masuknya plugin dan tema yang memperluas Gutenberg dan bergantung pada standar yang dibuatnya sebagai cetak biru untuk pengembangan mereka sendiri.

Sebagai pengembang di ekosistem WP selama beberapa tahun, saya terus-menerus melihat ke inti WordPress untuk memastikan bahwa aksesibilitas, gaya, dan perilaku di plugin saya sendiri selaras dengan inti. Jika 5.0 dirilis sebelum masalah aksesibilitas ditangani, maka komunitas WordPress akan mencari cetak biru yang tidak dapat diakses sebagai model untuk pengembangan mereka sendiri. Mari kita pastikan bahwa cetak biru memenuhi standar yang telah kita tetapkan untuk semua hal lain yang telah datang sebelumnya.

@tofumatt Apakah Anda menyarankan bahwa memasang peringatan yang mengatakan bahwa teknologi bantu tidak akan berfungsi dengan Gutenberg adalah solusi yang masuk akal, mengingat Editor Inti akan menjadi plugin yang harus dipasang ditambah dengan fakta bahwa pengguna mungkin atau mungkin tidak memilikinya kemampuan / pengetahuan untuk menginstal plugin itu? Saya harap saya salah paham, bisakah Anda menjelaskannya?

Seperti biasa, terima kasih atas waktu Anda!

Plugin Editor Klasik dibuat sebagai jalan keluar sementara bagi mereka yang belum siap untuk beralih ke Gutenberg. Ini paling banter, dan dengan cepat akan menjadi masalah bagi pengembang yang harus memberikan solusi untuk dua editor yang berbeda. Plugin Editor Klasik bahkan tidak bisa menjadi jalan sementara untuk orang-orang dengan kebutuhan aksesibilitas karena secara harfiah menyajikan pengalaman yang lebih rendah berdasarkan kecacatan. Persyaratan minimum untuk admin WordPress adalah WCAG 2.0 AA. Yang lainnya, termasuk plugin untuk menurunkan pengalaman, bertentangan dengan kebijakan kami sendiri. Saya mengambil sikap tegas tentang ini karena kami memiliki aturan. Kami tidak mengirimkan kode yang tidak memenuhi standar persyaratan kami sendiri. Aksesibilitas seharusnya tidak berbeda.

Seperti banyak orang lain di sini, saya menghargai upaya komunitas dan orang-orang yang mencurahkan waktu dan tenaga mereka ke Gutenberg untuk membuatnya siap diakses untuk 5.0. Sederhananya, Gutenberg belum siap karena tidak dapat diakses sepenuhnya. Akhir dari cerita.

Sampai Gutenberg dapat diakses, itu tidak boleh digabungkan menjadi inti. Gagasan untuk melepaskan Gutenberg menjadi inti bagi "mereka yang _bisa_ menggunakannya" tidak hanya berpandangan sempit tetapi juga sangat eksklusif — Saya akan melangkah lebih jauh dengan mengatakan bahwa ini menciptakan (dan menormalkan) pengalaman _pisah tetapi sama_ bagi pengguna WordPress. Itu adalah preseden yang sangat buruk dan sangat arogan.

Harapan saya adalah komunitas menang dan meyakinkan tim inti untuk menahan rilis 5.0 hingga dapat diakses sepenuhnya. Untuk itu, audit independen merupakan ide yang baik dan harus diupayakan.

Masalah ini diajukan untuk mempublikasikan pekerjaan saya tentang audit aksesibilitas, untuk mengomunikasikan bahwa saya ingin hal itu terjadi, dan untuk melacak pembagian audit tersebut dalam entri blog. Ini tidak dimaksudkan sebagai titik diskusi tentang apa yang harus dianggap sebagai pemblokir rilis untuk WordPress 5.0. Saya telah mencatat pendapat orang-orang tentang masalah ini, dan saya akan menyampaikannya ke @m , yang merupakan pemimpin rilis untuk WordPress 5.0. Pemahaman saya adalah:

  1. Saya tidak memiliki hak veto untuk pengiriman lebih dari 5.0, tetapi meskipun saya memilikinya:
  2. Saya masih tidak yakin ada cukup masalah Aksesibilitas yang mencegah rilis

Jika poin kedua berubah, saya akan menyampaikan info itu. Saya berencana untuk menjadi seorang advokat, tetapi saya tidak mengatur jadwal dan saya juga tidak memiliki data yang solid seputar aksesibilitas. Itulah inti dari audit: jadi kami dapat berbicara dari tempat data keras. 🙂

Terima kasih atas semua masukannya, tetapi karena diskusi ini telah menjadi sangat di luar topik dari cakupan yang dimaksudkan, saya mengunci percakapan masalah ini untuk saat ini. Saya akan membiarkannya terbuka dan memposting pembaruan seputar audit.

Ada sedikit diskusi tambahan tentang masalah ini di Slack: https://wordpress.slack.com/archives/C02RP4X03/p1539300688000100

Saya pikir itu layak dibahas di sini sehingga semua orang yang telah mengikuti masalah sejauh ini dapat mendapatkan informasi terbaru tentang apa yang terjadi. @ mor10 juga menunjukkan bahwa dia merasa tidak ada komunikasi yang jelas dari hasil audit tersebut. Sepertinya ada banyak kesalahpahaman seputar komunikasi saya dalam posting ini: permintaan maaf saya untuk itu. Saya akan mencoba menjawab hal-hal sebaik mungkin sekarang.

Saya pikir banyak kebingungan dalam tiket tertutup berasal dari kurangnya kejelasan tentang apa yang terjadi jika / ketika audit tidak dapat diselesaikan tepat waktu untuk jadwal rilis atau audit kembali menandai masalah substansial yang perlu diperbaiki. Berdasarkan komentar Anda, tidak jelas apakah menurut Anda:

  • a) semua masalah akan diperbaiki dalam garis waktu saat ini
  • b) masalah apa pun yang tidak dapat diperbaiki dalam tenggat waktu akan didorong ke 5.0.1
  • c) jika masalah substansial diangkat, jadwal akan berubah.

Apa yang Anda katakan sejauh ini _tampaknya_ hanya menunjukkan a atau b adalah opsi, tapi seperti yang saya katakan, tidak jelas. Gagasan tentang aksesibilitas yang didorong untuk memenuhi tenggat waktu rilis adalah hal yang dikhawatirkan orang selama lebih dari setahun, dan kekhawatiran tersebut belum teratasi.

  • @ mor10 di Slack (https://wordpress.slack.com/archives/C02RP4X03/p1539303342000100)

Berdasarkan masalah saat ini dalam Milestone, tujuan saya adalah memperbaiki semua masalah, tetapi menurut saya itu bukan pemblokir rilis. Saya akan tahu lebih baik bagaimana melakukan triase lebih dekat ke pemberian tag akhir, jadi saya tidak bisa menambahkan banyak hal itu sekarang. Untuk saat ini menurut saya itu adalah daftar realistis masalah yang paling penting sebelum 5.0

Masalah yang tidak dapat diperbaiki harus dipindahkan ke rilis WordPress / Gutenberg berikutnya, ya.

Saya tidak berpikir ada apa pun di sana saat ini yang menuntut penundaan rilis.


Masalah ini dikunci karena tujuan saya membuat masalah ini adalah:

  1. untuk berbagi pekerjaan saya menugaskan audit
  2. untuk berbagi pekerjaan saya membuat posting blog tentang Merek / Aksesibilitas di sekitar posting itu

Saya menghargai masukan tentang bagaimana audit dapat dilakukan dan juga mendengar tentang masalah seputar rekomendasi "cadangan" saya dari Editor Klasik jika Aksesibilitas menjadi masalah serius di Gutenberg. Perlu dicatat saat ini tidak ada laporan yang mengevaluasi Gutenberg dan merekomendasikan agar tidak melakukannya atas dasar aksesibilitas. Saya belum melihatnya, dan tidak ada yang terhubung dengan siapa pun di sini. Sentimen di sini adalah seputar kegagalan spekulatif. Bahasa semacam itu menurunkan motivasi para pengembang Gutenberg yang bekerja keras dan melihat kurangnya niat baik yang diasumsikan.

Peran Pimpinan Rilis Aksesibilitas baru dan ingin diberikan kepada saya minggu lalu . Pada saat yang sama tanggal rilis 19 November 2018 telah diselesaikan . Naluri pertama saya saat diberi peran utama rilis adalah mencoba menghabiskan uang Automattic untuk membuat audit sebagai tanda komitmen kami terhadap Aksesibilitas, dan untuk menciptakan pemahaman konkret tentang masalah aktual yang dihadapi Gutenberg dalam hal bekerja dengan teknologi pendukung. Saya sedang mengerjakan timeline terbatas dan berbagi informasi sebisa saya dan sebagaimana mestinya, dengan peringatan bahwa saya tidak ingin mengevaluasi perusahaan yang sedang saya diskusikan secara publik (saya anggap itu tidak profesional) dan saya harus memilah-milah sisi pengadaan barang dengan Automattic (aspek audit ini tidak dapat dipublikasikan, sejauh yang saya tahu).

Saya bukan keputusan akhir dalam rilis. Saya telah meng-cc @m tentang masalah ini; dia adalah pemimpin rilis dan dia membuat panggilan untuk menunda rilis berdasarkan masalah Aksesibilitas. Secara pribadi, saya tidak akan merekomendasikan untuk menunda rilis berdasarkan masalah yang diketahui saat ini, bahkan dalam pencapaian.

Ya, ada masalah yang lebih besar tentang desain yang dapat diakses secara keseluruhan, tetapi tim pengembangan dan desain mempertimbangkan masalah ini. Saya prihatin, lebih-lebih, dengan hal-hal yang kami kenali dan uji lebih sedikit karena kami sebagian besar adalah tim pengguna yang cukup terampil.


Beberapa orang di Slack telah mengungkapkan kepada saya pengamatan mereka bahwa masalah tersebut tampak seperti meminta umpan balik dan diskusi yang lebih luas. Itu bukanlah niat saya untuk mengajukan masalah ini, tetapi hanya untuk menjaga semuanya tetap terbuka; karena GitHub adalah tempat utama kami mengerjakan proyek ini, saya pikir ini adalah tempat terbaik untuk melakukannya. Saya mengunci masalah karena pembahasannya, meskipun mungkin berlaku untuk proyek secara keseluruhan, mengganggu:

  1. masalah yang dihadapi (dan audit dan posting blog dengan hasil)
  2. tim secara keseluruhan yang diberi tahu melalui komentar masalah

Komentar masalah harus dapat ditindaklanjuti, terpisah, dan mudah-mudahan memberikan informasi baru. Saya merasa komentar di sini gagal memenuhi kriteria tersebut, jadi saya ingin membatasi diskusi pada masalah yang ada.

Saya mengajukan masalah ini di tonggak sejarah karena saya ingin ini terjadi untuk WordPress 5.0. Jika tidak memungkinkan, akibat yang menyedihkan adalah harus dipindahkan. Saya mencoba yang terbaik untuk bekerja di bawah garis waktu terbatas dengan sumber daya terbatas. Bukan untuk "tambalan menyambut" semua orang, tetapi jika Aksesibilitas penting bagi Anda, saya akan sangat menghargai jika Anda mengarahkan perhatian Anda ke daftar masalah aksesibilitas terbuka kami , terutama yang ada di Milestone: daftar Aksesibilitas .


Saya ingin masalah ini tetap terbuka karena saya ingin melacak kemajuan saya dengan audit. Jika ada diskusi lain yang Anda ingin lakukan terkait dengan Aksesibilitas, tombol "Masalah Baru" selalu ada. Saya perhatikan ketika saya menulis komentar ini, masalah baru telah diajukan (# 10537): itu keren 😄

Terima kasih semuanya, dan semoga hari Jumat yang menyenangkan. ❤️

@tofumatt Bisakah Anda memperbarui info tentang audit?

Hal pertama yang pertama: Saya telah berbicara dengan beberapa perusahaan selama seminggu terakhir tentang melakukan audit, dan mendapatkan kembali proposal dari mereka.

Saya akan mengatakan bahwa saya menerima proposal yang cukup rinci dari:

  • Akses Level
  • Sistem Deque

Dan tanggapan yang kurang mendetail tetapi masih bagus dari:

  • Grup Paciello
  • Heydon Pickering

Mereka semua sepertinya tahu barang-barang mereka. Saya tidak akan membagikan detail proposal karena menurut saya itu tidak sesuai, tetapi saya memiliki berita malang di bagian audit. 😢

Setidaknya untuk saat ini, Automattic telah memutuskan untuk tidak melakukan audit Aksesibilitas di Gutenberg. Alasan utamanya adalah:

  1. audit tidak akan dapat ditindaklanjuti mengingat jadwal rilis kami, karena…
  2. audit tidak akan memengaruhi waktu rilis, jadi ...
  3. akan lebih bijaksana untuk mengeksplorasi audit pada waktu yang tidak terlalu terburu-buru di masa depan

Saya berharap kami akan mempelajari audit selanjutnya, tetapi sayangnya hal itu tidak akan terjadi sebelum proposal penggabungan dan oleh karena itu saya menutup masalah ini karena tidak dapat diperbaiki. Saya masih ingin membuat blog tentang keadaan aksesibilitas Gutenberg, baik dan buruk. Kami membuat beberapa peningkatan pada navigasi keyboard, kontras warna, perilaku fokus, dan pemilih tanggal / warna hanya minggu ini.

Maaf semua karena terlalu berharap dan kemudian mengecewakan komunitas yang satu ini. 😞

Sekadar catatan singkat untuk mengatakan bahwa saya ingin melihat ini berlanjut, meskipun ini terjadi setelah 5.0.
Apakah ada alasan untuk tidak membiarkannya terbuka dan menetapkannya ke pencapaian lain, atau masa depan?

Kami yakin telah mengalami sedikit rollercoaster emosional akhir-akhir ini, bukan? 🎢

Pertama-tama, terima kasih semuanya atas pekerjaan yang Anda lakukan. 💖 Saya tahu terkadang tidak mudah untuk menjadi pendukung aksesibilitas, ini bisa terasa seperti pertempuran di bukit yang konstan. Ketahuilah bahwa Anda memiliki pengaruh: dari pribadi (saya telah belajar banyak tentang aksesibilitas dari orang-orang yang membentuk tim Aksesibilitas WordPress), hingga yang mendasar (desain yang berpusat pada manusia adalah aspek penting dari praktik desain modern ).

Saya sangat menyukai gagasan audit profesional, meskipun saya tidak ingat kami pernah melakukan salah satunya di WordPress, tentu saja bukan syarat untuk rilis. Saya ingin melihat sesuatu seperti itu terjadi di beberapa titik. WordPress selalu berusaha memaksimalkan aksesibilitas dengan tetap berpegang pada pola dan semantik umum, dengan perbedaan yang tercakup oleh upaya utama dari semua sukarelawan di tim Aksesibilitas yang melakukan pengujian dan mengajukan laporan bug yang dapat ditindaklanjuti. Perpindahan Gutenberg menjadi aplikasi yang sepenuhnya berbasis JavaScript telah mempersulit penerapan pola tersebut, tetapi kita dapat bekerja sama untuk membuat pola baru, garis dasar baru.

Kami tahu bahwa Gutenberg masih membutuhkan lebih banyak pemolesan — yang sedang kami lakukan! —Dan seperti semuanya, akan ada masalah yang akan terus kami ulangi dalam beberapa bulan dan tahun mendatang. Berdasarkan banyak percakapan, tampaknya masalah yang paling kritis telah diajukan, banyak di antaranya telah diperbaiki, dan kami akan terus memperbaikinya saat muncul.

Ada banyak masalah yang belum terselesaikan (terima kasih terutama untuk semua orang yang mengirimkan masalah dalam seminggu terakhir ini!). Sebaiknya lihat bug scrub untuk mengatasi masalah ini dan memprioritaskannya. Kami dapat memastikan masalah yang secara aktif mencegah orang menggunakan Gutenberg diperbaiki, dan kemudian fokus pada masalah yang memudahkan orang untuk menggunakannya.

Saya telah menyebutkan ini sebelumnya, tetapi perlu diulang: WordPress 5.0 bukanlah garis finis, ini adalah pistol starter. Banyak dari kita di utas ini telah bekerja sama di WordPress selama bertahun-tahun sebelum Gutenberg dimulai, dan saya berharap kita akan bekerja sama di WordPress untuk tahun-tahun mendatang. Kami telah melihat banyak fitur baru datang ke WordPress selama bertahun-tahun, dan tidak ada yang tetap sama seperti saat pertama kali dirilis. Kami menghadapi tantangan yang oleh sebagian besar proyek lain dianggap tidak dapat diatasi, tetapi kami telah membuatnya berhasil.

Misi WordPress terus berlanjut untuk mendemokratisasi penerbitan. Aksesibilitas adalah tentang membuat segala sesuatunya bekerja untuk orang-orang yang secara historis sangat terpinggirkan. Ini tidak hanya gratis, misi WordPress secara inheren mengharuskannya untuk dapat diakses.

Apa yang kami rilis di WordPress 5.0 tidak ditetapkan secara permanen, kami akan terus memperbaikinya, mengerjakannya ulang, belajar darinya, dan membuatnya lebih baik. Gutenberg adalah fondasi tempat kami dapat membangun generasi web berikutnya, dan potensi untuk meningkatkan aksesibilitas seluruh web juga ada. Setiap komponen, setiap blok, setiap antarmuka harus dapat diakses sepenuhnya, dan setiap plugin dan tema pada akhirnya harus dapat memanfaatkannya. Generasi Gutenberg harus memberikan pengalaman yang dapat diakses _dengan default_. Tidak hanya itu, pemeriksa kontras warna dan peringatan hierarki heading adalah contoh bagus tentang bagaimana Gutenberg dapat menjadikan pembuatan konten yang dapat diakses sebagai perilaku default juga.

Saya telah membuka dan membuka kembali masalah ini, dan membuatnya menjadi tonggak untuk masa depan, tetapi kita dapat dengan mudah memindahkannya ke pencapaian yang lebih dekat di lain waktu. Saya memiliki permintaan khusus agar kita semua tetap fokus pada topik, dan fokus pada percakapan yang produktif. Saya ingin melihat kami mengambil apa yang telah dimulai di sini, dan mencari kerangka kerja untuk audit aksesibilitas yang berkualitas, sesuatu yang dapat diperluas untuk mencakup ruang lingkup Gutenberg fase 2, dan seterusnya. Kami mungkin belum sampai, tapi kami akan sampai. ❤️

Terkait # 10537.

WordPress 5.0 bukanlah garis finis, ini adalah pistol starter.

Namun pada akhirnya, pistol starter itu tampaknya hanya berfungsi untuk mereka yang tidak memiliki kemampuan berbeda. Pistol starter berfungsi dalam praktiknya, karena suaranya cukup keras untuk membuat udara terbangun yang dapat dirasakan oleh orang-orang tuna rungu, dan karena membuat kilatan / asap yang dapat mereka lihat; itu membuat suara bagi orang buta untuk mendengar. Pistol starter dapat diakses oleh semua orang; Gutenberg tampaknya tidak.

Dengan menolak untuk bahkan mempertimbangkan untuk menghentikan rilis Gutenberg sampai setelah audit a11y dilakukan, Anda secara efektif memberi tahu siapa pun bahwa _ secara fisik_ tidak dapat menggunakan Gutenberg bahwa mereka tidak penting bagi komunitas WordPress. Hal itu bertentangan dengan standar komunitas WordPress, tidak bertanggung jawab, dan, sejujurnya, itu memalukan dan berbahaya bagi produk yang ada di mana-mana untuk mengambil sikap seperti itu terhadap begitu banyak komunitas lainnya.

Saya membuat label "Memerlukan Masukan Aksesibilitas" untuk masalah yang memerlukan seseorang yang memiliki pengetahuan aksesibilitas untuk ikut serta, tetapi karena tidak ada yang dapat ditindaklanjuti dalam masalah ini, saya menghapus label tersebut 😄

Tidak ada yang mengatakan hal semacam itu, @cgrymala. Seperti yang saya sebutkan, audit aksesibilitas profesional _never_ menjadi persyaratan untuk fitur apa pun untuk digabungkan dalam riwayat WordPress. Saya pasti ingin melihat audit terjadi, tetapi menulis bahwa kurangnya audit adalah "tidak bertanggung jawab ... memalukan dan berbahaya" adalah jenis hiperbola yang menghalangi dialog konstruktif.

Saya akan mengulangi permintaan saya dari komentar saya sebelumnya, tetap pada topik , dan fokus pada percakapan yang produktif .

Lebih tepatnya, kurangnya audit tidak menghalangi kami untuk memperbaiki masalah. Jika aksesibilitas penting bagi Anda, jika Anda (atau seseorang yang Anda kenal) menggunakan teknologi pendukung, sekarang adalah waktu yang tepat untuk menguji dan melaporkan bug.

@pento , saya tidak melihat ada yang membantah bahwa audit adalah preseden? Itu sepertinya argumen yang tidak masuk akal, dan berdasarkan utas ini, preseden bukanlah asal mula ide audit.

Audit tersebut disarankan oleh @tofumatt karena ada alasan kuat untuk meyakini bahwa Gutenberg tidak dapat diakses sebagaimana mestinya menurut standar WordPress sendiri. Tanpa audit independen, atau bahkan hanya _A_ audit, mengapa Anda berharap komunitas tiba-tiba percaya bahwa Gutenberg dapat diakses? Kurangnya audit bukanlah tidak bertanggung jawab dan berbahaya, tetapi gaya pengambilan keputusan dan manajemen diktator seperti ini.

Mengingat kendala otentikasi, saya tidak berpikir bahwa membawa ini menjadi inti memberikan manfaat bagi WP di luar apa yang didapat komunitas dari plugin. Saya tidak percaya dengan keadaannya saat ini, manfaatnya lebih besar daripada biayanya, dan kita harus berbuat salah di sisi kesederhanaan.

Itulah yang dikatakan @m selama debat WP API. Ini adalah contoh lain dari kemunafikan yang membuktikan siklus daur ulang ini, dimulai dengan fakta bahwa perusahaan "tenggat waktu tidak sewenang-wenang" menolak untuk menetapkan tanggal rilis untuk 5.0, sampai mereka menemukan yang mereka sukai pada saat itu tidak ada ruang untuk perdebatan . Saya suka Gutenberg dan saya menggunakannya setiap hari. Ini memberikan nilai yang besar sebagai plugin, dan menurut heuristik Matt sendiri, kita harus melakukan kesalahan di sisi kesederhanaan sampai benar-benar siap.

Aksesibilitas penting bagi banyak orang di utas ini, yang telah menawarkan waktu, dukungan, dan uang untuk membantu kami mengatasi kebuntuan ini. Tidak jujur ​​jika Anda menyarankan bahwa jika kami benar-benar peduli, kami akan memperbaiki masalah.

Mengenai alasan yang diberikan untuk membatalkan audit:

audit tidak akan dapat ditindaklanjuti mengingat jadwal rilis kami, karena…
audit tidak akan memengaruhi waktu rilis, jadi ...
akan lebih bijaksana untuk mengeksplorasi audit pada waktu yang tidak terlalu terburu-buru di masa depan

Bahkan jika gagasan audit pihak ketiga sudah mati, tersirat dalam gagasan https://github.com/WordPress/gutenberg/issues/10537 akan menjadi audit Gutenberg untuk sarana aksesibilitas. Fakta bahwa Automattic bersedia merilis Gutenberg ke Core tanpa standar aksesibilitas yang diberlakukan sendiri sangat bermasalah . Pada akhirnya, saya kecewa karena diingatkan bahwa pada akhirnya, kepentingan Automattic tampaknya dipromosikan di atas kepentingan komunitas dalam hal pengembangan dan pelepasan Gutenberg.

Utas ini tentang:

  1. melakukan audit
  2. mengajukan masalah berdasarkan audit
  3. memposting hasilnya sebagai laporan ke blog Make / Accessibility

Kami menyadari kegunaan audit dan orang-orang ingin audit dilakukan. Harap simpan komentar terkait dengan proses:

  1. melakukan audit
  2. pelingkupan audit
  3. hasil audit

Saya menyembunyikan komentar di luar topik yang mengulang apa yang telah dikatakan dan menyoroti pentingnya audit. Saya ingin melihat satu dilakukan. Kami semua sepakat di sana. Harap pertahankan komentar tentang topik, produktif, dan pastikan mereka memberikan informasi baru / menambah masalah yang dihadapi.

@davisshaver Harap ingat etiket WordPress , khususnya:

Kontribusi ke proyek sumber terbuka WordPress adalah untuk kepentingan komunitas WordPress secara keseluruhan, bukan bisnis atau individu tertentu. Semua tindakan yang diambil sebagai kontributor harus dilakukan dengan mempertimbangkan kepentingan terbaik komunitas.

Proyek sumber terbuka WordPress adalah komunitas yang dijalankan oleh sukarelawan. Bahkan dalam kasus di mana kontributor disponsori oleh perusahaan, waktu itu disumbangkan untuk kepentingan seluruh komunitas open source.

Sementara @pento, @tofumatt, @m dan lain-lain disumbangkan oleh Automattic, mereka bekerja untuk kemajuan proyek. Automattic bukanlah yang memutuskan kapan Gutenberg akan dirilis.

Pengauditan dapat dan akan berlanjut seperti yang dicatat oleh @pento :

sekarang adalah waktu yang tepat untuk menguji dan melaporkan bug.

Apa pun yang dapat dilakukan untuk membantu berkontribusi pada proses pengujian dan pelaporan itu bermanfaat. Ada sejumlah masalah lama yang dapat menggunakan pengujian untuk melihat apakah masalah tersebut masih merupakan masalah yang tidak memerlukan teknologi bantuan khusus untuk mengujinya. Melakukan hal itu akan sangat membantu dan merupakan bagian dari apa yang akan diberikan oleh audit independen.

Saya tidak menyadari bahwa menjadi pemimpin rilis WordPress.org melibatkan Matt yang menyerahkan tanggung jawab fidusia ke Automattic. Meskipun Anda dapat berargumen bahwa konfliknya minimal, atau bahwa Matt secara aktif bekerja untuk mengurangi konflik, etiket WordPress yang Anda kutip adalah rekomendasi dan bukan deskripsi dunia ... Pada akhirnya konflik memang ada.

Saya yakin banyak orang yang mengintai topik ini saat ini dan saya akan mengatakan jika Anda tertarik dan ingin membantu tetapi Anda belum pernah menggunakan teknologi asistif sebelumnya (pembaca layar) bergabung dalam diskusi di https: // make .wordpress.org / chat / di saluran aksesibilitas. Jangan ragu untuk menghubungi saya bahkan dengan DM. Anda mungkin terkejut betapa mudahnya menyiapkan dengan NVDA / Voice Over / JAWS sehingga Anda dapat mulai menguji berbagai hal.

Selain itu, ada banyak alat yang tersedia untuk menguji persyaratan WCAG:
Kapak Chrome:
https://chrome.google.com/webstore/detail/axe/lhdoppojpmngadmnindnejefpokejbdd

Pemeriksa Kontras untuk WCAG: https://chrome.google.com/webstore/detail/wcag-contrast-checker/plnahcmalebffmaghcpcmpaciebdhgdf?hl=id

Alat Chrome A11y: https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb?hl=id

Ada 113 masalah terbuka dengan label aksesibilitas yang saat ini terbuka:
https://github.com/WordPress/gutenberg/labels/Accessibility

Entah kita setuju dengan keputusan yang sedang dibuat atau tidak, saya pikir kita semua bisa setuju bahwa masih banyak pekerjaan yang bisa kita ambil bagian untuk membantu menyelesaikannya. Meskipun tidak ada audit resmi, komunitas masih memiliki kekuatan untuk membantu memberikan pengalaman yang lebih dapat diakses.

Masalah ini diajukan untuk mempublikasikan pekerjaan saya tentang audit aksesibilitas, untuk mengomunikasikan bahwa saya ingin hal itu terjadi, dan untuk melacak pembagian audit tersebut dalam entri blog. Ini tidak dimaksudkan sebagai titik diskusi tentang apa yang harus dianggap sebagai pemblokir rilis untuk WordPress 5.0. Saya telah mencatat pendapat orang-orang tentang masalah ini, dan saya akan menyampaikannya ke @m , yang merupakan pemimpin rilis untuk WordPress 5.0. Pemahaman saya adalah:

1. I don't have have veto over 5.0 shipping, but even if I did:

2. I'm still not convinced there are sufficient Accessibility issues that prevent a release

Jika poin kedua berubah, saya akan menyampaikan info itu. Saya berencana untuk menjadi seorang advokat, tetapi saya tidak mengatur jadwal dan saya juga tidak memiliki data yang solid seputar aksesibilitas. Itulah inti dari audit: jadi kami dapat berbicara dari tempat data keras. 🙂

Terima kasih atas semua masukannya, tetapi karena diskusi ini telah menjadi sangat di luar topik dari cakupan yang dimaksudkan, saya mengunci percakapan masalah ini untuk saat ini. Saya akan membiarkannya terbuka dan memposting pembaruan seputar audit.

Secara harfiah, setiap orang penyandang disabilitas yang telah menguji Gutenberg, baik baru-baru ini maupun yang pertama, telah menandai masalah pemblokiran mengapa Gutenberg tidak dapat diakses. Dan pengujian pengguna sama pentingnya untuk aksesibilitas seperti kepatuhan WCAG 2.0 level AA. Mungkin harus mengatakan WCAG 2.1 AA pada saat ini tetapi WCAG 2.0 masih membawa Anda lebih dekat ke tempat yang Anda inginkan. Mengatakan bahwa Anda tidak memiliki data itu tidak akurat.

Kurangnya audit dalam kasus ini tidak bertanggung jawab karena, sebagai permulaan, tidak seperti WordPress di masa lalu, kerangka kerja telah dipilih yang tidak dilengkapi dengan komponen yang dapat diakses di luar kotak, dan tidak seperti WordPress sebelumnya, Anda banyak memodifikasi dokumen model objek dengan Gutenberg, serta menghapus sesuatu dari pohon aksesibilitas, dan dalam kasus browser, DOM dan pohon aksesibilitas secara harfiah adalah bagaimana teknologi pendukung mengambil informasi untuk diinterpretasikan. Bahkan jika Anda mengabaikan teknologi pendukung, seperti yang dikatakan Gutenberg saat ini, beban kognitifnya sangat besar. Plugin editor klasik adalah pengganti yang sama sekali tidak dapat diterima. Sebagai permulaan, ini untuk seluruh situs. Jadi, jika sebuah situs menggunakan Gutenberg, dan saya perlu masuk dan melakukan sesuatu dengan konten, saya tidak dapat melakukannya untuk setiap pengguna, dan saya tidak dapat menginstal plugin editor klasik, melakukan pekerjaan saya, lalu mencopot pemasangan itu dan berharap bahwa segala sesuatu akan berperilaku sebagaimana mestinya setelah pengembalian kembali ke Gutenberg terjadi. Dan ya, saya sudah menguji ini. Fakta bahwa aksesibilitas dibiarkan sebagai renungan, sekali lagi, secara harfiah adalah bagaimana WordPress mengalami kekacauan di tahun 2011/2012 ketika tim aksesibilitas pertama kali diluncurkan. Dan proyek ini secara harfiah membuat kesalahan yang sama persis lagi, dan meminta kami untuk percaya bahwa pada akhirnya akan menyelesaikannya dengan benar, lagi. Maaf, tapi berapa kali penyandang disabilitas harus dikirim ke belakang bus untuk kebaikan yang lebih besar? Berapa kali kita harus puas dengan banyak kata-kata indah tentang aksesibilitas, tentang bagaimana kita berjanji akan melakukan yang lebih baik di lain waktu, hanya untuk menemukan ketika datang ke paku payung kuningan bahwa aksesibilitas sebenarnya bukan prioritas?

Setidaknya untuk saat ini, Automattic telah memutuskan untuk tidak melakukan audit Aksesibilitas di Gutenberg. Alasan utamanya adalah:

  1. audit tidak akan dapat ditindaklanjuti mengingat jadwal rilis kami, karena…
  2. audit tidak akan memengaruhi waktu rilis, jadi ...
  3. akan lebih bijaksana untuk mengeksplorasi audit pada waktu yang tidak terlalu terburu-buru di masa depan

@tofumatt @pento Dapatkah Anda menjelaskan apakah garis waktu yang disebutkan di sini mengacu pada tanggal rilis 19 November 2018 atau 22 Januari 2019 seperti yang disebutkan dalam Cakupan dan Jadwal WordPress 5.0 yang Diusulkan ?

Tanggal 22 Januari 2019 akan memungkinkan lebih dari tiga bulan antara hari ini dan rilis 5.0 untuk menyelesaikan audit dan mengambil tindakan. Alasan di atas menunjukkan bahwa kami tidak dapat menyelesaikan audit dan secara signifikan meningkatkan aksesibilitas dalam waktu tiga bulan. Jika benar, itulah alasan lainnya untuk memulai proses sekarang dan menanggapi audit dengan memperbaiki sebanyak mungkin masalah sebelum rilis 5.0.

Gagasan bahwa garis waktu tidak akan terlalu terburu-buru setelah 5.0 (saat berada di tangan pengguna dunia nyata yang paling membutuhkannya) tidak masuk akal sama sekali.

Situs yang mematuhi WCAG 2.0 level AA tetapi konten baru yang diedit dengan Gutenberg tidak akan patuh saat 5.0 dirilis menimbulkan mimpi buruk hukum.

Terima kasih semua yang telah berkomentar di sini sejauh ini dan terus mendiskusikan topik. Saya sangat menghargainya: dengan begitu banyak hal yang terjadi seputar WordPress 5.0, ini sangat membantu saya untuk dapat menyisihkan waktu yang layak untuk masalah ini. 🙂

@amandarush : Anda menyebutkan beberapa masalah, saya akan mencoba menjawab semuanya, tetapi tolong beri tahu saya jika saya melewatkan sesuatu.

Secara harfiah, setiap orang penyandang disabilitas yang telah menguji Gutenberg, baik baru-baru ini maupun yang pertama, telah menandai masalah pemblokiran mengapa Gutenberg tidak dapat diakses.

Saya sangat berterima kasih kepada semua orang yang telah menandai masalah ini. Saya berpikir bahwa kami telah melakukan pekerjaan yang wajar untuk mengatasi masalah ini saat muncul, tetapi jelas ada lebih banyak pekerjaan yang harus dilakukan. Saat @tofumatt merujuk pada "tidak memiliki data", saya yakin dia melihatnya dari sudut pandang bahwa kami telah memperbaiki banyak masalah aksesibilitas, kami tidak memiliki gambaran lengkap tentang keadaan saat ini, jadi kami ingin mendapatkan gambaran yang lebih jelas tentang tingkat keparahan masalah yang tersisa.

Kurangnya audit dalam kasus ini tidak bertanggung jawab karena, sebagai permulaan, tidak seperti WordPress di masa lalu, telah dipilih kerangka kerja yang tidak dilengkapi dengan komponen yang dapat diakses di luar kotak.

Apakah Anda mengacu pada React di sini? Pemahaman saya adalah bahwa aplikasi yang dibangun dengan React juga dapat diakses oleh perpustakaan lain yang secara dinamis memperbarui DOM. Asalkan kita menggunakan atribut aria-* (serta memastikan fokus keyboard yang dapat diprediksi), bahwa atribut tersebut harus dapat digunakan dengan teknologi pendukung. Apakah ini tidak benar?

Plugin editor klasik adalah pengganti yang sama sekali tidak dapat diterima. Sebagai permulaan, ini untuk seluruh situs. Jadi, jika sebuah situs menggunakan Gutenberg, dan saya perlu masuk dan melakukan sesuatu dengan konten, saya tidak dapat melakukannya untuk setiap pengguna, dan saya tidak dapat menginstal plugin editor klasik, melakukan pekerjaan saya, lalu mencopot pemasangan itu dan berharap bahwa segala sesuatu akan berperilaku sebagaimana mestinya setelah pengembalian kembali ke Gutenberg terjadi.

Terima kasih telah mengemukakan kasus penggunaan ini, ini adalah contoh bagus di mana plugin Editor Klasik saat ini gagal. Kami pasti dapat menambahkan opsi per pengguna.

Dan proyek ini secara harfiah membuat kesalahan yang sama persis lagi, dan meminta kami untuk percaya bahwa pada akhirnya akan menyelesaikannya dengan benar, lagi. Maaf, tapi berapa kali penyandang disabilitas harus dikirim ke belakang bus untuk kebaikan yang lebih besar? Berapa kali kita harus puas dengan banyak kata-kata indah tentang aksesibilitas, tentang bagaimana kita berjanji akan melakukan yang lebih baik di lain waktu, hanya untuk menemukan ketika datang ke paku payung kuningan bahwa aksesibilitas sebenarnya bukan prioritas?

Maafkan saya. Terlepas dari niat terbaik semua orang di tim Gutenberg, kami belum berbuat cukup. Sejujurnya saya dapat mengatakan bahwa aksesibilitas _has_ selalu menjadi prioritas, tetapi itu belum menjadi prioritas _high_, dan kami telah melakukan pekerjaan yang buruk dalam berkomunikasi di mana aksesibilitas telah ditingkatkan. Saya menyebutkan beberapa peningkatan tersebut dalam komentar saya sebelumnya, tetapi peningkatan tersebut tidak ada manfaatnya jika kita belum mencapai pengalaman dasar yang dapat diakses.

Tentu saja, permintaan maaf tidak ada gunanya tanpa tindakan untuk memperbaikinya, jadi inilah yang saya usulkan. Saat ini, tujuannya adalah untuk memprioritaskan dan memperbaiki masalah aksesibilitas sebanyak mungkin. Kami telah memperbaiki ratusan, dan ada perbaikan yang sedang berlangsung untuk beberapa masalah terbuka. Kami akan menguji, tentu saja, tetapi kami membutuhkan pengalaman orang-orang yang menggunakan teknologi pendukung untuk mengungkap bug. Setiap pengujian dan pelaporan bug yang dapat Anda luangkan waktu sangat dihargai.

Meskipun saya yakin kami bisa membuat editor blok ke keadaan di mana ia memiliki UX yang dapat diterima untuk pengguna teknologi pendukung pada saat 5.0 dirilis, saya menyadari ada kemungkinan kami tidak bisa. Terlepas dari pengaturan per pengguna yang Anda sarankan, bagaimana lagi kami dapat memastikan plugin Editor Klasik adalah opsi yang masuk akal untuk digunakan orang-orang sampai mereka puas dengan status editor blok?

Saya masih ingin melihat audit aksesibilitas independen terjadi, tetapi tanpa jadwal rilis yang terburu-buru. Di situlah masalah ini dapat digunakan untuk membuat kerangka kerja audit yang komprehensif. Saat masalah terungkap, mereka dapat diperbaiki dalam rilis 5.0.x, tentu tidak perlu menunggu 5.1.

@kevinwhoffman : Garis waktu mengacu pada tanggal rilis 19 Nov (atau paling lambat 27 Nov). Mendorong tanggal rilis ke 22 Januari tidak akan memberi kita banyak waktu tambahan: antara WCUS (dan persiapan yang diperlukan sebelum itu), perlu mengatur rilis WordPress 4.9.9, lalu orang-orang sedang berlibur selama Natal dan Tahun Baru, kami mungkin mendapatkan dua minggu kerja penuh tambahan dengan mendorong tanggal rilis menjadi dua bulan. Tiga bulan tambahan terdengar seperti jumlah yang besar, tetapi itu akan memberi kami hasil aktual yang sangat sedikit, dan kami masih membutuhkan audit yang cepat, jadi kami dapat bekerja mengatasinya pada bulan November.

@rcemory : Meskipun komentar Anda keluar dari topik, perlu diperhatikan bahwa diskusi ini terkait dengan antarmuka editor blok itu sendiri, bukan konten yang dihasilkannya untuk ditampilkan di bagian depan situs Anda. Seperti WordPress sekarang, konten yang dihasilkan di editor blok dapat diakses. Dalam banyak kasus, ini lebih mudah diakses daripada sebelumnya, karena editor blok melakukan pekerjaan yang lebih baik dalam menambahkan label aria-* , ia memperingatkan ketika Anda menggunakan kombinasi warna yang tidak sesuai dengan WCAG, atau ketika Anda menempatkan elemen heading dalam urutan yang salah.

Plugin editor klasik adalah pengganti yang sama sekali tidak dapat diterima. Sebagai permulaan, ini untuk seluruh situs. Jadi, jika sebuah situs menggunakan Gutenberg, dan saya perlu masuk dan melakukan sesuatu dengan konten, saya tidak dapat melakukannya untuk setiap pengguna, dan saya tidak dapat menginstal plugin editor klasik, melakukan pekerjaan saya, lalu mencopot pemasangan itu dan berharap bahwa segala sesuatu akan berperilaku sebagaimana mestinya setelah pengembalian kembali ke Gutenberg terjadi.

Terima kasih telah mengemukakan kasus penggunaan ini, ini adalah contoh bagus di mana plugin Editor Klasik saat ini gagal. Kami pasti dapat menambahkan opsi per pengguna.

Ini akan bagus tetapi ini adalah kekhawatiran yang muncul lebih dari setahun yang lalu, dan sejauh ini belum ditangani. Karena dalam keadaan saat ini begitu sebuah posting berjalan GB itu tidak dapat dikembalikan ke "biasa" dan kemudian kembali ke GB lagi sambil menyimpan semua informasi yang relevan.
Oleh karena itu, rencana untuk memiliki opsi berbasis pengguna tidak realistis karena itu berarti bahwa editor yang menyisih dari GB akan kesulitan mengedit konten yang dibuat oleh penulis menggunakan GB.

Komentar dari @amandarush sangat kuat dan dari hati. Dan, saya tahu, berdasarkan pengalaman masa lalu mencoba memajukan aksesibilitas dalam WordPress.

Sejak saya terlibat dalam Tim Aksesibilitas, ada 4 (menurut saya) peningkatan fungsi utama di area admin: Pembuat menu khusus, Manajer media, Penyesuai, dan sekarang Gutenberg.

Seperti yang awalnya disusun dan dibangun, semua komponen ini cukup banyak (atau sama sekali) tidak dapat diakses oleh pengguna pembaca layar dan pengguna keyboard yang melihat. Dalam pandangan saya ini karena aksesibilitas tidak dipikirkan sama sekali pada desain grafis dan tahap UX. Setelah Tim Aksesibilitas berseru, peningkatan aksesibilitas telah dilakukan untuk semua 4, tetapi desain yang mendasarinya dan UX sebagian besar tetap sama.

Jadi saya membagikan pandangannya bahwa WordPress terus menerus melakukan kesalahan yang sama. Dan sayangnya saya berbagi keraguannya ketika kami mendengar "Aksesibilitas sangat penting bagi kami". Ini sangat membuat frustrasi, dan salah satu alasan saya jarang berkontribusi di WP lagi.

Tampaknya tidak mungkin sekarang bahwa masalah aksesibilitas akan menghentikan dorongan untuk merilis WP5.0 pada bulan November, yang tentu saja merupakan kekecewaan besar setelah daftar 'pemblokir' aksesibilitas pertama kali dirancang pada musim semi tahun ini. Dan keinginan yang sering dikutip agar WP mendemokratisasi web, dan berjanji untuk tidak merilis fungsionalitas apa pun yang tidak sesuai dengan WCAG2.0.

Namun menurut saya tinjauan aksesibilitas independen - yang melibatkan tidak hanya pengujian untuk WCAG2.1, tetapi juga pengujian pengguna yang tepat - akan menjadi hal yang masuk akal untuk dilakukan sekarang. Setidaknya dengan cara itu kita semua akan tahu di mana kita berdiri, dan fokus yang tepat dapat diberikan untuk memprioritaskan dan memperbaiki cacat / masalah aksesibilitas di rilis mendatang.

Menanggapi hal ini dari @pento

Apakah Anda mengacu pada React di sini? Pemahaman saya adalah bahwa aplikasi yang dibangun dengan React juga dapat diakses oleh perpustakaan lain yang secara dinamis memperbarui DOM. Asalkan kami menggunakan atribut aria- * yang sesuai (serta memastikan fokus keyboard yang dapat diprediksi), bahwa atribut tersebut harus dapat digunakan dengan teknologi pendukung. Apakah ini tidak benar?

Ya, itu benar, tetapi para pengembang perlu memahami bagaimana membuat komponen mereka dapat diakses dalam desain, semantik, operasi, manajemen fokus, dan dengan penggunaan ARIA yang benar. Sayangnya, ini jarang terjadi dalam pengalaman saya.

Jika / saat Automattic mengikuti jalur audit, mungkin ada baiknya tidak hanya mengidentifikasi aliran kritis / perjalanan pengguna, tetapi juga widget umum untuk ditinjau. Jika widget ini dapat diidentifikasi dan diaudit sendiri, widget tersebut juga dapat menjadi dasar dari pustaka pola yang dapat diakses. Ini dapat membantu mengurangi risiko aksesibilitas karena lebih banyak fitur yang dibuat menggunakan pola tersebut.

mungkin ada baiknya tidak hanya mengidentifikasi arus kritis / perjalanan pengguna, tetapi juga widget umum untuk ditinjau. Jika widget ini dapat diidentifikasi dan diaudit sendiri, widget tersebut juga dapat menjadi dasar dari pustaka pola yang dapat diakses. Ini dapat membantu mengurangi risiko aksesibilitas karena lebih banyak fitur yang dibuat menggunakan pola tersebut.

@aardrian Itu adalah titik awal yang menarik yang mungkin sudah ada yang akan diperlukan untuk audit yang mungkin dapat kita gunakan sekarang untuk bertindak: Saya belum melihat perjalanan pengguna untuk Gutenberg, dan itu mungkin titik awal yang paling jelas untuk mulai ruang lingkup audit tersebut.

@karmatosed @jwold - Apakah Anda tahu jika

Saya pikir sementara utas umum ini memiliki banyak emosi (dan saya setuju Gutenberg harus dapat digunakan oleh semua orang dan dikirimkan jika siap) - saya ingin menemukan kesamaan dan langkah selanjutnya. Saya ingin mengubah tempat percakapan menjadi mengidentifikasi di mana kita siap untuk bertindak.

Alur pengguna tersebut juga akan memberi kami daftar tugas tempat untuk diaudit bagi pengembang, penguji, dan pemburu bug untuk mulai membagi dan mencari hal-hal untuk dilaporkan.

@postphotos , menurut saya @afercia menguraikan serangkaian https://github.com/WordPress/gutenberg/issues/10318#issuecomment -428957684.

@aardrian Setuju, itu tempat yang bagus untuk memulai! 👍 Terima kasih sudah mengingatnya.

Permintaan saya masih berlaku - Saya ingin tahu, di luar alur kritis awal itu jika ada pekerjaan tambahan yang telah dimasukkan ke dalam perjalanan pengguna yang berkaitan dengan fitur karena akan membantu memvalidasi pekerjaan yang kami lakukan di sini. Mungkin ada item lain yang kami (grup ini) mungkin ingin tambahkan daftar awal @afercia , atau urutan setelah audit awal. 😄

Misalnya, kami tidak memanggil fitur Struktur Konten, urung / ulangi, dll. Atau melihat posting, dan tugas-tugas yang mungkin kami setujui adalah penting dan bermanfaat bagi pengguna untuk dapat menggunakannya - hal-hal yang kami setujui membuat Gutenberg sangat berguna dan harus dapat diakses. Akan sangat bagus untuk menemukan konsensus secara aktif jika kita bisa.

Manfaat tambahan untuk melakukan audit adalah kontribusi kembali ke proyek React yang lebih besar. React memiliki masalah aksesibilitasnya sendiri, dan audit Gutenberg dapat mengidentifikasi masalah dan solusi yang terkait dan dapat membantu inti React.

Nah, ini berita menarik: https://make.wordpress.org/core/2018/10/18/regarding-accessibility-in-gutenberg/

Pintasan keyboard untuk navigasi wilayah dan blokir, perintah garis miring, peningkatan bilah alat dan bilah sisi yang dapat difokuskan dari tengara dan peran ARIA yang ditingkatkan, pengujian ujung-ke-ujung otomatis, dan banyak lagi.

ICYMI: Organisasi WPCampus mengorganisir audit aksesibilitas Gutenberg.

Kami telah menyelesaikan RFP kami dan sekarang memilih vendor.

Namun, seperti yang mungkin diketahui sebagian besar dari Anda, audit aksesibilitas profesional merupakan pengeluaran yang besar untuk lembaga nonprofit kecil seperti WPCampus.

Kami meminta bantuan Anda untuk mendanai audit guna memastikan penelitian penting ini diselesaikan.

Anda dapat membaca lebih lanjut tentang inisiatif dan memberikan donasi di situs web kami: https://wpcampus.org/2018/11/fundraising-for-wpcampus-gutenberg-accessibility-audit/

Hai Rachel,

Saya melihat Anda meminta kami untuk menyumbang untuk audit.
Saya ingin tahu apakah Anda telah memikirkan posting saya ke utas yang saya tulis ini
beberapa bulan yang lalu, menawarkan untuk menyumbangkan audit aksesibilitas, seperti ini
akan sepenuhnya menyelesaikan setiap celah yang tersisa dalam pendanaan?
Kami dipercaya oleh beberapa pemerintah teratas dan Fortune 500 di dunia
dengan proyek seperti itu!

Berikut yang saya posting pada 11 Oktober 2018:

==========================

@tofumatt https://github.com/tofumatt Saya juga sangat prihatin
Aksesibilitas WordPress dan ingin membantu Anda sukses. Saya dapat memiliki
organisasi melakukan audit aksesibilitas penuh yang sesuai dengan WCAG-EM untuk
apa pun tingkat standar yang Anda sukai, termasuk teknis dan fungsional
menguji, * dan menyumbangkan bagian apa pun dari pekerjaan yang Anda butuhkan * agar sesuai dengan Anda
anggaran.

Saya pikir kita harus melihat ATAG dan WCAG AA, dan mungkin
WCAG 2.1 bukan 2.0. Kami juga dapat memberikan rekomendasi dan
pembinaan untuk membantu Anda memilih cara terbaik dan paling berkelanjutan untuk menutup semua
celah ditemukan.

Kami sangat dekat dengan komunitas pengembangan Anda, namun kami tahu
WordPress dengan baik selama bertahun-tahun. Saya memegang semua sertifikasi IAAP dan telah memimpin
lusinan audit semacam itu di platform WordPress, selama bertahun-tahun, untuk keduanya
sektor swasta dan publik. Silakan lihat bonafid kami di

davidberman.com/about untuk memutuskan bagaimana kami dapat memberikan bantuan terbaik.

Pikiran?

  • David

Pada Rabu, 28 Nov 2018 pukul 10:10, Rachel Cherry [email protected]
menulis:

ICYMI: Organisasi WPCampus mengorganisir audit aksesibilitas
Gutenberg.

Kami telah menyelesaikan RFP kami
https://wpcampus.org/2018/10/gutenberg-a11y-audit-rfp/ dan sekarang
memilih vendor.

Namun, seperti yang mungkin diketahui sebagian besar dari Anda, seorang profesional
audit aksesibilitas adalah biaya yang besar untuk lembaga nonprofit kecil seperti WPCampus.

Kami meminta bantuan Anda untuk mendanai audit dan memastikan ini penting
penelitian selesai.

Anda dapat membaca lebih lanjut tentang inisiatif dan memberikan donasi di situs web kami:
https://wpcampus.org/2018/11/fundraising-for-wpcampus-gutenberg-accessibility-audit/

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/WordPress/gutenberg/issues/10318#issuecomment-442480511 ,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/ABz4pIgVSgZmWJRL2n3Uy-i8Ov7NXnj1ks5uzqdcgaJpZM4XG_WQ
.

-
David Berman, RGD, FGDC, CPWA
David Berman Communications | [email protected] | @tokopedia
+ 1-613-728-6777 https://dialpad.com/launch?phone=%2B1-613-728-6777 | 340
Selby Avenue, Ottawa K2A 3X6

Penasihat Tingkat Tinggi, Perserikatan Bangsa-Bangsa | Pakar yang Diundang, W3C | Ico-D
Kursi Keberlanjutan | Ketua Carleton U. Access Network


Yang Akan Datang: Toronto | New Orleans | Montreal | Buenos Aires | Tampa | Tel Aviv
Kursus aksesibilitas: bergabunglah dengan kami secara online www.davidberman.com/next

Pesan ini mungkin berisi informasi hak milik. Tidak resmi
pengungkapan / penyalinan / distribusi konten dilarang.

@tofumatt , saya melihat ini di blog pribadi Matt Mullenweg pada 29 November:

Terakhir, Automattic akan mendanai studi aksesibilitas WordPress, Gutenberg, dan evaluasi praktik terbaik di seluruh web, untuk memastikan WordPress dapat diakses sepenuhnya dan menetapkan standar baru untuk web secara keseluruhan.

Karena Anda adalah perwakilan Automattic, setelah audit Automattic kembali aktif, dapatkah Anda memberi tahu kami apakah ini akan terpisah dari audit WPCampus atau apakah Automattic akan mendanai audit WPCampus?

Di satu sisi, saya benci melihat WPCampus harus mendanai itu. Di sisi lain, saya menyukai gagasan dua audit dari dua perusahaan untuk dibandingkan dan kontras.

Matt menanggapi pertanyaan saya di blognya:

Saya pikir tidak apa-apa memiliki dua juga, saya akan berbicara dengan Rachel tentang bagaimana pendanaan berjalan.

Bagi mereka yang mengikuti, telah berkomitmen untuk mendanai sepenuhnya apa pun yang dibutuhkan proyek Rachel di sisi Kampus WP, dan dalam fase pemilihan vendor untuk proyek yang disponsori Automattic. Tujuan yang terakhir adalah untuk juga melihat apa pendekatan aksesibilitas praktik terbaik untuk antarmuka gaya editor blok lainnya di web modern.

@m Terima kasih atas pembaruannya. Sangat menggembirakan melihat hal ini terus berlanjut dan saya benar-benar tidak sabar untuk melihat ke mana arahnya. Saya ingin agar WordPress suatu hari nanti menjadi contoh bagaimana aksesibilitas harus diperlakukan.

@

Bagi mereka yang mengikuti, telah berkomitmen untuk mendanai sepenuhnya apa pun yang dibutuhkan proyek Rachel di sisi WP Campus

Ini bagus dan berharga. Adakah alasan Anda tidak mendanainya secara total, hari ini? Tampaknya aneh meminta orang untuk terus menyumbang ketika mereka tahu itu akan sepenuhnya didanai.

@aardrian Itu bukan semangat dari apa yang kami lakukan. Kami ingin ini menjadi proyek komunitas dan memberikan kesempatan kepada orang dan organisasi untuk berpartisipasi dan menunjukkan dukungan, jika mereka mampu.

Pada akhir 2018, WPCampus merilis permintaan proposal untuk melakukan audit aksesibilitas editor blok WordPress, juga dikenal sebagai Gutenberg. Pada awal 2019, kami mengumumkan pemilihan Tenon, LLC untuk melakukan audit, dengan biaya $ 31.200.

Hari ini, dengan senang hati kami merilis laporan Tenon tentang aksesibilitas editor baru.

Lihat lebih lanjut di https://wpcampus.org/2019/05/gutenberg-audit-results/

Saya pikir itu menyimpulkan masalah ini 🎉🎉🎉🎉🎉

Semua masalah yang dilaporkan dilacak dalam proyek ini:
https://github.com/WordPress/gutenberg/projects/25

Semua masalah yang dilaporkan dilacak dalam proyek ini

Tidak sepenuhnya benar. Laporan WPCampus / Tenon menyertakan pertimbangan penting tambahan yang tidak tercakup dalam daftar masalah di GitHub. Lebih khusus lagi, Ringkasan Eksekutif dan Laporan Kegunaan menunjukkan (dengan data) ada masalah aksesibilitas struktural yang lebih luas di Gutenberg yang tidak dapat diatasi dalam masalah GitHub yang kecil dan dapat ditindaklanjuti dan membutuhkan solusi di tingkat yang lebih tinggi.

Ini untuk memperjelas bahwa meskipun semua masalah yang dilaporkan telah diselesaikan, akan ada masalah aksesibilitas penting yang masih harus diselesaikan. Ini biasanya terkait dengan desain umum editor.

Sebagai referensi, saya melampirkan di sini dua dokumen yang diterbitkan di https://wpcampus.org/2019/05/gutenberg-audit-results/

Dokumen ringkasan yang menjelaskan pengujian kegunaan Tenon
Gutenberg_UX_Report.pdf

Ringkasan bisnis plan
Gutenberg_Executive_Summary.pdf

Saya menyarankan untuk membuka masalah baru, atau bahkan proyek, untuk menangani masalah kegunaan yang ditemukan dalam laporan.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat