Klavye Erişilebilirliği: Web Siteniz Klavyeyle Gezilebilir mi?

Klavye erişilebilirliği, sitenizdeki her bağlantıya, düğmeye ve forma fare kullanmadan ulaşabilmek demektir. Bu rehberde Talha Aslan ve ekibi olarak odak düzenini, sekme sırasını, atlama bağlantısını ve menü ile modal tuzaklarını adım adım anlatıyoruz. Sonunda kendi sitenizde on dakikada uygulayabileceğiniz bir test planı ve kontrol listesi bulacaksınız.

Bu tanım kulağa basit gelir. Ancak pratikte sitelerin önemli bir kısmı ilk denemede sorun çıkarır: menü açılmaz, çerez bandı kapanmaz ya da odak çerçevesi tamamen kaybolur. Kısacası tasarım fareyle kusursuz görünse bile klavyede bambaşka bir deneyim sunabilir.

Bu yazıda genel erişilebilirlik konusunun yalnız bir dilimini, yani klavye erişilebilirliğini ele alıyoruz. Kavramın tamamını, renk ve metin alternatifleri dahil, web erişilebilirliği ve WCAG standartları rehberimizde anlattık. Burada ise yalnız klavye ve odak düzeni üzerinde duruyoruz.

Klavyeyle gezinme kimler için gerekli?

Klavyeyle gezinmeyi yalnız görme engelli kullanıcıların ihtiyacı sanmak yaygın bir yanılgıdır. Ekran okuyucu kullanan kişiler gerçekten klavyeye dayanır; ancak tek grup onlar değildir. Motor becerisi kısıtlı, el titremesi olan ya da fareyi uzun süre tutamayan kullanıcılar da klavyeyi ve klavye gibi davranan yardımcı cihazları tercih eder.

Öte yandan bu kitlenin bir kısmı geçici durumdadır. Bileği alçıda olan biri, dokunmatik yüzeyi bozulan bir dizüstü kullanıcısı ya da form doldururken hız isteyen bir muhasebeci de Tab tuşuyla ilerler. Ayrıca anahtar cihazı (switch), sesli komut yazılımı ve bazı göz takip sistemleri de arka planda klavye olaylarını taklit eder.

• Ekran okuyucu kullanan görme engelli ziyaretçiler.
• Motor becerisi kısıtlı ya da fareyi kullanamayan kişiler.
• Geçici sakatlığı olan veya donanımı arızalı kullanıcılar.
• Formları hızlı doldurmak isteyen deneyimli kullanıcılar.
• Klavye olayını taklit eden yardımcı teknolojilere güvenen herkes.

Yani klavye desteği küçük bir azınlık için eklenen bir süs değildir. Tersine, sitenizin temel kullanılabilirlik katmanıdır ve eksik olduğunda bu kişilerin tamamı formunuza ulaşamadan siteden çıkar.

WCAG klavye konusunda hangi ölçütleri koyar?

WCAG (Web İçeriği Erişilebilirlik Yönergeleri), W3C tarafından yayımlanan uluslararası erişilebilirlik standardıdır. Klavye ile ilgili ölçütler birkaç başlığa dağılmıştır ve her biri farklı bir sorunu hedefler. Aşağıdaki tablo, sahada en sık karşılaştığımız ölçütleri ve sitede neye karşılık geldiklerini özetliyor.

W3C'nin 2.1.1 Klavye ölçütü açıklamasına göre tek istisna, işlevin kendisinin kullanıcının hareket yoluna bağlı olmasıdır; serbest el çizimi buna örnektir. Bunun dışında sürükle bırak, boyut değiştirme veya bir öğeyi taşıma gibi işlevler için de klavye karşılığı sunmanız gerekir.

Odak (focus) nedir, odak göstergesi neden görünür olmalı?

Odak, klavyeden gelen girdinin o an hangi öğeye gideceğini belirleyen durumdur. Fareyle çalışan biri imleci gözüyle takip eder; klavye kullanıcısı ise yalnız odak göstergesini izler. Bu gösterge genellikle öğenin çevresinde beliren bir çerçeve, alt çizgi ya da renk değişimidir.

Belirgin bir gösterge yoksa kullanıcı karanlıkta yürür. Tab tuşuna basar, bir şeyin değiştiğini varsayar ama nerede olduğunu bilmez. Bu nedenle W3C'nin 2.4.7 Focus Visible (odak göstergesi) ölçütü, klavyeyle çalışan her arayüzde odak göstergesinin görünür olduğu bir kullanım biçimini şart koşar.

