WCAG Heading Pemeriksa

Apa itu pemeriksa heading WCAG?

Pemeriksa heading WCAG memvalidasi bahwa elemen heading pada halaman web (h1, h2, h3, h4, h5, h6) membentuk hierarki logis yang dapat dinavigasi oleh pembaca layar dan teknologi bantu lainnya. Heading adalah cara pengguna buta dan low-vision membaca sekilas halaman: mereka menggunakan pintasan pembaca layar untuk melompat dari heading ke heading, membangun daftar isi mental dalam hitungan detik. Jika heading hilang, urutannya salah, atau digunakan secara dekoratif, navigasi tersebut runtuh. Kriteria Keberhasilan WCAG 2.2 1.3.1 (Info dan Hubungan) dan 2.4.6 (Heading dan Label) mengharuskan heading menyampaikan struktur dengan benar.

Aturannya sederhana untuk dinyatakan dan mudah dilanggar. Harus ada tepat satu h1 per halaman (judul halaman). Setiap heading berikutnya harus paling banyak satu tingkat lebih dalam dari induknya (h2 dapat diikuti oleh h2 lain atau h3, tetapi tidak langsung oleh h4). Heading tidak boleh kosong. Tingkat heading harus menggambarkan struktur dokumen, bukan ukuran visual (jangan gunakan h4 hanya karena Anda ingin teks lebih kecil). Sebagian besar audit aksesibilitas menandai masalah hierarki heading sebagai hal pertama yang harus diperbaiki karena mereka umum, mudah diverifikasi, dan berdampak tinggi bagi pengguna pembaca layar.

Alat ini mem-parse HTML yang Anda tempel (tanpa upload, tanpa round-trip server), berjalan melalui elemen heading dalam urutan dokumen, dan melaporkan masalah: h1 hilang, beberapa h1, tingkat dilewati, heading kosong, dan outline struktur halaman. Outputnya adalah teks biasa yang menjelaskan setiap masalah. Jalankan pada halaman apa pun selama pengembangan, sebelum peluncuran, atau sebagai bagian dari siklus audit aksesibilitas reguler. Output dalam bahasa biasa, bukan skor numerik; tujuannya adalah memberi Anda masalah khusus untuk diperbaiki, bukan nilai lulus untuk dikejar.

Apa yang ada di dalam alat ini

Bagian atas halaman adalah textarea tempat Anda menempel HTML Anda. Anda dapat menempel dokumen lengkap (DOCTYPE, html, head, body) atau fragmen (hanya konten body). Alat ini mengekstrak semua elemen h1 sampai h6 dalam urutan dokumen menggunakan DOMParser browser standar, sehingga parsing cocok dengan apa yang akan dilakukan browser nyata. Textarea menangani input dengan ukuran apa pun; dokumen yang sangat besar (puluhan ribu baris) berfungsi tetapi memerlukan sebagian kecil detik lebih lama untuk di-parse.

Klik Periksa Heading dan hasilnya muncul di bawah. Bagian pertama adalah outline heading: setiap heading secara berurutan, diindentasi berdasarkan tingkat, sehingga Anda dapat membaca struktur sebagai daftar isi. Bagian kedua adalah daftar masalah: setiap masalah dengan lokasi spesifiknya, apa yang salah, dan penjelasan singkat tentang mengapa hal itu penting. Masalah dikategorikan berdasarkan tingkat keparahan: kesalahan (harus diperbaiki untuk kepatuhan WCAG) dan peringatan (praktik terbaik tetapi bukan kegagalan ketat).

Output tetap di browser; tidak ada yang diunggah. Anda dapat menempel HTML yang sama berkali-kali dengan suntingan di antaranya untuk mengulang perbaikan. Alat ini secara sengaja tidak memeriksa apa pun di luar struktur heading (tidak memverifikasi teks alt, kontras, urutan fokus, ARIA, atau kriteria WCAG lainnya). Untuk itu, gunakan alat ini bersama alat audit komprehensif seperti axe DevTools, Lighthouse, atau WAVE.

