Ali Buğatekin

kayıttan

11.01.2026 · 7 dk okuma

Web Uygulamalarında Yaygınlaşan Erişilebilirlik (Accessibility) Hikayesi ve Radix UI

— Ali Buğatekin

Radix UIAccessibility

Son yıllarda web uygulamalarında yalnızca “güzel görünen” arayüzler değil, herkes için erişilebilir arayüzler konuşulmaya başlandı.

Bu değişim tesadüf değil; hem teknik hem de iş tarafında ciddi bir karşılığı var.

Tam da bu noktada, modern frontend projelerinde adı giderek daha sık geçen bir altyapı öne çıkıyor: Radix UI.

“Çalışıyor” Bir UI, Erişilebilir Olmak Zorunda Değil

Bir web uygulamasında şu etkileşimleri düşünelim:

  • Modal açılır
  • Menü kapanır
  • Dropdown seçilir
  • Tooltip görünür

Çoğu zaman kontrolümüz şudur:

“

“Mouse ile çalışıyor mu?”

Ama erişilebilirlik şunu sorar:

  • Klavye ile kullanılabiliyor mu?
  • Focus doğru yönetiliyor mu?
  • Screen reader doğru şeyleri okuyor mu?
  • Görsel olmayan kullanıcı arka planı “görüyor” mu?

Bu soruların cevabı çoğu projede hayır.

Erişilebilirlik (a11y) Neden Gündeme Oturdu?

Erişilebilirlik uzun süre “sonra bakarız” konusuydu.

Ama bugün:

  • Kurumsal projelerde zorunlu
  • Kamu ve finans projelerinde yasal gereklilik
  • ABD / AB pazarlarında hukuki risk
  • Genişleyen kullanıcı profilleri

kısacası:

“

Erişilebilirlik artık UX detayı değil, ürün gerekliliği.

UI Bileşenlerinde Asıl Zor Olan Ne?

Bir modal yazmak göründüğü kadar basit değil.

Erişilebilir bir modal için:

  • Focus içeride kilitlenmeli
  • ESC ile kapanmalı
  • Arka plan pasif olmalı
  • Screen reader yalnızca modalı okumalı

Bu davranışların her biri ayrı ayrı doğru uygulanmalı.

Radix UI Neyi Çözüyor?

Radix UI, UI bileşenlerinin davranış katmanını çözer:

  • Keyboard navigation
  • Focus management (trap & restore)
  • ARIA role ve state’ler
  • Screen reader uyumu
  • Edge-case’ler (nested dialog, portal, scroll lock)

Ama şunları yapmaz:

  • Stil vermez
  • Tema dayatmaz
  • CSS üretmez

Bu yüzden Radix UI headless bir altyapıdır.

Radix UI Slot ve asChild: Semantik HTML Neden Bozulmuyor?

1<Dialog.Trigger asChild>
2  <a href="/profile" className="text-blue-600 underline">
3    Open profile dialog
4  </a>
5</Dialog.Trigger>

Burada:

  • Radix ekstra üretmez
  • Senin elementini kullanır
  • Ama tüm davranışı ve accessibility’yi ona aktarır

Sonuç:

  • HTML semantiği doğru
  • CSS bozulmaz
  • Accessibility korunur

Bu, klasik UI kütüphanelerinde yıllardır yaşanan büyük bir problemin kökten çözümüdür.

shadcn/ui Bu Resmin Neresinde?

Bugün birçok geliştirici doğrudan Radix UI yazmıyor. Ama shadcn/ui kullanıyor.

shadcn/ui:

  • Radix UI primitives üzerine kurulu
  • Görünüm ve Tailwind entegrasyonu sağlar
  • Radix’in karmaşıklığını sadeleştirir

Örnek bir shadcn Button:

1<Button asChild>
2  <Link href="/dashboard">Dashboard</Link>
3</Button>

Burada:

  • Davranış: Radix UI
  • Görünüm: shadcn/ui
  • Semantik: senin HTML'in

Radix UI’ın popülerliğinin en büyük sebebi de bu görünmez altyapı rolüdür.

Sonuç

“

Radix UI, web uygulamalarında erişilebilirliğin bir ekstra değil, temel bir yapı taşı hâline geldiği dönemin doğal sonucudur.

Bugün shadcn/ui kullanan herkes, farkında olarak ya da olmayarak Radix UI’nin erişilebilirlik yaklaşımını kullanıyor.

yararlı bulduysan paylaş