Ke arah kebolehcapaian

Hari Jumaat adalah penghujung hari bekerja. Berita buruk selalu datang pada penghujung hari bekerja pada hari Jumaat.

Anda akan meninggalkan pejabat, surat baru mengenai penyusunan semula yang lain baru sahaja tiba dalam mel.

Terima kasih xxxx, yyy mulai hari ini anda akan melaporkan zzzz
...
Dan pasukan Hugh akan memastikan produk kami boleh diakses oleh orang kurang upaya.

Oh tidak! Mengapa saya layak ini? Adakah mereka mahu saya pergi? Tetapkan diri anda untuk kerja keras tanpa rasa syukur dan cuba membetulkan kesilapan orang lain. Ini pasti satu kegagalan...

Ini adalah ketersediaan beberapa tahun yang lalu. Beberapa orang miskin diberi tugas "membersihkan" UI untuk mencuba dan menjadikannya boleh diakses oleh orang kurang upaya.

Perkara ini sebenarnya agak kabur - mungkin jika anda dapat melihat penunjuk fokus dan tab melalui medan, mempunyai beberapa teks alt dan beberapa huraian medan, ia akan dianggap bahawa aplikasi anda boleh diakses ...

Tetapi tiba-tiba "pepijat" mula membiak pada kelajuan runtuhan salji.

Pelbagai pembaca skrin (Bahasa Inggeris Pembaca Skrin) dan pelayar berkelakuan sama sekali berbeza.

Pengguna telah mengadu bahawa apl itu tidak boleh digunakan.

Sebaik sahaja kesilapan dibetulkan di satu tempat, yang lain muncul di tempat lain.

Dan hanya menukar dan membetulkan ralat antara muka pengguna memerlukan usaha Herculean.

Saya berada di sana. Saya terselamat, tetapi kami tidak "berjaya" - secara teknikal kami banyak membersihkan, menambah banyak perihalan bidang, peranan dan mencapai beberapa tahap pematuhan, tetapi tiada siapa yang gembira. Pengguna masih mengadu bahawa mereka tidak dapat menavigasi aplikasi. Pengurus masih mengadu tentang aliran kesilapan yang berterusan. Jurutera mengadu bahawa masalah itu ditimbulkan secara tidak betul, tanpa penyelesaian "betul" yang jelas yang akan berfungsi dalam semua kes.

Terdapat beberapa detik yang jelas membuka mata sepanjang perjalanan saya untuk memahami kebolehaksesan.
Mungkin yang pertama ialah kesedaran bahawa menambahkan fungsi kebolehaksesan di atas produk siap adalah sukar. Dan lebih sukar untuk meyakinkan pengurus bahawa ia amat sukar! Tidak, ini bukan sekadar "tambah beberapa teg" dan UI akan berfungsi dengan baik. Tidak, ini tidak boleh diselesaikan dalam masa tiga minggu; walaupun tiga bulan tidak akan mencukupi.
Detik kebenaran saya yang seterusnya datang apabila saya melihat secara langsung bagaimana pengguna buta sebenarnya menggunakan apl kami. Ini sangat berbeza daripada melihat mesej ralat.

Saya akan kembali kepada perkara ini berulang kali, tetapi hampir semua "andaian" kami tentang cara orang menggunakan apl kami adalah salah.

Menavigasi antara muka pengguna yang kompleks menggunakan ketukan kekunci Tab/Shift+Tab - ini payah! Kita perlukan sesuatu yang lebih baik. Pintasan papan kekunci, pengepala.

Hilang fokus apabila menukar UI bukan masalah besar, bukan? Mari kita fikirkan semula - ini sangat mengelirukan.

Saya meneruskan, mengerjakan projek yang berbeza untuk seketika, dan kemudian kami memulakan projek baharu, dengan antara muka pengguna yang kompleks dan pemasangan yang jelas, untuk akhirnya mendapat kebolehaksesan pada masa ini.

Jadi, kami mengambil langkah ke belakang dan melihat bagaimana kami boleh melaksanakan ini secara berbeza dan berjaya, dan menjadikan proses itu kurang membosankan!

Dengan cepat kami membuat beberapa kesimpulan:

