Herhangi Bir Web Sitesindeki En Yaygın 6 WCAG Hatası Nasıl Düzeltilir

Şu anda en popüler bir milyon web sitesinden herhangi birini açın; otomatik bir tarayıcının saniyeler içinde yakalayabileceği bir WCAG ihlali bulma olasılığınız 100’de 96’dır. Bir milyon ana sayfa arasında 56.114.377 farklı erişilebilirlik hatası tespit edildi — sayfa başına ortalama 56,1 hata. Bunu özellikle çarpıcı kılan şey, tespit edilen tüm hataların %96’sının yalnızca altı kategoriye girmesi ve bu en yaygın altı hata türünün son yedi yıldır değişmemiş olmasıdır. Bu, iyi anlaşılan birkaç sorunu düzeltmenin tüm web genelinde erişilebilirliği dramatik biçimde iyileştireceği anlamına geliyor — ve bu, sitenizle başlar.

Aynı Altı Hatanın Sürekli Ortaya Çıkmasının Nedeni

Gelişmiş geliştirme araçlarının ve artan hukuki incelemenin olduğu bir çağda, aynı hataların yıl üstüne yıl bu ölçekte nasıl kalabildiğini merak edebilirsiniz. Cevap sistemik. Bu hata yoğunluğu, erişilemezliğin web geliştirme pratiklerine ne kadar derinden yerleştiğini yansıtıyor. Şablon sorunları her sayfaya katlanarak yayılıyor. Bileşen hataları sitelerin tamamında tekrar ediyor. Erişilebilirliğe kasıtlı bir dikkat gösterilmediğinde, standart geliştirme iş akışları sistematik olarak erişilemez sonuçlar üretir.

Ayrıca otomasyonun yarattığı sahte bir ilerleme hissi de var. Otomatik testler potansiyel WCAG hatalarının yalnızca %30–40’ını yakalar. Otomatik testleri geçen sitelerde bile klavye ile gezinme, ekran okuyucu veya bilişsel erişilebilirlik açısından ciddi sorunlar olabilir. Bu, kâğıt üzerinde uyumlu görünen az sayıdaki sitenin bile pratikte muhtemelen yetersiz kaldığı anlamına gelir.

Hukuki riskler gerçek ve artıyor. Seyfarth Shaw’a göre, 2024’te 8.800 ADA Title III federal davası açıldı ve bunların yaklaşık 2.452’si özellikle web erişilebilirliğini hedefliyordu. E-ticaret siteleri orantısız bir riskle karşı karşıya — web erişilebilirliği davalarının %77’si çevrimiçi perakendeyi hedefliyor. Uyum artık “olsa iyi olur” değil. Bu, iş sürekliliği meselesi.

Cesaret verici olan diğer yüzü ise şu: Bu yoğunlaşmanın pratik sonuçları var. Kuruluşlar, birkaç sorun türüne odaklanarak erişilebilirlik sorunlarının çoğunu ele alabilir. Kapsamlı WCAG uyumu tüm 78 kritere dikkat gerektirir, ancak en yüksek etki, bu yaygın hataların düzeltilmesinden gelir. Öyleyse her birini, bugün uygulayabileceğiniz pratik çözümlerle birlikte ele alalım.

Hata #1 — Düşük Kontrastlı Metin (WCAG 1.4.3)

Düşük kontrastlı metin — arka planından yeterince renk ayrımı olmayan metin — incelenen ana sayfaların %83,6’sında görülüyor. Bu, her beş web sitesinden dördünden fazlasını etkileyen en yaygın WCAG hatasıdır. WCAG 1.4.3 (Minimum Kontrast) acımasızca nettir: normal metin, arka planına karşı en az 4,5:1 kontrast oranına ulaşmalıdır ve büyük metin (18pt veya 14pt kalın) en az 3:1’e ulaşmalıdır.

Kontrast hataları genellikle okunabilirlik yerine estetiği önceleyen tasarım kararlarından kaynaklanır. Beyaz arka plan üzerinde açık gri metin, kusursuz görüşe sahip tasarımcılara sofistike görünür. Düşük görme yetisine sahip kullanıcılar, yaşlı kullanıcılar veya parlama olan bir ekranda okuyan herkes için ise okunamazdır. İkincil etiketler, form yer tutucuları, altbilgi metni ve devre dışı düğme durumları genellikle başlıca suçlulardır — “ince” görünmeleri için stillenirler ve kitlenizin önemli bir kısmı için görünmez hale gelirler.