Tarayıcılar varsayılan bir çerçeve çizer. Ancak bu çerçeve her arka planda aynı netliği taşımaz; koyu bir başlık alanında mavi ince bir çizgi neredeyse kaybolabilir. Dolayısıyla varsayılanı olduğu gibi bırakmak yerine sitenizin renk paletine uygun, belirgin bir odak stili tasarlamanız daha güvenli bir yoldur.

Odak çerçevesini kaldırmak neden en yaygın hatadır?

Tasarım incelemelerinde en sık gördüğümüz klavye hatası, odak çerçevesinin stil dosyasında tamamen kapatılmasıdır. Genellikle gerekçe estetiktir: tasarımcı ya da müşteri, bir düğmeye tıklayınca beliren çerçeveyi "bozuk" bulur. Sonuç olarak tek satırlık bir kural, klavye kullanıcılarının sitedeki yönünü tamamen ortadan kaldırır.

Çözüm çerçeveyi silmek değil, ne zaman gösterileceğini ayırmaktır. Modern tarayıcıların desteklediği :focus-visible seçicisi tam olarak bu işe yarar. Tarayıcı, odağın klavyeyle mi yoksa fareyle mi geldiğini kendi sezgisiyle ayırır; böylece fare tıklamasında çerçeve çoğu zaman belirmez, Tab ile gelindiğinde ise belirir.

Örnek senaryo: bir hizmet sitesinin ana düğmeleri fareyle mükemmel çalışıyor, fakat klavyeyle gezen ziyaretçi hangi düğmede olduğunu göremiyor. Biz bu durumda önce çerçeveyi kapatan kuralı kaldırır, ardından :focus-visible ile marka renginde kalın bir çerçeve tanımlarız. Böylece tasarım dilini korursunuz, klavye kullanıcısı da yolunu bulur.

İyi bir odak göstergesini nasıl tasarlarsınız?

İyi bir odak göstergesi, sayfanın her bölümünde aynı netlikte göze çarpar. Tek bir rengin her arka planda işe yaramadığını unutmayın; açık zeminde koyu, koyu zeminde açık bir çizgi gerekir. Bu yüzden biz çoğu projede iki renkli bir yaklaşım kullanırız: iç tarafta koyu, dış tarafta açık bir halka.

• Çerçeveyi en az 2 piksel kalınlıkta tutun; ince çizgiler kolayca kaybolur.
• Öğe ile çerçeve arasında küçük bir boşluk (outline-offset) bırakın.
• Çerçeve rengi ile çevresindeki arka plan arasında güçlü bir kontrast sağlayın.
• Yalnız renk değişimine güvenmeyin; şekil ya da kalınlık farkı da ekleyin.
• Düğme, bağlantı, form alanı ve kart için aynı görsel dili kullanın.

Kontrastı göz kararı değil ölçerek kontrol edin. Örneğin renk kontrast kontrolü aracımızla odak renginizi başlık, gövde ve alt bilgi arka planlarıyla ayrı ayrı test edebilirsiniz. WCAG 2.2'deki daha sıkı "odak görünümü" ölçütü AAA düzeyindedir; yine de içindeki kalınlık ve kontrast mantığı iyi bir başlangıç noktası sunar.

Sekme sırasını nasıl belirlersiniz?

Sekme sırası, Tab tuşuna her bastığınızda odağın hangi öğeye geçeceğini gösteren dizidir. Tarayıcı bu sırayı HTML kaynak kodundaki sıraya göre kurar. Yani odak düzenini belirleyen asıl şey görsel yerleşim değil, öğelerin kodda yazıldığı sıradır.

Sorun da burada başlar. CSS ile öğeleri görsel olarak yer değiştirdiğinizde, örneğin flex ya da grid ile bir sütunu sağdan sola taşıdığınızda, ekranda gördüğünüz sıra ile Tab sırası birbirinden kopar. Kullanıcı sağ üstteki düğmeyi beklerken odak sayfanın altına atlar. W3C'nin 2.4.3 Odak Sırası ölçütü tam olarak bu kopukluğu önlemeyi amaçlar.

