Skip to main content
← notlar
Erişilebilirlik · 15 Ekim 2026 · 6 dk okuma

Otel siteniz EAA'ya hazır mı? Rezervasyon akışı için kontrol listesi

blurple studio
Çizim: odaklanmış bir tarihi olan bir rezervasyon takvimi, misafir sayacı ve Rezervasyon düğmesi
KISACA

Bir otel ekibinin kontrol etmesi gerekenler, misafirin sayfalarla karşılaştığı sırayla: tarih seçici, oda sayfaları, rezervasyon adımı, rezervasyon motoru, telefon ve erişilebilirlik beyanı. Bir öğleden sonrada yapılabilecek bir testle birlikte.

98 otel grubunun ve zincirin rezervasyon sitesini taradık. Test edebildiklerimizin %94'ünde, rezervasyon adımı da dahil, ciddi erişilebilirlik engelleri vardı (araştırma). Bu not, bir otel ekibine vereceğimiz kontrol listesi. Sırası, misafirin sayfalarla karşılaştığı sıra: ana sayfadaki arama kutusundan onay e-postasına kadar.

Başlamadan önce: EAA sizi kapsıyor mu?

  • İnternetten oda satmak e-ticarettir. AB'deki misafirler kendi sitenizden ya da uygulamanızdan oda rezerve edebiliyorsa, Avrupa Erişilebilirlik Yasası bu hizmeti kapsıyor; otelin nerede olduğu fark etmiyor. Almanya'dan bir misafire oda satan Antalya'daki ya da Bodrum'daki bir otel de kapsamda.
  • Mikro işletmeler muaf. Bu, 10 kişiden az çalışanı ve en fazla 2 milyon € cirosu ya da bilanço büyüklüğü olan işletmeler demek. Bir otel grubu genellikle bu tanıma girmiyor.
  • Ölçüt EN 301 549. Web siteleri için bu, WCAG 2.1 AA düzeyi anlamına geliyor.
  • Bu bir çalışma listesi, hukuki görüş değil. Kapsam ya da geçiş süreleri konusunda emin değilseniz hukuk danışmanınıza sorun.

1. Ana sayfa ve arama kutusu

Misafirin ilk yaptığı şey tarih seçmek. Pek çok sitede ekran okuyucu kullanan misafir tam burada takılıyor.

  • Tarih seçiciler. Takvimdeki her gün, ekran okuyucunun okuyabileceği bir adı olan bir düğme olmalı: "15 Ekim, müsait" gibi. Takvim ok tuşlarıyla kullanılabilmeli; misafir tarihleri isterse elle de yazabilmeli.
  • Misafir ve oda sayısı. + ve − düğmelerinin adı olmalı ("Yetişkin ekle") ve sayı değiştiğinde yeni sayı okunmalı.
  • Arama düğmesi gerçek bir düğme olmalı ve üzerinde görünür bir metin bulunmalı; bir kutunun içindeki ikon yetmez.
  • Çerez bildirimi klavyeyle kapatılabilmeli, odağı içinde hapsetmemeli ve odaktaki öğeyi kapatmamalı.
  • Fotoğraf üzerindeki metinler. Büyük fotoğrafın üzerindeki başlık ve kampanya metinlerinde kontrast en az 4,5:1 olmalı. Metnin arkasına koyulan koyu bir katman çoğu zaman sorunu çözer.
  • Açılır pencereler ve kampanyalar klavyeyle ve Esc tuşuyla kapatılabilmeli; kapandığında odak misafirin kaldığı yere dönmeli.

2. Oda sayfaları

  • Fotoğraf galerileri. Her fotoğrafın, ne gösterdiğini anlatan bir metin alternatifi olmalı: deniz manzaralı balkon, eşiksiz duş, iki tek kişilik yatak. Görmeyen bir misafir odaları ancak böyle karşılaştırabilir. Oklar adı olan düğmeler olmalı; galeri kendi kendine ilerlememeli ya da durdurulabilmeli.
  • Oda bilgileri yalnızca ikonla değil, metinle de verilmeli: büyüklük, yataklar, manzara, banyo.
  • Engelli odaları ayrıntılı anlatılmalı. Basamaksız giriş, tekerlekli sandalyeyle girilebilen duş, tutunma barları, kapı genişlikleri. Bu fiziksel erişilebilirlik ve EAA'nın kapsamında değil; ama engelli misafirlerin rezervasyondan önce aradığı bilgi tam olarak bu.
  • Fiyatlar sesli okunduğunda anlaşılır olmalı. Üstü çizili bir fiyat bunu metinle de söylemeli ("180 € yerine 150 €"). Fiyata nelerin dahil olduğu da yalnızca bir ipucu kutusunda değil, fiyatın yanında yazmalı.

