ARIA: racun atau penawar?

Apa yang dimaksud dengan ARIA?

ARIA memungkinkan penulis web menciptakan realitas alternatif, yang hanya terlihat oleh pembaca layar.

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

Jika sticky note ajaib ada, sticky note tersebut akan menggantikan keyakinan kita tentang apa yang dilakukan atau fungsi setiap alat. Misalnya, jika Anda menambahkan ARIA yang bertuliskan "benda ini di sini adalah lem pistol!". Meskipun itu kotak biru kosong, catatan melekat ajaib memberi tahu kita bahwa itu adalah lem pistol. Kita juga dapat menambahkan, "dan sudah terisi 30%". Pembaca layar kini melaporkan bahwa ada lem panas yang terisi 30%.

Web yang setara dengan ini adalah mengambil div biasa dengan gambar di dalamnya, dan menggunakan ARIA untuk mengatakan bahwa itu adalah penggeser dengan nilai 30 dari 100. ARIA tidak menjadikan div sebagai penggeser; ARIA hanya memberi tahu pembaca layar untuk mengatakan bahwa div adalah penggeser.

ARIA tidak memengaruhi tampilan halaman web, atau perilaku untuk pengguna mouse atau keyboard. Hanya pengguna teknologi pendukung yang merasakan dampak ARIA. Developer web dapat menambahkan ARIA arbitrer tanpa memengaruhi pengguna yang tidak menjalankan teknologi pendukung.

Anda membacanya dengan benar: ARIA sebenarnya tidak melakukan apa pun pada fokus keyboard atau urutan tab. Semuanya dilakukan dalam HTML, terkadang diubah dengan sedikit JavaScript.

Bagaimana cara kerja ARIA?

Browser diminta oleh pembaca layar atau teknologi pendukung lainnya untuk mengetahui informasi tentang setiap elemen. Jika ARIA ada di elemen, browser akan mengambil informasi dan mengubah informasi yang diberikan kepada pembaca layar tentang elemen tersebut.

Berikut adalah beberapa penggunaan umum ARIA.

• Tambahkan komponen khusus yang tidak ada di HTML, seperti pelengkapan otomatis, struktur, atau spreadsheet.
• Menambahkan komponen yang ada di HTML, tetapi penulis memutuskan untuk membuatnya ulang, mungkin karena ingin mengubah perilaku atau tampilan elemen standar. Misalnya, elemen <input type="range"> HTML pada dasarnya adalah penggeser, tetapi penulis ingin membuatnya terlihat berbeda.
  • Umumnya, hal ini dapat diatasi dengan CSS. Namun, untuk range, CSS adalah awkwARD. Penulis dapat membuat penggeser sendiri dan menggunakan role="slider" dengan aria-valuenow untuk memberi tahu keyboard nilai saat ini.
• Sertakan area yang selalu berubah untuk memberi tahu pembaca layar tentang perubahan yang relevan pada area halaman.
• Buat penanda, seperti judul. Penanda membantu pengguna pembaca layar menemukan hal yang mereka inginkan dengan lebih cepat. Penanda dapat berisi seluruh area terkait. Misalnya, "penampung ini adalah area utama halaman" dan "penampung ini di sini adalah panel navigasi".

Mengapa ARIA?

Akan sangat berguna untuk menambahkan beberapa ARIA ke HTML yang sudah berfungsi. Misalnya, kita mungkin ingin kontrol formulir mengarah ke pemberitahuan pesan error untuk input yang tidak valid. Atau kita mungkin ingin menunjukkan penggunaan {i>input<i} teks secara spesifik. Penyesuaian ini dapat membuat situs biasa lebih mudah digunakan dengan pembaca layar.

Contoh panel menu

Misalkan toko web lokal tidak menjual semua widget yang kita perlukan. Namun, kita adalah MacGyver. Kita dapat membuat widget kita sendiri dari widget lain. Ini sangat mirip dengan penulis web yang perlu membuat bilah menu.

