Haberler

Aktif projeler

Son güncelleme: 31 Ekim 2026

Devam ediyor

v3: Eksiksiz bir kalite güvence paketi

27 Eylül 2026

DrupalCon Europe 2026'da tanıtıldı

Öne çıkan yeni özellikler

• Test çekirdeği Sa11y ile birleştirildi. Birlikte geliştirilen yeni kural kümesi, temel içerik testi kural kümesine geliştirici testleri, kontrast denetimi ve okunabilirlik puanlaması ekliyor.
• Çok dilli destek
• Özel kontrol oluşturucu
• Kontrol paneli bakım araçları
• Yeni sonuçlar eklemek için bir site tarama aracı.
• Belirli testler için (bu PDF erişilebilir mi?) belirli rollerin uyarıları site genelinde kapatmasına olanak tanır.
• Ayrılmış yapılandırma: geliştirici ve içerik rollerine göre ayrı testler ve rapor görünümleri.

Ve projenin geleceği açısından belki de en önemlisi:

• Bu sponsor kuruluşu kurmak, mevcut kullanıcıları desteklemek ve gelecekteki proje fikirleri üzerindeki çalışmaları finanse etmek için bir hibe alındı.

v2: Kapatmalar ve raporlar

2 Mart 2023

İki yıl önce, yazarlara anında otomatik geri bildirim ve içeriklerini iyileştirmeye yönelik yararlı ipuçları sunan, Drupal için kurulup hemen kullanılabilen bir site eklentisi olarak Editoria11y erişilebilirlik denetleyicisini tanıttık.

Bunun karşılanmamış bir ihtiyacı gidereceğini düşünüyorduk. Mevcut seçeneklerin tümü, işe yarayabilmek için eğitim ve özenli kullanım gerektiriyordu; deneyimlerimiz de büyük bir kurumda binlerce içerik yazarını eğitmeye ve izlemeye çalışmanın soruna yaklaşmanın verimli bir yolu olmadığını göstermişti. Bir programın başarılı olması için yüksek düzeyde otomasyona sahip olması ve yaygın hataları tespit ettiğinde içerik yazarlarına kibarca “tam zamanında eğitim” sunması gerektiğinden emindik.

İşe yaradı.

Princeton'da iletişimlerimin yönünü büyük ölçüde tersine çevirdi. Kurulu olduğu platformlarda, içerik yazarlarına alternatif metin, bağlantı veya başlık iyileştirmeleri isteyen, birbirinin aynı e-postalar göndermekten, içerik yazarlarından metinlerinin bu kadar sık işaretlenmemesi için yazılarını nasıl iyileştirebileceklerine dair sorular almaya geçtik.

Dışarıdan gelen tepki ise coşku oldu:

Kendi içinde eksiksiz ipuçları yazmak

v1 ipuçlarında “özet ve ayrıntılar” yaklaşımını benimsedik: sorunun kısa bir açıklaması ve ayrıntılar için bir bağlantı.

Bu, geliştiriciler için yazılmış araçlara göre bir gelişmeydi: ipuçları kısa ve açıktı. Ancak nereye bağlantı verileceği kararı hep sorun oldu. Bazı kamu kurumu ve yükseköğretim kullanıcıları, Princeton'ın belgelerine verilen bağlantıları kaldırmak için ipuçlarını değiştirme gereği duydu; bu da onlara ek iş çıkardı. Biz de varsayılan ipuçlarını, satır içi örnekler içeren ve kendi içinde eksiksiz olacak şekilde yeniden yazdık.

Kırmızı uyarılar (kesin sorunlar) ile sarı uyarılar (olası sorunlar) arasındaki ayrım kafa karıştırıcı, zaman zaman da can sıkıcı oldu.

Bu yüzden sarı uyarıları, anlamlarını netleştirmek için “manuel kontroller”e dönüştürdük ve yazarların uyarıları kapatabilmesi için düğmeler ekledik. “Yok sayılan” uyarılar yalnızca düğmeye tıklayan kişi için gizlenir; “Tamam olarak işaretlenen” uyarılar ise tüm site editörleri için gizlenir. Site yöneticileri, bunların her birini kimin yapabileceğini seçebilir.

Kontrol paneli oluşturmak

Site sahiplerinin sık dile getirdiği bir yakınma, aracın sitenin her yerindeki sorunları bulmada çok başarılı olduğu, ancak site genelinde bir rapor görüntülemenin hiçbir yolu bulunmadığıydı.