1. Önce sayfayı mantıklı okuma sırasıyla kodlayın: başlık, ana menü, ana içerik, yan alan, alt bilgi.
2. Görsel düzeni bu sırayı bozmayacak şekilde kurun.
3. Mobil ve masaüstü düzenlerde sırayı ayrı ayrı deneyin.
4. Sonradan eklenen içeriği (bildirim, açılan panel) tetikleyen öğenin hemen arkasına yerleştirin.

Kısacası klavye erişilebilirliği açısından doğru sekme sırasının sırrı ekstra kod değil, temiz bir HTML yapısıdır. Bu sayede ekran okuyucu da sayfayı aynı mantıkla okur.

tabindex değerini ne zaman kullanmalısınız?

tabindex, bir öğenin klavye odağına katılıp katılmayacağını belirleyen HTML özniteliğidir. MDN belgelerine göre üç durum vardır: 0 değeri öğeyi doğal sıraya ekler, -1 değeri öğeyi Tab sırasından çıkarır ama komutla odaklanabilir bırakır, pozitif değerler ise sırayı elle değiştirir.

MDN, pozitif değerleri kullanmamanızı açıkça önerir. Çünkü tabindex="1" verdiğiniz bir öğe, sayfadaki tüm doğal öğelerin önüne geçer ve sırayı tahmin edilemez hale getirir. Üstelik site büyüdükçe bu sayıları yönetmek imkânsızlaşır.

• tabindex="0": Özel bir bileşeni (örneğin kendi yazdığınız sekme kontrolü) odaklanabilir yapmak için.
• tabindex="-1": Bir hata mesajına ya da açılan modal başlığına odağı komutla taşımak için.
• Pozitif değer: Neredeyse hiçbir durumda; sorunu kaynak sırasını düzelterek çözün.

Öte yandan zaten odaklanabilen öğelere, yani bağlantı, düğme ve form alanlarına tabindex eklemeniz gerekmez. Gereksiz eklemeler hem kodu kirletir hem de bazen aynı öğenin iki kez odak almasına yol açar.

Atlama bağlantısı (skip link) nedir, nasıl kurarsınız?

Atlama bağlantısı, sayfanın en başında yer alan ve kullanıcıyı menüyü geçerek doğrudan ana içeriğe götüren bağlantıdır. Genellikle "İçeriğe geç" metnini taşır. Normalde ekranda yer kaplamaz; ziyaretçi sayfada ilk kez Tab tuşuna bastığında belirir.

Bu bağlantının değeri, kalabalık menülerde ortaya çıkar. Örnek senaryo: kurumsal bir sitenin başlığında 30 bağlantılık bir menü, dil seçici ve arama kutusu var. Atlama bağlantısı olmadan klavye kullanıcısı her sayfada bu öğelerin hepsinden tek tek geçmek zorunda kalır. W3C'nin 2.4.1 Blokları Atlama ölçütü bu tekrarı atlatacak bir yol ister ve atlama bağlantısını yeterli tekniklerden biri olarak listeler.

1. Bağlantıyı body etiketinin hemen ardından, ilk odaklanabilir öğe olarak ekleyin.
2. Hedef olarak ana içerik alanının kimliğini (id) verin.
3. Bağlantıyı görsel olarak gizleyin ama odak geldiğinde ekranın üstünde belirgin biçimde gösterin.
4. Bağlantıya basıldığında odağın gerçekten ana içeriğe geçtiğini Tab ile doğrulayın.

Ayrıca ana içeriği main etiketiyle, menüyü nav etiketiyle işaretlemek ekran okuyucu kullanıcılarına ek bir atlama imkânı sunar. Yine de görsel atlama bağlantısı, ekran okuyucu kullanmayan klavye kullanıcıları için hâlâ gereklidir.

Alt menüler klavyede neden sorun çıkarır?

Tasarımcılar alt menülerin büyük kısmını yalnız fare üzerine gelme (hover) olayına bağlar. Klavye kullanıcısı ana menü öğesine odaklandığında ise hiçbir şey olmaz; alt sayfalar ya hiç belirmez ya da ekranda olmadan odak alır. İkinci durum daha da kafa karıştırıcıdır, çünkü kullanıcı Tab'a bastıkça odak görünmeyen bağlantılarda kaybolur.

