ARIA Rolleri Açıklandı: HTML'de ARIA Ne Zaman ve Nasıl Kullanılır

İşte insanı kendine getiren bir sayı: WebAIM’in en popüler bir milyon web sitesi ana sayfası analizine göre, ARIA öznitelikleri içeren sayfalar, hiç ARIA içermeyen sayfalara kıyasla ortalama olarak önemli ölçüde daha fazla tespit edilebilir erişilebilirlik hatası barındırıyor. Bu, ARIA kullanmaya karşı bir argüman değil — onu doğru kullanmaya yönelik bir argüman. ARIA, modern erişilebilirlik araç setindeki en güçlü araçlardan biridir, ama aynı zamanda en yanlış anlaşılanlardan da biridir. Doğru kullanırsanız sitenizi anlamlı biçimde milyonlarca engelli kullanıcıya açarsınız. Yanlış kullanırsanız onların deneyimini aktif olarak daha kötü hale getirirsiniz.

ARIA Nedir ve Neden Var?

ARIA, Accessible Rich Internet Applications (Erişilebilir Zengin İnternet Uygulamaları) ifadesinin kısaltmasıdır. W3C’nin Web Accessibility Initiative’i tarafından tanımlanan ve geliştiricilerin ekran okuyucular, braille ekranlar ve sesle kontrol yazılımları gibi yardımcı teknolojilere anlamsal bilgi iletmesini sağlayan bir HTML öznitelikleri kümesidir. Bir tarayıcı bir sayfayı işlerken iki paralel yapı oluşturur: DOM (gördüğünüz şey) ve Erişilebilirlik Ağacı (yardımcı teknolojilerin okuduğu şey). ARIA öznitelikleri, özel bileşenlerin ne olduğunu ve nasıl davrandığını doğru şekilde tanımlamak için bu Erişilebilirlik Ağacı’nı değiştirmenize olanak tanır.

ARIA’ya duyulan ihtiyaç gerçek bir sorundan doğdu. HTML belgeler için tasarlandı, uygulamalar için değil. Web, sekmeli arayüzler, modal diyaloglar, sürükle-bırak, canlı veri akışları gibi zengin, etkileşimli deneyimler için bir platforma dönüştüğünde, yerel HTML öğeleri bu bileşenlerin ne olduğunu veya ekran okuyucuya göre nasıl çalıştığını aktaramıyordu. ARIA bu boşluğu doldurur. MDN’in ifade ettiği gibi, ARIA “HTML’yi tamamlar, böylece uygulamalarda yaygın olarak kullanılan etkileşimler ve bileşenler, başka bir mekanizma olmadığında yardımcı teknolojilere aktarılabilir.”

ARIA görsel sunumu değiştirmez. Davranış eklemez. Klavye desteği kendiliğinden sağlamaz. Sadece Erişilebilirlik Ağacı’nın yardımcı teknolojiye neyi açığa çıkardığını değiştirir. Bu önemli bir ayrımdır — ve geliştiricilerin ARIA’yı kestirme bir yol olarak kullanmaya çalışırken yaptıkları pek çok hatanın sebebidir.

Spesifikasyon, W3C tarafından WAI-ARIA adıyla, şu anda 1.2 sürümünde olacak şekilde, 1.3 sürümü aktif geliştirme altında olacak biçimde sürdürülmektedir. Modern web desenlerinin tamamı boyunca erişilebilir kullanıcı arayüzü öğelerini tanımlayan bir rol, durum ve özellik ontolojisi sağlar.

Üç Sütun: Roller, Durumlar ve Özellikler

Tek satır ARIA yazmadan önce, spesifikasyonun sağladığı üç farklı yapı taşını anlamanız gerekir. Bunlar birbirinin yerine geçmez ve bunları karıştırmak en yaygın hata kaynaklarından biridir.

Roller, bir öğenin ne olduğunu tanımlar. Bir rol şu soruyu yanıtlar: Ne tür bir şeye bakıyorum? Örneklere button, dialog, navigation, tablist ve progressbar dahildir. Bir rolü role özniteliğiyle uygularsınız: <div role='button'>. Rol, öğenin amacını yardımcı teknolojiye iletir, böylece kullanıcı onunla nasıl etkileşime gireceğini bilir.