1. Kami tidak mahu orang yang membangunkan antara muka pengguna kacau dengan label/peranan aria dan, sudah tentu, struktur HTML komponen. Kami perlu menyediakan mereka dengan komponen yang betul yang membina kebolehaksesan terus dari kotak.
2. Kebolehcapaian == Kemudahan penggunaan – i.e. Ini bukan sekadar cabaran teknikal. Kami perlu mengubah keseluruhan proses reka bentuk dan memastikan kebolehcapaian diambil kira dan dibincangkan sebelum reka bentuk UI bermula. Anda perlu berfikir lebih awal tentang cara pengguna akan menemui sebarang fungsi, cara mereka menavigasi dan cara klik kanan dari papan kekunci akan berfungsi. Kebolehcapaian harus menjadi bahagian penting dalam proses reka bentuk - bagi sesetengah pengguna ia lebih daripada sekadar penampilan aplikasi.
3. Sejak awal lagi, kami ingin mendapatkan maklum balas daripada pengguna buta dan orang kurang upaya lain tentang kemudahan penggunaan aplikasi.
4. Kami memerlukan cara yang sangat baik untuk menangkap regresi kebolehaksesan.

Nah, dari sudut pandangan kejuruteraan, bahagian pertama kedengaran agak menyeronokkan - membangunkan seni bina dan melaksanakan perpustakaan komponen. Dan memang begitu.

Mengambil langkah ke belakang, melihat Contoh ARIA dan dengan menganggap ini sebagai masalah reka bentuk dan bukannya masalah "kesesuaian", kami memperkenalkan beberapa abstraksi. Komponen mempunyai 'Struktur' (terdiri daripada elemen HTML) dan 'Tingkah Laku' (cara ia berinteraksi dengan pengguna). Sebagai contoh, dalam coretan di bawah kami mempunyai senarai ringkas tidak tertib. Dengan menambahkan "tingkah laku", peranan yang sepadan ditambahkan pada senarai untuk menjadikannya bertindak seperti senarai. Kami melakukan perkara yang sama untuk menu.

Malah, bukan sahaja peranan ditambahkan di sini, tetapi juga pengendali acara untuk navigasi papan kekunci.

Ini kelihatan lebih kemas. Jika kita boleh mendapatkan pemisahan yang bersih antara mereka, tidak kira bagaimana struktur itu dicipta, kita boleh menggunakan Gelagat padanya dan mendapatkan kebolehaksesan yang betul.

Anda boleh melihat ini dalam tindakan di https://stardust-ui.github.io/react/ – Perpustakaan UX Bertindak, yang direka dan dilaksanakan dengan mengambil kira kebolehaksesan dari awal.

Bahagian kedua - mengubah pendekatan dan proses di sekitar reka bentuk pada mulanya menakutkan saya: jurutera rendah yang cuba meneruskan perubahan organisasi tidak selalu berakhir dengan baik, tetapi ia ternyata menjadi salah satu bidang paling menarik di mana kami membuat sumbangan penting kepada proses . Secara ringkasnya, proses kami adalah seperti berikut: fungsi baharu akan dibangunkan oleh satu pasukan, kemudian pasukan kepimpinan kami akan menyemak/mengulang cadangan, dan kemudian, setelah diluluskan, reka bentuk biasanya akan diserahkan kepada pasukan kejuruteraan. Dalam kes ini, pasukan kejuruteraan secara berkesan "memiliki" fungsi kebolehaksesan kerana menjadi tanggungjawab mereka untuk menyelesaikan sebarang isu yang berkaitan dengannya.

Pada mulanya, agak sukar untuk menjelaskan bahawa kebolehcapaian dan kebolehgunaan adalah berkait rapat dan ini perlu dilakukan pada peringkat reka bentuk, jika tidak, ia akan membawa kepada perubahan besar dan definisi semula beberapa peranan. Walau bagaimanapun, dengan sokongan pihak pengurusan dan pemain utama, kami mengambil idea itu dan melaksanakannya supaya reka bentuk diuji untuk kebolehaksesan dan kebolehgunaan sebelum ia dibentangkan kepada pihak pengurusan.

Dan maklum balas ini sangat berharga kepada semua orang - ia adalah hebat sebagai latihan dalam perkongsian pengetahuan/komunikasi tentang cara pengguna berinteraksi dengan aplikasi web, kami mengenal pasti banyak kawasan masalah UI sebelum ia dibina, pasukan pembangunan kini mempunyai spesifikasi yang lebih baik untuk tidak hanya visual, tetapi juga aspek tingkah laku reka bentuk. Perbincangan sebenar adalah perbincangan yang menyeronokkan, bertenaga, bersemangat tentang aspek teknikal dan interaksi.