Daha sağlam bir yaklaşım, alt menüyü bir düğmeye bağlamaktır. Ana başlık bir bağlantı olarak kalır, yanındaki ok simgesi ise ayrı bir düğme olur. Kullanıcı bu düğmeye Enter ya da Boşluk ile bastığında alt menü belirir, düğmenin aria-expanded durumu da değişir. Böylece ekran okuyucu menünün açık mı kapalı mı olduğunu duyurur.

• Alt menü kapalıyken içindeki bağlantılar Tab sırasına girmemeli.
• Esc tuşu açık alt menüyü kapatmalı ve odağı açan düğmeye geri vermeli.
• Odak menünün dışına çıktığında alt menü kendiliğinden kapanmalı.

Mobil menüde de aynı kurallar geçerlidir. Hamburger simgesinin gerçek bir düğme olması, açılan panelin odak alması ve kapatma düğmesinin klavyeyle erişilebilir olması gerekir. Mobil navigasyon seçimini hamburger menü rehberimizde ayrıca ele aldık.

Modal pencerelerde odak tuzağını nasıl önlersiniz?

Modal pencere, sayfanın üzerinde açılan ve arkadaki içerikle etkileşimi geçici olarak durduran katmandır. Klavye açısından iki ters hata yaparsınız: odak modalın dışına kaçar ya da kullanıcı modaldan hiç çıkamaz. İkisi de deneyimi bozar; ancak W3C'nin ARIA Yazım Uygulamaları rehberindeki modal diyalog kalıbı doğru davranışı net biçimde tarif eder.

1. Modal açıldığında odağı modalın içindeki uygun bir öğeye taşıyın; genellikle ilk odaklanabilir öğe ya da başlık.
2. Tab ve Shift+Tab odağı modalın içinde döndürsün; son öğeden sonra ilk öğeye dönsün.
3. Esc tuşu modalı kapatsın.
4. Modal kapandığında odak, modalı açan düğmeye geri dönsün.
5. Arkadaki sayfa içeriği modal açıkken odak almasın.

Dördüncü madde en sık unutulan adımdır. Modal kapanınca odak sayfanın en başına düşerse kullanıcı kaldığı yeri kaybeder ve uzun bir sayfada yeniden aşağı inmek zorunda kalır. Bu nedenle modalı tetikleyen öğeyi bir değişkende saklayıp kapanışta odağı ona geri vermek, küçük ama değerli bir ayrıntıdır.

Modern tarayıcılardaki yerel dialog öğesi, showModal yöntemiyle açıldığında bu davranışların bir kısmını kendiliğinden sağlar. Yine de her projede klavyeyle elle test etmeden bu varsayıma güvenmeyin.

Klavye tuzağı ile modal odak kilidi arasındaki fark nedir?

İlk bakışta ikisi aynı şey gibi durur: her iki durumda da odak belirli bir alanın içinde kalır. Fark, çıkış yolunun var olup olmamasındadır. Modal odak kilidi bilinçli bir tasarım kararıdır ve kullanıcı Esc tuşu ya da kapatma düğmesiyle istediği an çıkabilir.

Klavye tuzağı ise bir hatadır. W3C'nin 2.1.2 ölçütü, odak bir bileşene girebiliyorsa yalnız klavyeyle oradan çıkabilmesini ister. Standart dışı bir çıkış yöntemi gerekiyorsa da kullanıcıya bunun söylenmesi gerekir. Gömülü video oynatıcılar, üçüncü taraf harita kutuları, sohbet pencereleri ve bazı zengin metin editörleri bu tuzağın klasik kaynaklarıdır.

• Modal kilit: Bilinçli, çıkışı açık, Esc ile kapanır.
• Klavye tuzağı: İstenmeyen, çıkışı yok, sayfayı yenilemeden kurtulamazsınız.
• Test yöntemi: Her gömülü öğeye Tab ile girin ve Tab, Shift+Tab ya da Esc ile çıkmayı deneyin.

Örneğin bir sohbet balonu açıldığında odağı yakalayıp bırakmıyorsa, ziyaretçi sayfanın geri kalanına ulaşamaz. Böyle bir durumda üçüncü taraf bileşenin ayarlarını kontrol eder, çözüm yoksa alternatifini değerlendiririz.

Yapışkan başlık ve çerez bandı odağı neden gizler?

Yapışkan (sticky) başlıklar, sayfa kaydırıldığında ekranın üstünde sabit kalan alanlardır. Çerez bandı ve sohbet balonu da genellikle ekranın altında sabit durur. Klavye kullanıcısı Tab ile ilerlediğinde tarayıcı odaklanan öğeyi ekrandaki alana kaydırır; ancak bu öğe sabit bir katmanın tam altına denk gelebilir.

