--- title: "ARIA nedir?" author: Androverse author_url: https://androverse.com.tr/yazar/androverse publisher: Androverse updated_at: 2026-10-15 url: https://androverse.com.tr/sozluk/aria language: tr --- # ARIA nedir? ARIA, arayüz öğelerinin rolünü, durumunu ve ilişkilerini yardımcı teknolojilere bildirmeye yarayan erişilebilirlik özellikleridir. Diğer adlar: Accessible Rich Internet Applications. ## Nerede işine yarar? Önce uygun yerel HTML öğesi seçilir; gereken bilgi zaten o öğede varsa yeniden rol verilmez. Özel kontrollerde rol kadar klavye davranışı ve ad da önemlidir. aria-expanded gibi durumlar, ekrandaki gerçek davranışla birlikte güncellenmelidir. ## Bir cümlede uygulaması Açılır menüyü açan düğmede aria-expanded değerini menünün açık durumuyla eşlemek. ## Neyle karıştırılmamalı? ARIA bir öğeye otomatik klavye davranışı kazandırmaz; davranış ayrıca uygulanır ve test edilir. ## Bir rol, davranışın yerine geçmez Bir açılır içerik kontrolü düşünelim. Kullanıcı başlığa basıyor, altında açıklama açılıyor. Görsel olarak açık ve kapalı hali belirgin olabilir; yardımcı teknoloji kullanan kişinin de kontrolün adını ve durumunu anlayabilmesi gerekir. ARIA, gerekli rol, durum ve özellik bilgisini erişilebilirlik ağacına aktarmaya yarayan nitelikler sunar. Ancak açılma, kapanma veya klavye davranışını kendiliğinden yazmaz; bu davranışın uygun biçimde uygulanması gerekir. Örnek bir hatada geliştirici sıradan bir kapsayıcıya düğme rolü verir, fakat klavye etkileşimini eklemez. Ekran okuyucu bu öğeyi düğme olarak duyurabilirken klavye kullanan kişi beklediği işlemi yapamaz. W3C APG’nin vurguladığı ilke burada önemlidir: yanlış kullanılan ARIA, verdiği bilgi ile gerçek davranış arasında uyumsuzluk yaratabilir. Uygun yerel HTML öğesi varsa önce onun sağladığı anlam ve davranış değerlendirilir. Bu nedenle ARIA’yı sayfaya serpiştirilecek erişilebilirlik süsleri gibi kullanmayız. Her niteliğin hangi bilgi eksikliğini tamamladığını sorarız. Kontrolün görünür adıyla erişilebilir adı uyumlu mu? Açık durum değişince aktarılan durum da güncelleniyor mu? Gizli içerik yanlışlıkla erişilebilir kalıyor mu? Bu sorular, kodun yalnız sözdizimi açısından doğru olmasından daha geniş bir davranış incelemesi gerektirir. Tasarım ile geliştirme arasında da bu bilginin paylaşılması gerekir. Bir menünün yalnız görüntüsü teslim edilirse hangi öğenin kontrol, hangisinin bağlantı ve hangisinin başlık olduğu belirsiz kalabilir. Tasarım notuna davranış ve durum eklemek, uygun örüntünün seçilmesini kolaylaştırır. Her özel bileşen yeni bir sorumluluk getirir: adı, rolü, durumu, klavye kullanımı ve odak yönetimi aynı deneyimin parçaları olarak düşünülmelidir. Canlı güncellenen içerikte de ölçülü davranmak gerekir. Her küçük görsel değişikliği yardımcı teknolojiye duyurmak, kullanıcının okumaya çalıştığı bilgiyi sürekli bölebilir. Önemli işlem sonucu ile dekoratif değişikliği ayır; neyin ne zaman bildirileceğini kullanılan örüntü ve gerçek ihtiyaç üzerinden belirle. Bir formun sonucu, arama filtresinin etkisi veya hata durumu farklı öncelikler taşıyabilir. Burada amaç mümkün olan en çok mesajı üretmek değil, kişinin gerekli değişimi anlamasını sağlamaktır. Duyurulan bilgi görünür içerikle tutarlı olmalı ve kullanıcıyı ilgisiz teknik ayrıntılarla meşgul etmemelidir. Dinamik arayüzün sözlü karşılığı da tasarımın bir parçasıdır. ### Yerel öğe Önce mevcut HTML öğesinin ihtiyacı karşılayıp karşılamadığına bak. Bir işlem için gerçek düğme, gezinme için gerçek bağlantı kullanmak birçok temel davranışı doğru zemine oturtur. Özel kontrol gerekiyorsa bunu bilinçli seç; yerel öğeyi yalnız görünümünü beğenmediğin için terk etme. ### Ad ve durum Kontrolün erişilebilir adı ne yapacağını anlatmalı, durumu ise gerçek görünüm ve davranışla eşleşmeli. Açılıp kapanan yüzeyde durum güncellemesini unutmak yanlış bilgi aktarır. Etiketin görünür metinle ilişkisini koru; kullanıcıların farklı yöntemlerle aynı kontrolü tanıyabilmesi önemlidir. ### Davranış Bir rolün beklenen etkileşimleri olduğunu unutma. Rol eklemek gerekli olayları ve odak yönetimini otomatik kurmaz. Kullanılan örüntünün resmi davranış açıklamasını incele, sonra gerçek bileşeni uygun yöntemlerle değerlendir. Yalnız DOM’da niteliğin bulunması, işlevin kullanılabilir olduğunu göstermez. ## HTML semantiği ve ARIA ### Yerel anlam HTML’nin anlamlı öğeleri içerik ve kontroller için yerleşik bir temel sunar. Düğme, bağlantı, başlık ve form alanı gibi öğeler doğru amaçla kullanıldığında tarayıcıya ve yardımcı teknolojilere bilgi verir. Görsel stiller bu öğeleri markaya göre şekillendirebilir; anlamlı yapıyı kaybetmek zorunda değildir. ### Gerekli ek bilgi ARIA, yerel yapı tek başına yeterli olmadığında veya dinamik durumların aktarılması gerektiğinde kullanılabilir. Bu kullanım gerçek davranışla birlikte tasarlanır. Gereksiz roller eklemek, doğru yerel anlamı geçersiz kılabilir veya çelişkili bilgi oluşturabilir. En çok nitelik eklenen bileşen, otomatik olarak en erişilebilir bileşen değildir. ## Yerel HTML davranışını korumak ARIA, erişilebilirlik ağacına ad, rol ve durum bilgisi taşır; eksik etkileşimi kendi başına yazmaz. Bir öğeye düğme rolü vermek klavye davranışını otomatik eklemez. Uygun yerel HTML öğesi kullanılabiliyorsa önce onun sağladığı davranış değerlendirilir. - Önce doğru HTML öğesini seç. - Görünür etiket ile erişilebilir adı uyumlu tut. - Açık, seçili ve devre dışı durumlarını gerçek davranışla eşleştir. ## Daha fazla ARIA daha iyi mi? Hayır. Yanlış veya gereksiz ARIA yerel anlamı bozabilir. Bir metin alanının adı ve bir açılır kontrolün durumu gibi gerçek ihtiyaçlar karşılanmalı; uygulama ekran okuyucu ve klavyeyle denenmelidir. ## Bu karar, işinin neresinde? ARIA kavramının bir projede nasıl ele alındığını; yaklaşım, süreç ve teslimler üzerinden incele. [Web tasarım & yazılım](https://androverse.com.tr/hizmetler/web-tasarim-yazilim) ## Karar masası ### Her öğeye aria-label eklemek yararlı mı? Hayır. Görünür ve doğru ilişkilendirilmiş metin zaten yeterli ad sağlayabilir. Gereksiz ek etiketler farklı veya tekrar eden bir anlam oluşturabilir. Önce kontrolün erişilebilir adının nereden geldiğini anla. Görsel simge tek başına eylemi ifade ediyorsa bir ad gerekebilir, fakat bu ad gerçek eylemi anlatmalıdır. Kullanıcının gördüğü ve yardımcı teknolojinin duyurduğu bilgi arasında gereksiz fark yaratmaktan kaçın. ### Gizli bir panel için neye bakılır? Panel kapalıyken içindeki kontrollerin yanlışlıkla odak alıp almadığı ve yardımcı teknolojiler tarafından nasıl sunulduğu değerlendirilir. Kullanılan gizleme yöntemi, animasyon ve odak davranışı birlikte düşünülmelidir. Bir niteliği ekleyip bütün sorunun çözüldüğünü varsayma. Panel açıldığında ve kapandığında hangi kontrolün kullanılacağı açık olmalı. Özellikle odak panel içindeyken kapanması halinde anlamlı bir dönüş planlanmalıdır. ### APG örneğini kopyalamak yeterli mi? Örnekler bir örüntünün nasıl çalışabileceğini öğretir, ancak ürünün bağlamına doğrudan uygunluk garantisi vermez. İçerik, tarayıcı, yardımcı teknoloji ve özel davranışlar sonucu etkileyebilir. Örneğin hangi sorunu çözdüğünü ve sınırlarını oku. Ürüne uyarlarken klavye davranışını veya durum ilişkilerini yanlışlıkla kaldırmamaya dikkat et. Sonuç gerçek bileşen üzerinde değerlendirilmelidir; kaynakta bir örneğin bulunması uygulamanın doğru olduğunu tek başına kanıtlamaz. ## Bir açılır kontrolün sözünü kontrol et Sitedeki içerik açan bir kontrolü seç. Görünürde ne yaptığını, kodda hangi role sahip olduğunu ve yardımcı teknolojiye hangi durumun aktarıldığını ayrı notlara yaz. Üçü aynı davranışı anlatmalı. - [ ] Kontrolün yerel öğesini belirle. Gerçek bir düğme olması gereken yerde yalnız tıklama olayı eklenmiş kapsayıcı varsa neden böyle seçildiğini sor. Stil gereksinimiyle davranış gereksinimini ayır. Mümkünse yerel semantiği koruyan en küçük ve anlaşılır çözümü tercih et. - [ ] Açık ve kapalı durumdaki adı ve durum bilgisini incele. Görsel işaret değişirken aktarılan bilgi sabit kalıyor mu? Etiketin hangi hedefe ait olduğunu anlamak için gerekli ilişki var mı? Aynı isimli birden çok kontrol varsa bağlamın onları ayırt etmeye yetip yetmediğini düşün. - [ ] Klavye ile aç, içerikte ilerle ve kapat. Odağın nerede kaldığını kaydet. Beklenen davranışı kullanılan örüntünün resmi rehberiyle karşılaştır. Bütün açılır yüzeylere aynı klavye kuralını zorlamadan, kontrolün gerçek türüne uygun davranışı belirle. - [ ] Bulduğun farkı yalnız eksik nitelik listesi olarak yazma. Kullanıcının ne duyduğu, ne yapabildiği ve ne beklediğini birlikte anlat. Böylece düzeltme yapan kişi sorunun anlamını görür. Değişiklik sonrasında gerçek akışı yeniden değerlendirmek gerektiğini not et. ARIA bir erişilebilirlik etiketi değil, gerçek arayüz davranışı hakkında verilen bilgidir. Bu bilgi doğru, gerekli ve davranışla uyumlu olduğunda işe yarar. Yerel HTML anlamı sağlam bir başlangıçtır. ## Bağlantılı kavramlar - [Semantik HTML](https://androverse.com.tr/sozluk/semantik-html) — Semantik HTML, içeriğin yapısını ve işlevini uygun HTML öğeleriyle ifade etmektir. - [Klavye odağı](https://androverse.com.tr/sozluk/klavye-odagi) — Klavye odağı, o anda klavye girdisini alacak etkileşimli öğenin seçili durumudur. - [Erişilebilirlik](https://androverse.com.tr/sozluk/erisilebilirlik) — Erişilebilirlik, farklı yetileri ve yardımcı teknolojileri olan insanların bir içeriği algılayabilmesi, kullanabilmesi ve anlayabilmesi için tasarlamaktır. ## Konuyu uygulamaya taşı - [Web tasarım & yazılım](https://androverse.com.tr/hizmetler/web-tasarim-yazilim) — ARIA kavramının bir projede nasıl ele alındığını; yaklaşım, süreç ve teslimler üzerinden incele. - [Menüyü bulmak bir yetenek değil.](https://androverse.com.tr/blog/menuyu-bulmak-bir-yetenek-degil) — ARIA ile ilgili tasarım kararını Androverse’nin uygulama örnekleri ve değerlendirme sorularıyla birlikte düşün. ## Kaynaklar - [W3C WAI — ARIA Authoring Practices](https://www.w3.org/WAI/ARIA/apg/) [Androverse profili](https://androverse.com.tr/yazar/androverse) · [Yayın ilkeleri](https://androverse.com.tr/yayin-ilkeleri)