ARIA: racun atau penawar?

Bagaimana berbohong kepada pembaca layar dapat menyembuhkan aksesibilitas, jika tidak menggosokkan garam ke dalamnya!

Apa itu ARIA?

ARIA memungkinkan penulis web menciptakan realitas alternatif, yang hanya dapat dilihat oleh pembaca layar 🤥

Terkadang perlu untuk memperluas kebenaran atau bahkan "berbohong" kepada pembaca layar tentang apa yang terjadi di konten web. Misalnya, "fokus benar-benar ada di sini!" atau "ini benar-benar penggeser!". Ini seperti menambahkan catatan tempel ajaib di atas alat dan widget di meja kerja Anda. Catatan tempel ajaib ini membuat semua orang percaya dengan apa yang tertulis di dalamnya.

Setiap kali ada catatan tempel yang ajaib, catatan tersebut menggantikan keyakinan kita tentang apa itu setiap alat, atau sesuatu tentang alat tersebut. Contoh: "alat yang tepat di sini adalah lem tembak!". Meskipun sebenarnya masih berupa kotak biru kosong di atas meja kerja, catatan tempel yang ajaib akan membuat kita melihatnya adalah lem tembak. Kita juga bisa menambahkan, "dan sudah 30% penuh!". Pembaca layar akan melaporkan bahwa ada 30% glue gun penuh di sana.

Web yang setara dengan ini adalah dengan mengambil elemen kotak biasa (div) dengan gambar di dalamnya, dan menggunakan ARIA untuk mengatakan itu adalah penggeser pada nilai 30 dari 100.

Apa yang bukan ARIA?

ARIA tidak memengaruhi tampilan laman web, ataupun perilaku pengguna mouse atau keyboard. Hanya pengguna teknologi pendukung yang akan melihat perbedaan dari ARIA. Developer web dapat menambahkan ARIA arbitrer apa pun tanpa memengaruhi pengguna yang tidak menjalankan teknologi pendukung.

Anda membacanya dengan benar: ARIA sebenarnya tidak melakukan apa pun terhadap fokus keyboard atau urutan tab. Itu semua dilakukan dalam HTML, kadang-kadang disesuaikan dengan bit JavaScript.

Bagaimana cara kerja ARIA?

Browser dimintai informasi tentang setiap elemen oleh pembaca layar atau teknologi pendukung lainnya. Ketika ARIA ada di suatu elemen, browser akan mengambil informasi dan mengubah informasi yang disampaikannya kepada pembaca layar tentang elemen tersebut.

Mengapa ARIA?

Kenapa kita mau berbohong kepada pengguna!?

Katakanlah toko web lokal tidak menjual semua widget yang kita butuhkan. Tapi, kami adalah MacGyver. Kita bisa membuat {i>widget<i} sendiri dari widget lainnya! FWIW, tujuh barang MacGyver yang paling sering digunakan adalah pisau Swiss Army, permen karet, tali sepatu, korek api, klip kertas, lilin ulang tahun, dan lakban. Dia menggunakannya untuk membuat bom dan hal-hal lain yang tidak hanya ada di sana. Cara ini sangat mirip dengan seorang penulis web yang perlu membuat bilah menu. Bilah menu sangat berguna sehingga Anda akan berpikir mereka akan menjadi bagian dari HTML, padahal sebenarnya tidak. Baiklah! Anda tidak berpikir penulis akan senang dengan link dan tombol, bukan? Jadi, penulis akan menyusunnya menggunakan alat favoritnya: divs, image, style, pengendali klik, pengendali penekanan tombol, spit, dan ARIA.

Terkadang, kami tidak menggunakan ARIA secara maksimal, melainkan hanya sebagai peningkatan kualitas. Akan berguna untuk menambahkan sedikit ARIA pada beberapa HTML yang pada dasarnya sudah berfungsi. Misalnya, kita mungkin ingin kontrol formulir mengarah ke pemberitahuan pesan error yang terkait dengan beberapa input yang tidak valid. Atau kita mungkin ingin menunjukkan bahwa {i>textbox <i}adalah untuk mencari. Perubahan kecil ini bisa membuat {i>website<i} biasa lebih bermanfaat dengan pembaca layar.

Contoh panel menu

Mendukung orang yang mengklik mouse

Mari kita buat bilah menu bersama-sama. Kami menampilkan banyak item dalam elemen kotak generik yang disebut divs. Setiap kali pengguna mengklik div, perintah yang sesuai akan dijalankan. Keren, cara ini cocok untuk orang yang suka mengklik mouse!