Sejarah dan latar belakang

Heading HTML sejak awal (1991)

Tim Berners-Lee memperkenalkan HTML pada 1991 dengan elemen h1 sampai h6 sebagai bagian dari 18 tag asli. Maksud semantik asli selalu struktur dokumen, bukan gaya visual. Hierarki heading Web berasal dari tradisi yang jauh lebih tua: dokumen cetak (buku, makalah, laporan pemerintah) telah menggunakan tingkat bagian bernomor selama berabad-abad untuk menyampaikan struktur. HTML mewarisi model itu secara langsung. Meskipun 35 tahun semantik stabil, penyalahgunaan heading adalah salah satu bug aksesibilitas paling umum di web modern karena desainer sering menggaya berdasarkan ukuran visual dulu dan memeriksa struktur kedua.

Pembaca layar belajar bernavigasi dengan heading (1996 dan seterusnya)

JAWS (Job Access With Speech) dirilis oleh Henter-Joyce pada 1989 dan menambahkan navigasi heading halaman Web saat Web tumbuh populer melalui akhir 1990-an. Menekan tombol H di JAWS melompat ke heading berikutnya; tombol bernomor 1 sampai 6 melompat ke tingkat heading tertentu. Setiap pembaca layar utama sejak (NVDA pada 2006, VoiceOver pada 2005, TalkBack di Android) telah menyalin pintasan ini. Survei Pengguna Pembaca Layar Tahunan WebAIM secara konsisten menemukan bahwa 67 sampai 70 persen pengguna pembaca layar bernavigasi dengan heading sebagai metode utama mereka untuk memahami halaman. Hierarki heading yang rusak karenanya bukan masalah kosmetik.

WCAG 1.0 dan bangkitnya standar aksesibilitas (1999)

Web Content Accessibility Guidelines 1.0 diterbitkan oleh W3C pada Mei 1999, standar internasional pertama untuk aksesibilitas Web. WCAG 1.0 secara eksplisit mengharuskan heading digunakan untuk struktur dokumen (Checkpoint 3.5). WCAG 2.0 (2008) menyempurnakan ini menjadi Kriteria Keberhasilan 1.3.1 (Info dan Hubungan, Tingkat A) dan 2.4.6 (Heading dan Label, Tingkat AA). WCAG 2.1 (2018) dan 2.2 (2023) mempertahankan kriteria ini tidak berubah karena persyaratan yang mendasarinya kokoh. Sebagian besar undang-undang aksesibilitas di seluruh dunia (ADA di AS, EAA di Eropa, AODA di Ontario) sekarang mengutip WCAG 2.1 AA sebagai dasar hukum.

Pemberian bagian HTML5 dan outline dokumen (2014)

HTML5 (Rekomendasi W3C 2014) memperkenalkan elemen pemberian bagian (article, section, nav, aside) dan algoritma outline yang seharusnya menurunkan hierarki heading dari kedalaman nesting. Algoritma tersebut tidak pernah diimplementasikan di browser atau pembaca layar mana pun dan secara resmi dihapus pada 2022. Panduan praktisnya adalah: gunakan tingkat heading eksplisit (h1 sampai h6) dan perlakukan elemen pemberian bagian sebagai pengelompokan semantik, bukan sebagai pengganti kedalaman heading. HTML Living Standard sekarang menyatakan dengan jelas bahwa tingkat heading harus diatur secara eksplisit.

Peran ARIA dan aria-level (2014 dan seterusnya)

WAI-ARIA 1.1 (Rekomendasi W3C 2017) menyediakan role="heading" dengan aria-level="N" sebagai cara alternatif untuk menandai heading, berguna ketika Anda tidak dapat menggunakan elemen h1-h6 asli (misalnya, dalam komponen framework yang perlu merender tingkat heading berbeda dalam konteks berbeda). Pembaca layar memperlakukan role="heading" identik dengan elemen asli. Praktik terbaik adalah menggunakan elemen asli jika memungkinkan; gunakan ARIA hanya ketika semantik asli tidak tersedia. Alat ini memeriksa baik elemen heading asli maupun elemen dengan role="heading".