Meskipun elemen <nav> ada, panel menu sering kali disusun bersama menggunakan div, gambar, tombol, pengendali klik, tuas penekanan tombol, dan ARIA.

Mendukung pengguna mouse

Mari kita buat menu bar bersama. Kita menampilkan banyak item dalam elemen kotak generik yang disebut div. Setiap kali pengguna mengklik div, div akan mengeksekusi perintah yang sesuai. Keren, ini berfungsi untuk pengguna klik mouse.

Selanjutnya, kita membuatnya terlihat menarik. Kita menggunakan CSS untuk menyelaraskan elemen dengan baik dan menempatkan garis batas visual di sekelilingnya. Kami membuatnya terlihat cukup mirip dengan panel menu lain yang secara intuitif diketahui oleh pengguna dengan gangguan penglihatan bahwa ini adalah panel menu dan cara menggunakannya. Panel menu kami bahkan menggunakan warna latar belakang yang berbeda pada item apa pun yang diarahkan mouse, sehingga memberi pengguna beberapa masukan visual yang bermanfaat.

Beberapa item menu adalah induk. Submenu ini menghasilkan submenu turunan. Setiap kali pengguna mengarahkan kursor ke salah satu dari ini, kita akan memulai animasi yang menggeser submenu turunan.

Semua ini cukup sulit diakses, seperti biasanya untuk banyak hal di web.

Membuat keyboard panel menu dapat diakses

Mari tambahkan aksesibilitas {i>keyboard<i}. Ini hanya memerlukan perubahan HTML, bukan ARIA. Perlu diingat bahwa ARIA tidak memengaruhi aspek inti seperti tampilan, mouse, atau keyboard untuk pengguna tanpa teknologi pendukung.

Sama seperti halaman web yang dapat merespons mouse, halaman web juga dapat merespons keyboard. JavaScript kami dapat memproses semua penekanan tombol yang terjadi dan memutuskan apakah penekanan tombol tersebut berguna. Jika tidak, halaman akan menampilkannya kembali seperti ikan yang terlalu kecil untuk dimakan. Aturan yang berlaku antara lain:

• Jika pengguna menekan tombol panah, mari kita lihat blueprint panel menu internal kita sendiri dan tentukan item menu aktif yang baru. Kami akan menghapus sorotan saat ini dan menandai item menu baru sehingga pengguna yang dapat melihat secara visual mengetahui posisinya. Halaman web kemudian harus memanggil event.preventDefault() untuk mencegah browser melakukan tindakan biasa (men-scroll halaman, dalam hal ini).
• 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 hal lain, kirimkan kembali ke halaman. Misalnya, panel menu kita tidak memerlukan tombol Tab, jadi kembalikan tombol tersebut. Hal ini sulit dilakukan dengan benar. Misalnya, panel menu memerlukan tombol panah, tetapi tidak memerlukan Alt+Panah atau Command+Panah. Ini adalah pintasan untuk berpindah ke halaman sebelumnya dan berikutnya dalam histori web tab browser Anda. Jika penulis tidak berhati-hati, panel menu akan memakannya. Jenis bug ini sering terjadi, dan kita bahkan belum memulai ARIA.

Akses pembaca layar ke menu bar kami

Panel menu kami dibuat dengan lakban dan div. Akibatnya, pembaca layar tidak tahu apa saja warnanya. Warna latar belakang untuk item aktif hanyalah warna. Div item menu hanyalah objek biasa tanpa makna tertentu. Akibatnya, pengguna panel menu kami tidak mendapatkan petunjuk tentang tombol yang harus ditekan atau item yang sedang mereka buka.

Tapi itu tidak adil. Menu bar berfungsi dengan baik untuk pengguna yang dapat melihat.

ARIA dapat membantu. ARIA memungkinkan kita berpura-pura kepada pembaca layar bahwa fokus berada di menu bar. Jika penulis melakukan semuanya dengan benar, panel menu kustom kita akan terlihat oleh pembaca layar seperti panel menu di aplikasi desktop.