Çözüm neredeyse her zaman bir CSS ayarıdır. Renk çiftlerinizi WebAIM’in kontrast aracı veya tarayıcı DevTools erişilebilirlik paneli gibi bir kontrast denetleyicisinden geçirin, ardından geçene kadar ön plan veya arka plan değerini biraz oynatın. İşte sık görülen bir başarısız desen ve nasıl düzeltileceği:

/* Başarısız — oran yaklaşık 2.3:1 */
.secondary-label {
  color: #aaaaaa;
  background-color: #ffffff;
}

/* Başarılı — oran yaklaşık 7:1 */
.secondary-label {
  color: #595959;
  background-color: #ffffff;
}

Yer tutucu metin için, WCAG’nin bunu dekoratif bir ipucu değil, gerçek metin olarak ele aldığını unutmayın — dolayısıyla 4,5:1 eşiğini karşılaması gerekir. Talimatları iletmek için yalnızca yer tutucu metne güvenmekten kaçının; her durumda görünür bir <label> öğesiyle eşleştirin. Metin içeren görseller kullanıyorsanız, kontrastı CSS ile düzeltemezsiniz — bu görselleri yeniden üretmeniz gerekir; bu da metni grafiğe gömmek yerine canlı HTML metni tercih etmeniz için bir başka nedendir.

Hata #2 — Eksik Görsel Alternatif Metni (WCAG 1.1.1)

Alternatif metni olmayan görseller ana sayfaların %58,2’sinde görülüyor. Görsellerde alt metin olmadığında, ekran okuyucu kullanıcıları anlamlı içeriğin olması gereken yerde ya sessizlikle ya da anlamsız dosya adlarıyla karşılaşır. Bu sorun yeni değil. Alt metin, 1999’daki WCAG 1.0’dan beri temel bir erişilebilirlik gereksinimidir. Yirmi beş yıl sonra bile çoğu web sitesi bunu tutarlı şekilde uygulamada başarısız oluyor.

Bu sorunun sürmesinin nedeni bilgi değil, iş akışı boşluğudur. Bu hata oranı, içerik iş akışlarındaki sistematik boşluklara işaret eder. Yazarlar ve editörler çoğu zaman alt metne ihtiyaç olduğunu bilmez. İçerik yönetim sistemleri her zaman bunun için uyarmaz. Kalite güvencesi eksikliği yakalamaz. Bu nedenle çözümün iki katmanı vardır: teknik ve süreçsel.

Teknik tarafta, anlamlı her görselin, görselin ilettiğiyle aynı bilgiyi ileten bir alt özniteliğine ihtiyacı vardır. Dekoratif görseller — yalnızca görsel süsleme olan ve hiçbir bilgi eklemeyenler — ekran okuyucuların bunları tamamen atlaması için boş bir alt="" almalıdır. Bu ayrımı doğru yapmak, özniteliği eklemek kadar önemlidir. Görsellerin büyük bir yüzdesinde eksik veya hatalı alt metin var. Bazı anlamlı görsellerin hiç açıklaması yokken, dekoratif görseller sıklıkla anlamlı içerik gibi ele alınıyor. Her iki sorun da algılanabilir içerik için WCAG uyumunu bozar.

<!-- Anlamlı görsel: neyi ilettiğini açıklayın -->
<img src='team-photo.jpg' alt='The Accsible engineering team at their 2024 offsite in Lisbon' />

<!-- Dekoratif görsel: boş alt, role gerek yok -->
<img src='wave-divider.svg' alt='' />

<!-- Bağlantılı görsel: görseli değil, hedefi açıklayın -->
<a href='/pricing'>
  <img src='pricing-icon.svg' alt='View pricing plans' />
</a>

Süreç tarafında, CMS şablonlarınızı içerik görselleri için alt alanını zorunlu kılacak şekilde güncelleyin ve varlık yükleyen herkesi eğitin. Accsible gibi otomatik araçlar, site genelinde eksik veya boş alt metne sahip görselleri tespit edebilir ve ekibinize sistematik olarak üzerinde çalışabileceği denetlenebilir bir liste sunar.