Yeniden yazım, bulguları sitenin veritabanına senkronize etme seçeneği ekliyor. Site sahipleri artık bulgulara sayfaya veya soruna göre göz atabilir, hangi sorunların yok sayıldığını veya Tamam olarak işaretlendiğini inceleyebilir; aynı fikirde değillerse de sorunu geri yükleyebilir!

Geliştiriciler için V2 kod turu

V2 neredeyse baştan sona yeniden yazıldı. Yeni özelliklerden bazıları:

• jQuery bağımlılığının kaldırılması, daha fazla platforma kurulabilmesini sağlıyor ve performansı 2 kat artırıyor.
• Denetleyici artık sayfanın birbirinden bağımsız birden çok bölümüne bakacak şekilde yapılandırılabiliyor (ör. makale içeriği ve sayfa altbilgisi).
• Denetleyici artık çeşitli Web bileşenleri ve JavaScript kütüphaneleri tarafından kullanılan gölge DOM içindeki öğeleri test edebiliyor.
• Birçok yeni parametre platform entegrasyonlarını kolaylaştırıyor. Örneğin belirli kullanıcılar, içeriğinden sorumlu olmadıkları ancak sonuçlarını yine de istek üzerine görüntülemek isteyebilecekleri belirli sayfalarda tüm sorunları otomatik olarak yok sayabiliyor.
• Denetleyici artık birden çok temel temayla ve renkleri özelleştirmeye yarayan parametrelerle birlikte geliyor.
• Otomatik testler kod gerilemelerini önlemeye yardımcı oluyor.

2024 A11yTalks

11 Haziran 2024

Drupal GovCon 2023

27 Ekim 2023

DrupalCamp NJ 2023

28 Mart 2023

v1: Satır içi yardım

11 Mart 2021

Yüksek düzeyde erişilebilir Web içeriği oluşturmak karmaşık bir iştir ve genellikle yoğun bir eğitimle başlar.

Alışılmış uygulamalardan uzaklaşılmalıdır:

• Tablolar sahte sütunlar oluşturmak için kullanılmamalıdır
• Akan metin ortalanmamalı veya iki yana yaslanmamalıdır
• Anlam aktarmak için yalnızca görsel biçimlendirmeye (yazı tipi kalınlığı ve boyutu) güvenilmemelidir; çünkü kullanıcılar içeriği dinliyor veya “okuyucu modunda” görüntülüyor olabilir

Yeni uygulamalar teşvik edilmelidir:

• Görsellerin bağlama uygun, anlamlı alternatif metne ihtiyacı vardır
• Sayfaların gerçek bir yapıya ihtiyacı vardır
• Bağlantıların anlamlı başlıkları olmalıdır

Eğitimlerimizin bir kısmı elbette yeni kavramlar öğrettiğimiz için düzenleniyor; ancak bir noktada şu soruyu sormak gerekir: yeni becerilere duyulan ihtiyacın ne kadarı kavramların yeni olmasından, ne kadarı araçlarımızı güncellemeden yeni beklentiler ortaya koymamızdan kaynaklanıyor? Bir şeyin yeni olması, sezgisel olamayacağı anlamına gelmez.

Yazımın tarihinden dersler

1. Aşama: Yazarı suçla

Yazılı tarihin başlangıcından 1980'lerin başına kadar, bir sözcük yanlış yazıldığında yazarı suçladık. Doğru yazmayı öğrenme sorumluluğu yazardaydı.

Peki insanlar yazımlarını nasıl geliştiriyordu? Bu size tanıdık gelecek:

1. Özel öğretmenlerin yanında veya sınıfta eğitim alıyorlardı
2. Kendilerine çalışmaları için listeler, kılavuzlar ve sözlükler veriliyordu; bunların geçmişi kile kazınmış antik çivi yazısı sözlüklere kadar uzanıyordu.

2. Aşama: Sözlüğü suçla

Ancak 1980'lerde bir şey değişti: buna “yazımın 2. aşaması” diyelim. En popüler kelime işlem programları yazım denetimini devreye aldı.

Peki suçlama oyununa ne oldu? Neredeyse bir gecede suç araca kaydı:

• Bir sözcüğün nasıl yazıldığını bilmiyor musunuz? Tahminde bulunun ve bir eşleşme çıkmasını umun. Çıkmazsa sözlüğü suçlayın.
• Sözlüğün tanımadığı için işaretlediği gerçek bir sözcük mü kullandınız? Söylenin, sonra da alt çizgiyi yok saymaya veya sağ tıklayıp sözcüğü sözlüğe eklemeye karar verin.

Yazım denetimi tüm yazım hatalarımızı düzeltti mi? Elbette hayır. Ama yardımcı oldu. Ayrıca yükün ve sorumluluğun büyük bölümünü yazardan makineye aktardı.