Kebohongan ARIA pertama kami adalah atribut aria-activedescendant. Tetapkan atribut ke ID item menu yang aktif, dengan berhati-hati memperbaruinya setiap kali berubah. Misalnya, aria-activedescendant="settings-menuitem". Hal ini menyebabkan pembaca layar mempertimbangkan item aktif ARIA sebagai fokus, yang dibacakan dengan lantang atau ditampilkan di penampil Braille.

Dengan menggunakan aria-activedescendant untuk menunjuk dari panel menu yang difokuskan ke item menu tertentu, pembaca layar kini mengetahui ke mana pengguna telah berpindah, tetapi tidak ada hal lain tentang objek tersebut. Apa hal div ini? Di sinilah atribut peran berperan. Kita menggunakan role="menubar" pada elemen penampung untuk keseluruhannya, lalu kita menggunakan role="menu" pada grup item, dan role="menuitem" pada … drumroll … setiap item menu.

Bagaimana jika item menu dapat mengarah ke menu turunan? Pengguna perlu mengetahui hal itu. Untuk pengguna yang dapat melihat, mungkin ada gambar segitiga kecil di akhir menu, tetapi pembaca layar tidak tahu cara membaca gambar secara otomatis, setidaknya pada tahap ini. Kita dapat menambahkan aria-expanded="false" di setiap item menu yang dapat diluaskan untuk menunjukkan bahwa ada sesuatu yang dapat diluaskan, dan tidak diluaskan. Selain itu, penulis harus menempatkan role="none" pada segitiga img untuk menunjukkan bahwa aplikasi tersebut hanya untuk tujuan kecantikan. Hal ini mencegah pembaca layar mengucapkan apa pun tentang gambar yang akan berlebihan.

Memperbaiki bug keyboard

Meskipun akses keyboard adalah bagian dari HTML inti, akses ini mudah ditimpa. Contoh:

• Kotak centang menggunakan spasi untuk beralih, tetapi penulis lupa memanggil preventDefault(). Sekarang, tombol spasi akan mengalihkan kotak centang dan memindahkan halaman ke bawah, yang merupakan perilaku browser default untuk tombol spasi.
• Dialog modal ARIA ingin menjebak navigasi tab di dalamnya. Jika penulis lupa untuk mengizinkan Control+Tab secara khusus untuk membuka tab baru saat berada dalam dialog, tombol tersebut tidak akan berfungsi seperti yang diharapkan.
• Penulis membuat daftar pilihan dan menerapkan tombol atas dan bawah. Namun, penulis masih perlu menambahkan navigasi awal, akhir, pageup, pagedown, atau huruf pertama.

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

Untuk masalah akses keyboard murni, sebaiknya coba juga tanpa pembaca layar, atau dengan menonaktifkan mode browser virtual. Anda dapat menemukan bug keyboard tanpa pembaca layar, karena akses keyboard diterapkan dengan HTML, bukan ARIA. Bagaimanapun, ARIA tidak memengaruhi perilaku keyboard atau mouse; melainkan, terletak pada pembaca layar tentang apa yang ada di halaman web, apa yang saat ini difokuskan, dan sebagainya.

Bug keyboard hampir selalu merupakan bug dalam konten web, khususnya dalam HTML dan JavaScript, bukan di ARIA.

Mengapa ada begitu banyak?

Ada banyak cara penulis dapat salah menggunakan ARIA. Setiap kesalahan akan menyebabkan kerusakan total atau perbedaan kecil. Masalah kecil tersebut mungkin lebih buruk, karena penulisnya kemungkinan tidak mengetahui mereka sebelum memublikasikannya.