Selanjutnya kita membuatnya terlihat menarik. Kami menggunakan CSS, yaitu gaya, menata sesuatu dengan baik dan menempatkan garis batas visual di sekelilingnya. Kita membuatnya terlihat seperti bilah menu lain yang secara intuitif tahu bahwa itu adalah bilah menu dan cara menggunakannya. Panel menu kita bahkan menggunakan warna latar belakang yang berbeda pada item apa pun yang ada di atas mouse, sehingga memberikan beberapa masukan visual yang bermanfaat bagi pengguna.

Beberapa item menu adalah induk. Mereka memunculkan submenu turunan. Setiap kali pengguna mengarahkan kursor ke salah satunya, kita akan memulai animasi yang menggeser submenu turunan.

Tentu saja, ini sangat sulit diakses, seperti kebanyakan kasus di web, terutama karena wizard standar HTML tidak menambahkan semua yang dibutuhkan oleh penulis web. Dan meskipun demikian, penulis web akan selalu ingin membuat versi khusus mereka sendiri.

Membuat panel menu kami dapat diakses dengan keyboard

Sebagai langkah pertama menuju aksesibilitas, mari kita tambahkan aksesibilitas keyboard. Bagian ini hanya menggunakan HTML, dan bukan ARIA. Perlu diingat bahwa ARIA tidak memengaruhi aspek inti seperti tampilan, mouse, atau keyboard bagi pengguna tanpa teknologi pendukung.

Seperti halnya laman web yang dapat merespons {i>mouse<i}, dan juga dapat merespons {i>keyboard<i}. JavaScript kami akan memproses semua penekanan tombol yang terjadi dan memutuskan apakah penekanan tombol berguna. Jika tidak, ia akan melemparkannya kembali ke laman seperti ikan yang terlalu kecil untuk dimakan. Aturan kami kurang lebih seperti:

• Jika pengguna menekan tombol panah, mari kita lihat blueprint panel menu internal kita dan putuskan seperti apa item menu aktif yang baru. Kita akan menghapus sorotan saat ini dan menyoroti item menu baru sehingga pengguna yang melihat dapat mengetahui lokasinya secara visual. Halaman web kemudian harus memanggil event.preventDefault() untuk mencegah browser melakukan tindakan yang biasa (dalam hal ini, men-scroll halaman).
• Jika pengguna menekan tombol Enter, kita dapat memperlakukannya seperti klik, dan melakukan tindakan yang sesuai (atau bahkan membuka menu lain).
• Jika pengguna menekan tombol yang seharusnya melakukan sesuatu yang lain, jangan memakannya! Tampilkan kembali ke halaman sebagaimana mestinya. Misalnya, panel menu kita tidak memerlukan tombol Tab, jadi tampilkan kembali. Ini sulit untuk dilakukan dengan benar, dan penulis sering mengacaukannya. Misalnya, panel menu memerlukan tombol panah, tetapi bukan Alt+Arrow atau Command+Arrow. Itu adalah pintasan untuk berpindah ke halaman sebelumnya/berikutnya di histori web tab browser Anda. Jika penulis tidak berhati-hati, {i> menu bar<i} akan memakannya. Serangan semacam ini sering terjadi, dan kita bahkan belum mulai dengan ARIA!

Akses pembaca layar ke panel menu

Panel menu kami dibuat dengan lakban dan divs. Akibatnya, pembaca layar tidak mengetahui apa itu. Warna latar belakang untuk item aktif hanyalah warna. Div item menu hanyalah objek biasa tanpa arti tertentu. Akibatnya, pengguna panel menu tidak mendapatkan petunjuk apa pun tentang tombol yang harus ditekan atau item yang berada di dalamnya.

Tapi itu tidak adil! Bilah menu berfungsi dengan baik untuk pengguna yang berpenglihatan normal.

ARIA untuk menolong. ARIA memungkinkan kita berpura-pura kepada pembaca layar bahwa fokus ada di panel menu. Jika penulis melakukan semuanya dengan benar, panel menu kustom kita akan terlihat ke pembaca layar seperti panel menu di aplikasi desktop.

Pertama, ahem, ARIA lie, adalah menggunakan atribut aria-activedescendant, dan menetapkannya ke ID item menu yang saat ini aktif, berhati-hatilah untuk memperbaruinya setiap kali berubah. Misalnya, aria-activedescendant="settings-menuitem". Kebohongan putih kecil ini menyebabkan pembaca layar mempertimbangkan item aktif ARIA sebagai fokus, yang dibacakan dengan keras atau ditampilkan di penampil Braille.

Kembali ke aria-activedescendant. Dengan menggunakannya untuk menunjuk dari panel menu yang difokuskan ke item menu tertentu, pembaca layar sekarang tahu ke mana pengguna telah berpindah, tetapi tidak ada hal lain tentang objek. Apa itu div? Di sinilah atribut peran berperan. Kita menggunakan role="menubar" pada elemen penampung untuk semuanya, lalu menggunakan role="menu" pada grup item, dan role="menuitem" pada ... drum ... masing-masing item menu.

