Web sitesinde klavye erişimi nasıl test edilir?

Web sitesinde klavye erişimi, yalnızca fare kullanmadan Tab, Shift+Tab, Enter, Space ve ok tuşlarıyla tüm işlevleri tamamlayarak test edilir.

Bu test, görme, motor veya geçici fiziksel kısıtları bulunan kullanıcıların siteyi kullanıp kullanamadığını gösterir. Aynı zamanda klavye kullanan geliştiriciler ve hızlı gezinmeyi tercih eden ziyaretçiler için de önemlidir.

Test sırasında üç noktayı ayrı değerlendirin: odak nereye gidiyor, odak ekranda görünüyor mu ve kullanıcı işlemi tamamlayabiliyor mu? Sadece Tab tuşuna basmak, erişilebilirlik testinin tamamı değildir.

Web sitesinde klavye erişimi neden test edilmelidir?

Web sitesinde klavye erişimi, fare kullanamayan kişinin bağlantılara, menülere, formlara ve butonlara ulaşabilmesini sağlar.

Klavye erişimi olmayan bir kullanıcı, ana navigasyona ulaşamayabilir. Bir modal pencere açıldığında içeride sıkışabilir. Form alanına erişse bile gönderim butonunu çalıştıramayabilir.

Bu sorunlar özellikle teklif formu, ödeme adımı, rezervasyon ekranı ve giriş sayfasında doğrudan dönüşüm kaybı oluşturur. Sorun, yalnızca estetik veya teknik bir ayrıntı değildir.

Testi gerçek bir kullanıcı akışı üzerinden yapmak gerekir. Örneğin ziyaretçi ana sayfaya gelir, hizmet sayfasını açar, formu doldurur ve gönderir. Bu akışın her adımını fare kullanmadan tamamlayın.

Bir sayfanın klavyeyle açılması, kullanılabildiği anlamına gelmez. Odak sırası görsel düzeni izlemiyorsa kullanıcı hangi alanda olduğunu anlayamaz. Odak görünmüyorsa tuşlara basmak tahmine dönüşür.

Otomatik araçlar bazı HTML ve ARIA hatalarını bulabilir. Ancak yanlış odak sırasını, anlaşılmayan hata mesajını veya klavyeyle erişilemeyen özel menüyü her zaman yakalayamaz.

Klavye erişilebilirliği testi için hangi tuşlar kullanılır?

Klavye testinde temel olarak Tab, Shift+Tab, Enter, Space, ok tuşları ve Escape kullanılır.

Tab, bir sonraki odaklanabilir öğeye geçer. Shift+Tab, önceki öğeye döner. Enter, bağlantıları ve bazı butonları çalıştırır. Space, genellikle buton, onay kutusu ve açılır seçimlerde kullanılır.

Ok tuşları, menü, sekme, radyo düğmesi ve özel bileşenlerde denenmelidir. Escape ise açılır menüyü, modal pencereyi veya bildirim katmanını kapatmalıdır.

Teste tarayıcı yakınlaştırmasını yüzde 200 seviyesine çıkararak da devam edin. Yakınlaştırma sırasında içerik kesiliyorsa veya yatay kaydırma zorunlu hale geliyorsa, klavye kullanımı ayrıca zorlaşabilir.

Her sayfada önce Tab tuşuna basın. İlk odak noktası genellikle “İçeriğe geç” bağlantısı, logo veya ana navigasyon olur. Kullanıcı ana içeriğe hızlıca geçebiliyor mu kontrol edin.

Bir öğeye odaklandığınızda Enter ve Space davranışını ayrı ayrı deneyin. Görsel olarak buton görünen bir öğe yalnızca fare tıklamasıyla çalışıyorsa klavye erişimi eksiktir.

Testi yalnızca masaüstünde yapmayın. Farklı tarayıcılarda aynı akışı tekrarlayın. Tarayıcı, tema, JavaScript bileşeni veya eklenti değişiklikleri odak davranışını etkileyebilir.

