Sebagian besar developer sudah terbiasa dengan bahasa markup standar dari web modern kami, HyperText Markup Language (HTML). Namun, Anda mungkin kurang familier dengan Accessible Rich Internet Applications (ARIA) (sebelumnya disebut WAI-ARIA): apa itu WAI-ARIA, apa itu API, cara menggunakannya, serta kapan—dan tidak—menggunakannya.
HTML dan ARIA memainkan peran penting dalam membuat produk digital mudah diakses, terutama dalam hal teknologi pendukung (AT) seperti pembaca layar. Keduanya digunakan untuk mengonversi konten ke dalam format alternatif, seperti Braille atau Text-to-Speech (TTS).
Mari kita tinjau sejarah singkat ARIA, alasan pentingnya ARIA, serta waktu dan cara terbaik untuk menggunakannya.
Pengantar ARIA
ARIA pertama kali dikembangkan pada tahun 2008 oleh grup Web Accessibility Initiative (WAI)—sebuah bagian dari World Wide Web Consortium (W3C) menyeluruh yang mengatur dan mengatur internet.
ARIA bukanlah bahasa pemrograman yang sesungguhnya, melainkan sekumpulan atribut yang dapat Anda tambahkan ke elemen HTML untuk meningkatkan aksesibilitasnya. Atribut ini mengomunikasikan peran, status, dan properti kepada teknologi pendukung melalui API aksesibilitas yang ditemukan di browser modern. Komunikasi ini terjadi melalui pohon aksesibilitas.
"WAI-ARIA, Accessible Rich Internet Applications Suite, mendefinisikan cara untuk membuat konten web dan aplikasi web lebih mudah diakses oleh difabel. Hal ini terutama membantu konten dinamis dan kontrol antarmuka pengguna canggih yang dikembangkan dengan HTML, JavaScript, dan teknologi terkait."
Grup WAI
Hierarki aksesibilitas
ARIA mengubah kode yang salah atau tidak lengkap untuk membuat pengalaman yang lebih baik bagi pengguna yang menggunakan AT dengan mengubah, mengekspos, dan menambahkan bagian pohon aksesibilitas.
Hierarki aksesibilitas dibuat oleh browser dan didasarkan pada hierarki Document Object Model (DOM) standar. Seperti hierarki DOM, hierarki aksesibilitas berisi objek yang mewakili semua elemen markup, atribut, dan node teks. Hierarki aksesibilitas juga digunakan oleh API aksesibilitas khusus platform untuk memberikan representasi yang dapat dipahami oleh teknologi pendukung.
ARIA sendiri tidak mengubah fungsionalitas atau tampilan visual elemen. Artinya, hanya pengguna AT yang akan melihat perbedaan antara produk digital dengan ARIA dan tanpanya. Ini juga berarti bahwa developer saja yang bertanggung jawab untuk membuat perubahan gaya dan kode yang sesuai untuk membuat elemen dapat diakses semudah mungkin.
Tiga fitur utama ARIA adalah peran, properti, dan status/nilai.
Peran menentukan fungsi elemen di halaman atau aplikasi.
<div role="button">Self-destruct</div>
Properti menyatakan karakteristik atau hubungan dengan objek.
<div role="button" aria-describedby="more-info">Self-destruct</div>
<div id="more-info">This page will self-destruct in 10 seconds.</div>
Status/nilai menentukan kondisi saat ini atau nilai data yang terkait dengan elemen.
<div role="button" aria-describedby="more-info" aria-pressed="false">
Self-destruct
</div>
<div id="more-info">
This page will self-destruct in 10 seconds.
</div>
Meskipun ketiga elemen ARIA dapat digunakan dalam satu baris kode, tetapi tidak diperlukan. Sebagai gantinya, buat lapisan peran, properti, dan status/nilai ARIA hingga Anda mencapai sasaran aksesibilitas akhir. Memasukkan ARIA dengan benar ke dalam code base akan memastikan pengguna AT akan memiliki semua informasi yang mereka butuhkan untuk menggunakan situs, aplikasi, atau produk digital Anda lainnya dengan sukses dan setara.
Baru-baru ini, Chrome DevTools telah menciptakan cara untuk melihat hierarki aksesibilitas lengkap yang memudahkan developer memahami pengaruh kode mereka terhadap aksesibilitas.
Kapan menggunakan ARIA
Pada tahun 2014, W3C secara resmi menerbitkan rekomendasi HTML5. Bersamaan dengan itu,
ada beberapa perubahan besar, termasuk penambahan elemen bangunan terkenal seperti <main>
,
<header>
, <footer>
, <aside>
, <nav>
, serta atribut seperti hidden
dan
required
. Dengan elemen dan atribut HTML5 baru tersebut, ditambah dengan
peningkatan dukungan browser, bagian tertentu dari ARIA kini menjadi tidak terlalu penting.
Jika browser mendukung tag HTML dengan peran implisit dengan ARIA yang setara, biasanya tidak perlu menambahkan ARIA ke elemen. Namun, ARIA masih menyertakan banyak peran, status, dan properti yang tidak tersedia dalam versi HTML apa pun. Atribut tersebut tetap berguna untuk saat ini.
Hal ini mengantarkan kita pada pertanyaan utama: Kapan sebaiknya Anda menggunakan ARIA? Untungnya, grup WAI telah mengembangkan lima aturan ARIA untuk membantu Anda memutuskan cara membuat elemen dapat diakses.
Aturan 1: Jangan gunakan ARIA
Ya, Anda tidak salah baca. Menambahkan ARIA ke sebuah elemen tidak membuatnya lebih mudah diakses. Laporan aksesibilitas tahunan WebAIM Million menemukan bahwa halaman beranda dengan ARIA menampilkan rata-rata 70% lebih banyak error yang terdeteksi daripada halaman tanpa ARIA, terutama karena penerapan atribut ARIA yang tidak tepat.
Ada pengecualian untuk aturan ini. ARIA diperlukan bila elemen HTML tidak memiliki dukungan aksesibilitas. Hal ini mungkin karena desain tidak memungkinkan elemen HTML tertentu atau fitur/perilaku yang diinginkan tidak tersedia dalam HTML. Namun, situasi ini jarang terjadi.
<a role="button">Submit</a>
<button>Submit</button>
Jika ragu, gunakan elemen HTML semantik.
Aturan 2: Jangan tambahkan ARIA (tidak perlu) ke HTML
Pada umumnya, elemen HTML berfungsi dengan baik dan tidak memerlukan ARIA tambahan yang ditambahkan padanya. Faktanya, pengembang yang menggunakan ARIA sering kali harus menambahkan kode tambahan untuk membuat elemen itu berfungsi pada elemen interaktif.
<h2 role="tab">Heading tab</h2>
<div role="tab"><h2>Heading tab</h2></div>
Lakukan lebih sedikit pekerjaan dan dapatkan kode yang berperforma lebih baik saat Anda menggunakan elemen HTML seperti yang diinginkan.
Aturan 3: Selalu dukung navigasi keyboard
Semua kontrol ARIA interaktif (tidak dinonaktifkan) harus dapat diakses dari keyboard. Anda dapat menambahkan tabindex= "0" ke elemen apa pun yang memerlukan fokus yang biasanya tidak menerima fokus keyboard. Jika memungkinkan, hindari menggunakan indeks tab dengan bilangan bulat positif untuk mencegah potensi masalah urutan fokus keyboard.
<span role="button" tabindex="1">Submit</span>
<span role="button" tabindex="0">Submit</span>
Aturan 4: Jangan sembunyikan elemen yang dapat difokuskan
Jangan tambahkan role= "presentation"
atau aria-hidden= "true"
ke elemen yang perlu
memiliki fokus—termasuk elemen dengan tabindex= "0"
. Saat Anda menambahkan
peran/status ini ke elemen, elemen tersebut akan mengirim pesan ke AT bahwa
elemen ini tidak penting dan akan dilewati. Hal ini dapat menyebabkan kebingungan atau mengganggu
pengguna yang mencoba berinteraksi dengan suatu elemen.
<div aria-hidden="true"><button>Submit</button></div>
<div><button>Submit</button></div>
Aturan 5: Gunakan nama yang dapat diakses untuk elemen interaktif
Tujuan elemen interaktif perlu disampaikan kepada pengguna sebelum mereka tahu cara berinteraksi dengannya. Pastikan semua elemen memiliki nama yang dapat diakses oleh orang yang menggunakan perangkat AT.
Nama yang dapat diakses dapat berupa konten yang dikelilingi oleh elemen (dalam kasus
<a>
), teks alternatif, atau label.
Untuk setiap contoh kode berikut, nama yang dapat diakses adalah "Sepatu kulit merah".
<!-- A plain link with text between the link tags. -->
<a href="shoes.html">Red leather boots</a>
<!-- A linked image, where the image has alt text. -->
<a href="shoes.html"><img src="shoes.png" alt="Red leather boots"></a>
<!-- A checkbox input with a label. -->
<input type="checkbox" id="shoes">
<label for="shoes">Red leather boots</label>
Ada banyak cara untuk memeriksa nama yang dapat diakses elemen, termasuk memeriksa hierarki aksesibilitas menggunakan Chrome DevTools atau mengujinya dengan pembaca layar.
ARIA dalam HTML
Meskipun menggunakan elemen HTML sendiri adalah praktik terbaik, elemen ARIA dapat ditambahkan dalam situasi tertentu. Misalnya, Anda dapat memasangkan ARIA dengan HTML dalam pola yang memerlukan tingkat dukungan AT yang lebih tinggi karena kendala lingkungan, atau sebagai metode fallback untuk elemen HTML yang tidak sepenuhnya didukung oleh semua browser.
Tentu saja, ada rekomendasi untuk menerapkan ARIA di HTML. Yang terpenting: jangan mengganti peran HTML default, mengurangi redundansi, dan waspada terhadap efek samping yang tidak diinginkan.
Mari kita lihat beberapa contohnya.
<a role="heading">Read more</a>
<a aria-label="Read more about some awesome article title">Read More</a>
<ul role="list">...</ul>
<ul>...</ul>
<details> <summary role="button">more information</summary> ... </details>
<details> <summary>more information</summary> ... </details>
Kompleksitas ARIA
ARIA itu rumit, dan Anda harus selalu berhati-hati saat menggunakannya. Meskipun contoh kode dalam pelajaran ini cukup mudah, membuat pola kustom yang mudah diakses dapat menjadi rumit dengan cepat.
Ada banyak hal yang perlu diperhatikan, termasuk, tetapi tidak terbatas pada: interaksi keyboard, antarmuka sentuh, dukungan AT/browser, kebutuhan terjemahan, batasan lingkungan, kode lama, dan preferensi pengguna. Sedikit pengetahuan coding dapat merugikan—atau hanya menjengkelkan—jika digunakan dengan tidak benar. Ingatlah untuk membuat kode Anda tetap sederhana.
Kesampingkan peringatan tersebut, aksesibilitas digital bukanlah situasi yang sama sekali atau tidak sama sekali—ini adalah spektrum yang memungkinkan beberapa area abu-abu seperti ini. Beberapa solusi coding dapat dianggap "benar", tergantung situasinya. Yang penting Anda terus belajar, menguji, dan mencoba membuat dunia digital kita lebih terbuka bagi semua orang.
Menguji pemahaman Anda
Uji pengetahuan Anda tentang ARIA dan HTML
Manakah dari pilihan berikut yang merupakan praktik terbaik untuk membuat tombol yang mudah diakses?
<div id="saveChanges" aria-role="button" aria-pressed="false" tabindex="0">Go to shop</div>
<a id="saveChanges" aria-label="Some awesome article title">Go to shop</a>
<button id="saveChanges" type="button">Go to shop</button>