Ama bu, son değildi…

3. Aşama: Yazma aracını suçla

Son yıllarda bir adım daha atıldı: bilgisayarlar bizim yerimize yazmaya başladı:

• Tahmine dayalı algoritmalar bir sonraki sözcüğü, bir sonraki ifadeyi, hatta belki de kısa mesaj yanıtının tamamını tahmin etmeye çalışıyor.
• Otomatik biçimlendirme araçları yıldızları, sayıları ve harfleri listelere, kısa kodları özel karakterlere ve emojilere vb. dönüştürmeye çalışıyor.
• Dikte araçları, eş sesli sözcükler arasında seçim yapmak için kavramları tanımaya çalışıyor.

Peki bu işler ters gittiğinde suç kimin oluyor? Aracın!

Sosyal medya toplayıcıları o utanç verici “Öyle demek istememiştim!” ekran görüntülerine bayılıyor.

Editoria11y, 2. aşamaya doğru atılmış bir adım

Eğitimlerimizde test etme konusuna çok zaman ayırıyor ve oldukça iyi birkaç test aracını tanıtıyoruz. Bunların hiçbiri her şeyi yakalayamaz: “kavramları renk veya konum göndermeleriyle açıklamaktan kaçınmak” gibi hususların bir insan tarafından kontrol edilmesi gerekir; araçlar genellikle bir sitedeki gerçek sorunların yarısından biraz azını yakalar. Yine de araçlar, editoryal içerikteki pek çok yaygın hatayı yakalamakta oldukça başarılıdır.

Ancak üç sorun var:

1. Çoğu manuel araçtır. İçerik oluşturucunun bunları kullanmayı öğrenmiş olması, içeriğini yazarken var olduklarını hatırlaması ve işi bittiğinde çalıştırmayı unutmaması gerekir. Bu üç hata noktası, içeriğin büyük bir kısmının (çoğunun mu?) denetlenmeden kalması için el birliğiyle çalışır.
2. Çok fazla şeyi işaretlerler. Yalnızca yazarın az önce yaptığı hataları değil; tasarımcının yaptığı renk sorunlarını, geliştiricinin yaptığı teknik sorunları, bilgilendirme amacıyla yapısal öğeleri vb. de işaretlerler. Bu da eğitimlerin çıtasını yükseltir: yazarların yalnızca aracı anlaması yetmez, yanlış pozitiflerden veya gayet gerçek olmakla birlikte bugün, tam da bu makaleyi yazarken düzeltmek kendi sorumlulukları olmayan şeylerden oluşan bir listeyi yok saymayı da öğrenmeleri gerekir.
3. Otomatik araçlar genellikle “siteyi tara, kontrol panelini ziyaret et” paradigmasına sahiptir. Yine: bu, yazarın kontrol panelini ziyaret etmesi için eğitildiğini ve bunu yapmayı hatırlayacağını varsayar.

Bu yüzden Princeton yeni bir şey yapmaya girişti: yalnızca yaygın editoryal hatalara bakan, web sitesine entegre, otomatik bir denetleyici.

Otomatik olmak… zor.

1. Otomatik denetleyiciler ölçülü olmalıdır: fazla ısrarcı olurlarsa yazarın işini böler ve onu sinirlendirirler. Fazla kibar olurlarsa kolayca göz ardı edilen bir arka plan gürültüsüne dönüşebilirler.
2. Otomatik denetleyiciler yüksek performanslı olmalıdır: çalışırken sayfa titrer veya takılırsa yazarlar onlardan rahatsız olur ve onları devre dışı bırakır.
3. Otomatik denetleyiciler yeni başlayanlara uygun ipuçları sunmalıdır. Birçok yazar, içeriklerini daha erişilebilir kılacak etiketleme, yapı ve dil konularını ilk kez burada duyacaktır. Uyarılar, içeriği iyileştirmek için pratik öneriler içeren, basit ve teknik olmayan bir dille yazılmalıdır.

Biz de bu hedeflere bulabildiğimiz en yakın araçla başladık: Toronto Metropolitan University çıkışlı Sa11y. Onun test mimarisini ve kullanıcı dostu “ipuçlu bilgi paneli” yaklaşımını aldık; ardından testlerin her zaman otomatik çalışması için aracı uyarlamaya, performansını optimize etmeye, ipuçlarında ince ayar yapmaya ve bir geliştiricinin aracı herhangi bir platforma hızla uyarlamak için kullanabileceği uzun bir yapılandırma seçenekleri listesi oluşturmaya yarım yıl harcadık.