Sonuç olarak odak oradadır ama kullanıcı onu göremez. WCAG 2.2 ile gelen 2.4.11 ölçütü, odaklanan öğenin sayfa yazarının eklediği içerik yüzünden tamamen gizlenmemesini ister. Bu ölçüt AA düzeyindedir; dolayısıyla AA hedefleyen her sitede dikkate alınmalıdır.

Pratik çözümler basittir. CSS'teki scroll-padding-top değerini yapışkan başlığın yüksekliğine göre ayarlarsanız tarayıcı öğeyi başlığın altına değil, hemen altına konumlandırır. Çerez bandında ise bandı odak sırasının başına almak ve kapatılana kadar sayfayı örtmemesini sağlamak işe yarar. Özellikle mobilde ekran küçük olduğu için bu sabit katmanları ayrıca deneyin.

Div ile yapılan düğmeler klavyede neden çalışmaz?

Bir düğmeyi button etiketi yerine div ya da span ile kurduğunuzda tarayıcı ona hiçbir yerleşik davranış vermez. Bu öğe odak almaz, Enter veya Boşluk tuşuna tepki vermez ve ekran okuyucu onu düğme olarak tanımlamaz. Fareyle tıklama çalıştığı için ekip bu hatayı tasarım aşamasında genellikle fark etmez.

Gerçek bir button etiketi ise bu davranışların hepsini ücretsiz sunar. Benzer biçimde sayfa değiştiren her öğe a etiketi, işlem başlatan her öğe button etiketi olmalıdır. Bu ayrım hem klavye hem de ekran okuyucu için anlamlıdır, çünkü kullanıcı bağlantının yeni bir yere götüreceğini, düğmenin ise bir işlem yapacağını bekler.

Örnek senaryo: bir ürün kartının tamamı tıklanabilir, ama kart yalnız fare olayına bağlı bir div. Klavye kullanıcısı kartlara hiç ulaşamaz ve ürün detayına geçemez. Bu durumda kartın içindeki ürün başlığını gerçek bir bağlantıya çevirip tıklama alanını CSS ile genişletmek en temiz çözümdür. Etkileşimli öğelerin genel tasarım ilkelerini etkileşimli web tasarım öğeleri yazımızda bulabilirsiniz.

Formlar, kaydırıcılar ve karuseller klavyede nasıl çalışmalı?

Formlar sitenizin para kazandığı yerdir; bu yüzden klavye erişilebilirliği testinde en çok zamanı onlara ayırın. Her alanın ekranda okunan bir etiketi olmalı, odak alanlar arasında mantıklı bir sırayla ilerlemeli ve hata mesajı göründüğünde odak ilgili alana ya da hata özetine taşınmalı. Ayrıca özel tasarım seçim kutuları ve tarih seçiciler, ok tuşlarıyla da çalışmalıdır.

Karuseller ve kaydırıcılar ise farklı bir sorun çıkarır. Otomatik dönen bir karusel, klavye kullanıcısı bir bağlantıya odaklanmışken o bağlantıyı ekrandan çekip alabilir. Bu nedenle durdurma düğmesi koymak, odak karuselin içindeyken otomatik dönüşü bekletmek ve önceki ile sonraki düğmelerini gerçek düğme olarak kurmak gerekir.

• Form alanlarında etiket ile alanı programatik olarak eşleştirin.
• Gönder düğmesine Enter ile ulaşılabildiğini doğrulayın.
• Karuselde görünmeyen slaytların bağlantıları Tab sırasına girmesin.
• Akordeon başlıklarını düğme olarak kurun ve açık ya da kapalı durumunu bildirin.

Form tasarımının dönüşüm tarafını randevu, teklif ve demo formu tasarımı yazımızda konuştuk; burada yalnız klavye davranışına odaklanıyoruz.

Klavye erişilebilirliği SEO'yu ve dönüşümü etkiler mi?

Google, klavye erişilebilirliğini doğrudan bir sıralama sinyali olarak açıklamış değildir. Bu nedenle "odak çerçevesi ekledik, sıralamamız yükselecek" gibi bir vaatte bulunmayız. Ancak dolaylı bağlar güçlüdür ve görmezden gelmek doğru olmaz.