Gugatan aksesibilitas dan kasus bisnis (2017 dan seterusnya)

Domino's Pizza v. Robles (Mahkamah Agung AS 2019) menetapkan bahwa Americans with Disabilities Act (ADA, 1990) berlaku untuk situs web komersial. Ratusan gugatan serupa diikuti setiap tahun (lebih dari 4.000 gugatan web ADA diajukan pada 2024 saja). European Accessibility Act (EAA, berlaku Juni 2025) menjadikan aksesibilitas setara WCAG sebagai persyaratan hukum untuk sebagian besar situs web yang menghadap konsumen di seluruh UE. Struktur heading yang gagal adalah salah satu masalah termudah untuk diidentifikasi dan didokumentasikan oleh penggugat, yang membuat pemeriksaan heading dasar menjadi langkah kepatuhan dengan leverage tinggi.

Alur kerja praktis

Pemeriksaan pra-peluncuran pada halaman dan template baru

Sebelum halaman atau template baru dirilis, jalankan HTML melalui pemeriksa ini. Masalah struktur heading adalah bug aksesibilitas termudah untuk diperkenalkan (terutama dalam konten yang didorong CMS di mana editor memilih tingkat heading berdasarkan ukuran visual) dan termudah untuk diperbaiki. Menangkapnya sebelum peluncuran jauh lebih murah daripada setelahnya, ketika perbaikan memerlukan koordinasi dengan pemilik konten. Untuk agensi, bangun pemeriksaan ini ke dalam daftar periksa QA; untuk tim internal, jalankan sebagai bagian dari tinjauan kode atau sebelum bergabung ke main.

Audit situs yang ada untuk kepatuhan aksesibilitas

Untuk audit aksesibilitas (pra-litigasi, kepatuhan EAA, persyaratan kontrak), telusuri halaman paling banyak dikunjungi dan jalankan HTML masing-masing melalui pemeriksa ini. Dokumentasikan temuannya: halaman mana yang memiliki masalah heading, jenis apa, cara memperbaikinya. Gabungkan dengan axe DevTools atau Lighthouse untuk kriteria WCAG lainnya. Temuan struktur heading biasanya termudah untuk diperbaiki dan membentuk bagian kemenangan cepat yang solid dalam laporan audit.

Pelatihan editor CMS dan templating

Konten yang didorong CMS (WordPress, Drupal, Contentful, Sanity) sering memberikan editor dropdown heading dengan opsi H1 sampai H6. Editor yang tidak tahu aturan memilih tingkat berdasarkan ukuran visual. Tunjukkan pemeriksa ini kepada editor sehingga mereka dapat melihat apa yang dihasilkan oleh pilihan heading mereka. Untuk template, jalankan output yang dirender melalui pemeriksa setelah setiap perubahan desain untuk memastikan pilihan heading editor masih menghasilkan hierarki yang valid. Banyak plugin CMS ada yang memperingatkan editor pada saat penulisan; alat ini melayani langkah verifikasi.

Memvalidasi template email dan buletin HTML

Email HTML yang dibaca oleh pembaca layar harus mengikuti hierarki heading yang sama dengan halaman web. Jalankan HTML template email Anda melalui pemeriksa ini sebelum mengirim ke daftar besar. Masalah template email umum: beberapa h1 (ketika setiap bagian memiliki judulnya sendiri), h1 hilang (ketika tata letak dimulai langsung dengan h2), dan h4 dekoratif yang digunakan murni untuk heading kecil. Perbaiki ini sebelum mengirim; pengguna teknologi bantu di daftar Anda akan melihatnya.

Memvalidasi konversi PDF ke HTML