Tab sırası nasıl kontrol edilir?

Tab sırası, odaklanabilir öğelerin kullanıcıya sunulduğu mantıksal ilerleme sırasıdır.

Örneğin üst menüden ana içeriğe, ardından içerik bağlantılarına ve form alanlarına geçmek genellikle anlaşılırdır. Odak önce footer alanına, sonra üst menüye gidiyorsa sıra kullanıcıyı şaşırtır.

Kontrol için sayfayı yenileyin ve fareye dokunmadan Tab tuşuna basın. Her adımda odaklanan öğeyi kısa notlarla kaydedin. Örnek kayıt şöyle olabilir: logo, menü, arama, ana başlık, hizmet bağlantısı, form adı ve gönder butonu.

Görsel sırayla DOM sırası aynı olmalıdır. CSS ile kutuların yerini değiştirmek veya HTML sırasını görsel tasarıma uydurmamak, klavye kullanıcılarında beklenmeyen geçişler oluşturabilir.

Yanlış: Formda görsel olarak önce ad, sonra telefon, sonra e-posta görünürken Tab sırasını e-posta, ad, telefon şeklinde bırakmak.
Doğru: Kullanıcının ekranda gördüğü ve klavyeyle izlediği sırayı aynı tutmak.

Odaklanmaması gereken dekoratif öğeler de kontrol edilmelidir. Dekoratif ikonlara, arka plan bağlantılarına veya gereksiz kapsayıcılara odak gelmesi, kullanıcıya ek ve anlamsız duraklar yaratır.

HTML içinde tabindex değerlerini rastgele kullanmak genellikle sorunu çözmez. Pozitif tabindex değerleri, doğal belge sırasını bozabilir. Öncelik, doğru HTML yapısını kurmak olmalıdır.

Tab sırası bazı durumlarda işe yaramaz bir ölçüm olabilir. Sayfada yalnızca statik metin varsa, odak noktalarının az olması sorun değildir. Önemli olan tüm etkileşimli işlevlerin erişilebilir olmasıdır.

Odak göstergesi nasıl test edilir?

Odak göstergesi, klavye kullanıcısının o anda hangi öğede bulunduğunu ekranda açıkça göstermelidir.

Tab tuşuna basarken her adımda bağlantının veya butonun çevresinde belirgin bir çerçeve, renk değişimi ya da başka bir görsel işaret arayın. Odak yalnızca renk farkıyla gösteriliyorsa kontrastı ayrıca değerlendirin.

CSS içinde outline: none kullanımı, yerine görünür bir stil eklenmeden uygulanmamalıdır. Tasarım amacıyla varsayılan çizgiyi kaldırmak, klavye kullanıcısının konumunu tamamen kaybetmesine neden olabilir.

Odak göstergesi arka plan üzerinde seçilebilmelidir. Beyaz bir çerçeve, açık renkli bir bölümde görünmüyorsa teknik olarak mevcut olsa bile pratikte işe yaramaz.

Odak göstergesini ana menü, kart bağlantıları, form alanları, seçim kutuları, açılır listeler, modal içeriği ve çerez tercihleri gibi tüm bileşenlerde kontrol edin.

Fareyle üzerine gelme ve klavyeyle odaklanma durumları aynı görsel açıklığı taşımalıdır. Yalnızca hover durumuna özel bilgi veriliyorsa, klavye kullanıcısı aynı içeriği göremeyebilir.

Odak, sayfa içinde kaybolmamalıdır. Sabit üst menü, çerez bildirimi veya açılır reklam, odaklanan öğenin üzerini kapatıyorsa kullanıcı hangi kontrolde olduğunu anlayamaz.

Bu kontrolün karşı durumu da önemlidir. Çok kalın, hareketli veya ekranın büyük bölümünü kaplayan odak efekti erişilebilirliği artırmayabilir. Görünürlük ile içerik okunabilirliği birlikte değerlendirilmelidir.