Öncelikle klavye dostu bir site çoğu zaman temiz, anlamlı HTML üzerine kuruludur. Gerçek bağlantılar ve düğmeler, arama motoru tarayıcılarının da sayfanızı daha kolay anlamasını sağlar. Örneğin yalnız tıklama olayıyla çalışan sahte bağlantılar, tarayıcıların izleyebileceği bir adres sunmaz.

Dönüşüm tarafı ise daha nettir. Teklif formuna klavyeyle ulaşamayan bir ziyaretçi, ne kadar ikna olmuş olursa olsun başvurusunu tamamlayamaz. Dolayısıyla klavye testini, dönüşüm odaklı web tasarım sürecinin doğal bir adımı olarak görmenizi öneririz. Lighthouse gibi araçların erişilebilirlik puanı da bu testin bir kısmını yansıtır, ama tamamını değil.

Klavye testini on dakikada nasıl yaparsınız?

Klavye testi için özel bir yazılıma ihtiyacınız yok; bir tarayıcı ve on dakika yeterli. Fareyi masanın kenarına itin, hatta isterseniz kablosunu çıkarın. Ardından sitenizin en önemli üç sayfasını, yani ana sayfa, bir hizmet sayfası ve iletişim sayfasını sırayla deneyin.

1. Adres çubuğuna tıklayın ve ilk kez Tab tuşuna basın. Atlama bağlantısı belirdi mi?
2. Tab ile ilerlerken her adımda odağın nerede olduğunu görebiliyor musunuz?
3. Odak sırası ekrandaki okuma sırasını izliyor mu, yoksa zıplıyor mu?
4. Ana menüdeki alt menüleri Enter ya da Boşluk ile açıp Esc ile kapatabiliyor musunuz?
5. Çerez bandını ve varsa sohbet balonunu klavyeyle kapatabiliyor musunuz?
6. Bir modal açın: odak içeri girdi mi, Esc ile kapandı mı, odak açan düğmeye döndü mü?
7. Formu baştan sona doldurup gönderebiliyor musunuz? Hata mesajı odağı yönlendiriyor mu?
8. Yapışkan başlık ya da alt bant odaklanan öğeyi gizliyor mu?
9. Shift+Tab ile geri dönerken odak aynı düzeni izliyor mu?

Her "hayır" cevabını sayfa adresi ve öğe adıyla bir tabloya not edin. Böylece geliştirici ekibinize net, tekrarlanabilir bir hata listesi verirsiniz. Testi mobil görünümde de, tarayıcının cihaz öykünme modunda harici klavyeyle tekrarlayın.

Otomatik araçlar klavye sorunlarını yakalar mı?

Otomatik erişilebilirlik tarayıcıları değerlidir, ancak klavye sorunlarının yalnız bir kısmını yakalar. Örneğin pozitif tabindex değerlerini, etiketsiz form alanlarını ya da odaklanabilir olmayan etkileşimli öğelerin bazı türlerini işaretleyebilirler. Fakat odak sırasının mantıklı olup olmadığını veya modal kapandıktan sonra odağın nereye gittiğini bir algoritma tutarlı biçimde değerlendiremez.

Bu yüzden biz iki katmanlı çalışırız. Önce otomatik bir tarama ile kolay hataları temizleriz; ardından yukarıdaki elle test planını uygularız. Lighthouse'un erişilebilirlik raporu da otomatik denetimin bitiminde, elle kontrol etmeniz gereken maddeleri ayrıca listeler. Lighthouse kullanımını Lighthouse ile site testi rehberimizde adım adım anlattık.

Kısacası otomatik puan yüz çıksa bile klavye erişilebilirliği sorunları sürebilir. Puan bir başlangıç noktasıdır; asıl doğrulama, klavyeyi elinize alıp siteyi gerçekten kullanmaktır.

Örnek senaryo: hizmet sitesinde teklif formuna klavyeyle ulaşmak

Bu bölümdeki senaryo kurgusaldır ve tipik bir hata zincirini göstermek için kurguladık. Bir danışmanlık firmasının sitesinde ziyaretçi ana sayfadan teklif formuna ulaşmak istiyor. İlk Tab basışında odak çerçevesiz bir logo bağlantısına gidiyor, çünkü stil dosyası odak çerçevesini kapatmış.