Saat Anda mengubah PDF menjadi HTML untuk aksesibilitas (sehingga dapat dibaca oleh pembaca layar dengan navigasi heading), konverter harus memetakan tag struktur PDF ke tingkat heading HTML. Hasilnya sering rusak: PDF tanpa penandaan yang tepat menghasilkan HTML datar tanpa heading sama sekali, dan bahkan PDF yang ditandai kadang-kadang menghasilkan output semua-h1 atau semua-h2. Jalankan HTML yang dikonversi melalui pemeriksa ini untuk menemukan masalah sebelum menerbitkan halaman yang dikonversi.

Onboarding pengembang dan desainer baru

Pengembang front-end junior dan desainer mendapat manfaat dari melihat contoh konkret hierarki heading yang rusak dan pengalaman pembaca layar yang dihasilkan. Pasangkan alat ini dengan demo pembaca layar (NVDA di Windows gratis, VoiceOver di Mac bawaan) untuk menunjukkan bagaimana heading mendorong navigasi pembaca layar. Hubungan antara aturan heading abstrak dan pengalaman pengguna konkret sering kali adalah apa yang membuat pelajaran melekat.

Jebakan umum

Memilih tingkat heading berdasarkan ukuran visual

Kesalahan paling umum: menggunakan h4 karena Anda ingin teks lebih kecil, atau melompat dari h2 ke h4 karena tidak ada h3 berukuran tepat dalam desain. Tingkat heading bersifat struktural, bukan visual; gunakan CSS untuk mengontrol ukuran dan gunakan tingkat yang sesuai dengan hierarki dokumen. Jika sistem desain Anda tidak memiliki gaya visual untuk setiap tingkat yang diperlukan, tambahkan satu (atau timpa dengan nama kelas) daripada memilih tingkat yang salah.

Beberapa h1 per halaman

Halaman harus memiliki tepat satu h1 yang mewakili judul halaman. Bug umum: logo situs dibungkus h1 ditambah judul artikel juga dalam h1 (dua h1), beranda dengan setiap bagian hero menggunakan h1 (beberapa h1), atau tidak ada h1 sama sekali karena tata letak dimulai dengan h2. Perbaikannya bersifat struktural: pilih konten terpenting di halaman sebagai h1 tunggal dan turunkan yang lain ke h2 atau lebih rendah. Alat seperti axe dan Lighthouse memperingatkan tentang beberapa h1 karena alasan ini.

Tingkat heading yang dilewati

Pergi dari h2 langsung ke h4 merusak outline dokumen. Pengguna pembaca layar yang bergerak heading-ke-heading mengharapkan setiap h4 bersarang di bawah h3, dan h3 yang hilang membingungkan struktur. Perbaikannya adalah memasukkan tingkat menengah yang hilang atau menurunkan h4 ke h3. Penyebab paling umum adalah menyalin desain dari mockup di mana hierarki visual menggunakan tiga ukuran tetapi sistem desain menggunakan empat tingkat heading; periksa kembali setelah setiap pembaruan komponen.

Heading kosong

H2 tanpa konten teks (sering karena widget JavaScript menghapus teks tetapi mempertahankan elemen) muncul dalam daftar heading pembaca layar sebagai heading tanpa label, yang membingungkan dan tidak berguna. Baik isi heading dengan teks, atau hapus elemen heading sepenuhnya. Ini umum dalam aplikasi satu halaman di mana elemen placeholder dirender sebelum data dimuat; render heading hanya ketika ada konten untuk dimasukkan ke dalamnya.

Heading di dalam pembungkus non-semantik

Heading yang dibungkus dalam div dengan role="presentation" atau aria-hidden="true" dihapus dari pohon aksesibilitas, yang dapat menyembunyikan heading yang sebaliknya benar dari pembaca layar. Audit elemen induk setiap heading untuk memastikan mereka tidak melucuti heading dari pohon aksesibilitas. CSS display:none dan visibility:hidden juga menghapus heading; hanya gunakan ini secara sengaja dan jangan pernah pada konten yang harus terlihat oleh pembaca layar.