Bugün şöyle görünüyor:

Bir yazar sitesinde oturum açtığında, Editoria11y'nin açma/kapama düğmesi her sayfadaki sorunların sayısını ve türünü (geçti, manuel kontrol gerekiyor, olası sorunlar bulundu) gösterir. Tıklayarak satır içi vurgulamaları ve ipuçlarını görebilirler. Hata yeniyse, yani yazar az önce düzenlediği bir sayfaya bakıyorsa, panel otomatik olarak açılır.

Mart 2021 itibarıyla bu, 400'den fazla Princeton web sitesinin şunları otomatik olarak denetlediği anlamına geliyor:

• İyi bir belge ana hattı
  • Atlanan başlık seviyeleri
  • Boş başlıklar
  • Çok uzun başlıklar
  • Aslında başlık olabilecek, şüphe uyandıracak kadar kısa blok alıntılar.
• Metin alternatifleri
  • Alternatif metni olmayan görseller
  • Alternatif metni dosya adı olan görseller
  • Alternatif metni çok uzun olan görseller
  • “… görseli” veya “… fotoğrafı” gibi gereksiz sözcükler içeren alternatif metinler
  • Alternatif metni bağlantı hedefini değil görseli tanımlıyor gibi görünen, bağlantı içindeki görseller
  • Genellikle metin alternatifi gerektiren gömülü görselleştirmeler
• Anlamlı bağlantılar
  • Metni olmayan bağlantılar
  • Başlığı dosya adı olan bağlantılar
  • Başlığı yalnızca genel ifadelerden oluşan bağlantılar: “buraya tıklayın”, “daha fazla bilgi”, “indir” vb.
  • Dış bağlantı simgesi olmadan yeni pencerede açılan bağlantılar
• Genel kalite güvencesi
  • Yıldız, sayı ve harf yerine liste biçimlendirmesi kullanıldığından emin olma
  • ÇOK MİKTARDA BÜYÜK HARFLE YAZILMIŞ METİN
  • Başlıksız tablolar ve tablo başlıkları (<th>) yerine belge başlıkları (“Başlık 3”) kullanan tablolar
  • Kullanıcıya indirilen dosyanın erişilebilirliğini test etmesini veya erişilebilir bir alternatif biçim sunmasını hatırlatan, PDF'lere ve diğer belgelere verilen bağlantılar
  • Kullanıcıya kapalı altyazı eklemesini hatırlatan gömülü videolar
  • Kullanıcıya transkript sağlamasını hatırlatan gömülü ses içerikleri
  • Kullanıcıya alt özelliklerini sağlamasını hatırlatan gömülü sosyal medya içerikleri

JavaScript kütüphanesini topluluğa sunduk, Drupal için kurulup hemen kullanılabilen bir entegrasyon oluşturduk ve WordPress için de benzer bir entegrasyon üzerinde çalışmaya başladık.

3. Aşamaya doğru: Varsayılan olarak erişilebilir

Editoria11y birçok açıdan geçici bir çözümdür. Yakaladığı hataların çoğu, içerik yazarlarına yeni beklentiler yüklememiz (“içeriğinizi iyi bir yapıyla etiketleyin”) ama onlara tam tersini teşvik eden araçlar vermemiz yüzünden yapıldı.

İleriye giden yol, erişilebilir içerik oluşturmayı daha kolay ve olabildiğince otomatik hale getirmektir. Bunun nasıl görüneceği henüz belli değil, ancak muhtemelen şunları içerecek:

• Hangi seçeneklerin sunulduğunu yeniden düşünmek. Örneğin: kullanıcılara Web'de metni iki yana yaslamamalarını söyleyip duruyorsak, o “metni iki yana yasla” düğmesini emekli etmenin zamanı gelmedi mi?
• Varsayılan seçenekleri yeniden düşünmek. Örneğin: çoğu içerik yönetim sisteminde varsayılan tablonun başlıkları yoktur. “Özellikler”e tıklayıp erişilebilirlik özelliklerini eklemeyi bilmek kullanıcıya düşüyor; belki de bunu tersine çevirmenin zamanı gelmiştir?
• Tahmine dayalı biçimlendirme ve “çalışırken ipuçları” üzerine kafa yormak. Kullanıcı bir satırın tamamını kalın yaparsa, onu başlık yapmasını önerebilir miyiz? Kullanıcı bir başlık seçmeye giderse, ona altı seçenek sunmak yerine hangi başlık seviyelerini isteyebileceğini tahmin edebilir miyiz? Zor kavramlar için tam zamanında eğitim sağlayabilir miyiz?