Durumlar, bir öğenin dinamik durumunu — kullanıcının sayfayla etkileşime girmesiyle değişen bir şeyi — tanımlar. aria-expanded özniteliği, ekran okuyucuya bir daraltılabilir bölümün açık mı kapalı mı olduğunu söyler. aria-checked, özel bir onay kutusunun işaretli olup olmadığını yansıtır. Durumların JavaScript ile senkronize tutulması gerekir; hiç değişmeyen statik bir aria-expanded='false' yalnızca işe yaramaz olmakla kalmaz, aynı zamanda aktif olarak yanıltıcıdır.

Özellikler, bir öğe hakkında betimleyici, genellikle daha durağan bilgiler sağlar. aria-label, bir öğeye görünür metnini geçersiz kılan erişilebilir bir ad verir. aria-labelledby, metni etiket olarak kullanılan başka bir öğeye işaret eder. aria-describedby, ek açıklayıcı metne bağlanır. aria-required, bir form alanının doldurulması gerektiğini belirtir. Durumların sık sık değişmesi beklenirken, özellikler genellikle bir kez ayarlanır ve öyle bırakılır — her ne kadar istisnalar olsa da.

Roller bir öğenin ne olduğunu tanımlar. Durumlar, şu anda nasıl davrandığını tanımlar. Özellikler ek betimleyici bağlam sağlar. Tam erişilebilir özel bir bileşen üretmek için bu üçünün birlikte çalışmasına ihtiyacınız vardır.

Altın Kural — ve Neden Sandığınızdan Daha Önemli

W3C’nin ARIA kullanımı için birinci kuralı açıktır: İhtiyacınız olan anlamsal yapı ve davranış zaten yerleşik olarak sunuluyorsa, yerel bir HTML öğesi veya özniteliği kullanın. Önce ARIA’ya yönelmeyin. Bu bazen “kötü ARIA’dansa hiç ARIA olmaması daha iyidir” ilkesi olarak adlandırılır — ki bu ifade, iyi niyetli ama yanlış ARIA kullanımının çok gerçek tehlikesini yansıtır.

Yerel HTML öğeleri, ARIA anlamsal özelliklerini kendiliğinden taşır. Bir <button> öğesi, Erişilebilirlik Ağacı’na zaten bir buton olarak açığa çıkar. Zaten klavye ile odaklanılabilirdir. Zaten Enter ve Space tuşlarına basıldığında tetiklenir. Zaten etiketini duyurur. <div role='button'> yazdığınız anda, tüm bu davranışı — klavye işleme, odak yönetimi, durum güncellemeleri — JavaScript ile elle yeniden oluşturma sorumluluğunu üstlenmiş olursunuz. Bu teorik bir kaygı değildir. Özel bir butonda klavye desteğini unutmak, üretimde en yaygın ve en zararlı ARIA hatalarından biridir.

ARIA’nın gerçekten gerekli olduğu durumlar genellikle birkaç senaryoda toplanır: HTML karşılığı olmayan karmaşık bir bileşen (bir carousel, otomatik tamamlama özellikli bir combobox, bir ağaç görünümü) oluşturduğunuzda; DOM’u yeniden yapılandırmanın maliyet açısından mümkün olmadığı eski işaretlemeyi iyileştirdiğinizde; özel anlamsal bilgiler açığa çıkarması gereken bir web bileşeni geliştirdiğinizde; ya da yerel bir öğe için tarayıcı ve yardımcı teknoloji desteği o kadar tutarsızdır ki, ARIA karşılığı pratikte daha güvenilir çalıştığında.

Bu senaryoların dışında, ilk içgüdünüz her zaman anlamsal HTML olmalıdır. <div role='navigation'> yerine <nav> kullanın. <div role='main'> yerine <main> kullanın. <div role='button'> yerine <button> kullanın. Yerel öğeler daha sağlamdır, daha iyi desteklenir ve çok daha az bakım gerektirir.

Başlıca ARIA Rol Kategorilerine Kısa Bir Tur

WAI-ARIA spesifikasyonu, rolleri birkaç kategoriye ayırır. Bu kategorileri anlamak, hangi rolü ne zaman kullanmanız gerektiğini bilmenize yardımcı olur.

Landmark Roller