Hata #3 — Eksik Form Girdi Etiketleri (WCAG 1.3.1, 3.3.2)

Web sitelerinin %48,6’sında form girdi etiketleri eksik. Bu hata özellikle zararlıdır çünkü kullanıcıların gerçekten bir şeyler yaptığı yerler formlardır — kayıt olma, ödeme, iletişim kurma, destek talebi gönderme. Birçok formda erişilebilir etiketler yoktur, yalnızca yer tutuculara dayanır, talimatları ve hata mesajlarını programatik olarak açığa çıkarmaz veya yalnızca klavye ile kullanımı desteklemez. Formlar çoğu dijital deneyim için temel olduğundan, bu hatalar ciddi kullanılabilirlik engelleri yaratır.

En yaygın hata, yer tutucu metni bir <label> yerine kullanmaktır. Yer tutucular, kullanıcı yazmaya başlar başlamaz kaybolur; bu da kısa süreli hafıza bozukluğu olan herkesin — ya da form ortasında dikkati dağılan herhangi birinin — alanın ne için olduğunu hatırlayamamasına yol açar. Ekran okuyucular yer tutucuları nasıl ele aldıkları konusunda farklılık gösterir ve hiçbir yaklaşım, doğru bir etiket ilişkilendirmesi kadar güvenilir değildir.

Doğru desen, for ve id özniteliklerinin eşleşmesiyle girdisine bağlanan bir <label> öğesi kullanmaktır. Tasarım nedenleriyle görünür bir etiket mümkün değilse, aria-label veya aria-labelledby kullanın — ancak kullanabilecekken ARIA’ya sarılmayın; önce bir <label> kullanın.

<!-- Doğru: açık etiket ilişkilendirmesi -->
<label for='email'>Email address</label>
<input type='email' id='email' name='email' autocomplete='email' />

<!-- Yanlış: yalnızca yer tutucu -->
<input type='email' placeholder='Email address' />

<!-- Etiketin görsel olarak gizlenmesi gerektiğinde kabul edilebilir -->
<label for='search' class='visually-hidden'>Search the site</label>
<input type='search' id='search' name='q' />

Hata mesajları da programatik olarak ilişkilendirilmelidir. Bir form doğrulama yapıp bir hata bulduğunda, mesaj aria-describedby kullanılarak alanla ilişkilendirilmeli ve ideal olarak odak ilk geçersiz alana taşınmalıdır. Form doğrulama hataları verimli, sezgisel ve erişilebilir olmalıdır — hata açıkça tanımlanmalı, sorunlu elemana hızlı erişim sağlanmalı ve kullanıcı hatayı kolayca düzeltip formu yeniden gönderebilmelidir.

Hata #4 — Boş Bağlantılar ve Düğmeler (WCAG 2.4.4, 4.1.2)

Web sitelerinin %44,6’sında boş köprüler var. Boş düğmeler sayfaların neredeyse %30’unda bulundu ve bu sayı önceki yıla göre arttı. Bu, görme engelli veya az gören kullanıcıların gönder, sıfırla, filtrele veya ara gibi düğmelerin amacını anlamayacağı anlamına gelir. Boş bağlantılar ve düğmeler birlikte, ekran okuyucu kullanıcıları için en sinir bozucu deneyimlerden birini temsil eder — adı olmayan etkileşimli öğelerle karşılaşmak, üzerinde etiket olmayan bir kapı koluna basıp nereye açıldığını bilmemeye benzer.

Boş bağlantılar en yaygın olarak, bir <a> etiketinin tek çocuğu bir simge veya görsel olduğunda ve hiçbir metin alternatifi sağlanmadığında ortaya çıkar. Boş düğmeler ise yalnızca simge içeren düğmeler — hamburger menüler, kapatma simgeleri, sosyal paylaşım düğmeleri — herhangi bir erişilebilir ada sahip olmadığında oluşur. Her ikisi de düzeltmesi kolay sorunlardır.

<!-- Boş bağlantı — başarısız -->
<a href='/dashboard'><svg>...</svg></a>

<!-- aria-label ile düzeltilmiş -->
<a href='/dashboard' aria-label='Go to dashboard'><svg aria-hidden='true'>...</svg></a>

