Erişilebilirlik ağacı, tarayıcının HTML’den çıkardığı ve her etkileşimli öğenin rolünü, adını ve durumunu listeleyen sade bir sayfa haritasıdır; ekran okuyucular yirmi yıldır bu haritayı kullanır. Artık ChatGPT Atlas, Playwright MCP gibi yapay zeka ajanları da bir sayfayı büyük ölçüde bu haritadan okuyor; ağaçta adı olmayan bir buton, ajan için yoktur.
UX tasarımcısı Patrick Neeman (UX Collective), 12 Ekim 2026 tarihli yazısında bu tezi şöyle özetliyor: erişilebilirlik bir zamanlar ilkesel olarak savunulan küçük bir kitleye hizmet ediyordu, şimdi aynı yapı trafiğin büyük bölümünü oluşturan makinelerin de okuduğu yapı. Aşağıda iddiaları birincil kaynaklarla kontrol ettik ve sitenizi kendi başınıza nasıl test edeceğinizi adım adım çıkardık.
Yapay zeka ajanları bir web sayfasını nasıl okur?
Google’ın geliştirici rehberi web.dev‘e göre bir ajanın sayfayı algılamak için üç yolu var. Yetenekli ajanlar üçünü birlikte kullanıyor: yapıyı ağaçtan ve DOM’dan alıp, yerleşimi ekran görüntüsüyle doğruluyor.
Satıcıların hangi kanaldan başladığı farklı, ama yön aynı:
- Microsoft Playwright MCP: Bir modelin tarayıcıyı kullanmasını sağlayan resmi sunucu, README’sine göre ekran görüntüsü yerine “yapılandırılmış erişilebilirlik anlık görüntüleri” ile çalışıyor; görüntü modeline hiç ihtiyaç duymuyor.
- OpenAI ChatGPT Atlas: OpenAI’ın yayıncı ve geliştirici SSS’i, Atlas’ın sayfa yapısını ve etkileşimli öğeleri yorumlamak için ekran okuyucuların kullandığı ARIA etiketlerinden yararlandığını söylüyor ve site sahiplerine WAI-ARIA pratiklerini öneriyor.
- Google: web.dev rehberi, modern ajanların DOM, erişilebilirlik ağacı ve ekran görüntüsünü birlikte kullandığını; geliştiricilerin üçünde de temiz sinyal vermesi gerektiğini yazıyor.
Trafik tarafındaki ölçek de değişti. Search Engine Journal‘ın aktardığı Cloudflare Radar verisine göre 30 Mayıs – 5 Haziran 2026 haftasında HTML içeriğe gelen HTTP isteklerinin %57,2‘si otomatik botlardan, %42,8’i insanlardan geldi. Bu botların hepsi ajan değil; ama “makine okuru” artık kenar durum değil.
Klavyeyle bitirilemeyen görev, ajanla da bitmiyor
Erişilebilirlik her sayfada eşit önemde değil. Düzyazı ağırlıklı bir sayfada ajan, dağınık yapıya rağmen metni okuyabilir. Asıl risk ajanın bir şey yapması gereken yerde başlıyor: doğru butonu bulmak, alanı doldurmak, adımlar arasında yolunu kaybetmemek.
Bunu ölçen en somut çalışma, UC Berkeley ve Michigan Üniversitesi araştırmacılarının A11y-CUA veri seti (arXiv, 10 Şubat 2026; CHI ’26). Araştırmacılar bir bilgisayar kullanan ajanı (CUA) 60 gündelik görevde üç koşulda denedi. Klavyeyle sınırlanmak, ekran okuyucu kullanan birinin yoluna; büyüteç ise az gören bir kullanıcının görüş alanına karşılık geliyor.
Ders basit: klavye kullanıcısının takıldığı yerde ajan da takılır. Erişilebilir yapı “ajana hazırlık” için ayrı bir iş kalemi değil, işin kendisi. NN/g de 10 Nisan 2026 tarihli yazısında aynı sonuca varıyor: ajan, her işlevsel anlamda bir kullanıcı ve erişilebilirliğe yatırımın artık net bir iş gerekçesi var.
Web’in durumu: 2026’da erişilebilirlik altı yıl sonra ilk kez kötüleşti
WebAIM Million 2026 raporu, en popüler bir milyon ana sayfanın %95,9‘unda otomatik tespit edilebilen WCAG hatası buldu (2025’te %94,8). Sayfa başına ortalama hata 51’den 56,1‘e çıktı, ortalama sayfa 1.437 öğeye ulaştı. Ajanın ağaçta “boş” gördüğü öğelerin çoğu bu listede:
WebAIM bu kötüleşmeyi kısmen otomatik ya da yapay zeka destekli kodlama pratiklerine (“vibe coding”) ve üçüncü taraf kütüphanelere artan bağımlılığa bağlıyor; yapay zekanın ürettiği kodu doğrudan ölçmüyor. İroni ortada: sayfayı okuyamayan ajanlarla aynı dalga, okunamayan yapıyı üretmeye de yardım ediyor.
Önce neyi düzeltmeli? Dört kategori
Neeman’ın önerdiği sıralama, web.dev ve NN/g rehberleriyle örtüşüyor. Hepsi yıllardır bilinen erişilebilirlik işi; yeni olan, bunu harfiyen okuyan ikinci bir okurun gelmesi.
1. Semantik yapı ve landmark’lar
Yerel HTML öğeleri ağaçta kendini ek iş gerektirmeden tanıtır. Tıklama dinleyicisi takılmış bir <div> ise adsız, rolsüz bir kutudur. Başlıklar (h1 → h2 → h3, seviye atlamadan) ajana sayfanın taslağını, <nav>, <main>, <header> gibi landmark’lar hangi bölgede olduğunu söyler.
<!-- Ajan için adsız, rolsüz bir kutu -->
<div class="btn" onclick="sepeteEkle()"><svg>…</svg></div>
<!-- Ağaçta: button "Sepete ekle" -->
<button type="button" onclick="sepeteEkle()">
<svg aria-hidden="true">…</svg> Sepete ekle
</button>
<!-- Ağaçta: textbox "E-posta" — label ile input bağlı -->
<label for="eposta">E-posta</label>
<input id="eposta" type="email" autocomplete="email">2. Ad, rol ve durum
Ajanın kullanabileceği her kontrolün ağaçta bir adı, ne olduğunu söyleyen bir rolü ve değiştiğinde bir durumu (açık/kapalı, seçili) olmalı. Gerçek sayfaların çoğu burada çöküyor:
Yalnızca ikonlu butonlar: görünür etiket ya da aria-labelyoksa ağaçta boş bir “button”.- Hepsi “devamını oku” diyen bağlantılar: ajan hangisinin nereye gittiğini ayırt edemez. NN/g de “buraya tıklayın” türü belirsiz metinlerden kaçınmayı öneriyor.
- Genel markup’tan kurulmuş açılır menü ve modallar: ağaçta soru işareti olarak kalır.
Yerel öğe + görünür metin: <button>,<a href>,<select>ad ve rolü bedavaya getirir.
3. Metin alternatifleri ve etiketler
Alternatif metni olmayan bir görsel, ajan için ürün fotoğrafı mı logo mu grafik mi belli olmayan bir boşluktur; alt metinsiz bağlantılı görsel “hiçbir yere giden bağlantı” olur. Anlamlı görsellere gerçek alt metin, dekoratif olanlara boş alt="", her form alanına programatik bir <label>. web.dev de etiketleri for özniteliğiyle alanlara bağlamayı açıkça öneriyor.
4. Geri bildirim ve sabit yerleşim
Onay yalnızca görsel bir değişiklikse ajan hiçbir şey olmamış gibi davranır; sonuç, hata ve durum mesajları canlı bölgelerle (live region) ve yönetilen odakla ağaca ulaşmalı. Yerleşim de sabit kalmalı: web.dev, “Sepete ekle” butonunun ürün kategorileri arasında yer değiştirmemesini ve bir işlemi tamamlamak için gereken etkileşimli öğelerin görünür ve 8 piksel kareden büyük olmasını öneriyor.
ARIA yamayla değil, doğru HTML ile
ARIA, yerel HTML’in ifade edemediği boşlukları doldurmak için var. Ama W3C’nin ARIA kullanımının ilk kuralı açık: ihtiyaç duyduğunuz anlam ve davranışa sahip yerel bir HTML öğesi ya da özniteliği varsa, bir öğeyi ARIA rolüyle yeniden amaçlandırmak yerine onu kullanın. Yanlış ya da boş bir ARIA özniteliği ağacı boş bırakmaz; onu kendinden emin, yanlış bilgiyle doldurur.
Veri de bu uyarıyı destekliyor. WebAIM‘e göre 2026’da ana sayfaların %82,7’si ARIA kullanıyor ve sayfa başına ARIA özniteliği bir yılda %27 arttı. SEJ’nin aktardığı rapor verisine göre ARIA bulunan sayfalarda ortalama 59,1 hata, bulunmayanlarda 42 hata var. OpenAI’ın “ARIA ekleyin” tavsiyesini okurken bu farkı akılda tutun: önce doğru öğe, ARIA yalnızca boşluk için. Konuyla ilgili daha önce “Blocked aria-hidden” uyarısında yaygın yanlış çözümü ele almıştık.
Erişilebilirlik ağacı nasıl kontrol edilir? Chrome DevTools ile 5 adım
Bütün siteyi bir anda “ajana hazır” yapmaya çalışmayın. Ajanın bir şey yapması gereken akışları seçin (ödeme, rezervasyon, hesap değişikliği) ve önce onları okunur hale getirin. Kontrol için ek araç gerekmiyor:
- Elements panelini açın: Sayfada sağ tık → İncele (ya da F12) ile DevTools’u açın ve Elements panelinde test edeceğiniz öğeyi seçin.
- Accessibility sekmesine geçin: Sağdaki bölmede Accessibility sekmesini açın; görünmüyorsa More Tabs (») menüsünün arkasında olabilir.
- Tam ağacı açın: Show accessibility tree anahtarını açın. DOM ağacının yerini tam sayfa erişilebilirlik ağacı alır; istediğiniz an DOM görünümüne geri dönebilirsiniz.
- Ad, rol, durum okuyun: Computed Properties bölümünde seçili öğenin Name, Role ve Focusable değerlerine bakın. Name boşsa ajan o kontrolü tanımıyor demektir.
- Klavye testi: Aynı akışı yalnızca klavyeyle tamamlamayı deneyin. Bitiremediyseniz A11y-CUA verisi, ajanın da büyük olasılıkla bitiremeyeceğini söylüyor.
Okunur olmak onay vermek demek değil
Neeman yazısında kendi tezine karşı bir maliyeti de açıkça yazıyor: erişilebilir ve semantik olarak doğru bir sayfa, bir yapay zeka asistanının okuyup özetlemesi ve tıklama göndermeden cevap üretmesi için de en kolay sayfa. Okunurluk ajanı kazandırırken tıklamayı kaybettirebilir. Bu bozuk sayfa yayınlamak için bir gerekçe değil, ama gözler açık girilmesi gereken gerçek bir takas.
NN/g de ajanlara hizmet etmenin her iş modeli için doğru olmadığını, reklamla dönen siteler ya da rekabete duyarlı fiyatlama gibi durumlarda ajanları kısıtlamanın mantıklı olabileceğini; ama tamamen dışarıda kalmanın da kendi riskini taşıdığını yazıyor. Ayrım şu: semantik yapı her koşulda yardımcı teknoloji kullanan insanlar için gerekli; hangi ajana ne kadar kapı açacağınız ayrı bir iş kararı. Ajanların tasarım iş akışlarına girişini OpenAI dots ve Webflow’un MCP ile animasyon kuran ajanı yazılarımızda, arayüzün ajanlar karşısında nasıl değiştiğini ise Butonun Ölümü yazısında tartışmıştık.
Sık sorulan sorular
Erişilebilirlik ağacı nedir?
Tarayıcının DOM’dan türettiği, her öğenin rolünü (button, link, heading), adını ve durumunu içeren sadeleştirilmiş bir yapıdır. Ekran okuyucular sayfayı bu ağaç üzerinden okur; Playwright MCP gibi ajan araçları da sayfayı ekran görüntüsü yerine bu ağaçtan alır.
ChatGPT Atlas web sitemi nasıl okuyor?
OpenAI’ın yayıncı SSS’ine göre Atlas, sayfa yapısını ve etkileşimli öğeleri yorumlamak için ekran okuyucuların kullandığı ARIA etiketlerinden ve rollerinden yararlanıyor. OpenAI, butonlara, menülere ve formlara açıklayıcı rol, etiket ve durum eklemek için WAI-ARIA pratiklerini öneriyor.
Web sitemi yapay zeka ajanlarına nasıl uygun hale getiririm?
Yerel HTML öğeleri kullanın (div yerine button ve a), her kontrolü görünür bir adla etiketleyin, form alanlarını label ile bağlayın, görsellere alt metin verin ve yerleşimi sayfalar arasında sabit tutun. Ardından kritik akışı Chrome DevTools’taki erişilebilirlik ağacından ve yalnızca klavyeyle test edin.
ARIA eklemek ajan uyumluluğunu artırır mı?
Yalnızca yerel HTML’in karşılayamadığı boşlukta. W3C’nin ilk ARIA kuralı, yerel bir öğe varsa onu kullanmayı söylüyor; yanlış ya da boş ARIA ağaca yanlış bilgi yazar. WebAIM 2026 verisinde ARIA bulunan sayfalar ortalamada daha fazla hata içeriyor.
Erişilebilir site yapay zeka ajanları için gerçekten fark eder mi?
A11y-CUA çalışmasında aynı ajan 60 görevin %78,3’ünü normal koşulda tamamlarken, yalnızca klavyeyle sınırlandığında başarı %41,7’ye, büyüteç koşulunda %28,3’e düştü. Klavyeyle tamamlanamayan bir akış, ağaca dayanan bir ajan için de büyük olasılıkla tamamlanamaz.
Kaynaklar: Patrick Neeman (UX Collective); web.dev; A11y-CUA (arXiv:2602.09310); WebAIM Million 2026; Search Engine Journal; OpenAI Publishers and Developers FAQ; Microsoft Playwright MCP; NN/g; W3C Using ARIA; Chrome DevTools.
Bir Yorum Yazın