Landmark roller, bir sayfanın ana bölgelerini işaretler ve ekran okuyucu kullanıcılarının klavye kısayollarıyla doğrudan önemli bölümlere atlamasına olanak tanır. En yaygın kullanılan landmark roller banner, navigation, main, complementary, contentinfo, search ve formdur. Bunların her birinin doğrudan yerel bir HTML karşılığı vardır: <header>, <nav>, <main>, <aside>, <footer> vb. Pratikte bu, modern anlamsal HTML kullanıyorsanız landmark rollerin neredeyse her zaman gereksiz olduğu anlamına gelir. Bunları yalnızca yapısal nedenlerle anlamsal olmayan işaretlemeye mahkûm kaldığınızda ekleyin.

<!-- Prefer this -->
<header>
  <nav>...</nav>
</header>
<main>...</main>
<footer>...</footer>

<!-- Use ARIA only when you must use divs -->
<div role='banner'>
  <div role='navigation'>...</div>
</div>
<div role='main'>...</div>
<div role='contentinfo'>...</div>

Widget Roller

Widget roller, kullanıcının doğrudan etkileşime girdiği etkileşimli bileşenleri tanımlar. ARIA’nın en önemli işini yaptığı yer burasıdır, çünkü pek çok widget deseni için yerel HTML karşılığı yoktur. Yaygın widget roller arasında button, checkbox, dialog, menu, menuitem, slider, tablist, tab, tabpanel, tooltip, tree ve combobox bulunur.

Bir widget rolü kullandığınızda, klavye etkileşimi için tam sorumluluk alırsınız. WAI-ARIA Authoring Practices Guide (APG), her widget türü için beklenen klavye desenlerini tanımlar — örneğin sekmeler arasında geçiş için ok tuşları, bir diyalogu kapatmak için Escape, bir listbox’taki ilk ve son öğeye atlamak için Home ve End. Bu desenleri uygulamamak, bileşeninizin teknik olarak etiketlenmiş ama klavyeyle çalışan kullanıcılar için işlevsel olarak kullanılamaz olduğu anlamına gelir.

<!-- A custom tab interface -->
<div role='tablist' aria-label='Account settings'>
  <button role='tab' aria-selected='true' aria-controls='panel-profile' id='tab-profile'>
    Profile
  </button>
  <button role='tab' aria-selected='false' aria-controls='panel-security' id='tab-security' tabindex='-1'>
    Security
  </button>
</div>
<div role='tabpanel' id='panel-profile' aria-labelledby='tab-profile'>
  <p>Profile settings content</p>
</div>
<div role='tabpanel' id='panel-security' aria-labelledby='tab-security' hidden>
  <p>Security settings content</p>
</div>

Live Region Roller

Live region’lar, ARIA’nın gerçekten en faydalı özelliklerinden biridir. Yardımcı teknolojilerin dinamik içerik güncellemelerini — durum mesajları, hata bildirimleri, sohbet mesajları ve yükleme göstergeleri gibi — ekran değişimini göremeyen kullanıcılara duyurmasını sağlarlar. Live region’lar olmadan, bir form gönderen ekran okuyucu kullanıcısı, odak açıkça sonuca taşınmadıkça işlemin başarılı mı başarısız mı olduğunu asla bilemeyebilir.

Temel live region roller alert, status, log, marquee ve timerdır. alert rolü, kullanıcıyı hemen bölen aria-live='assertive' ayarını örtük olarak taşır — hatalar veya acil uyarılar için uygundur. status rolü ise aria-live='polite' kullanır, yani duyurmadan önce kullanıcının mevcut görevini bitirmesini bekler — başarı mesajları ve ilerleme göstergeleri için idealdir.

<!-- Polite status message for non-urgent feedback -->
<div role='status' aria-live='polite' aria-atomic='true'>
  <!-- Dynamically inject text here with JavaScript -->
</div>

<!-- Assertive alert for errors that demand immediate attention -->
<div role='alert'>
  Please correct the errors below before submitting.
</div>

Live region’larda kilit nokta, kapsayıcının dinamik içerik eklenmeden önce DOM’da mevcut olması gerektiğidir. Aynı anda oluşturulup doldurulan bir live region, ekran okuyucular tarafından sıklıkla kaçırılır. Kapsayıcıyı sayfa yüklenirken oluşturun ve olaylar gerçekleşirken JavaScript ile doldurun.