<!-- Boş düğme — başarısız -->
<button><svg>...</svg></button>

<!-- Görsel olarak gizli metinle düzeltilmiş -->
<button>
  <svg aria-hidden='true'>...</svg>
  <span class='visually-hidden'>Close menu</span>
</button>

Düzeltilmiş her örnekte SVG üzerindeki aria-hidden='true' özniteliğine dikkat edin. aria-label veya görsel olarak gizli metinle bir metin alternatifi sağladığınızda, SVG’yi erişilebilirlik ağacından gizlemek istersiniz — aksi halde ekran okuyucular hem etiketi hem de SVG’nin kendi başlık veya açıklamasını okuyabilir ve bu da kafa karıştırıcı çift anonslara yol açar. “Buraya tıklayın”, “daha fazlasını okuyun” veya “daha fazla bilgi edinin” gibi muğlak bağlantı metni de ilişkili bir hatadır. Muğlak bağlantı metni gibi diğer köprü sorunları ana sayfaların neredeyse %14’ünde bulundu ve bu oran önceki yıla göre arttı. Bağlantıların uygun metne sahip olması, kullanıcıların bağlantının nereye götüreceğini bilmesi için önemlidir. Her bağlantının erişilebilir adı, bağlamdan bağımsız olarak anlamlı olmalıdır; çünkü ekran okuyucu kullanıcıları sıklıkla bir sayfadaki tüm bağlantıların listesini açarak gezinir.

Hata #5 — Eksik Belge Dili (WCAG 3.1.1)

Bu, kontrast veya alt metne kıyasla önemsiz görünebilir, ancak sayfaların yaklaşık %16’sında belge dili ayarlanmamış — ve ekran okuyucu kullanıcıları üzerindeki etkisi anında ve sarsıcıdır. Ekran okuyucu kullanıcısının ilgili dil paketi yüklüyse, içerik doğru şekilde seslendirilir. Aksi halde kötü bir aksan gibi duyulur ve anlaşılmaz olabilir.

Çözüm tek bir HTML özniteliğidir — kelimenin tam anlamıyla bir satır kod — ve bunun eksik olması için hiçbir mazeret yok. <html> öğenize uygun BCP 47 dil etiketiyle lang özniteliğini ekleyin. Sayfanızın bölümleri, sayfanın geneliyle farklı bir dildeyse, bu belirli öğelere de bir lang özniteliği ekleyin.

<!-- Eksik: lang özniteliği yok -->
<html>

<!-- Doğru: İngilizce sayfa -->
<html lang='en'>

<!-- Doğru: Fransızca sayfa -->
<html lang='fr'>

<!-- Sayfa içinde satır içi dil değişimi -->
<p>The French phrase <span lang='fr'>joie de vivre</span> means a cheerful enjoyment of life.</p>

Bir CMS veya statik site üreticisi kullanıyorsanız, lang özniteliği temel şablonunuzda ayarlanmalıdır. Şablonunuzu bir kez kontrol edin, bir kez düzeltin ve sitenizdeki her sayfa anında düzelmiş olur. Bu, belki de listenin tamamındaki en yüksek getiri/çaba oranına sahip düzeltmedir — tek bir şablon değişikliği, tüm alan adınız genelinde sorunu ortadan kaldırır.

Hata #6 — Erişilemez Klavye Gezinmesi ve Odak Yönetimi (WCAG 2.1.1, 2.4.7)

Klavye erişilebilirliği, otomatik testlerle gerçek dünya kullanılabilirliği arasındaki farkın en büyük olduğu alandır. Otomatik araçlar bazı klavye hatalarını — etkileşimli öğelerin anlamsız etiketlerden inşa edilmesi gibi — tespit edebilir, ancak sekme sırasını, odak tuzağını veya yalnızca ok tuşlarıyla bir açılır menüde gezinme deneyimini simüle edemez. Siteler sıklıkla varsayılan odak göstergelerini alternatif sunmadan kaldırır ve bu da klavye ile gezinmeyi neredeyse imkânsız hale getirir. Bu, yalnızca motor engelli kullanıcıları değil, klavyeyi tercih eden herkesi, güç kullanıcılarını ve anahtarlama cihazları kullanan kişileri de etkiler.