Menü, açılır liste ve modal pencere klavyeyle nasıl test edilir?

Menü, açılır liste ve modal pencere testinde açma, içeride gezinme, kapatma ve odağın geri dönmesi ayrı ayrı kontrol edilir.

Önce ana menüye Tab ile ulaşın ve Enter veya Space ile açmayı deneyin. Açılan alt menüdeki bağlantılara ulaşabiliyor musunuz? Menü kapanmadan bir sonraki bölüme geçebiliyor musunuz?

Menü açıldığında odak, kullanıcıya mantıklı bir noktada kalmalıdır. Büyük menülerde ok tuşları kullanılabilir. Ancak bu davranış, kullanıcıya görünür ipuçları vermeden uygulanırsa öğrenme yükü oluşturabilir.

Modal pencere açıldığında odak doğrudan pencerenin başlığına veya ilk etkileşimli öğesine taşınmalıdır. Kullanıcı, modal açıkken arka plandaki bağlantılara Tab ile geçememelidir.

Escape tuşunu deneyin. Modal kapanıyorsa odak, modalı açan butona geri dönmelidir. Odak sayfanın başına gidiyorsa kullanıcı önceki işlem bağlamını kaybedebilir.

Çerez tercih pencerelerinde de aynı test yapılmalıdır. Kullanıcı yalnızca “kabul et” seçeneğine değil, reddetme ve tercihleri yönetme seçeneklerine de klavye ile ulaşabilmelidir. İlgili ayrıntılar için web sitesinde reklam çerezi için rıza alma sürecini ayrıca inceleyebilirsiniz.

Modal veya açılır menü fareyle çalışıyor, fakat Enter ya da Space ile açılmıyorsa sorun vardır. Aynı şekilde kapatma simgesi yalnızca küçük bir ikon olarak kodlanmışsa klavye kullanıcısı pencereyi kapatamayabilir.

Bu test, her özel bileşenin davranışını ayrıca doğrular. Hazır bir arayüz kütüphanesi kullanmak, menünün otomatik olarak erişilebilir olduğu anlamına gelmez.

Formların klavye erişimi nasıl test edilir?

Form testi, tüm alanlara sırayla ulaşmayı, alanları doldurmayı, hataları anlamayı ve gönderimi tamamlamayı kapsar.

İlk olarak Tab sırasını izleyin. Etiket, giriş alanı ve açıklama metni kullanıcı tarafından anlaşılır sırada görünmelidir. Placeholder metni, kalıcı etiketin yerine kullanılmamalıdır.

Her alanın amacı açık olmalıdır. “Bilgi girin” gibi genel bir etiket, telefon veya e-posta alanının beklediği veriyi açıklamayabilir. Gerekli alanlar da yalnızca renk veya yıldızla belirtilmemelidir.

Formu eksik veriyle gönderin. Hata mesajı, ilgili alanla ilişkilendirilmeli ve klavye odağı hatanın bulunduğu noktaya taşınmalıdır. Kullanıcı hatayı görmek için sayfanın tamamını aramamalıdır.

Hata mesajı yalnızca kırmızı metin olarak verilmemelidir. Renk körlüğü olan kullanıcılar için metinsel açıklama gerekir. Örneğin “Telefon numarası 10 hane olmalıdır” ifadesi, genel “Hatalı giriş” mesajından daha işlevseldir.

Tab ile gönder butonuna ulaşın ve Enter ile Space tuşlarını deneyin. Formun iki kez gönderilmediğini de kontrol edin. Yükleme sırasında buton durumu kullanıcıya görünür olmalıdır.

Otomatik doldurma, maske ve tarih seçici bileşenlerini ayrıca deneyin. Telefon maskesi, kullanıcının rakam eklemesini engelliyorsa form klavye erişimine sahip görünse bile tamamlanamaz.

Form erişilebilirliği özellikle e-ticaret sitelerinde kritik bir adımdır. Ürün ve ödeme akışının tamamı klavyeyle çalışmıyorsa, e-ticaret sitelerinde erişilebilirlik değerlendirmesi yalnızca yasal başlıklara indirgenmemelidir.

