1. Neden erişilebilirlik (accessibility) otel UX’inde kritik?
Erişilebilirlik, otel için üç açıdan kritiktir:
- Kullanılabilirlik: Misafir rezervasyonu gerçekten tamamlayabilir mi?
- Güven: Şeffaflık, anlaşılabilir metin ve tutarlı etkileşim güven yaratır.
- Risk yönetimi: Standartlara yaklaşmak, hukuki ve itibar riskini azaltır (ülke ve projeye göre değişebilir).
Engelli misafirler için erişilebilirlik; “mükemmel tasarım” değil, temel ihtiyaçtır. Örneğin tekerlekli sandalye kullanan bir misafir için erişilebilir oda seçeneklerinin net gösterilmemesi, rezervasyonun baştan kaybedilmesine yol açar.
Otel bağlamında 4 kritik kırılma noktası
- •Dil ve içerik: Oda açıklaması anlaşılır mı?
- •Galeri: Alt metin ve odak (focus) yönetimi var mı?
- •Rezervasyon akışı: Takvim/kisi seçimi/oda seçimi klavye ile çalışıyor mu?
- •Form/ödeme: Label, hata mesajı, ARIA ve okuma sırası doğru mu?
☑ Mini Check
- •Rezervasyon akışı fare olmadan tamamlanabiliyor mu?
- •Form alanlarının label’ı var mı (placeholder’a güvenilmiyor mu)?
- •Erişilebilir oda bilgisi açık ve bulunabilir mi?
- •Kontrast minimum seviyeye uygun mu (WCAG AA hedefi)?
Ne yapmalıyım?
- • Erişilebilirliği “sonradan düzeltme” değil, tasarım standardı yapın.
- • Rezervasyon akışını sadece mouse ile değil, klavye ile de test edin.
- • Erişilebilir oda bilgisi ve filtrelerini otel satış stratejisinin parçası olarak görün.
- • Teknik uygulama için iç link: https://dgtlface.com/tr/yazilim/web-sitesi-gelistirme
2. Otel web sitelerinde erişilebilirlik nasıl sağlanır?
AEO checklist (5–7 madde, net)
- Başlık hiyerarşisini doğru kurun (H1→H2→H3) ve sayfada tek H1 kullanın.
- Renk kontrastını WCAG AA seviyesinde hedefleyin; metin ve butonlar okunur olmalı.
- Tüm site klavye ile gezilebilir olmalı: menü, takvim, filtreler, modal/lightbox.
- Form alanlarında gerçek label, açıklayıcı hata mesajı ve doğru odak yönetimi kullanın.
- Screen reader için ARIA etiketleri (gerektiğinde) ve “skip link” gibi yardımcı mekanizmalar ekleyin.
- Erişilebilir oda seçeneklerini net filtre/ikonlarla gösterin ve metinle açıklayın.
- Lighthouse erişilebilirlik skorunu düzenli ölçün; 90+ hedefi bir kalite standardı olarak takip edin.
Voice (doğal soru): “Erişilebilir oda nasıl belirtilir?”
Kısa cevap: Filtre + ikon + metin birlikte olmalı; sadece ikon yeterli değildir. Oda kartında “erişilebilir” etiketi, detay sayfasında açıklama ve ölçüler net yazılmalıdır.
☑ Mini Check
- •Bu 7 maddenin hangileri bugün eksik? (en az 2 tanesini seç)
- •“Skip to content” linki var mı?
- •Takvim bileşeni screen reader ile anlaşılır mı?
Ne yapmalıyım?
- • Erişilebilirlik için bir “çekirdek standart” dokümanı çıkarın ve tüm sayfalara uygulayın.
- • Tasarım sistemine (UI kit) a11y state’lerini ekleyin: focus, error, disabled.
- • Düzenli test rutinini sprint planına bağlayın (aylık/çeyreklik).
3. WCAG ve temel erişilebilirlik ilkeleri (otel UI bileşenlerine çeviri)
WCAG, erişilebilirlik için çerçeve sunar; ama otel sitelerinde bunun karşılığı somut bileşen kararlarıdır. Burada hedef “her şeyi ezberlemek” değil; en kritik ilkeleri otel bileşenlerine çevirmektir.
Algılanabilirlik (Perceivable) — içerik görülebilir/duyulabilir olmalı
- •Kontrast yeterli
- •Görsellere alt metin
- •Video varsa altyazı/alternatif açıklama
Kullanılabilirlik (Operable) — klavye ile kullanılabilirlik
- •Menü, modal, lightbox, takvim klavye ile çalışmalı
- •Odak sırası mantıklı olmalı
- •“Odak tuzağı” (focus trap) doğru yönetilmeli
Anlaşılabilirlik (Understandable) — metin ve hata mesajları
- •Form hata mesajları “ne yanlış + nasıl düzeltirim” formatında
- •Mikro kopya sade ve net
- •Tarih/para formatı açık
Sağlamlık (Robust) — yardımcı teknolojilerle uyum
- •Semantik HTML öncelikli
- •ARIA sadece gerektiğinde, doğru şekilde
- •Screen reader okuma sırası tutarlı
☑ Mini Check (WCAG → UI)
- •Butonların odağı (focus) görünür mü?
- •Modal/lightbox açıldığında odak içine giriyor mu?
- •Error mesajı alanla ilişkilendiriliyor mu?
- •Görsellerin alt metni var mı ve anlamlı mı?
Ne yapmalıyım?
- • “Semantik HTML + doğru odak” ikilisini ana kural yapın.
- • ARIA’yı “yama” gibi değil, doğru kullanım için sınırlı uygulayın.
- • Her yeni bileşeni erişilebilirlik checklist’iyle yayına alın.
4. Klavye ve screen reader dostu rezervasyon akışı
Rezervasyon akışı; takvim, kişi seçimi, oda filtreleri ve formdan oluşur. Bu bileşenlerden biri erişilebilir değilse tüm akış kırılır.
Klavye navigasyonu — pratik gereksinimler
- •Tab ile menüye gir, “skip link” ile ana içeriğe geç
- •Takvimde yön tuşlarıyla gün seçimi (veya erişilebilir alternatif)
- •Filtrelerde checkbox/radio doğru çalışmalı
- •Oda kartlarında CTA’ya erişim net olmalı
Screen reader uyumu — okuma sırası ve etiketler
- •Oda kartında başlık, fiyat, iptal özeti, CTA doğru sırada okunmalı
- •Form alanlarında label ve açıklama (helper text) ayrı olmalı
- •Hata mesajı “aria-describedby” ile alana bağlanmalı (uygulama detayı)
☑ Mini Check (Akış)
- •Takvim fare olmadan kullanılabiliyor mu?
- •Oda filtreleri ve oda kartları screen reader ile anlaşılır mı?
- •Formda hata mesajı alanla ilişkilendiriliyor mu?
- •Odak sırası “mantıklı” mı (rastgele zıplamıyor mu)?
Ne yapmalıyım?
- • Rezervasyon akışını “klavye ile tamamla” testiyle doğrulayın.
- • Takvim/filtre bileşenlerini a11y uyumlu kütüphane/uygulama ile standardize edin.
- • Hata mesajlarını kullanıcıya yol gösterecek şekilde yazın ve teknik bağını kurun.
5. Renk kontrastı, font ve bileşen tasarımı (WCAG AA hedefi)
Kontrast, erişilebilirliğin en hızlı kazanımıdır. Düşük kontrast; sadece görme engelli kullanıcılar için değil, güneş altında mobil kullanan herkes için sorundur (yönlü).
Kontrast pratikleri
- •Metin–arka plan kontrastı yeterli
- •CTA butonlarında hem metin hem buton arka planı okunur
- •Linkler sadece renkle ayrışmasın (underline gibi)
Font ve okunabilirlik
- •Çok ince fontlardan kaçının
- •Satır aralığı ve paragraf genişliği okumayı desteklesin
- •Büyük harf (ALL CAPS) kullanımını sınırlayın
☑ Mini Check (Kontrast/Tipografi)
- •CTA metni her cihazda rahat okunuyor mu?
- •Linkler yalnız renkle ayrışmıyor mu?
- •Font ağırlığı ve boyutu okunabilir mi?
- •Focus ring görünür mü?
Ne yapmalıyım?
- • Kontrastı “tasarım tercihi” değil, standart haline getirin (AA hedefi).
- • Tüm buton ve linklerde focus state’i görünür kılın.
- • Tasarım sistemine erişilebilir tipografi ölçeği ekleyin.
6. Otel Erişilebilirlik Checklist’ini İndir — Accessibility (WCAG)
CHECKLISTv1.0Checklist + Sprint
Otel Erişilebilirlik Checklist’ini İndir — Accessibility (WCAG) (v1.0)
Bu checklist, otel web sitenizde erişilebilirliği (WCAG AA) hızlıca tarayıp en kritik sorunları (kontrast, klavye gezilebilirliği, screen reader uyumu, form hataları, erişilebilir oda sunumu) önceliklendirmenizi sağlar. Amaç, “her şeyi aynı anda” değil; 14 günlük sprintle en büyük etkiyi yaratacak iyileştirmeleri uygulamaya dökmektir.
Kim Kullanır?
Otel pazarlama + ajans + web geliştirme/UX ekibi.
Nasıl Kullanılır?
- Rezervasyon akışını klavye ile baştan sona tamamlayın ve checklist’i işaretleyin.
- Lighthouse erişilebilirlik skorunu ölçün; 90+ hedefiyle gap’leri not edin.
- “Kırmızı” çıkan 5 maddeyi 14 günlük sprint planına yerleştirip uygulayın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Skip link var (“İçeriğe atla”)
- ▢ ✅ Tüm interaktif öğelerde görünür focus state var
- ▢ ✅ Menü, dropdown, modal klavye ile çalışıyor
- ▢ ✅ Takvim bileşeni erişilebilir (alternatif/klavye desteği)
- ▢ ✅ Formlarda gerçek label var (placeholder değil)
- ▢ ✅ Error mesajı alanla ilişkilendiriliyor ve çözüm söylüyor
- ▢ ✅ Kontrast WCAG AA hedefinde
- ▢ ✅ Görsellerin alt metni anlamlı
- ▢ ✅ Erişilebilir oda filtresi + ikon + metin var
- ▢ ✅ Lighthouse Accessibility skoru 90+ hedefleniyor ve takip ediliyor
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Otel Erişilebilirlik Checklist’ini İndir ↓Ücretsiz • PDF / Excel
Problem → Kök Neden → Çözüm tablosu
| Problem | Kök Neden | Çözüm |
|---|---|---|
| Klavye ile rezervasyon tamamlanmıyor | Takvim/modal focus yönetimi yok | Focus trap + erişilebilir takvim |
| Form terk artıyor | Label yok, hata mesajı belirsiz | Label + aria-describedby + net hata metni |
| Okunabilirlik düşük | Kontrast zayıf, font ince | AA kontrast + tipografi standardı |
| Erişilebilir oda bulunamıyor | Filtre/etiket yok | Filtre + oda kartı etiketi + detay listesi |
14 günlük sprint planı (Gün 1–14)
- •Gün 1: Lighthouse + klavye test envanteri
- •Gün 2: “Kırmızı 5” madde seçimi
- •Gün 3–5: Kontrast + focus state düzeltmeleri
- •Gün 6–8: Form label + error state + ARIA bağları
- •Gün 9–10: Takvim/modal erişilebilirliği
- •Gün 11: Erişilebilir oda filtresi + oda kartı etiketleri
- •Gün 12: Regression test (klavye + screen reader temel)
- •Gün 13–14: Rapor + backlog
Öncesi/Sonrası KPI tablosu
| KPI | Önce | Sonra |
|---|---|---|
| Lighthouse Accessibility | ___ | ___ |
| Form completion | ___ | ___ |
| Drop-off (form) | ___ | ___ |
Deliverables listesi
- •Erişilebilirlik audit raporu (gap listesi)
- •UI bileşen a11y standardı
- •14 günlük sprint backlog
- •Test planı (release gate)
7. Erişilebilir oda seçenekleri nasıl gösterilmeli? (otel özel kritik)
Otel sitelerinde erişilebilir oda bilgisi genelde “oda açıklamasında bir satır” olarak kaybolur. Oysa engelli misafir için bu, en kritik filtrelerden biridir.
Filtre + ikon + metin (üçlü kural)
- •Filtre: “Erişilebilir odalar” checkbox
- •İkon: tekerlekli sandalye sembolü (sadece ikon değil)
- •Metin: “Geniş kapı, duş erişimi, tutunma barı” gibi kısa özet
Antalya/Bodrum senaryosu
Erişilebilir oda stoğu yüksek olan otellerde, bu filtreyi oda listesinde görünür kılmak hem kullanıcı memnuniyetini hem de satış fırsatını artırır (yönlü). Ayrıca çağrı merkezine “oda erişilebilir mi?” sorusunu azaltabilir.
☑ Mini Check (Erişilebilir oda)
- •Oda listesinde filtre var mı?
- •Oda kartında etiket/ikon + metin birlikte mi?
- •Oda detayında erişilebilirlik özellikleri madde madde mi?
- •Fotoğraflarda erişilebilir banyo/kapı genişliği gibi kanıtlar var mı?
Ne yapmalıyım?
- • “Erişilebilir odalar” filtresini oda listesine ekleyin ve görünür kılın.
- • Oda kartında kısa etiket + detay sayfasında madde listesi kullanın.
- • Galeride erişilebilirlik kanıt görsellerini ekleyin (banyo/duş erişimi).
8. Erişilebilirlik testleri ve sürekli iyileştirme (rutin)
Erişilebilirlik bir kere yapılıp bırakılmaz; her yeni kampanya bloğu, her yeni form alanı erişilebilirliği bozabilir. Bu yüzden test rutini şarttır.
Hızlı test paketi
- •Lighthouse Accessibility (90+ hedef notu)
- •Klavye ile rezervasyon akışı testi (baştan sona)
- •Screen reader ile oda listesi + form testi (temel kontrol)
- •Kontrast kontrolü (CTA, link, metin)
Süreç önerisi
- •Her sprintte 1 a11y iyileştirme maddesi
- •UI bileşenlerinde “a11y kabul kriterleri”
- •Hata/şikâyet kanalı: erişilebilirlik geri bildirimi
☑ Mini Check (Süreç)
- •Aylık Lighthouse kontrolü var mı?
- •Klavye testi release öncesi yapılıyor mu?
- •Form hata mesajları standardize mi?
- •Erişilebilirlik checklist’i release gate mi?
Ne yapmalıyım?
- • Erişilebilirlik checklist’ini release kontrol listesine ekleyin.
- • “Klavye ile tamamla” testini standart QA adımı yapın.
- • Teknik paydaşlarla semantik bağ kurun:
- • Web geliştirme: https://dgtlface.com/tr/yazilim/web-sitesi-gelistirme
- • Teknik SEO: https://dgtlface.com/tr/seo/teknik-seo
- • Sunucu/güvenlik (uygulama ve izleme): Varsayım: https://dgtlface.com/tr/yazilim/sunucu-guvenlik
9. Hemen uygulayabileceğiniz 10 erişilebilirlik adımı (SXO)
- Skip link ekleyin (“İçeriğe atla”).
- Tüm butonlarda görünür focus state kullanın.
- Menü ve dropdown’ları klavye ile çalışır hale getirin.
- Takvim bileşenini erişilebilir alternatifle destekleyin.
- Formlarda label zorunlu; placeholder tek başına yeterli değil.
- Hata mesajını alanla ilişkilendirin ve çözüm söyleyin.
- Kontrastı AA hedefinde tutun; CTA/link okunaklı olsun.
- Görsellerde anlamlı alt metin kullanın.
- Erişilebilir oda filtresi + etiket + açıklama üçlüsünü kurun.
- Lighthouse erişilebilirlik skorunu düzenli takip edin.
| Alan | Kontrol | Hızlı not |
|---|---|---|
| Kontrast | Metin/CTA AA hedefi | Düşük ışık/mobilde de iyileştirir |
| Klavye | Menü→takvim→form tamamlanır | Odak sırası mantıklı olmalı |
| Form | Label + error state | “Ne yanlış + nasıl düzeltirim” |
| Screen reader | Okuma sırası/ARIA | Semantik HTML öncelikli |
| Erişilebilir oda | Filtre + ikon + metin | Oda kartı + detay sayfası |
Bir Sonraki Adım
Rezervasyon akışınızı WCAG AA, klavye ve screen reader uyumu açısından değerlendirip uygulanabilir bir iyileştirme planı alın.
Sık Sorulan Sorular
Otel web sitemi engelli kullanıcılar için nasıl erişilebilir yaparım?▾
WCAG AA kontrastı hedefleyin, siteyi klavye ile tamamen gezilebilir yapın ve form alanlarında gerçek label + anlaşılır hata mesajları kullanın. Erişilebilir oda seçeneklerini filtre/etiketle net gösterin ve düzenli test rutini kurun.
Rezervasyon formu erişilebilirliği nasıl sağlanır?▾
Her alanda label olmalı, hata mesajı alanla ilişkilendirilmeli ve odak (focus) kullanıcıyı doğru yere yönlendirmelidir. Screen reader için okuma sırası ve gerekliyse ARIA açıklamaları doğru kurgulanmalıdır.
Renk kontrastı UX’i nasıl etkiler?▾
Düşük kontrast metni ve CTA’yı okunmaz yapar; sadece görme engelli kullanıcılar için değil, mobilde güneş altında kullanımda da deneyimi bozar. WCAG AA hedefi okunabilirliği artırır.
Erişilebilir oda seçenekleri nasıl gösterilmeli?▾
Oda listesinde filtre, oda kartında etiket/ikon ve oda detayında net açıklama birlikte kullanılmalıdır. Sadece ikon veya belirsiz bir satır metin, kullanıcı için yeterli olmaz.
Görme engelli kullanıcılar sitemi kullanabilir mi?▾
Kontrast, başlık hiyerarşisi, alt metinler ve screen reader uyumlu form/menü yoksa zorlanırlar. Doğru etiketleme ve klavye uyumuyla rezervasyon akışı erişilebilir hale getirilebilir.
ARIA etiketleri her yerde kullanılmalı mı?▾
Hayır; semantik HTML önceliklidir. ARIA, yalnızca ihtiyaç olan yerde ve doğru şekilde kullanılır; yanlış kullanım screen reader deneyimini bozabilir.
Lighthouse erişilebilirlik skoru kaç olmalı?▾
Pratik hedef olarak 90+ iyi bir standarttır; fakat en önemlisi, gerçek kullanıcı akışlarının (rezervasyon) klavye ve screen reader ile tamamlanabilmesidir.
İlgili İçerikler
İlgili Yazılar