Alt metin neden otomatik kontrolden fazlasını gerektiriyor?

Alt metin kalitesi neden önem taşıyor?

Bir görselin ne anlattığını metinle ifade eden HTML özniteliği olan alt metin, erişilebilir web deneyiminin temel parçalarından biri. Ancak alt metin kalitesi, alanda bir metin bulunup bulunmadığından daha geniş bir mesele: Bir görsel için açıklama eklenmiş olması, bu açıklamanın kullanıcıya yararlı bilgi verdiği anlamına gelmiyor.

GitHub’ın aktardığı 2026 WebAIM Million raporuna göre, en popüler bir milyon ana sayfadaki görsellerin yüzde 16,2’sinde alt metin yok. Alt metin bulunan görsellerin yüzde 10,8’inde ise “image” gibi açıklayıcı olmayan ifadeler, ham dosya adları ya da yakındaki bir görselden tekrarlanan açıklamalar yer alıyor. Bu tablo, otomatik denetimlerin yakaladığı eksiklerle insan deneyimini etkileyen açıklama niteliğinin aynı problem olmadığını ortaya koyuyor.

Otomatik araçların temel sınırı

Otomatik araçlar, alt metnin hiç yazılmadığını güvenilir biçimde saptayabiliyor. Buna karşılık, bir açıklamanın görseli ve kullanıldığı bağlamı yeterince anlatıp anlatmadığını yalnızca işaretleme diline bakarak kesin şekilde ölçmek zor. Çünkü bir metnin yararlılığı çoğu durumda görselin kendisine ve çevresindeki içeriğe bağlı.

Bu ayrımın pratik sonucu açık: alt="IMG_2847.png" gibi bir dosya adı, teknik olarak erişilebilir ad alanını doldurduğu için kontrolden geçebilir. Beş yıldız biçimli simgede aynı “3/5 stars” açıklamasının tekrar edilmesi de benzer biçimde geçebilir. Metnin mevcut olması ile anlamlı olması, otomatik denetim açısından ayrı eşiklerdir.

GitHub’ın vurguladığı gibi, kalite odaklı ancak sık yanlış pozitif üreten kurallar ekipler tarafından kapatılabilir. Bu nedenle denetim aracının her kötü açıklamayı bulmaya çalışması, güvenilir uyarılar vermesinden daha iyi bir sonuç olmayabilir.

GitHub’ın alt metin kalitesi yaklaşımı

GitHub, GitHub Accessibility Scanner için bir alt metin eklentisi geliştirdi. Eklentinin tasarımı iki katmana dayanıyor: Görselin içeriğine ihtiyaç duymadan alt metin dizgesi üzerinden doğrulanabilen sorunlar ve ancak görsel ile çevresindeki bağlam değerlendirilerek ele alınabilecek durumlar.

Varsayılan olarak çalışan beş belirleyici kural, ağ çağrısı ya da yapay zekâ modeli çalıştırmak için kimlik bilgisi gerektirmiyor. Bu kurallar, bir alt metin dizgesinin nesnel olarak sorunlu olup olmadığını inceliyor. İsteğe bağlı bir kural ise görsel içeriği ve çevredeki bağlam sağlandığında bir modele başvuruyor. Böylece dizgenin tek başına cevaplayamayacağı değerlendirmeler için farklı bir yol sunuluyor.

Hangi sorunlar metne bakılarak saptanabilir?

GitHub’ın ayırdığı ilk grupta, alt metnin kendisine dayanarak tespit edilebilecek durumlar var. Alt özniteliğinin bulunmaması, boşluk karakterlerinden oluşması, “hero.png” veya “IMG_2847.jpg” gibi bir dosya adı içermesi bunlardan bazıları. “TODO” ya da “tbd” gibi sonradan değiştirilmek üzere bırakılmış yer tutucular da bu gruba giriyor.

Tek başına içerik söylemeyen “image”, “logo” ve “chart” gibi genel ifadeler de denetlenebiliyor. Yakın konumdaki görsellerde aynı alt metnin tekrarlanması da dizgeler karşılaştırılarak belirlenebilen başka bir durum. Bu kontrollerin ortak noktası, görselin ne gösterdiğine dair tahminde bulunmadan, metin hakkında doğrulanabilir bir iddia kurmaları.

Boş alt metin neden hata sayılmıyor?

Tarayıcının önce hangi görselleri değerlendireceği de önemli bir karar. GitHub, sayfadaki img etiketlerinin tümünü doğrudan seçmek yerine Playwright’ın rol tabanlı konumlandırıcısını kullanıyor. Bu yöntemle tarayıcının erişilebilirlik ağacında yer almayan öğeler kapsam dışı kalıyor.

Buna alt="" taşıyan görseller de dahil. Boş alt metin, yazarın görseli dekoratif olarak işaretlediğini ifade ediyor. GitHub’a göre bunu uyarıya dönüştürmek, erişilebilirlik için teşvik edilmesi gereken bir uygulamayı cezalandırmak olurdu. Dolayısıyla denetim, açıklama yazılmamış her örneği aynı kategoride ele almıyor; dekoratif olarak açıkça tanımlanan görselleri ayırıyor.

Neden dar ve kesin kurallar tercih ediliyor?

GitHub’ın belirsiz alt metin kuralı, metni normalleştirdikten sonra tek başına bilgi taşımayan sözcüklerden oluşan seçilmiş bir listeyle karşılaştırıyor. Kural yalnızca tam eşleşmede çalışıyor. Örneğin alt="image" uyarı alırken, “image of the login screen with the SSO button highlighted” gibi daha açıklayıcı uzun bir ifade almıyor.

Bu yöntem, kötü yazılmış pek çok alt metni kaçırabilir. Buna rağmen tercih edilen yön, daha fazla örneği yakalamak için tahmine dayalı davranmak değil; yanlış pozitif ihtimalini düşük tutmak. Erişilebilirlik kontrollerinde bu, aracın hangi hatayı gerçekten bildiğini anlaşılır kılan bir denge: Kuralın kapsamadığı her zayıf açıklama kabul edilebilir değildir, yalnızca o kuralın kesin olarak kanıtlayamadığı bir durumdur.

İnsan değerlendirmesi ve model destekli kontrol

Bir alt metnin görseli yeterince betimleyip betimlemediği, yalnızca metne bakılarak her zaman çözülemez. GitHub’ın isteğe bağlı model kuralı bu boşluğu hedefliyor; görsel içeriğini ve onu çevreleyen bağlamı kullanarak, dizge denetiminin sınırında kalan örnekleri değerlendirmeye açıyor.

Buradaki temel ayrım, modelin ya da otomatik aracın her durumda kesin karar verebildiği iddiası değil. Eklentinin yaklaşımı, kanıtlanabilen metin hatalarını varsayılan, belirleyici kurallarla ele alırken; görsel anlayışı gerektiren kalite sorularını ayrı ve isteğe bağlı bir değerlendirme olarak konumlandırıyor. Alt metin yazımında da asıl ders bu ayrımda yatıyor: Kontrolü geçmek başlangıç noktası olabilir, fakat yararlı bir açıklama için görselin neyi ilettiğini ve sayfada neden bulunduğunu hesaba katmak gerekiyor.