Bagaimana jika item menu dapat mengarah ke menu turunan? Pengguna perlu tahu itu kan? Untuk pengguna yang berpenglihatan normal, mungkin ada gambar kecil segitiga di akhir menu, tetapi pembaca layar tidak tahu cara membaca gambar secara otomatis, setidaknya pada tahap ini. Kita dapat menambahkan aria-expanded="false" pada setiap item menu yang dapat diluaskan untuk menunjukkan bahwa 1) ada sesuatu yang dapat diperluas, dan 2) saat ini tidak diperluas. Sebagai sentuhan tambahan, penulis harus menempatkan role="none" pada segitiga img untuk menunjukkan bahwa elemen tersebut hanya untuk tujuan prettifikasi. Hal ini mencegah pembaca layar mengatakan apa pun tentang gambar yang akan berlebihan dan mungkin mengganggu.

Menangani bug

Bug keyboard (HTML!)

Meskipun akses keyboard adalah bagian dari HTML inti, penulis sering kali mengacaukannya, baik karena mereka tidak terlalu banyak menggunakan navigasi keyboard, atau karena ada banyak hal yang perlu dilakukan dengan benar.

Contoh bug:

• Kotak centang menggunakan spasi untuk beralih, tetapi penulis lupa memanggil preventDefault(). Sekarang, spasi akan mengalihkan kotak centang dan halaman ke bawah, yang merupakan perilaku browser default untuk spasi.
• Dialog modal ARIA ingin membatasi navigasi tab di dalamnya, dan penulisnya lupa untuk secara khusus mengizinkan Control+Tab masuk ke browser. Sekarang, Control+Tab hanya menavigasi dalam dialognya, dan tidak beralih tab di browser sebagaimana mestinya. Duh.
• Penulis membuat daftar pilihan, dan menerapkan ke atas/bawah, tetapi tidak menerapkan home/end/pageup/pagedown atau navigasi huruf pertama.

Penulis harus mengikuti pola yang telah diketahui. Lihat bagian Referensi untuk informasi selengkapnya.

Untuk masalah murni akses keyboard, sebaiknya coba tanpa pembaca layar atau dengan menonaktifkan mode browser virtual. Pembaca layar umumnya tidak diperlukan untuk menemukan bug keyboard, dan akses keyboard sebenarnya diterapkan dengan HTML, bukan ARIA. Lagi pula, ARIA tidak memengaruhi hal-hal dasar seperti perilaku {i>keyboard<i} atau {i>mouse<i}, tetapi hanya terletak pada pembaca layar tentang apa yang ada di laman web, apa yang saat ini difokuskan, dll.

Bug keyboard hampir selalu menjadi bug di konten web, khususnya di HTML dan JavaScript-nya, bukan di ARIA.

Bug ARIA: mengapa ada begitu banyak?

Ada banyak bagian di mana penulis dapat salah memahami ARIA, dan masing-masing akan menyebabkan kerusakan total atau perbedaan kecil. Sudut pandang yang halus mungkin lebih buruk, karena penulisnya tidak akan dapat memahaminya sebelum memublikasikannya.

Lagi pula, kecuali jika penulisnya adalah pengguna pembaca layar yang berpengalaman, akan terjadi kesalahan pada ARIA. Dalam contoh panel menu, penulis dapat berpikir bahwa peran "option" digunakan jika "menuitem" benar. Mereka mungkin lupa menggunakan aria-expanded, lupa menetapkan dan menghapus aria-activedescendant pada waktu yang tepat, atau lupa memiliki panel menu yang berisi menu lainnya. Dan bagaimana dengan jumlah item menu? Biasanya item menu disajikan oleh pembaca layar dengan sesuatu seperti "item 3 dari 5" sehingga pengguna tahu di mana mereka berada. Hal ini umumnya dihitung secara otomatis oleh browser, tetapi dalam beberapa kasus, dan pada beberapa kombinasi browser - pembaca layar, angka yang salah mungkin dihitung, dan penulis harus mengganti angka ini dengan aria-posinset dan aria-setsize.

Dan ini hanyalah bilah menu. Pikirkan berapa banyak jenis widget yang ada. Sekilas tentang spesifikasi ARIA atau praktik penulisan jika Anda suka. Untuk setiap pola, ada banyak cara untuk disalahgunakan oleh ARIA. ARIA bergantung pada penulis untuk mengetahui apa yang mereka lakukan. Apa yang mungkin tidak beres, mengingat sebagian besar penulis bukan pengguna pembaca layar?

Dengan kata lain, 100 persen diperlukan bagi pengguna pembaca layar yang sebenarnya untuk mencoba widget ARIA sebelum dianggap dapat dikirimkan. Terlalu banyak perbedaan. Idealnya, semuanya akan dicoba dengan beberapa kombinasi pembaca layar browser yang berbeda, karena banyaknya keunikan implementasi, selain beberapa implementasi yang tidak lengkap.