Belge Yapısı Roller

article, list, listitem, table, row, cell, figure ve heading gibi belge yapısı roller, içeriğin yapısal organizasyonunu tanımlar. Bunların çoğu artık yerel HTML öğeleri tarafından geçersiz kılınmıştır ve MDN, belge yapısı rollerinin çoğunun “artık kullanılmaması gerektiğini, çünkü tarayıcıların aynı anlama sahip anlamsal HTML öğelerini artık desteklediğini” belirtir. Başlıca istisna, yerel HTML öğelerinin kullanılamadığı özel render ortamları, web bileşenleri veya SVG tabanlı içerikle çalıştığınız durumlardır.

Her Geliştiricinin Bilmesi Gereken Temel ARIA Özellikleri

Rollerin ötesinde, gerçek dünyadaki erişilebilirlik çalışmalarında sürekli karşınıza çıkan birkaç ARIA özelliği vardır. En sık başvuracağınız özellikler bunlardır:

• aria-label: Görünür bir metin etiketi olmadığında veya görünür metin yetersiz olduğunda bir öğe için erişilebilir bir ad sağlar. Yaygın kullanım alanları: yalnızca ikon içeren butonlar, görünür etiketi olmayan arama alanları ve modal pencerelerdeki kapatma butonları. aria-label’in, görünür metni veya yerel etiketi geçersiz kıldığını unutmayın; bu yüzden görünür metni olan öğelerde dikkatli kullanın.
• aria-labelledby: Metin içeriği erişilebilir ad olarak kullanılan bir veya daha fazla öğeye işaret eder. Etiket metni görünür içerikle senkronize kaldığı için karmaşık durumlarda aria-label’den daha sağlamdır. Boşlukla ayrılmış bir öğe ID’leri listesi kabul eder ve yardımcı teknolojiler referans verilen metinleri sırayla birleştirir.
• aria-describedby: Bir ad değil, ek bağlam sağlayan açıklama metnine bağlanır. Form alanlarını hata mesajlarına bağlamak veya bir aracı, açıkladığı öğeyle ilişkilendirmek için kullanın. Ekran okuyucular genellikle bunu öğenin adı ve rolünden sonra duyurur.
• aria-hidden: Bir öğeyi Erişilebilirlik Ağacı’ndan tamamen kaldırır. Süsleme amaçlı ikonlar, yinelenen içerik ve ekran okuyucu kullanıcıları için gürültü yaratacak yalnızca görsel öğeler için çok değerlidir. Asla odaklanılabilir bir öğeye aria-hidden='true' uygulamayın — kullanıcı hâlâ tab ile ona gelebilir, ama hakkında hiçbir bilgi alamaz.
• aria-expanded: Bir açılır menü, akordeon veya disclosure bileşeni gibi daraltılabilir bir öğenin şu anda açık mı kapalı mı olduğunu iletir. JavaScript ile dinamik olarak değiştirilmelidir; statik bir değer, özniteliği tamamen eklememekten daha kötüdür.
• aria-current: Bir küme içindeki mevcut öğeyi belirtir; en yaygın olarak, aktif sayfa bağlantısını (aria-current='page') veya çok adımlı bir süreçteki mevcut adımı işaretlemek için kullanılır.

Gerçekte Erişilebilirliğe Zarar Veren Yaygın ARIA Hataları

ARIA içeren sayfaların, ARIA içermeyenlere göre daha fazla erişilebilirlik hatası gösterme eğiliminde olduğu düşünüldüğünde, en sık nelerin yanlış gittiğini açıkça belirtmekte fayda var. Bunlar uç örnekler değil — her gün üretim kodunda görülen kalıplar.

Güçlü yerel anlamsal yapıya sahip öğelerde ARIA rolü kullanmak. Bazı HTML öğeleri, spesifikasyonun “güçlü yerel anlamsal yapı” dediği şeye sahiptir — tarayıcıya derinlemesine gömülü ve güvenle geçersiz kılınamayan anlamlar. Uygun olmayan bir rolü bir <button> veya <input> üzerine yerleştirmek, tarayıcının ARIA rolünü tamamen yok saymasına veya yardımcı teknolojileri şaşırtan çelişkili davranışlar üretmesine neden olabilir. Bildirdiğiniz rol, onu yerleştirdiğiniz öğe için uygun olmalıdır.