En yaygın klavye hataları şunlardır: hiçbir zaman odak almayan <div> veya <span> etiketlerinden inşa edilmiş özel etkileşimli bileşenler; tarayıcının varsayılan odak halkasını outline: none veya outline: 0 ile kaldıran ve bunu eşit derecede görünür bir şeyle değiştirmeyen CSS kuralları; odak tuzağı olmayan modal diyaloglar (böylece klavye kullanıcıları üstteki katmanın arkasına sekme yapabilir); ve fare olmadan kullanılamayan karuseller veya akordeonlar.

<!-- Klavye ile erişilemeyen özel düğme — başarısız -->
<div class='btn' onclick='doSomething()'>Submit</div>

<!-- Doğru: gerçek bir düğme kullanın -->
<button type='button' onclick='doSomething()'>Submit</button>

<!-- Odak stillerini kaldırmak — WCAG 2.4.7’yi ihlal eder -->
* {
  outline: none; /* bunu asla global olarak yapmayın */
}

<!-- Daha iyi: estetiği korurken odağı görünür biçimde stillendirin -->
:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

:focus-visible sözde sınıfı burada en iyi arkadaşınızdır. Kullanıcı klavye ile gezinirken odak stillerini gösterir, ancak fare tıklamaları için bunları bastırır — böylece erişilebilirlikten ödün vermeden temiz bir estetik elde edersiniz. Modallar ve çekmeceler için, sekme gezinmesini diyalog açıkken diyalog içinde kısıtlayan ve kapandığında odağı tetikleyici elemana geri döndüren bir odak tuzağı yardımcı aracı kullanın. Açılır pencereler sıklıkla uygun odak yönetimi olmadan, etiketsiz veya klavye ile gezinme desteği olmadan görünür. Bu, özellikle kayıt, giriş ve ödeme gibi kritik kullanıcı akışlarında ciddi kesintilere neden olur.

Bireysel bileşenlerin ötesinde, bir atla gezinme bağlantısı eklemeyi düşünün — odaklandığında görünür hale gelen ve klavye kullanıcılarının tekrarlayan gezinmeyi atlayıp ana içeriğe atlamasına izin veren görsel olarak gizli bir bağlantı. Tekrarlayan gezinmeyi atlamaya izin veren atla bağlantıları sitelerin çoğunda eksik. Üç satır HTML ve küçük bir CSS parçasıdır ve klavye ile içerik açısından zengin bir sayfada gezinmek zorunda olan herkes için derin bir fark yaratır.

<!-- Bunu <body> içinde ilk öğe olarak yerleştirin -->
<a href='#main-content' class='skip-link'>Skip to main content</a>

<!-- Ardından CSS’inizde -->
.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  left: 0;
  top: 0;
  z-index: 9999;
}

ARIA Hakkında Bir Not: Dikkatli Kullanın

Birçok ekip, erişilebilirlik boşluklarını hızlıca kapatmak için ARIA (Accessible Rich Internet Applications) özniteliklerine yöneliyor. Veriler, bunun çoğu zaman yardımcı olmaktan çok geri teptiğini gösteriyor. Değerlendirilen ana sayfaların yaklaşık %79’u ARIA kullanıyordu ve bu oran önceki yıla göre artmıştı. ARIA kullanan ana sayfalarda, ARIA kullanmayan sayfalara göre iki kattan fazla hata vardı. Sorun ARIA’nın kendisi değil — genellikle ARIA’nın yanlış veya hatalı kullanımıdır. İyi niyetli birçok geliştirici, ARIA ekleyerek içeriği daha erişilebilir hale getirdiğini düşünürken, aslında çoğu zaman daha az erişilebilir hale getiriyor.

Yol gösterici ilke basittir: önce semantik HTML kullanın. Bir <button>, <div role='button'>’dan daha iyidir. Bir <nav>, <div role='navigation'>’dan daha iyidir. Yerel HTML öğeleri, yerleşik klavye davranışı, odak yönetimi ve sizin elle kopyalamanız gereken örtük ARIA rolleriyle birlikte gelir — ve bu manuel kopyalama, hataların sızdığı yerdir. ARIA’yı, HTML’nin gerçekten ihtiyaç duyduğunuz semantiği ifade edemediği durumlara saklayın; canlı bölgeler, karmaşık bileşik bileşenler veya dinamik durum değişiklikleri gibi.