3. Rezervasyon adımı

  • Her alanın görünür bir etiketi olmalı. Yazmaya başlayınca kaybolan yer tutucu metin etiket değildir.
  • Hata mesajları hangi alanın hatalı olduğunu ve nasıl düzeltileceğini söylemeli. Hata yalnızca kırmızı renkle gösterilmemeli; odak hataya taşınmalı ki ekran okuyucu kullanan misafir de duysun.
  • Süre sınırları. Oturum ya da fiyat garantisi sona erecekse misafir önceden uyarılmalı ve ek süre isteyebilmeli.
  • Aynı bilgiyi iki kez istemeyin. Misafirin daha önce girdiği bir bilgi, örneğin e-posta adresi, akışın ilerleyen adımında otomatik dolmalı. Bu bir WCAG 2.2 kuralı; şimdiden karşılamaya değer.
  • CAPTCHA. Görsel tanımaya ya da bulmaca çözmeye dayanmayan bir alternatif sunulmalı (WCAG 2.2).
  • Ödeme. Kart formu çoğu zaman ödeme kuruluşunuzdan gelen bir çerçeve. Onu da test edin: bir başlığı, etiketli alanları ve okunabilir hata mesajları olmalı.
  • Onay. Onay sayfasındaki ve e-postadaki rezervasyon numarası ve ayrıntılar görsel değil, metin olmalı.

4. Rezervasyon motoru

Pek çok otel sitesinde rezervasyon adımları bir sağlayıcının ürünü. Misafir bunu bilmiyor; onun için karşısındaki sizin oteliniz.

  • Sağlayıcıdan erişilebilirlik uyum raporunu isteyin. Rapor EN 301 549'a ya da WCAG 2.1 AA'ya göre hazırlanmış olmalı. Neyin henüz çalışmadığını yazan kısmı özellikle okuyun.
  • Sözleşmeye yazın: bir hedef tarih, sağlayıcının geçmesi gereken bir test, neyi kimin ne kadar sürede düzelteceği.
  • Kendi marka ayarlarınızla test edin. Sağlayıcının kendi demosu geçse bile, sizin renkleriniz onun şablonlarında kontrast testinden kalabilir.
  • Tek bir yolculuk gibi ele alın. Sitenizden motora geçen misafir, farklı bir dil ayarıyla, farklı bir yazı boyutuyla ya da bir anda kaybolan bir odak çerçevesiyle karşılaşmamalı.

5. Telefonda

  • Yakınlaştırmayı engellemeyin. Sayfadaki `user-scalable=no` ve `maximum-scale=1` ayarlarını kaldırın. Taradığımız sitelerin dörtte biri yakınlaştırmayı engelliyordu.
  • Dokunma alanlarını yeterince büyük yapın. WCAG 2.2 en az 24×24 piksel istiyor; biz 44×44 ile tasarlıyoruz.
  • Sabit çubuklar ve sohbet düğmeleri. "Hemen rezervasyon yap" çubuğu ya da sohbet balonu, misafirin yazdığı alanın üstünü kapatmamalı.
  • Dar ekranlar. Sayfa 320 piksel genişlikte yana kaydırmadan kullanılabilmeli.

6. Overlay'ler ve erişilebilirlik beyanı

  • Bir overlay widget'ına güvenmeyin. Widget, onu bulup kullanan kişi için sayfanın görünüşünü değiştiriyor ama ekran okuyucunun okuduğu kodu düzeltmiyor. Taramamızda overlay kullanan 5 sitenin 4'ünde yine ciddi engeller vardı.
  • Bir erişilebilirlik beyanı yayımlayın ve her sayfanın alt kısmından link verin. Beyanda hangi standardı esas aldığınız, neyin henüz çalışmadığı, misafirin başka hangi yoldan rezervasyon yapabileceği (telefon, e-posta, sohbet), kime ulaşacağı ve beyanın en son ne zaman gözden geçirildiği yazmalı. Taramamızda 30 Türk otel grubundan yalnızca biri ana sayfasından böyle bir beyana link veriyordu.

Bir öğleden sonrada nasıl test edilir?

  1. Yalnızca klavye. Fareyi çıkarın ve ana sayfadan ödeme ekranına kadar bir oda rezerve etmeyi deneyin. Her adımda nerede olduğunuzu görebiliyor musunuz?
  2. Ekran okuyucu. iPhone'da VoiceOver'ı açın (Ayarlar → Erişilebilirlik) ve tarihlerinizi seçmeyi deneyin.
  3. Yakınlaştırma. Masaüstü tarayıcıyı %200'e büyütün; telefonunuzda yazı boyutunu en büyüğe getirin.
  4. Otomatik kontrol. Ana sayfada, bir oda sayfasında ve rezervasyon adımında axe DevTools'u ya da ücretsiz aracımız a11y-ray'i çalıştırın. Otomatik kontroller gerçek engellerin üçte birini bulur; başlangıç için iyidir ama tek başına yetmez.

Sizin tamamlayamadığınız bir adımı misafiriniz de tamamlayamaz. İşe oradan başlayın.

Bu işi daha önce yapmış bir ekiple birlikte yürütmek isterseniz Compliance Check tam olarak bunun için var. Araştırmamızdaki gruplardan birini yönetiyorsanız hello@blurple.digital adresine yazın; kendi sonuçlarınızı size özel olarak ve ücretsiz gönderelim.

İşinize yaradıysa ekibinizle paylaşın.
Ürününüze birlikte bakalım mı?

Kısa bir görüşmede nerede durduğunuzu ve ilk adımın ne olması gerektiğini açıkça söyleriz.