Widget rollerle klavye desteğini unutmak. ARIA’nın role='button' ifadesi, ekran okuyucuya öğenin bir buton olduğunu söyler. Öğeyi klavye ile çalışır hale getirmez. role='button' içeren bir <div> kullanıyorsanız, onu odaklanılabilir yapmak için tabindex='0' eklemeli ve hem Enter hem de Space tuşları için olay dinleyicileri eklemelisiniz. Bu parçaların herhangi birinin eksik olması, klavyeyle çalışan kullanıcılar için deneyimi bozar.

<!-- Incomplete and inaccessible -->
<div role='button' onclick='doSomething()'>Submit</div>

<!-- Correct custom button implementation -->
<div
  role='button'
  tabindex='0'
  onclick='doSomething()'
  onkeydown='if(event.key==="Enter"||event.key===" ")doSomething()'
>Submit</div>

<!-- Or, the right answer: just use a button -->
<button onclick='doSomething()'>Submit</button>

Odaklanılabilir öğelerde aria-hidden kullanmak. Odaklanılabilir bir öğeye aria-hidden='true' uygulamak, onu Erişilebilirlik Ağacı’ndan gizler ama klavye gezinmesinden gizlemez. Klavye kullanan bir kullanıcı hâlâ tab ile ona gelebilir, ama hakkında hiçbir bilgi alamaz ve ne yaptığını bilemez. Bu, WCAG 2.1’de 4.1.2 Başarı Kriteri (Ad, Rol, Değer) kapsamında bir başarısızlıktır.

Güncellenmeyen ARIA durumları. UI değiştiğinde aria-expanded, aria-checked, aria-selected ve benzeri durumları güncellememek, ekran okuyucu kullanıcılarına arayüz hakkında temelde yanlış bir resim sunar. Görsel olarak açılan ama tetikleyicisi hâlâ aria-expanded='false' okunan bir menü, aktif olarak yanıltıcıdır.

Gereksiz roller. Bir <nav> öğesine role='navigation' veya bir <button> öğesine role='button' eklemek hiçbir işe yaramaz. Kodu kalabalıklaştırır ve bazı yardımcı teknoloji kombinasyonlarını zaman zaman şaşırtabilir. Yerel anlamsal yapıya güvenin.

ARIA ve WCAG: Bağlantıyı Anlamak

ARIA, WCAG değildir. Birlikte çalışan ayrı spesifikasyonlardır. WCAG (Web Content Accessibility Guidelines), erişilebilir içerik için gerekli sonuçları — yani neyi — tanımlar. ARIA ise bu sonuçların bir kısmına ulaşmak için kullanılan teknik mekanizmalardan biri olarak nasıl kısmının parçasıdır. ARIA için en ilgili WCAG başarı kriteri, tüm kullanıcı arayüzü bileşenlerinin bir ada sahip olmasını, rollerini yardımcı teknolojilere açığa çıkarmasını ve durumlarını ve özelliklerini programatik olarak iletmesini gerektiren 4.1.2: Name, Role, Value’dır. ARIA, özel bileşenler için bu kriteri karşılamanın başlıca araçlarından biridir.

ARIA ayrıca birkaç başka başarı kriterini de destekler. Landmark roller, atlama navigasyonunu mümkün kılarak 2.4.1 (Bypass Blocks) kriterine katkıda bulunur. Live region’lar, odak almadan programatik olarak belirlenebilir olmasını gerektiren WCAG 2.1’deki 4.1.3 (Status Messages) kriterini karşılamak için genellikle doğru araçtır. aria-label ve aria-labelledby’nin doğru kullanımı, 2.4.6 (Headings and Labels) ve 1.3.1 (Info and Relationships) kriterlerinin karşılanmasına yardımcı olur.

WCAG uyumunun giderek artan biçimde yasal bir gereklilik haline geldiğini belirtmekte fayda var. European Accessibility Act, Haziran 2025’te tam olarak yürürlüğe girdi ve AB üye devletleri genelinde geniş bir özel sektör dijital hizmet yelpazesine zorunlu erişilebilirlik gereklilikleri getirdi. Amerika Birleşik Devletleri’nde ADA, web erişilebilirliğini kapsayacak şekilde yorumlanmaya devam ediyor ve Section 508 kapsamındaki federal gereklilikler, devlet kurumları ve federal fon alan kuruluşlar için geçerli. ARIA’yı doğru anlamak sadece iyi bir uygulama değil — giderek artan biçimde uyumluluk yükümlülüklerinizin bir parçası.