Menggunakan ARIA ketika HTML asli akan berfungsi

Menambahkan role="heading" aria-level="2" ke div alih-alih menggunakan elemen h2 berfungsi untuk aksesibilitas tetapi merupakan kompleksitas yang tidak perlu. Elemen h1-h6 asli mendapatkan semantik heading secara gratis, merender dengan benar dalam gaya browser default, dan bertahan dari bug pembaca layar lebih baik daripada penggantian ARIA. Aturan pertama ARIA (per WAI-ARIA Authoring Practices) adalah: jangan gunakan ARIA ketika HTML asli menyediakan semantik yang sama. Gunakan elemen heading asli kecuali batasan framework benar-benar memaksa ARIA.

Privasi dan penanganan data

HTML yang Anda tempel tetap di browser Anda sepanjang pemeriksaan. DOMParser yang mengekstrak heading berjalan di JavaScript pada mesin Anda; hasilnya dirender di halaman di bawah textarea. Tidak ada langkah upload, tidak ada pemrosesan jarak jauh, dan tidak ada telemetri tentang HTML apa yang Anda tempel. Ini penting karena HTML yang paling ingin Anda periksa (template pra-peluncuran, situs klien di bawah NDA, halaman admin internal) adalah persis apa yang tidak boleh Anda tempelkan ke validator SaaS pihak ketiga.

Setelah halaman dimuat, alat berfungsi offline. Anda dapat memutuskan koneksi dari internet, menempel HTML, menjalankan pemeriksaan, dan meninjau hasilnya tanpa markup Anda pernah menyentuh mesin lain. Sebagian besar pemeriksa aksesibilitas cloud (PowerMapper, Tenon, Site Improve) memerlukan upload URL halaman atau HTML; untuk halaman rahasia itu persis mode kegagalan yang harus dihindari.

Kapan tidak menggunakan alat ini

Untuk audit WCAG lengkap (gunakan alat komprehensif)

Struktur heading adalah salah satu dari puluhan kriteria WCAG. Untuk audit lengkap, gunakan axe DevTools (ekstensi Chrome/Firefox gratis dari Deque), Lighthouse (terintegrasi dalam Chrome), WAVE (alat gratis WebAIM), atau solusi berbayar seperti Tenon atau PowerMapper. Mereka memeriksa kontras warna, teks alt, penggunaan ARIA, label formulir, urutan fokus, dan banyak lagi. Jalankan alat ini bersama, bukan menggantikan, yang komprehensif.

Untuk konten dinamis (uji DOM yang dirender)

Jika heading Anda dihasilkan oleh JavaScript (React, Vue, Svelte, Angular), sumber HTML statis tidak berisi heading akhir. Anda perlu menempel DOM yang dirender setelah JavaScript berjalan. Gunakan DevTools browser: buka halaman, buka DevTools, tab Elements, klik kanan body atau main, Copy outerHTML, lalu tempel ke pemeriksa ini. Atau gunakan ekstensi browser yang berjalan langsung di DOM langsung.

Untuk pipeline CI/CD otomatis (gunakan pustaka Node)

Jika Anda ingin pemeriksaan heading berjalan otomatis pada setiap komit atau pull request, integrasikan axe-core, Pa11y, atau jest-axe ke dalam suite pengujian Anda. Mereka menjalankan pemeriksaan heading (dan banyak pemeriksaan WCAG lainnya) tanpa kepala dalam CI. Alat browser ini untuk penggunaan interaktif selama pengembangan dan tinjauan, bukan untuk otomatisasi. Keduanya memiliki tempatnya; gunakan alat browser untuk audit sekali pakai dan pustaka CI untuk validasi berkelanjutan.

Untuk aksesibilitas dokumen PDF atau Word