Klavye erişimi için hangi kontrol listesi kullanılmalı?

Klavye erişimi kontrol listesi, her sayfada aynı adımları uygulayarak unutulan işlevleri azaltır.

• Sayfa yenilendikten sonra ilk Tab adımını ve “İçeriğe geç” bağlantısını kontrol edin.
• Tüm bağlantı, buton, form alanı ve özel bileşenlere klavye ile ulaşın.
• Her odak noktasının ekranda belirgin göründüğünü doğrulayın.
• Tab sırasının görsel ve içerik mantığıyla uyumlu olduğunu kontrol edin.
• Enter ve Space tuşlarıyla butonların beklenen işlemi yaptığını deneyin.
• Açılır menülerin, sekmelerin ve listelerin klavye ile kullanılabildiğini doğrulayın.
• Modal açıldığında odağın içeriye geçtiğini, kapanınca geri döndüğünü kontrol edin.
• Form alanlarının etiket, açıklama ve hata mesajlarını test edin.
• Yatay kaydırma veya yakınlaştırma sırasında odaklanan öğenin görünür kaldığını inceleyin.
• İşlem tamamlandığında başarı veya hata durumunun klavye kullanıcısına bildirildiğini kontrol edin.

Listeyi ana sayfa, hizmet sayfası, iletişim sayfası, kampanya sayfası ve ödeme adımında uygulayın. Tek bir sayfada başarılı sonuç almak, sitenin tamamının erişilebilir olduğunu göstermez.

Önceliği dönüşüm içeren akışlara verin. İletişim formu, teklif talebi, rezervasyon, üyelik ve ödeme işlemleri, içerik sayfalarından daha yüksek risk taşır.

Her bulgu için sayfa adresi, adım, kullanılan tuş, beklenen davranış ve gerçekleşen sonucu kaydedin. “Klavye çalışmıyor” yerine “Üçüncü Tab adımında menü açılmıyor” gibi ölçülebilir not yazın.

Kontrol listesi tek başına yeterli değildir. Kullanıcı testinde gerçek bir kişi aynı akışı tamamlayamıyorsa, teknik ekip listede hata görmese bile sorun araştırılmalıdır.

Manuel test ve otomatik araçlar nasıl karşılaştırılır?

Manuel klavye testi kullanıcı akışını gösterir; otomatik araçlar ise kod ve yapıdaki belirli hataları hızlıca tarar.

Otomatik tarama, testin başlangıç noktasıdır. Araç raporunda hata görünmemesi, her işlevin klavyeyle kullanılabildiği anlamına gelmez.

Örneğin bir özel açılır menü teknik olarak düğme rolüne sahip olabilir. Buna rağmen Enter sonrası odak doğru yere taşınmıyorsa kullanıcı menünün içeriğini kullanamaz.

Manuel testte bulduğunuz sorunları otomatik sonuçlarla eşleştirin. Aynı hata birkaç sayfada tekrarlanıyorsa ortak bileşeni düzeltmek, tek tek sayfa düzenlemekten daha doğru olabilir.

Ekran okuyucu testi, klavye testinin yerine geçmez. Ekran okuyucu kapalıyken bile görünür odak, sıra ve işlem davranışı sorunlu olabilir.

Test sonucunu “geçti” veya “kaldı” şeklinde sınırlamayın. Sorunun etkisini ve tekrarlanma alanını yazın. Böylece geliştirme önceliği daha net belirlenir.

Klavye erişimi testi hangi sırayla yapılır?

Klavye erişimi testi, önce temel gezinme sonra bileşen ve form akışları kontrol edilerek yapılmalıdır.

