1. Erişilebilirlik Nedir, Neden Önemlidir?
Erişilebilirlik; bir web sitesinin farklı yeteneklere, cihazlara ve kullanım koşullarına sahip insanlar tarafından sorunsuz kullanılabilmesidir. Kurumsal sitelerde bunun iki pratik getirisi vardır: risk azaltımı (uyum ve şikayet riskleri) ve kalite artışı (daha az friksiyon, daha iyi form tamamlama, daha net navigasyon). Otel sitesinde erişilebilir bir rezervasyon/iletişim deneyimi, call center’a “soru amaçlı” yükü azaltıp daha nitelikli taleplere alan açabilir; B2B’de ise doküman ve tablo erişilebilirliği, karar vericinin içeriği tüketmesini kolaylaştırır.
Ne yapmalıyım?
- • En çok kullanılan 10 sayfada hızlı bir WCAG taraması yap
- • Formlar ve menü navigasyonunu klavye ile test et
- • Kontrastı kritik CTA ve metinlerde ilk sıraya al
2. WCAG İlke ve Kategorileri
WCAG, erişilebilirliği 4 ana ilkeyle toplar: Algılanabilir (Perceivable), Çalıştırılabilir (Operable), Anlaşılabilir (Understandable), Sağlam (Robust). Bunlar teorik gibi görünse de pratikte her biri doğrudan UI kararına dönüşür.
WCAG prensipleri nelerdir ve neyi garanti eder?
WCAG’in 4 prensibi, içeriğin kullanıcı tarafından algılanmasını (kontrast/alt metin), arayüzün çalıştırılmasını (klavye/focus), etkileşimlerin anlaşılmasını (hata mesajı dili) ve kodun farklı yardımcı teknolojilerle uyumunu (semantik HTML/ARIA) garanti etmeyi hedefler. Bu prensipler, erişilebilirliği “tek tek öneriler” yerine ölçülebilir bir standarda dönüştürür.
Otel ve B2B için pratik eşleştirme
- •Algılanabilir: oda özellikleri, fiyat/koşullar, görsel alt metinleri
- •Çalıştırılabilir: menüler, tarih seçici, rezervasyon adımları, modal’lar
- •Anlaşılabilir: form doğrulama, hata mesajı dili, açıklamalar
- •Sağlam: semantik HTML, ARIA, screen reader uyumu
Ne yapmalıyım?
- • WCAG’i 4 ilke üzerinden ekip diline çevir (her ilkeye 3 madde)
- • Bulgu → aksiyon → doğrulama döngüsü kur
- • Sürüm sonrası erişilebilirlik “regresyon” kontrolü ekle
3. Kontrast, Klavye Navigasyonu, Screen Reader Uyumlu Kod
Erişilebilirliğin “en hızlı kazanım” alanları genelde bu üçlüdür: kontrast, klavye/focus, semantik kod. Bu iyileştirmeler yalnız engelli kullanıcıları değil, mobil kullanımı ve genel kullanılabilirliği de iyileştirir.
Renk kontrast oranları (pratik yaklaşım)
Kontrast, sadece “tasarım zevki” değil okunabilirliktir. Özellikle CTA butonları, linkler ve küçük metinlerde kontrast hataları çok yaygındır.
Varsayım (genel pratik): Kontrast hedefi belirleyin; kritik metinler ve CTA’larda “yeterli kontrast” standardını koruyun.
Focus state ve klavye ile gezinme
Klavye ile gezinme testi basittir: Tab ile dolaşın, Shift+Tab ile geri dönün. Nerede olduğunuz görünmüyorsa (focus state yoksa), kullanıcı kaybolur. Otel sitelerinde tarih seçici, galeri modal’ı, menü dropdown’ları burada sık kırılır.
Alt metin ve ARIA etiketleri (dozunda)
Alt metinler görselleri anlamlandırır; ARIA ise semantik HTML’in yetmediği yerlerde yardımcı olur. En sık hata: ARIA’yı “rastgele eklemek” ve yanlış bilgi vermek. Dozunda ve doğru kullanın; önce semantik HTML.
Ne yapmalıyım?
- • Kontrastı CTA + body text + linklerde kontrol et
- • Menü, modal, datepicker’ı klavye ile baştan sona test et
- • Alt metin standardı oluştur (oda görseli, hizmet görseli, ikon)
4. Form ve Hata Mesajlarında Erişilebilirlik
Form erişilebilirliği, hem WCAG hem dönüşüm açısından en kritik alanlardan biridir. Hata mesajı sadece kırmızı yazı değildir; screen reader bunu duyabilmeli, kullanıcı hangi alanda sorun olduğunu anlayabilmelidir. Label/placeholder karmaşası, yanlış input type ve focus yönetimi formu erişilemez hale getirir.
WCAG uyumlu form ve hata mesajı nasıl olmalı?
Her input’un gerçek bir label’ı olmalı, zorunlu alanlar net işaretlenmeli ve hata mesajı ilgili alana bağlanmalıdır. Hata oluştuğunda focus doğru alana gitmeli ve screen reader kullanıcıya hatayı duyurabilmelidir. Mesaj dili “ne yanlış” kadar “nasıl düzeltilir”i de söylemelidir.
Otel için kritik form alanları
- •Tarih seçimi ve kişi sayısı (klavye ile çalışır olmalı)
- •Oda seçimi/filtreler (focus sırası bozulmamalı)
- •Ödeme adımı varsa (Varsayım): hata mesajları açık olmalı
B2B için doküman ve tablo erişilebilirliği
B2B’de PDF/tablolar çok kullanılır. Tablo başlıkları, doğru semantik yapı ve okunabilirlik; screen reader deneyimini belirler.
Ne yapmalıyım?
- • Formlarda label/aria ilişkilerini kontrol et
- • Hata mesajı dilini “yardım” formatına çevir
- • PDF/tablolar için erişilebilirlik kontrol rutini koy
5. Otel ve B2B İçin Pratik Accessibility Checklist’i
TR’de erişilebilirlik çoğu zaman kamu siteleriyle anılıyor; oysa otel ve B2B sitelerinde de pratik bir checklist ile hızlı kazanımlar alınabilir. Burada amaç “mükemmel olmak” değil, sistematik iyileştirme ve regresyonu önlemektir.
Otel senaryoları (oda/erişim bilgisi ve rezervasyon)
- •“Engelli erişimi” bilgisi görünür ve okunabilir mi?
- •Oda kartları ve galeriler klavye ile gezilebilir mi?
- •Rezervasyon adımlarında focus kayboluyor mu?
B2B senaryoları (doküman, tablo, form)
- •PDF/whitepaper linkleri açıklayıcı mı?
- •Tablo başlıkları doğru mu?
- •Demo/teklif formu screen reader ile anlaşılır mı?
Key Statistics / Data Point (sheet): Erişilebilirlik iyileştirmeleri yapılan sitelerde, yalnız engelli kullanıcı deneyimi değil; genel kullanılabilirlik ve mobil etkileşim metriklerinde de iyileşme raporlanıyor. (Kesin rakam iddiası yapılmadan, gözlemsel veri noktası olarak işlendi.)
Ne yapmalıyım?
- • Her sprint sonunda 15 dakikalık “klavye testi” rutini koy
- • Kontrastı kritik sayfalarda sabitle (CTA/başlık/metin)
- • Erişilebilirlik checklist’ini QA sürecine ekle
| Alan | Kontrol | Sık Hata | Hızlı Çözüm |
|---|---|---|---|
| Kontrast | Metin/CTA okunaklı mı? | Düşük kontrast buton/link | Renkleri token ile düzelt |
| Klavye | Tab ile her yere gidiliyor mu? | Focus görünmüyor | Focus style ekle |
| Screen reader | Semantik doğru mu? | Yanlış/eksik ARIA | Önce semantik HTML, sonra ARIA |
| Görseller | Alt metin var mı? | “img1” gibi anlamsız alt | Konu+amaç odaklı alt yaz |
| Formlar | Label + hata ilişkili mi? | Placeholder-only | Label/aria + fokus yönetimi |
6. Web Sitesi Erişilebilirlik (WCAG) Checklist Şablonunu İndir — Yazılım / Accessibility
Web Sitesi Erişilebilirlik (WCAG) Checklist Şablonunu İndir — Yazılım / Accessibility (v1.0)
Bu asset, WCAG uyumunu kontrast, klavye navigasyonu, screen reader uyumu ve form/hata erişilebilirliği üzerinden pratik bir kontrol listesine dönüştürür. Otel ve B2B sitelerinde hızlı kazanımlar için 14 günlük sprint planı ve ölçüm/KPI takibi sunar. Amaç; erişilebilirliği “tek seferlik proje” değil, sürdürülebilir bir kalite rutini haline getirmektir.
Kim Kullanır?
UX/UI, front-end, QA, içerik ekibi ve proje yöneticisi.
Nasıl Kullanılır?
- En kritik 10 sayfayı seçin ve checklist’e göre tarayın; her bulguya kanıt ekleyin (screenshot/test notu).
- Bulgu → kök neden → çözüm tablosuyla önceliklendirin.
- 14 günlük sprint planını uygulayın; 30 gün sonunda KPI’ları önce/sonra kıyaslayın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Kontrast (metin/CTA/link) kontrol edildi mi?
- ▢ ✅ Klavye ile tam gezinme (Tab/Shift+Tab) çalışıyor mu?
- ▢ ✅ Focus state görünür mü?
- ▢ ✅ Semantik HTML doğru mu (başlıklar, listeler, tablo)?
- ▢ ✅ ARIA yalnız gerektiğinde ve doğru kullanılıyor mu?
- ▢ ✅ Görsellerde anlamlı alt metin var mı?
- ▢ ✅ Formlarda label + hata mesajı ilişkisi var mı?
- ▢ ✅ Hata sonrası focus doğru alana gidiyor mu?
- ▢ ✅ PDF/doküman erişilebilirliği kontrol edildi mi? (B2B)
- ▢ ✅ Release sonrası regresyon rutini var mı?
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
Sitenizi WCAG’e göre tarayıp kontrast, klavye, screen reader ve form bulgularını önceliklendirelim.
Sık Sorulan Sorular
Erişilebilirlik (accessibility) nedir, web sitesi için neden önemlidir?▾
WCAG uyumlu site nasıl yapılır?▾
Kontrast, klavye navigasyonu ve alt metin için temel kurallar neler?▾
Otel ve B2B sitelerinde erişilebilirlik checklist’i nasıl olmalı?▾
Screen reader uyumu için ARIA her yerde kullanılmalı mı?▾
İlgili İçerikler
İlgili Yazılar