ARIA Uygulamanızı Test Etmek

ARIA uygulamanızın gerçekten çalışıp çalışmadığını bilmenin tek yolu, onu gerçek yardımcı teknolojilerle test etmektir. axe, WAVE ve Lighthouse gibi otomatik araçlar, eksik zorunlu özellikler, geçersiz roller veya odaklanılabilir bir öğeye uygulanmış aria-hidden gibi yapısal ihlalleri yakalayabilir — ancak bir ekran okuyucunun modal pencerenizi mantıklı bir şekilde duyurup duyurmadığını veya özel ağaç bileşeninizde klavye navigasyonunun beklenen desenleri takip edip etmediğini söyleyemezler.

Manuel test için kapsanması gereken başlıca ekran okuyucular, Windows’ta JAWS ve NVDA’dır (birlikte masaüstü ekran okuyucu kullanımının büyük çoğunluğunu temsil ederler) ve macOS ile iOS’ta VoiceOver’dır. TalkBack, Android’i kapsar. Her ekran okuyucu ve tarayıcı kombinasyonu farklı davranabilir, bu nedenle en az iki kombinasyon üzerinde test yapmak şiddetle tavsiye edilir. Her etkileşimli durumu test edin: diyalogu açın, akordeonu genişletin, seçeneği seçin, uyarıyı tetikleyin. Duyurunun, gören bir kullanıcının aynı arayüze bakarak anlayacağı şeyle eşleştiğini doğrulayın.

Özel bileşenleri test ederken, o bileşen türü için WAI-ARIA Authoring Practices Guide’da tanımlanan klavye etkileşim modelini adım adım uygulayın. Sekme listeniz ok tuşlarına yanıt vermiyorsa veya diyalog penceresi odağı tuzaklamıyorsa, ARIA işaretlemeniz otomatik bir denetimde ne kadar doğru görünürse görünsün bunlar birer başarısızlıktır.

Temel Çıkarımlar

• Her zaman ARIA’dan önce anlamsal HTML’yi tercih edin. <button>, <nav>, <main> ve <dialog> gibi yerel öğeler, ARIA eklenmiş div karşılıklarına göre daha sağlam ve çok daha az kod gerektiren yerleşik erişilebilirlik anlamsal yapısı taşır. Yerel HTML gerçekten yetersiz kaldığında ARIA’ya başvurun.
• ARIA roller bir kestirme değil, bir taahhüttür. Özel bir öğeye role='button' veya role='dialog' uygulamak, o widget türü için tam klavye etkileşim modelini uygulamayı taahhüt ettiğiniz anlamına gelir. Davranışla eşleşmeyen roller, kafa karışıklığına ve WCAG başarısızlıklarına yol açar.
• ARIA durumlarını UI’nizle senkronize tutun. aria-expanded, aria-checked, aria-selected gibi dinamik öznitelikler ve aria-live içeriği, UI değiştikçe JavaScript ile güncellenmelidir. Güncel olmayan bir durum aktif olarak zararlıdır — kullanıcıya yanlış bilgi iletir.
• Dinamik içerik güncellemeleri için live region kullanın. Sayfa yeniden yüklenmeden güncellenen tüm içerik — bildirimler, hata mesajları, yükleme durumları, sohbet akışları — ekran okuyucu kullanıcılarının, gören kullanıcıların otomatik olarak gördüğü aynı bilgiyi alabilmesi için bir aria-live bölgesine veya alert ya da status gibi uygun bir role ihtiyaç duyar.
• Sadece otomatik araçlarla değil, gerçek yardımcı teknolojilerle test edin. Otomatik tarayıcılar yapısal ARIA hatalarını yakalar, ancak uygulamanızın tutarlı ve kullanılabilir bir deneyim üretip üretmediğini doğrulayamaz. JAWS, NVDA ve VoiceOver ile yapılan manuel test, bu boşluğu kapatmanın tek yoludur.