Sonra kullanıcı menüye geliyor. "Hizmetler" alt menüsü yalnız fare üzerine gelince açıldığı için klavyede görünmüyor; fakat içindeki on iki bağlantı yine de odak alıyor. Kullanıcı görünmeyen bağlantılar arasında kayboluyor. Ardından sayfanın altındaki çerez bandı, odaklanan "Teklif al" düğmesini tamamen örtüyor.

Düzeltme planı dört adımdan oluşur: :focus-visible ile belirgin bir çerçeve eklemek, alt menüyü düğmeyle açılan yapıya çevirmek, atlama bağlantısı koymak ve çerez bandını odak sırasının başına alıp kapatılabilir yapmak. Bu adımların ardından kullanıcı aynı yolu birkaç Tab basışıyla, gözle takip ederek tamamlar.

Klavye erişilebilirliği kontrol listesi

Aşağıdaki listeyi her yeni sayfa yayına çıkmadan önce ve büyük tasarım değişikliklerinden sonra uygulamanızı öneririz. Maddelerin tamamı elle, birkaç dakikada kontrol edilebilir niteliktedir.

• Sayfadaki tüm bağlantı, düğme ve form alanlarına Tab ile ulaşabiliyorum.
• Odak göstergesi her arka planda belirgin ve kontrastı yeterli.
• Odak sırası görsel okuma sırasıyla uyumlu.
• Pozitif tabindex değeri kullanılmıyor.
• Sayfanın başında çalışan bir atlama bağlantısı var.
• Alt menüleri klavyeyle açabiliyor, Esc ile kapatabiliyorum.
• Kapalı menü ve gizli slayt bağlantıları odak almıyor.
• Modal açıldığında odak içeri giriyor, kapanınca açan düğmeye dönüyor.
• Hiçbir gömülü bileşende klavye tuzağı yok.
• Yapışkan başlık ve çerez bandı odaklanan öğeyi gizlemiyor.
• Etkileşimli öğelerde gerçek a ve button etiketleri var.
• Form hataları odağı doğru alana yönlendiriyor.

Bu listedeki her madde, bir önceki bölümlerde anlattığımız bir ölçüte ya da uygulamaya karşılık gelir. Dolayısıyla listeyi bir proje şablonuna ekleyip tasarım, geliştirme ve içerik ekiplerinizle paylaşabilirsiniz.

Odak düzenini tasarım aşamasında nasıl planlarsınız?

Klavye erişilebilirliği sorunlarının çoğu kodda değil, tasarım dosyasında doğar. Tasarımcı yalnız normal ve fare üzerine gelme durumlarını çizer, odak durumunu hiç tanımlamazsa geliştirici de bunu atlar. Bu yüzden biz her bileşen için odak durumunu tasarım sisteminin zorunlu bir parçası sayarız.

Pratikte bu, düğme, bağlantı, form alanı, kart ve menü öğesi için ayrı bir "odakta" görünümü çizmek anlamına gelir. Ayrıca her ekran tasarımının yanına Tab sırasını numaralarla gösteren kısa bir not eklemek, geliştirme ekibinin işini çok kolaylaştırır. Böylece sıra kararını tasarımcı verir, geliştirici yalnız uygular.

Bu yaklaşımı kullanıcı odaklı arayüz tasarımı ilkeleriyle birleştirdiğinizde klavye desteği proje sonunda yapılan bir düzeltme olmaktan çıkar, baştan gelen bir kalite standardına dönüşür.

Bunu sitenizde nasıl kurarız?

Yeni bir site tasarlarken klavye erişilebilirliğini ve odak düzenini ilk taslaktan itibaren plana katarız. Odak stillerini tasarım sistemine ekler, menü ve modal bileşenlerini yukarıdaki kalıplara göre kurar ve yayından önce elle klavye testinden geçiririz. Mevcut bir sitede ise önce bu yazıdaki test planıyla bir hata listesi çıkarır, ardından öncelik sırasına göre düzeltiriz.

Kendi sitenizin klavyede nasıl davrandığından emin değilseniz web tasarım hizmetimiz kapsamında bu düzenlemeleri biz kurarız. Sayfa sayınızı ve kullandığınız altyapıyı paylaşmanız yeterli; size kapsamı net bir teklif hazırlarız. Erişilebilir, hızlı ve dönüşüm odaklı bir site için web tasarım teklifi almak üzere sayfamızı ziyaret edebilirsiniz.