Lagi pula, kecuali jika penulis adalah pengguna pembaca layar yang berpengalaman, akan ada masalah dalam ARIA. Dalam contoh menu bar, penulis dapat berpikir bahwa peran "option" akan digunakan jika "menuitem" benar. Mereka bisa lupa menggunakan aria-expanded, lupa menyetel dan menghapus aria-activedescendant pada waktu yang tepat, atau lupa memiliki panel menu yang berisi menu lain. Bagaimana dengan jumlah item menu? Biasanya, item menu ditampilkan oleh pembaca layar dengan sesuatu seperti "item 3 dari 5" sehingga pengguna tahu posisinya. Biasanya hal ini dihitung secara otomatis oleh browser, tetapi dalam beberapa kasus, dan dalam beberapa browser - kombinasi pembaca layar, angka yang salah mungkin akan 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. Lihat spesifikasi ARIA atau praktik penulisan jika Anda mau. Untuk setiap pola, ada banyak cara penyalahgunaan ARIA. ARIA mengandalkan penulis untuk mengetahui apa yang mereka lakukan. Apa yang mungkin salah, mengingat sebagian besar penulis bukan pengguna pembaca layar?

Dengan kata lain, pengguna pembaca layar yang sebenarnya harus mencoba widget ARIA 100 persen sebelum dianggap dapat dikirim. Nuansanya terlalu banyak. Idealnya, semuanya akan dicoba dengan beberapa kombinasi pembaca layar browser yang berbeda, karena banyaknya keanehan implementasi, selain beberapa implementasi yang tidak lengkap.

Ringkasan

ARIA dapat digunakan untuk mengganti atau menambahkan apa pun dan segala sesuatu yang dikatakan HTML. Hal ini dapat membuat perubahan kecil pada presentasi aksesibilitas atau membuat seluruh pengalaman. Karena alasan ini, ARIA sangat canggih, tetapi berbahaya di tangan developer kami yang bukan pengguna pembaca layar.

ARIA adalah lapisan markup yang menggantikan pilihan lain. Saat pembaca layar menanyakan apa yang terjadi, jika ARIA ada, pengguna akan mendapatkan versi kebenaran ARIA.

Referensi lainnya

Praktik Penulisan ARIA W3C mendokumentasikan karakteristik navigasi keyboard yang penting dari setiap contoh dan menyediakan JavaScript, CSS, dan ARIA yang berfungsi. Contoh ini berfokus pada hal-hal yang berfungsi saat ini, dan tidak mencakup perangkat seluler.

Apa yang dimaksud dengan Accessibility API?

API aksesibilitas adalah cara pembaca layar atau teknologi pendukung lainnya mengetahui apa yang ada di halaman dan apa yang terjadi. Contohnya mencakup MSAA, IA2, dan UIA. Ada dua bagian untuk aksesibilitas API:

• "Pohon" objek yang mewakili hierarki container. Misalnya, dokumen dapat berisi banyak paragraf. Paragraf dapat berisi teks, gambar, link, dan dekorasi teks. Setiap item dalam hierarki objek dapat memiliki properti, seperti peran (apa nama saya?), nama atau label, nilai yang dimasukkan pengguna, deskripsi, dan status boolean, seperti dapat difokuskan, difokuskan, diperlukan, dicentang. ARIA dapat mengganti salah satu properti ini.
  • Pembaca layar menggunakan hierarki untuk membantu pengguna menavigasi dalam mode buffer virtual, seperti, "harap buka judul berikutnya".
• Serangkaian peristiwa yang terjadi yang menjelaskan perubahan pada hierarki, seperti "fokus sekarang di sini". Pembaca layar menggunakan peristiwa untuk memberi tahu pengguna apa yang baru saja terjadi. Saat markup HTML atau ARIA penting berubah, peristiwa akan diaktifkan untuk memberi tahu pembaca layar bahwa ada sesuatu yang berubah.

HTML dipetakan dengan baik ke API aksesibilitas ini. Jika HTML tidak cukup, ARIA dapat ditambahkan sehingga browser mengganti semantik HTML sebelum mengirim hierarki objek atau peristiwa ke pembaca layar.