Kami boleh melakukan ini dengan lebih baik jika kami mempunyai pengguna buta dan kurang upaya pada mesyuarat ini (atau seterusnya) - ini sukar untuk diatur, tetapi kami kini bekerjasama dengan kedua-dua organisasi dan syarikat buta tempatan, yang menyediakan ujian luaran untuk mengesahkan aliran pelaksanaan pada awal pembangunan—baik pada tahap aliran komponen dan pelaksanaan.

Jurutera kini mempunyai spesifikasi yang agak terperinci, komponen tersedia yang boleh mereka gunakan untuk melaksanakan, dan cara untuk mengesahkan aliran pelaksanaan. Sebahagian daripada pengalaman yang telah mengajar kita ialah perkara yang telah kita rindui selama ini—bagaimana kita boleh menghentikan regresi. Begitu juga, orang boleh menggunakan integrasi atau ujian hujung ke hujung untuk menguji kefungsian, yang kami perlukan untuk mengesan perubahan dalam interaksi dan aliran pelaksanaan—kedua-dua visual dan tingkah laku.

Menentukan regresi visual adalah tugas yang agak ditakrifkan, terdapat sangat sedikit yang boleh ditambah pada proses selain mungkin menyemak sama ada fokus boleh dilihat semasa menavigasi dengan papan kekunci. Lebih menarik ialah dua teknologi yang agak baharu untuk bekerja dengan kebolehcapaian.

1. Insight Accessibility ialah satu set alat yang boleh dijalankan dalam penyemak imbas dan sebagai sebahagian daripada kitaran binaan/ujian untuk mengenal pasti masalah.
2. Mengesahkan bahawa pembaca skrin berfungsi dengan betul telah menjadi tugas yang sangat mencabar. Dengan pengenalan akses kepada Kebolehaksesan DOM, kami akhirnya dapat mengambil gambar kebolehaksesan apl, sama seperti yang kami lakukan untuk ujian visual dan mengujinya untuk regresi.

Jadi, dalam bahagian kedua cerita, kami beralih daripada mengedit kod HTML kepada bekerja pada tahap abstraksi yang lebih tinggi, mengubah proses pembangunan reka bentuk dan memperkenalkan ujian menyeluruh. Proses baharu, teknologi baharu dan tahap pengabstrakan baharu telah mengubah sepenuhnya landskap kebolehcapaian dan maksud bekerja dalam ruang ini.
Tetapi ini hanya permulaan.

"Pemahaman" seterusnya ialah pengguna buta memacu teknologi canggih - mereka adalah orang yang paling mendapat manfaat bukan sahaja daripada perubahan yang kami terangkan sebelum ini, tetapi juga pendekatan dan idea baharu diwujudkan oleh ML/AI. Contohnya, teknologi Immersive Reader membolehkan pengguna mempersembahkan teks dengan lebih mudah dan jelas. Ia boleh dibaca dengan kuat, struktur ayat dipecahkan secara tatabahasa, malah makna perkataan dipaparkan secara grafik. Ini tidak sesuai dengan mentaliti lama "jadikan ia boleh diakses" sama sekali - ia adalah ciri kebolehgunaan yang akan membantu semua orang.

ML/AI mendayakan cara baharu sepenuhnya untuk berinteraksi dan bekerja, dan kami teruja untuk menjadi sebahagian daripada peringkat seterusnya dalam perjalanan termaju ini. Inovasi didorong oleh perubahan dalam pemikiran - manusia telah wujud selama beribu tahun, mesin selama ratusan tahun, laman web selama beberapa dekad, dan telefon pintar lebih sedikit, teknologi mesti menyesuaikan diri dengan manusia, dan bukan sebaliknya.

P.S. Artikel tersebut telah diterjemahkan dengan penyimpangan kecil daripada yang asal. Sebagai pengarang bersama artikel ini, saya bersetuju dengan penyimpangan ini dengan Hugh.

Hanya pengguna berdaftar boleh mengambil bahagian dalam tinjauan. Log masuk, Sama-sama.

Adakah anda memberi perhatian kepada kebolehaksesan aplikasi anda?

• Ya

• Tiada

• Ini adalah kali pertama saya mendengar tentang kebolehaksesan apl.

17 pengguna mengundi. 5 pengguna berpantang.

Sumber: www.habr.com