Ringkasan

Singkatnya, keajaiban ARIA dapat digunakan untuk mengganti atau menambahkan ke apa pun dan semua yang dikatakan HTML. Fungsi ini dapat digunakan untuk melakukan sedikit perubahan pada presentasi aksesibilitas, atau membuat seluruh pengalaman. Inilah sebabnya mengapa ARIA sangat canggih, tetapi juga berbahaya, di tangan penulis web lokal kami yang ramah yang umumnya tidak menggunakan pembaca layar.

ARIA hanyalah sebuah kebenaran sederhana yang menggantikan lapisan markup. Ketika pembaca layar menanyakan apa yang terjadi, jika ARIA ada, mereka akan mendapatkan kebenaran versi ARIA, bukan kebenaran dasar yang sebenarnya.

Adendum 1: Referensi Tambahan

Referensi hybrid dengan info keyboard dan contoh kode

• Praktik Penulisan ARIA W3C: ini mendokumentasikan karakteristik navigasi keyboard yang penting dari setiap contoh dan memberikan kode JS/CSS/ARIA yang berfungsi. Contoh-contoh tersebut difokuskan pada hal-hal yang berhasil saat ini, dan tidak mencakup seluler.

Tambahan 2: Apa yang paling sering digunakan untuk ARIA?

Karena ARIA dapat menggantikan atau melengkapi kebenaran kecil atau besar, umumnya berguna untuk mengatakan hal-hal yang penting bagi pembaca layar.

Berikut adalah beberapa penggunaan umum ARIA.

• Widget khusus yang tidak ada di HTML, seperti panel menu, pelengkapan otomatis, hierarki, atau spreadsheet
• Widget yang ada di HTML, tetapi penulisnya tetap menciptakannya sendiri, mungkin karena widget tersebut perlu menyesuaikan perilaku atau tampilan widget normal. Misalnya, elemen <input type="range"> HTML pada dasarnya adalah penggeser, tetapi penulis ingin membuatnya terlihat berbeda. Dalam sebagian besar hal, CSS dapat digunakan, tetapi untuk input type="range", CSS dianggap tidak nyaman. Penulis dapat membuat penggesernya sendiri, dan menggunakan role="slider" pada penggeser tersebut dengan aria-valuenow untuk menentukan nilai saat ini.
• Region live memberi tahu pembaca layar "di area halaman ini, apa pun yang berubah perlu diberitahukan kepada pengguna."
• {i>Landmark<i} (sekarang HTML memiliki padanannya). Jenis {i>heading<i}, karena dimaksudkan untuk membantu pengguna pembaca layar menemukan apa yang mereka inginkan dengan lebih cepat. Namun, keduanya berbeda karena berisi seluruh area terkait. Seperti, "penampung ini adalah area utama halaman" dan "penampung ini adalah panel navigasi".

Adendum 3: Apa yang dimaksud dengan Accessibility API?

API aksesibilitas adalah cara pembaca layar atau AT lain mengetahui apa yang ada di halaman dan apa yang terjadi saat ini. Contohnya termasuk MSAA, IA2, dan UIA. Dan itu hanya Windows! Ada dua bagian untuk API aksesibilitas:

• "Pohon" objek yang mewakili hierarki container. Ini seperti boneka Rusia, tetapi setiap boneka dapat berisi beberapa boneka lainnya. Contohnya, dokumen dapat berisi banyak paragraf, dan sebuah paragraf dapat berisi teks, gambar, link, cetak tebal, dll. Setiap item dalam hierarki objek dapat memiliki properti seperti peran (apa saya?), nama/label, nilai yang dimasukkan pengguna, deskripsi, serta status boolean seperti dapat difokuskan, difokuskan, wajib, dicentang. ARIA dapat mengganti salah satu properti ini. Pembaca layar menggunakan hierarki tersebut untuk membantu pengguna bernavigasi dalam mode buffer virtual, seperti "tolong buka judul berikutnya".
• Serangkaian peristiwa yang terjadi dan mendeskripsikan perubahan pada hierarki, seperti "fokus sekarang ada di sini!". Pembaca layar menggunakan peristiwa untuk memberi tahu pengguna apa yang baru saja terjadi. Saat markup HTML atau ARIA yang penting berubah, peristiwa akan diaktifkan untuk memberi tahu pembaca layar bahwa ada sesuatu yang berubah.

Biasanya penulis hanya menggunakan HTML, yang memetakan dengan baik ke API aksesibilitas ini. Jika HTML tidak cukup, ARIA akan digunakan dan browser akan mengganti semantik HTML sebelum mengirim hierarki objek atau peristiwa ke pembaca layar.