1. Test edilecek sayfaları seçin ve ana kullanıcı akışlarını yazın.
2. Sayfayı yenileyin, fareyi bırakın ve ilk Tab adımını kaydedin.
3. Tab ve Shift+Tab ile tüm odaklanabilir öğelerin sırasını izleyin.
4. Her odak noktasının görünür olduğunu ve ekran dışında kalmadığını kontrol edin.
5. Enter, Space, ok tuşları ve Escape ile etkileşimli bileşenleri deneyin.
6. Formu geçerli ve hatalı verilerle göndererek hata akışını test edin.
7. Modal, menü veya sekme açıldıktan sonra odağın hareketini inceleyin.
8. Bulguları ekran görüntüsü, sayfa adresi ve klavye adımıyla kaydedin.
9. Düzeltmelerden sonra aynı akışı yeniden çalıştırın ve sonucu karşılaştırın.

Bu sıra, sorunun kaynağını daha kolay ayırır. Önce odak gelmiyorsa form hata mesajını test etmek anlamlı değildir.

Her akışı en az bir kez baştan sona durmadan tamamlamayı deneyin. Kullanıcı, işlem sırasında fareye ihtiyaç duyuyorsa ilgili akış klavye açısından tamamlanmamıştır.

Landing page üzerinde özellikle başvuru veya iletişim formuna odaklanın. Landing page dönüşüm optimizasyonu yalnızca metin ve buton yerleşimiyle ölçülmez; formun kullanılabilirliği de sonucu etkiler.

Testi tasarım değişikliklerinden sonra tekrarlayın. Yeni bir sabit header, çerez katmanı veya JavaScript bileşeni önceki odak düzenini bozabilir.

İşletme sitelerinde bu kontrolü yayın öncesi kontrol sürecine eklemek daha güvenlidir. Sonradan fark edilen erişim sorunları, özellikle kampanya ve ödeme akışlarında daha geniş düzeltme gerektirebilir.

Klavye erişimi sorunları nasıl raporlanır ve düzeltilir?

Klavye erişimi sorunları, belirli adım, beklenen sonuç ve gerçekleşen sonuç yazılarak raporlanmalıdır.

Örnek rapor formatı şöyledir: “İletişim sayfası, dördüncü Tab adımı, odak telefon alanına geçiyor ancak görünmüyor. Beklenen sonuç, alan çevresinde belirgin odak göstergesidir.”

Önceliği kullanıcıyı işlemi tamamlamaktan alıkoyan hatalara verin. Hiç açılmayan menü, gönderilemeyen form ve modal içinde sıkışan odak, yalnızca görsel odak sorunlarından önce ele alınmalıdır.

Geliştirme ekibi düzeltme yaparken semantik HTML kullanımı, doğal belge sırası ve doğru buton elemanları ilk kontrol noktalarıdır. Her sorunda ARIA eklemek, yapısal hatayı otomatik olarak çözmez.

Düzeltme sonrası aynı tarayıcı ve aynı adımlarla yeniden test yapın. Ardından farklı bir sayfada ortak bileşeni deneyin. Böylece çözümün yalnızca tek bir örnekte çalışmadığını doğrularsınız.

Web sitesi yeniden tasarlanıyor veya yeni bir işletme sitesi hazırlanıyorsa, erişilebilirlik gereksinimleri tasarım aşamasında yazılmalıdır. Son aşamada eklenen odak stilleri, hatalı HTML sırasını düzeltmeyebilir.

AI destekli arama ve ajan deneyimleri de bu yapıyla ilişkilidir. Ajanların sayfadaki işlevleri anlayabilmesi için açık etiket, anlamlı düğme adı ve düzenli içerik yapısı gerekir. Bu nedenle AI ajanları için web sitesinde erişilebilirlik konusunu yalnızca ekran okuyucu başlığı olarak değerlendirmeyin.

Test sonucu bir uyum sertifikası gibi sunulmamalıdır. Klavye testi belirli kullanıcı akışlarını gösterir. Kapsamlı erişilebilirlik değerlendirmesi için ekran okuyucu, kontrast, yeniden boyutlandırma ve içerik yapısı da ayrıca incelenmelidir.