Back to News/97% Website Gagal di Accessibility Test — Apa yang Kamu(e) Lakukan Salah?

97% Website Gagal di Accessibility Test — Apa yang Kamu(e) Lakukan Salah?

Kebanyakan developer menganggap accessibility itu 'nggak urgent' sampai mereka kena lawsuit. Belajar WCAG 2.2, prinsip POUR, dan teknik implementasi yang bisa langsung kamu terapin sebelum digital kamu jadi mimpi buruk legal — dan yang lebih penting, tentang kemanusiaan.

Faisal Affan
4/1/2026
97% Website Gagal di Accessibility Test — Apa yang Kamu(e) Lakukan Salah? — 1 / 2
1 / 2

Accessibility: Kapan Digital Tidak Boleh Ada yang Tertinggal

"The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect." — Tim Berners-Lee, W3C Director


Mengapa Kamu Perlu Baca Artikel Ini?

3 Alasan Cepat:

  1. Legal risk — 4.000+ lawsuit accessibility di AS tahun 2024
  2. 15% populasi — punya keterbatasan, dan maioria开发者 skip ini
  3. SEO benefit — accessibility = structure HTML lebih baik

Statistik Kritis

1,3 miliar penyandang disabilitas global. 97% homepage tidak memenuhi standar dasar. Pasar assistive technology: $30 miliar+.


Overview: Apa Itu Accessibility (A11y)?

Accessibility (A11y) = praktik membuat produk digital bisa digunakan oleh semua orang, termasuk penyandang disabilitas.

Dua Standar yang Harus Kamu Tahu

Prop

Type

Prinsip WCAG: POUR


Spektrum Disabilitas yang Harus Ditampung

Prop

Type


Level WCAG: Mana yang Harus Kamu Targetkan?

Level A — Minimum

Requirements dasar. Jika miss, website akan fail accessibility test.

Level AA — Standar Industri

Target kebanyakan regulasi. Compliance yang reasonable untuk大多数 organisasi.

Level AAA — Strict

Full compliance jarang diperlukan. Strictest requirements.

Rekomendasi

Targetkan WCAG AA sebagai baseline compliance. Ini yang大多数 regulasi international pakai.


Risiko Jika Kamu Skip Accessibility

4 Risiko Utama:

RisikoDampak
LegalLawsuit di US/EU market — bisa sangat mahal
Users15-20% populasi dengan keterbatasan tidak bisa pakai
SEOStruktur HTML buruk = SEO suffers
BrandNon-inclusive = brand image rusak

WCAG 2.2: 9 Hal Baru yang Perlu Kamu Tahu

Versi terbaru (Oktober 2023) menambahkan 9 Success Criteria baru:

Element dengan focus tidak boleh tersembunyi oleh sticky headers.

Focus indicator harus kontras 3:1+ dan area yang cukup besar.

Semua drag-and-drop harus punya alternatif single-pointer (button up/down).

Interactive targets minimal 24x24 CSS pixels.

Clearance yang cukup untuk target yang lebih kecil.

Help mechanism di satu page = help di semua page dengan posisi konsisten.

Jangan minta informasi yang sudah di-input sebelumnya.

CAPTCHA cognitive puzzles tidak diperbolehkan — berikan alternatif.

Tidak ada bagian focused element yang boleh tersembunyi.


Kerangka Hukum: ADA dan Section 508

Americans with Disabilities Act (ADA)

Prop

Type

Sejak Facebook v. Nizzud (2019) dan Domino's Pizza v. Laredo (2019), courts secara konsisten memutuskan ADA berlaku untuk websites.

Section 508

Untuk entitas federal AS, semua EICT harus memenuhi standar Access Board.


Implementasi Praktis: Dari Teori ke Kode

1. Semantic HTML: Fondasi yang Tidak Boleh Di-skip

Gunakan element HTML sesuai fungsinya:

<!-- ❌ Bad: Tidak semantic -->
<div class="header">
  <div class="nav">
    <div class="logo">Brand</div>
  </div>
</div>

<!-- ✅ Good: Semantic dengan landmarks -->
<header>
  <nav aria-label="Main navigation">
    <a href="/" aria-label="Home">Brand</a>
  </nav>
</header>
<main id="main-content">
  <article>...</article>
</main>
<footer>...</footer>

Opinion

Gunakan <button> bukan <div> untuk interactive elements. Screen reader perlu tahu ini button.

2. Alt Text: Deskripsi untuk yang Tidak Bisa Melihat

Prop

Type

3. Keyboard Navigation: Fokus dan Tab Order

Pastikan tab order mengikuti reading order visual. Hindari positive tabindex.

Jangan hilangkan outline tanpa pengganti yang jelas.

Pastikan tidak ada element yang trap keyboard user.

Berikan mekanisme untuk disable/remap single-key shortcuts.

/* ✅ Good: Focus indicator yang jelas */
:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

/* ❌ Bad: outline: none tanpa alternatif */
button:focus {
  outline: none;
}
<!-- Letakkan di first element body -->
<a href="#main-content" class="skip-link">
  Skip to main content
</a>
.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  background: #005fcc;
  color: white;
  padding: 8px 16px;
  z-index: 100;
}

.skip-link:focus {
  top: 0;
}

5. Color Contrast: Bukan Sekadar Estetika

