HTML Aksesibilitas Dasar: Atribut alt, aria-label, aria-hidden, role, dan tabindex
Daftar Isi
Aksesibilitas HTML berarti membuat antarmuka yang dapat dipahami dan dioperasikan oleh lebih banyak pengguna, termasuk orang yang menggunakan pembaca layar, keyboard, pembesaran layar, pengendali suara, atau teknologi bantu lainnya. Setelah memahami HTML semantik dan navigasi, tahap berikutnya bukan menambahkan ARIA sebanyak mungkin, melainkan memahami kapan HTML asli sudah cukup dan kapan metadata aksesibilitas tambahan memang diperlukan. Lima atribut yang sering ditemui adalah alt, aria-label, aria-hidden, role, dan tabindex. Kelimanya memengaruhi aspek berbeda: alternatif teks untuk gambar, nama aksesibel, keterpaparan terhadap teknologi bantu, semantik elemen, dan perilaku fokus keyboard. Kesalahan paling umum terjadi ketika atribut-atribut tersebut dianggap sebagai alat dekoratif yang dapat dipasang secara seragam pada semua elemen. Sebaliknya, nilai atribut dapat mengubah informasi yang diterima pengguna pembaca layar atau urutan interaksi keyboard. Tutorial ini memakai HTML standar tanpa framework, JavaScript, library, maupun dependency eksternal. Contoh dapat disimpan sebagai index.html dan dibuka pada browser modern. Untuk pengujian yang lebih representatif, gunakan pula keyboard dan, bila tersedia, pembaca layar pada kombinasi browser dan sistem operasi yang memang didukung oleh proyek Anda.
Prinsip yang akan digunakan sepanjang tutorial adalah mengutamakan elemen HTML native. Tombol tindakan menggunakan <button>, tautan menggunakan <a href="...">, dan gambar informatif mendapat teks alternatif yang tepat. HTML native biasanya menyediakan semantik, perilaku fokus, serta interaksi keyboard tanpa perlu direkonstruksi dengan ARIA. aria-label digunakan ketika kontrol benar-benar membutuhkan nama aksesibel yang tidak tersedia sebagai teks yang sesuai; aria-hidden="true" digunakan untuk menyembunyikan konten redundan atau dekoratif dari accessibility tree, bukan untuk menyembunyikan kontrol aktif; role dipakai dengan hati-hati karena HTML sering sudah memiliki role implisit; sedangkan tabindex terutama berguna untuk mengatur apakah elemen dapat menerima fokus secara programatis atau masuk urutan Tab. Karena hasil pembaca layar dapat berbeda menurut browser, sistem operasi, dan teknologi bantu, tutorial ini tidak mengandalkan kalimat persis yang akan diucapkan. Target verifikasi adalah struktur, nama, role, status fokus, dan kemampuan operasi yang tepat.
Landasan Sains dan Prinsip Kerja Metode
Browser mem-parsing HTML menjadi DOM dan, bersama informasi dari CSS serta subsistem platform, menyediakan informasi aksesibilitas yang dapat dipakai teknologi bantu melalui API aksesibilitas sistem operasi. Representasi yang biasa disebut accessibility tree berisi informasi seperti role, nama, state, dan relasi yang relevan. HTML semantik memberikan banyak informasi tersebut secara native: <button> memiliki semantik tombol, <nav> merepresentasikan landmark navigasi, dan sebuah tautan dengan href merupakan kontrol yang dapat difokuskan secara normal. ARIA dapat menambahkan atau memodifikasi semantik aksesibilitas, tetapi tidak otomatis menambahkan perilaku. Misalnya, menaruh role="button" pada <div> tidak dengan sendirinya menjadikannya setara dengan tombol HTML: developer masih bertanggung jawab terhadap fokus dan interaksi keyboard yang tepat. Inilah alasan aturan praktis “gunakan HTML native terlebih dahulu” sangat penting. Atribut ARIA bukan pengganti semantik HTML atau implementasi interaksi. Pada contoh dasar, kita bahkan tidak memerlukan role eksplisit pada tombol karena role native-nya sudah benar.
Accessible name atau nama aksesibel adalah nama yang digunakan teknologi bantu untuk mengidentifikasi suatu elemen. Sumber nama bergantung pada elemen dan aturan Accessible Name and Description Computation. Untuk gambar <img>, alt mempunyai peran khusus sebagai teks alternatif. Gambar informatif memerlukan alt yang menyampaikan tujuan atau informasi relevan dalam konteks, sedangkan gambar yang benar-benar dekoratif umumnya menggunakan alt="". Untuk kontrol tertentu, teks terlihat atau elemen label biasanya lebih baik daripada nama yang hanya tersedia bagi pembaca layar. aria-label dapat memberikan nama aksesibel berupa string ketika pendekatan semantik yang sesuai tidak menyediakan nama yang dibutuhkan. Penting untuk mengetahui bahwa aria-label dapat menentukan atau mengganti nama aksesibel menurut algoritme penamaan; karena itu jangan menambahkannya tanpa alasan pada elemen yang sudah bernama jelas. Teks yang terlihat juga bermanfaat bagi pengguna dengan gangguan kognitif serta pengguna input suara, sehingga nama tersembunyi tidak semestinya menjadi pengganti universal bagi label visual.
Fokus keyboard adalah konsep terpisah dari accessibility tree. Elemen interaktif native seperti tombol dan tautan ber-href secara normal masuk urutan fokus berurutan. tabindex="0" memasukkan elemen ke urutan fokus berdasarkan urutan dokumen, sementara tabindex="-1" membuat elemen tidak berada dalam navigasi Tab berurutan tetapi tetap dapat difokuskan melalui skrip atau mekanisme lain yang sesuai. Nilai positif seperti tabindex="1" memang valid secara sintaksis, tetapi umumnya harus dihindari karena menciptakan urutan fokus yang terpisah dari urutan dokumen dan mudah menghasilkan pengalaman navigasi membingungkan. Sementara itu, aria-hidden="true" dimaksudkan untuk menghilangkan elemen dan turunannya dari accessibility tree; atribut ini tidak menyembunyikan elemen secara visual dan tidak mencegah fokus keyboard. Karena itu, menerapkannya pada elemen yang dapat difokuskan, atau leluhur yang berisi kontrol fokus, dapat menyebabkan situasi ketika fokus mencapai sesuatu yang tidak terekspos dengan benar kepada teknologi bantu. Aksesibilitas yang baik membutuhkan keselarasan antara struktur DOM, visual, semantik aksesibilitas, dan urutan fokus.
Formula, Komposisi Bahan, atau Spesifikasi Parameter
Tidak ada “formula” numerik untuk aksesibilitas HTML. Parameter yang tepat adalah pemetaan antara kebutuhan antarmuka dan semantik yang diberikan browser. Tabel berikut merangkum sepuluh keputusan teknis yang dapat dipakai sebelum menulis atribut. Perhatikan perbedaan antara atribut HTML seperti alt dan tabindex serta atribut ARIA seperti aria-label dan aria-hidden. role juga merupakan bagian dari mekanisme ARIA ketika digunakan untuk menetapkan semantik eksplisit. Nilai terbaik bukan atribut terbanyak, tetapi representasi yang paling sederhana dan sesuai elemen.
| Komponen | Spesifikasi/Rasio | Fungsi Teknis |
|---|---|---|
| Gambar informatif | alt berisi alternatif teks yang relevan | Menyediakan alternatif tekstual untuk informasi atau fungsi gambar |
| Gambar dekoratif | alt="" | Menandai gambar agar tidak memerlukan alternatif verbal yang bermakna |
| Tombol berteks | Elemen button dengan teks terlihat | Menyediakan role, fokus, nama, dan perilaku keyboard native |
| Tombol ikon tanpa teks | aria-label dengan nama ringkas dan bermakna | Memberikan nama aksesibel ketika ikon tidak menyediakan nama yang memadai |
| Ikon dekoratif | aria-hidden="true" bila diperlukan | Menghindari informasi dekoratif atau redundan terekspos ke teknologi bantu |
| Semantik native | Tanpa role redundan | Mempertahankan semantik bawaan elemen HTML yang sesuai |
| Role eksplisit | Gunakan hanya ketika kebutuhan semantik membenarkannya | Mengomunikasikan peran elemen kepada teknologi bantu |
| Fokus normal | Elemen interaktif native; tabindex tambahan biasanya tidak perlu | Mempertahankan urutan fokus alami berdasarkan dokumen |
| Fokus programatis | tabindex="-1" | Memungkinkan fokus programatis tanpa memasukkan elemen ke urutan Tab biasa |
| Elemen khusus dalam urutan fokus | tabindex="0", hanya jika pola interaksi memang memerlukan | Memasukkan elemen ke urutan fokus alami tanpa prioritas positif |
aria-hidden="true" pada elemen yang dapat menerima fokus atau pada leluhur yang berisi kontrol fokus. Jangan pula memakai role dan tabindex untuk mengubah <div> menjadi tombol jika <button> dapat digunakan. ARIA dapat memengaruhi semantik yang terekspos, tetapi tidak otomatis menciptakan perilaku keyboard atau event activation yang dimiliki kontrol HTML native.Panduan Langkah Kerja Bertahap
Buat Dokumen Dasar dan Pertahankan Semantik Native
Mulai dengan satu file index.html. Contoh pertama sengaja menggunakan tombol dan tautan native untuk membangun baseline sebelum ARIA ditambahkan. Tidak ada instalasi package atau web server yang diperlukan untuk fitur yang dipelajari di sini; file lokal dapat dibuka langsung pada browser modern. Tombol memiliki teks “Simpan perubahan”, sehingga nama terlihat dan semantik tombol sudah tersedia dari elemen HTML. Tautan memiliki href="#detail", sehingga merupakan tautan nyata dan dapat membawa fokus navigasi ke bagian dokumen yang dituju menurut perilaku browser. Judul h2 dengan ID yang cocok menyediakan target fragmen. Ini penting karena aksesibilitas dimulai dari pemilihan elemen, bukan dari atribut ARIA tambahan.
<!doctype html>
<html lang="id">
<head>
<meta charset="utf-8">
<title>Latihan Aksesibilitas HTML</title>
</head>
<body>
<main>
<h1>Pengaturan Profil</h1>
<button type="button">Simpan perubahan</button>
<a href="#detail">Baca detail profil</a>
<h2 id="detail">Detail profil</h2>
<p>Informasi detail akun tersedia di bagian ini.</p>
</main>
</body>
</html>Simpan file lalu buka di browser. Tekan Tab berulang kali dari awal halaman. Hasil yang diharapkan adalah kontrol interaktif dapat menerima fokus menggunakan mekanisme native; Anda tidak perlu menambahkan tabindex="0" pada tombol atau tautan tersebut. Aktifkan tombol dengan keyboard untuk memastikan ia memiliki perilaku tombol native, walaupun contoh belum memasang aksi aplikasi sehingga tidak terjadi perubahan data. Aktifkan tautan dan periksa bahwa URL memperoleh fragmen #detail serta bagian target dinavigasi. Anda juga dapat membuka panel Accessibility pada DevTools yang tersedia di browser untuk menginspeksi role dan nama elemen. Nama panel dan detail tampilannya berbeda menurut browser, jadi yang diverifikasi adalah konsepnya: tombol memiliki semantik tombol serta nama yang berasal dari teksnya. Baseline ini mencegah kebiasaan menambahkan role="button" dan tabindex pada elemen yang sudah menyediakannya secara native.
Terapkan alt Sesuai Fungsi Gambar
Selanjutnya tambahkan dua gambar ke dalam main pada index.html. Agar contoh dapat diuji tanpa membuat file gambar tambahan, kode memakai data URL SVG sebagai sumber gambar. Data URL tersebut hanya mekanisme demo; prinsip alt sama untuk JPEG, PNG, WebP, SVG melalui img, atau format gambar lain yang didukung browser. Gambar pertama diasumsikan menyampaikan informasi status profil sehingga mendapatkan teks alternatif ringkas. Gambar kedua hanya pemisah dekoratif, sehingga memakai alt="". Jangan menulis “gambar dari” secara otomatis di setiap alternatif teks; jelaskan informasi atau fungsi yang perlu diperoleh pengguna dalam konteks.
<p>
<img
src="data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='40' height='40'%3E%3Ccircle cx='20' cy='20' r='18' fill='green'/%3E%3C/svg%3E"
alt="Profil telah terverifikasi"
width="40"
height="40">
</p>
<p>
<img
src="data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='160' height='4'%3E%3Crect width='160' height='4' fill='gray'/%3E%3C/svg%3E"
alt=""
width="160"
height="4">
</p>Letakkan snippet tersebut setelah paragraf detail pada file yang sama, simpan, lalu muat ulang. Browser seharusnya menampilkan lingkaran hijau dan garis abu-abu. Verifikasi melalui inspector aksesibilitas browser bila tersedia: gambar informatif harus memiliki alternatif/nama yang mencerminkan “Profil telah terverifikasi”, sedangkan gambar dekoratif dengan alt="" tidak semestinya menyampaikan informasi bermakna sebagai gambar kepada teknologi bantu. Jika menggunakan pembaca layar, uji dengan konfigurasi normal Anda, tetapi jangan mengandalkan susunan ucapan persis karena implementasinya dapat berbeda. Periksa juga konteks: bila kalimat di sekitar gambar sudah menyampaikan informasi identik sehingga gambar benar-benar dekoratif, alternatif kosong mungkin justru lebih tepat. Dengan kata lain, kualitas alt ditentukan oleh fungsi gambar dalam konteks, bukan semata-mata oleh apa yang terlihat pada piksel.
Berikan Nama pada Tombol Ikon dengan aria-label
aria-label berguna ketika sebuah kontrol mempunyai fungsi yang jelas tetapi tidak memiliki teks terlihat yang dapat menjadi nama aksesibel. Tambahkan tombol ikon berikut ke main. Karakter × dipakai sebagai representasi visual sederhana, sedangkan nama “Tutup panel bantuan” diberikan melalui aria-label. Ikon juga diberi aria-hidden="true" karena ia tidak perlu menjadi sumber informasi terpisah setelah tombol mempunyai nama yang tepat. Tombol tetap menggunakan elemen button, sehingga kita tidak perlu menambahkan role="button" maupun tabindex="0".
<button type="button" aria-label="Tutup panel bantuan">
<span aria-hidden="true">×</span>
</button>Setelah menyimpan dan memuat ulang file, tekan Tab sampai tombol ikon menerima fokus. Hasil yang diharapkan adalah tombol tetap dapat difokuskan dan diaktifkan menggunakan mekanisme tombol native. Karena tidak ada JavaScript, aktivasi tidak benar-benar menutup panel; snippet ini hanya menguji semantik dan nama. Inspeksi accessibility properties tombol pada DevTools dan pastikan nama aksesibelnya berasal dari aria-label, sementara span dekoratif tidak menjadi informasi tambahan yang terpisah. Jika nanti desain memungkinkan teks “Tutup panel bantuan” tampil secara visual, pertimbangkan penggunaan teks tersebut sebagai konten tombol sehingga semua pengguna memperoleh label yang sama. Hindari menambahkan aria-label ke tombol berteks hanya untuk mengulang label yang sudah ada. Selain redundan, nama ARIA yang berbeda dari teks terlihat dapat menciptakan ketidakselarasan, terutama bagi pengguna perangkat lunak input suara yang mengacu pada label yang mereka lihat.
Gunakan aria-hidden Hanya untuk Informasi Redundan
aria-hidden="true" berguna untuk konten presentasional yang tidak seharusnya menjadi node bermakna bagi teknologi bantu. Contoh berikut membuat tautan unduhan dengan ikon panah sederhana. Teks “Unduh laporan” sudah mengomunikasikan fungsi kontrol; simbol panah hanya dekorasi, sehingga span yang memuatnya dapat disembunyikan dari accessibility tree. Atribut ini tidak menghilangkan panah secara visual. Perbedaan tersebut harus dipahami dengan jelas: CSS seperti display: none berkaitan dengan rendering, sedangkan aria-hidden mengatur keterpaparan ke API aksesibilitas dalam konteks ini. Jangan memindahkan aria-hidden="true" ke elemen <a>, karena tautan merupakan kontrol yang perlu ditemukan pengguna teknologi bantu.
<a href="laporan.pdf">
<span aria-hidden="true">↓ </span>Unduh laporan
</a>Tambahkan snippet ke main. Untuk latihan semantik, file laporan.pdf tidak harus dibuat selama tautan tidak diaktifkan; jika Anda ingin menguji navigasinya, sediakan file tersebut pada direktori yang sama. Setelah memuat ulang, panah dan teks harus tetap terlihat. Tekan Tab dan pastikan tautan masih menerima fokus. Di inspector aksesibilitas, periksa bahwa simbol dekoratif tidak menyumbang informasi yang tidak diperlukan pada nama tautan dan nama bermakna tetap berasal dari “Unduh laporan”. Pengujian ini juga menunjukkan mengapa aria-hidden tidak boleh dipakai sebagai teknik menonaktifkan kontrol. Ia tidak menghapus kontrol dari urutan Tab. Bila sebuah kontrol harus dinonaktifkan, gunakan mekanisme yang memang sesuai dengan elemen dan pola antarmukanya, misalnya atribut disabled pada tombol ketika kondisi aplikasinya menghendaki tombol dinonaktifkan. Pisahkan selalu keputusan visual, keputusan fokus, dan keputusan accessibility tree.
Pahami role Tanpa Menimpa Semantik yang Sudah Benar
Atribut role menjelaskan peran aksesibilitas suatu elemen, tetapi penggunaannya bukan target tersendiri. Untuk elemen HTML yang sudah mempunyai semantik sesuai kebutuhan, role eksplisit biasanya tidak diperlukan. Contoh berikut membandingkan landmark native dan region generik yang memang diberi nama. <nav> sudah membawa semantik navigasi, sehingga tidak perlu ditulis sebagai <nav role="navigation">. Sementara itu, role="region" pada div memberikan semantik region; aria-labelledby="status-title" menghubungkan nama region dengan heading yang terlihat. Contoh ini menunjukkan penggunaan role dengan alasan tertentu, bukan sekadar duplikasi semantik native.
<nav aria-label="Navigasi akun">
<a href="#detail">Detail profil</a>
</nav>
<div role="region" aria-labelledby="status-title">
<h2 id="status-title">Status akun</h2>
<p>Profil telah melalui pemeriksaan identitas.</p>
</div>Tambahkan kode ke main lalu muat ulang. Periksa accessibility tree: elemen nav seharusnya terekspos dengan semantik navigasi tanpa role eksplisit, sedangkan div memperoleh semantik region dan nama yang mengacu pada heading “Status akun”. Detail representasi DevTools dapat berbeda antarbrowser. Pastikan pula ID status-title unik dalam dokumen karena referensi aria-labelledby harus menunjuk elemen yang dimaksud. Contoh ini tidak berarti setiap kelompok konten perlu role="region"; terlalu banyak region dapat membuat struktur navigasi teknologi bantu menjadi bising. Gunakan elemen sectioning atau landmark HTML yang tepat ketika tersedia. Role eksplisit lebih relevan ketika semantik yang diperlukan tidak dapat dinyatakan melalui elemen native yang cocok. Yang terpenting, jangan menganggap role menambahkan perilaku. Apabila membuat widget ARIA kompleks, developer tetap harus mengikuti pola keyboard dan state yang sesuai; untuk materi dasar ini, elemen native adalah jalur yang lebih aman dan sederhana.
Kelola tabindex dan Audit Urutan Fokus
Langkah terakhir mendemonstrasikan dua nilai tabindex yang penting. Untuk elemen interaktif native, jangan tambahkan tabindex="0" tanpa kebutuhan karena elemen tersebut sudah berada dalam urutan fokus. tabindex="-1" berguna pada target yang perlu menerima fokus secara programatis, misalnya container pesan status setelah suatu operasi, walaupun pemindahan fokus melalui JavaScript tidak diimplementasikan dalam tutorial tanpa skrip ini. Sebaliknya, tabindex="0" membuat elemen yang secara native tidak sequentially focusable ikut dalam urutan Tab. Itu hanya masuk akal jika elemen tersebut memang memiliki alasan interaksi atau pola keyboard yang valid. Contoh berikut menyediakan area latihan fokus dan tetap memakai tombol native untuk aksi nyata.
<section aria-labelledby="focus-title">
<h2 id="focus-title">Latihan fokus</h2>
<div tabindex="0">
Area demonstrasi yang sengaja dapat menerima fokus.
</div>
<p id="save-status" tabindex="-1">
Status penyimpanan akan muncul di sini.
</p>
<button type="button">Simpan profil</button>
</section>Tambahkan snippet ke main, simpan, lalu muat ulang halaman. Tekan Tab dari awal dokumen dan catat urutan fokus. Area demonstrasi dengan tabindex="0" akan masuk ke navigasi fokus berurutan; paragraf dengan tabindex="-1" tidak semestinya menjadi pemberhentian Tab biasa; tombol tetap menjadi pemberhentian native. Uji juga Shift+Tab untuk memastikan urutan balik masuk akal. Jangan mengganti nilai dengan angka positif untuk “memperbaiki” urutan. Jika urutan fokus buruk, perbaiki urutan DOM agar sesuai dengan struktur visual dan logis. Pada aplikasi nyata, document.getElementById("save-status").focus() dapat digunakan dalam JavaScript ketika pemindahan fokus memang dibenarkan oleh desain interaksi, tetapi pemindahan fokus otomatis perlu dilakukan secara hati-hati agar tidak mengejutkan pengguna. Untuk tutorial ini, inspeksi dengan Tab sudah cukup untuk memverifikasi efek atribut. Setelah memahami efeknya, hapus tabindex="0" dari elemen noninteraktif bila proyek nyata tidak mempunyai alasan aksesibilitas untuk membuatnya fokus.
Verifikasi Akhir dan Parameter Kelayakan
Audit akhir sebaiknya tidak terbatas pada melihat bahwa halaman “tampak benar”. Gunakan keyboard terlebih dahulu, kemudian inspector aksesibilitas browser dan pembaca layar bila tersedia dalam matriks pengujian proyek. Verifikasi nama kontrol, role, urutan fokus, alternatif gambar, dan keberadaan konten dekoratif dalam accessibility tree. Pengujian otomatis dapat membantu menemukan sebagian masalah, tetapi tidak dapat menentukan seluruh kualitas alt, kecocokan nama terhadap konteks, atau kewajaran urutan interaksi. Lima parameter berikut dapat dipakai sebagai target praktis setelah contoh direfaktor sesuai prinsip tutorial.
| Parameter | Sebelum Menerapkan Metode | Sesudah Menerapkan Metode (Target) |
|---|---|---|
| Nama kontrol | Kontrol ikon dapat tidak memiliki nama yang bermakna | Setiap kontrol memiliki nama aksesibel yang sesuai fungsi dan dapat diperiksa |
| Alternatif gambar | Gambar informatif atau dekoratif diperlakukan sama | Gambar informatif memiliki alt kontekstual dan gambar dekoratif memakai alt kosong |
| Semantik role | Role dapat ditambahkan secara redundan atau tanpa perilaku sesuai | Semantik native diprioritaskan dan role eksplisit hanya digunakan dengan alasan jelas |
| Urutan fokus | tabindex positif atau fokus tambahan dapat mengacaukan navigasi | Tab dan Shift+Tab mengikuti urutan dokumen yang logis tanpa tabindex positif |
| Konten tersembunyi dari AT | aria-hidden dapat mengenai kontrol fokus | aria-hidden hanya mengenai konten yang aman diabaikan dan tidak menyembunyikan kontrol fokus |
Solusi Masalah di Lapangan (FAQ Teknis)
1. Mengapa pembaca layar masih menyebut nama tombol walaupun ikon di dalamnya memakai aria-hidden?
Karena aria-hidden="true" pada ikon hanya menyembunyikan ikon tersebut dari accessibility tree; atribut itu tidak menghapus nama yang berasal dari elemen tombol. Jika tombol memiliki aria-label="Tutup panel bantuan", tombol tetap memiliki nama aksesibel tersebut. Ini justru hasil yang diinginkan: ikon dekoratif tidak menambah informasi, sedangkan kontrol tetap dapat dikenali. Jika hasil berbeda dari harapan, inspeksi elemen yang tepat dan periksa apakah aria-hidden secara keliru ditempatkan pada tombol atau leluhur tombol. Jangan menilai keberhasilan hanya dari ucapan yang persis sama pada semua pembaca layar karena kombinasi browser dan teknologi bantu dapat mempresentasikan informasi dengan cara berbeda. Verifikasikan role, accessible name, dan kemampuan fokus secara terpisah.
2. Apakah semua tombol ikon harus menggunakan aria-label?
Tidak. Kebutuhannya adalah memastikan kontrol mempunyai nama aksesibel yang benar, bukan memastikan atribut tertentu selalu hadir. Jika nama sudah diperoleh melalui mekanisme lain yang tepat, menambahkan aria-label dapat menjadi redundan atau bahkan mengganti nama yang sebelumnya sudah baik. Untuk tombol ikon sederhana tanpa teks atau sumber nama lain, aria-label adalah pilihan praktis. Jika desain dapat menyediakan teks terlihat, teks tersebut sering lebih mudah dipahami oleh lebih banyak kelompok pengguna. Periksa hasil akhir melalui accessibility inspector dan pastikan nama menggambarkan tindakan, misalnya “Tutup panel bantuan”, bukan bentuk ikon seperti “tanda silang”. Nama berbasis fungsi biasanya lebih berguna karena menjelaskan apa yang terjadi ketika kontrol diaktifkan.
3. Mengapa div dengan role="button" tidak bekerja seperti button saat keyboard digunakan?role="button" menyatakan semantik aksesibilitas, tetapi tidak mengubah div menjadi implementasi tombol HTML native. Sebuah tombol khusus memerlukan pengelolaan fokus serta aktivasi keyboard yang sesuai dengan pola widget, dan kompleksitas tersebut tidak diperoleh hanya dengan menambahkan role. Bila tindakan memang berupa tombol, solusi paling sederhana adalah mengganti elemen menjadi <button type="button">. Browser kemudian menyediakan semantik serta perilaku keyboard native yang dibutuhkan. Setelah penggantian, uji Tab untuk fokus dan aktivasi keyboard. Pendekatan ini juga mengurangi kode yang harus dipelihara. Widget khusus tetap mungkin dibutuhkan pada antarmuka kompleks, tetapi implementasinya harus mengikuti spesifikasi dan pola interaksi yang relevan, bukan sekadar meniru tampilannya.
4. Mengapa urutan Tab terasa acak setelah saya menambahkan tabindex?
Penyebab umum adalah penggunaan nilai tabindex positif seperti 1, 2, dan seterusnya, atau struktur DOM yang tidak sesuai dengan alur antarmuka. Nilai positif membentuk prioritas fokus yang dapat berinteraksi buruk ketika halaman berkembang dan kontrol baru ditambahkan. Hapus prioritas positif, pertahankan elemen interaktif native dalam urutan dokumen yang logis, dan gunakan tabindex="0" hanya bila sebuah elemen memang harus masuk sequential focus navigation. Gunakan tabindex="-1" ketika target perlu dapat menerima fokus tanpa menjadi pemberhentian Tab normal. Setelah perubahan, mulai dari bagian atas halaman dan uji seluruh alur menggunakan Tab serta Shift+Tab. Bandingkan posisi fokus dengan urutan visual dan urutan informasi di DOM; ketiganya idealnya membentuk pengalaman yang koheren.
Kesimpulan dan Rencana Aksi
Lima atribut yang dibahas mempunyai tanggung jawab berbeda dan sebaiknya tidak dipertukarkan. alt memberikan alternatif tekstual yang sesuai untuk gambar; aria-label dapat menyediakan nama aksesibel saat nama yang diperlukan tidak tersedia dengan cara yang lebih tepat; aria-hidden="true" mengeluarkan konten dari accessibility tree dan karena itu harus dijauhkan dari kontrol yang dapat difokuskan; role mengomunikasikan semantik tetapi tidak menciptakan perilaku interaksi; sementara tabindex memengaruhi kemampuan dan urutan fokus, dengan nilai positif yang umumnya sebaiknya dihindari. Rencana aksi yang efektif adalah mengaudit halaman mulai dari HTML native, kemudian memeriksa setiap gambar, nama kontrol, penggunaan ARIA, dan jalur keyboard. Hapus atribut redundan sebelum menambahkan yang baru. Setelah itu uji dengan Tab dan Shift+Tab, periksa accessibility tree, serta lakukan pengujian teknologi bantu yang relevan dengan dukungan proyek. Untuk pengembangan berikutnya, pelajari accessible name secara lebih mendalam, relasi aria-labelledby dan aria-describedby, state ARIA, pengelolaan fokus pada antarmuka dinamis, serta pola widget WAI-ARIA. Prinsip dasarnya tetap sama: semantik native lebih dahulu, ARIA hanya ketika dibutuhkan, dan setiap keputusan harus diverifikasi berdasarkan perilaku pengguna nyata.
Ditulis dan diedit oleh Ahmad Ismail Al Malik