PDF dan dokumen Word memiliki sistem tagging aksesibilitas sendiri (PDF/UA, gaya heading Word). Mereka tidak menggunakan heading HTML, jadi alat ini tidak berlaku. Untuk aksesibilitas PDF, gunakan Adobe Acrobat Pro Accessibility Checker atau PAC 2024 (gratis, terfokus pada PDF/UA). Untuk Word, gunakan Accessibility Checker bawaan (tab Review). Konversikan ke HTML terlebih dahulu jika Anda ingin menggunakan alat ini, tetapi konversi itu sendiri dapat menimbulkan masalah heading.

Pertanyaan lainnya

Apakah pernah OK untuk melewati tingkat heading?

Tidak dalam konten dokumen langsung. WCAG 2.2 SC 1.3.1 menyiratkan heading harus membentuk urutan hierarkis. Satu kasus umum di mana terlihat seperti lompatan adalah outline halaman yang dimulai pada h1 lalu h2 di dalam area konten utama, sementara sidebar atau navigasi juga memiliki h2; itu baik-baik saja karena keduanya saudara di bawah h1 halaman. Aturan sebenarnya adalah: jangan lewati tingkat dalam aliran konten yang berkelanjutan. Pemeriksa hanya menandai lompatan yang sebenarnya.

Bagaimana jika framework saya hanya mendukung satu tingkat heading?

Beberapa pustaka komponen merender heading pada tingkat tetap (selalu h2, terlepas dari nesting). Perbaikannya adalah mengekspos prop tingkat pada komponen heading (h2, h3, dll.) dan memiliki induk meneruskan nilai yang sesuai. Framework seperti React umumnya melakukan ini; jika milik Anda tidak, tambahkan aria-level pada komponen dan gunakan role="heading" sebagai solusi sementara sampai Anda dapat memperbaiki. Jangka panjang, setiap komponen heading yang dapat digunakan kembali harus menerima prop tingkat.

Apakah alat memeriksa peran ARIA seperti role="heading"?

Ya. Setiap elemen dengan role="heading" dan atribut aria-level yang valid (1 sampai 6) diperlakukan sebagai heading pada tingkat yang ditunjukkan. Elemen h1-h6 asli selalu lebih disukai, tetapi heading bertanda ARIA sama validnya untuk pembaca layar dan diperiksa bersama yang asli.

Seberapa penting hierarki heading dibandingkan dengan kriteria WCAG lainnya?

Sangat. Survei Pengguna Pembaca Layar Tahunan WebAIM secara konsisten menemukan bahwa 67-70% pengguna pembaca layar bernavigasi dengan heading sebagai cara utama mereka untuk memahami halaman. Heading yang buruk secara efektif memblokir salah satu metode navigasi aksesibilitas utama. Dalam analisis WebAIM Million tahunan WebAIM, masalah heading termasuk lima kegagalan aksesibilitas paling umum di seluruh web. Kombinasi dampak pengguna tinggi dan deteksi mudah menjadikan mereka prioritas utama.

Apakah setiap halaman harus memiliki h1?

Ya, dengan pengecualian langka. Setiap dokumen HTML lengkap harus memiliki tepat satu h1 yang mewakili judul halaman. Pengecualiannya adalah fragmen yang secara eksplisit dimasukkan ke dalam halaman yang lebih besar (tanda tangan email, widget yang disematkan di halaman lain); halaman host menyediakan h1 dan fragmen dimulai pada h2 atau lebih rendah. Untuk halaman mandiri, h1 yang hilang adalah kegagalan aksesibilitas yang jelas.

Dapatkah saya mempercayai alat ini untuk audit kepatuhan hukum?

Untuk struktur heading secara khusus, ya: aturannya tepat dan alat mengimplementasikannya secara akurat. Untuk kepatuhan WCAG secara keseluruhan, tidak ada satu pun alat otomatis yang cukup; pengujian manual dengan teknologi bantu, tinjauan ahli, dan pengujian pengguna dengan pengguna cacat diperlukan untuk audit kelas hukum. Gunakan alat ini sebagai salah satu dari beberapa input untuk audit Anda, bukan sebagai satu-satunya sumber kebenaran untuk kepatuhan.