Erişilebilirliği İş Akışınıza Dahil Etmek

Mevcut ihlalleri düzeltmek gereklidir, ancak yenilerinin ortaya çıkmasını engellemek, olgun erişilebilirlik programlarını tek seferlik uyum koşularından ayıran şeydir. Erişilebilirlik tek seferlik bir düzeltme değildir. Her içerik güncellemesi, tasarım değişikliği veya kod dağıtımı yeni sorunlar ortaya çıkarabilir. Bu rehberde ele alınan altı hata kategorisi genellikle şablon düzeyindeki sorunlardır — üstbilgiyi, altbilgiyi ve paylaşılan bileşenleri düzeltin ve aynı anda yüzlerce sayfada sorunu ortadan kaldırırsınız.

İhlaller üretime ulaşmadan yakalanması için otomatik taramayı CI/CD hattınıza entegre edin. axe-core gibi araçlar birim testlerine ve uçtan uca test paketlerine gömülebilir. Bunu, periyodik manuel klavye gezintileri ve ekran okuyucu testleriyle eşleştirin — macOS ve iOS’ta VoiceOver, Windows’ta NVDA — çünkü otomatik testler yaygın erişilebilirlik hatalarını tespit edebilir, ancak manuel testler boşlukları doldurmaya yardımcı olur. Daha hızlı bir başlangıca ihtiyaç duyan ekipler için, Accsible gibi bir erişilebilirlik katman aracı, daha uzun vadeli kod düzeyinde düzeltmeler planlanıp dağıtılırken, önemli bir sorun sınıfını sunum katmanında ortaya çıkarıp hafifletebilir.

Son olarak, kod tabanınızdaki en büyük kaldıraç noktasını ele alın: şablonlarınızı. Çoğu web sitesi şablonlar kullanır — her sayfada tekrar eden bir üstbilgi, altbilgi, gezinme ve sayfa düzeni. Bu şablonlardaki sorunlar tüm sitenize katlanarak yayılır. En yüksek etki için önce bunları düzeltin. Tek bir düzeltilmiş temel şablon, tek bir dağıtımla 10.000 WCAG hatasını sıfıra indirebilir.

Temel Çıkarımlar

• Altı sorun türü manzaraya hakim. Düşük kontrastlı metin, eksik alt metin, etiketlenmemiş form girdileri, boş bağlantılar ve düğmeler, eksik belge dili ve bozuk klavye gezinmesi, WCAG hatalarının ezici çoğunluğunu oluşturur. Bu altı kategoriyi düzeltmek, harcanan çabaya kıyasla orantısız derecede yüksek sonuçlar verir.
• Çoğu düzeltme CSS veya tek satır HTML değişiklikleridir. <html> etiketinize lang='en' eklemek, outline: none yerine :focus-visible stilleri kullanmak ve etiketleri girdilerle ilişkilendirmek saatler süren, aylar süren işler değil — yine de sitenizi ziyaret eden engelli her kullanıcıyı etkileyen hataları ortadan kaldırırlar.
• Şablonlar en yüksek kaldıraçlı düzeltme noktasıdır. Paylaşılan bileşenler ve sayfa şablonlarındaki erişilebilirlik hataları tüm sitenize kopyalanır. Önce üstbilginizi, altbilginizi, gezinmenizi ve formlarınızı denetleyin — buralarda düzeltmek, her yerde düzeltmek demektir.
• ARIA ilk başvuru değil, son çare aracıdır. Güçlü bir semantik HTML temeli olmadan ARIA’ya ağır şekilde yaslanan sitelerde, daha az değil, önemli ölçüde daha fazla erişilebilirlik hatası olma eğilimi vardır. Mümkün olduğunda yerel HTML öğelerini tercih edin.
• Otomatik tarama gerçek sorunların yarısından azını yakalar. Araçlarınızı, odak tuzakları, mantıksız sekme sırası sorunları ve değişiklikleri duyurmayan dinamik içerik gibi hiçbir tarayıcının ortaya çıkaramayacağı hataları bulmak için manuel klavye gezintileri ve ekran okuyucu testleriyle tamamlayın.