WCAG Contrast Requirements

  • 4.5:1 — Teks normal (AA)
  • 3:1 — Teks besar 18pt+ atau 14pt+ bold (AA)
  • 3:1 — Component states dan graphical objects (AA)
:root {
  /* ✅ Good: Contrast sufficient */
  --text-primary: #1a1a2e;   /* 15.5:1 against white */
  --text-secondary: #4a4a68; /* 7.2:1 against white */

  /* ❌ Bad: Contrast insufficient */
  --text-muted: #888888; /* 2.8:1 against white */
}

6. ARIA: Gunakan Dengan Bijak

Aturan Utama ARIA

Jika HTML native sudah cukup, gunakan HTML. ARIA tidak bikin element lebih accessible — cuma menambah informasi untuk assistive technology.

// ❌ Bad: ARIA tidak perlu
<div role="button" tabindex="0" onClick={handleClick}>
  Submit
</div>

// ✅ Good: HTML native
<button type="submit">Submit</button>

// ❌ Bad: Label tidak terhubung
<input type="text" placeholder="Email" />

// ✅ Good: Explicit association
<label htmlFor="email">Email</label>
<input id="email" type="email" />

7. Forms: Error Handling yang Informatif

<label htmlFor="password">Password</label>
<input
  id="password"
  type="password"
  aria-describedby="password-requirements password-error"
  aria-invalid="true"
/>
<p id="password-requirements">
  Minimal 8 karakter, 1 huruf besar, 1 angka
</p>
<p id="password-error" role="alert">
  Password harus mengandung minimal 8 karakter
</p>

Tools: Audit, Testing, Monitoring

Automated Testing (Cepat, Scalable)

Google Lighthouse

Built-in Chrome DevTools. Quick audit dengan score + suggestions.

npx lighthouse https://example.com --only-categories=accessibility

axe DevTools

Lebih akurat dari Lighthouse. Ada versi CI/CD.

npm install @axe-core/react

Pa11y

CLI tool — cocok untuk pipeline automation.

npx pa11y https://example.com

Accessibility Insights

Step-by-step audit + guided fixes dari Microsoft.

Screen Reader Testing: Ground Truth

Opinion: 80% dev skip screen reader testing. Ini biggest blind spot.

Testing dengan assistive technology yang real adalah satu-satunya cara tahu user experience yang sebenarnya.

Prop

Type

Contrast & Visual Tools

Prop

Type

Manual Testing Checklist

  • Tab navigation tanpa mouse — semua fungsi accessible?
  • Focus state jelas — terlihat?
  • Form bisa dipakai keyboard — semua inputs reachable?
  • Tidak ada "trap" — modal/dropdown bisa di-escape?

Testing Checklist: Sebelum Launch

Pre-Launch Checklist

  • Keyboard-only navigation: semua fungsi accessible tanpa mouse?
  • Screen reader: reading order logical?
  • Zoom 200%: content masih usable?
  • High contrast mode: semua elements visible?
  • Reduced motion: animations respect prefers-reduced-motion?

Healthcare Apps: Checklist Tambahan

Prop

Type

HIPAA + ADA

Di healthcare, compliance bukan cuma WCAG — harus selaras dengan HIPAA Privacy Rule. Beberapa akomodasi accessibility harus mempertimbangkan implikasi HIPAA.


Action Plan: Dari Mana Mulai?

Priority 1: Security Mindset

Treat accessibility seperti vulnerability. Broken accessibility = UX vulnerability. Sama seperti security, harus diintegrasi dari awal.

Priority 2: WCAG AA Minimum Checklist

  • Alt text semua image
  • Keyboard fully usable
  • Contrast ≥ 4.5:1
  • Label form jelas
  • ARIA hanya jika perlu

Priority 3: Minimum Stack

  1. Lighthouse — quick check
  2. axe DevTools — debug
  3. NVDA / VoiceOver — manual reality check

Priority 4: Production-Grade

  • Pa11y / axe CI integration
  • Design system enforce contrast + semantics
  • Fail build jika accessibility score < threshold

First-Principles: Accessibility ≈ API Contract untuk Manusia

Insight

Jika API harus predictable untuk machine, maka UI harus predictable untuk manusia dengan berbagai keterbatasan.

Engineer yang paham ini biasanya:

  • Code lebih semantic
  • UX lebih robust
  • Bug lebih sedikit

Accessibility Tools = Observability Layer untuk UX

Tanpa ini:

  • UI kelihatan "normal"
  • Tapi broken untuk sebagian user

Dengan ini:

  • UX jadi measurable (seperti latency / error rate)

Kesimpulan

Accessibility bukan feature yang ditambahkan di akhir — ia adalah fundamental architecture principle.

Final Action Items

  1. Audit current state dengan axe-core atau Lighthouse
  2. Fix high-impact issues: keyboard navigation, alt text, color contrast
  3. Implement skip links dan focus management
  4. Add accessibility ke Definition of Done
  5. Regular testing dengan assistive technology

Accessibility yang baik = good design. Ketika kita membangun untuk edge cases, seluruh user experience meningkat.

Digital yang truly universal = digital yang bekerja untuk semua orang, tanpa terkecuali.


Referensi

Prop

Type


Related Articles

97% Website Gagal di Accessibility Test — Apa yang Kamu(e... | Faisal Affan