Klavye Erişilebilirliği: Web Sitenizi Tamamen Klavye ile Gezilebilir Hale Nasıl Getirirsiniz

Bir iş başvuru formu doldurmaya, bir tıbbi randevu almaya ya da çevrimiçi bir alışverişi tamamlamaya çalıştığınızı ve farenizin çalışmadığını hayal edin. Bozuk değil, sadece önemsiz: Tamamen Tab, Enter ve ok tuşlarına basarak gezinirsiniz. Dünya çapında milyonlarca insan için bu bir düşünce deneyi değil. Motor engelleri olan kişiler, tekrarlayan zorlanma yaralanmaları yaşayanlar, görme bozukluğu olanlar ve ekran okuyuculara güvenenler, web ile birincil arayüzleri olarak klavye gezinimine bağımlıdır. Yine de araştırmalar, web sitelerinin %85’inin yeterli klavye gezinimi sunamadığını ve bu kullanıcıları her gün temel dijital görevlerin dışında bıraktığını tutarlı biçimde gösteriyor. Siteniz bu çoğunluğun içindeyse, bu rehber sizin için.

Kimler Klavye Gezinimine Bağımlı — ve Neden Sandığınızdan Daha Önemli

Klavye erişilebilirliği, küçük bir kullanıcı dilimi için niş bir kaygı değildir. Buna bağımlı olan nüfus, çoğu geliştiricinin fark ettiğinden daha geniş ve çeşitlidir. Fare kullanamayan fiziksel engelli kişiler, ekrandaki fare imlecini göremeyen görme engelli kişiler ve fare kullanımını sınırlaması gereken tekrarlayan zorlanma gibi kronik rahatsızlıkları olan kişiler, web’e açılan kapıları olarak klavye gezinimine güvenir. Engelliliğin ötesinde, birçok güç kullanıcısı — geliştiriciler, yazarlar, veri girişi profesyonelleri — hız ve verimlilik için klavye kısayollarını tercih eder.

Ekran okuyucu kullanıcıları da başka büyük bir grubu temsil eder. Ekran okuyucular, odak ve anlamsal yapıya göre sayfa öğelerini yorumlar ve seslendirir; kullanıcılar içeriğin içinde tuş vuruşlarıyla hareket eder. Bir web sitesi klavye odağını korumaz veya mantıklı bir odak sırasını desteklemezse, ekran okuyucu ile gezinme tamamen çöker. Dragon NaturallySpeaking gibi ses tanıma yazılımları da klavye olayları üretir; bu da zayıf klavye desteğinin sesle kontrol edilen gezinmeyi de bozduğu anlamına gelir.

İş açısından gerekçe de aynı derecede ikna edicidir. Mevcut verilere göre, ABD’de engelli kişiler neredeyse yarım trilyon dolarlık harcanabilir gelire sahiptir. Web siteniz klavye ile erişilebilir değilse, bu pazarın önemli bir bölümünü aktif olarak geri çeviriyorsunuz demektir. Hukuki risk de gerçektir: Klavye erişilebilirliği, ADA, Section 508, Avrupa Erişilebilirlik Yasası ve küresel ölçekte EN 301 549 ile uyumun ölçütü olan WCAG’e uygunluk için esastır. Kullanıcının bir sayfa öğesinin içinde sıkışıp kaldığı ve çıkış yolu bulamadığı klavye tuzakları, erişilebilirlik davalarında yer alan açık WCAG ihlalleri olarak gösterilir.

Belki de en çarpıcı olan: Engelli kullanıcıların %71’i kullanımı zor buldukları bir web sitesini basitçe terk eder. Şikâyet etmezler. Giderler. Ve klavye erişilebilirliği sorunları genellikle formlar, modallar, gezinme menüleri ve ödeme akışları gibi en kritik etkileşim noktalarında kümelendiği için, zarar doğrudan dönüşüm oranlarınıza yansır.

WCAG Çerçevesi: Kurallar Gerçekte Ne Gerektiriyor

Web İçeriği Erişilebilirlik Yönergeleri (WCAG), klavye gereksinimlerini ağırlıklı olarak 2.1 Kılavuzu altında düzenler — “Tüm işlevselliği klavye ile kullanılabilir hale getirin.” Ne’nin ve ne’nin gerekmediğini anlamak, uyumluluğa giden ilk adımdır. 5 Ekim 2023’te resmi W3C standardı haline gelen ve mevcut çerçeveye dokuz yeni başarı ölçütü ekleyen WCAG 2.2, artık ADA, Section 508 ve Avrupa Erişilebilirlik Yasası için önerilen standarttır.

Bilmeniz gereken temel klavye ile ilgili başarı ölçütleri şunlardır:

• SC 2.1.1 Keyboard (Seviye A): Tüm işlevsellik, tek tek tuş vuruşları için belirli bir zamanlama gerektirmeden bir klavye arayüzü üzerinden kullanılabilir olmalıdır; temel işlev yol bağımlı girdi (serbest çizim gibi) gerektirdiği durumlar hariç. Bu taban seviyedir — her etkileşimli öğe klavye ile erişilebilir ve kullanılabilir olmalıdır.
• SC 2.1.2 No Keyboard Trap (Seviye A): Klavye odağı klavye kullanılarak bir bileşene taşınabiliyorsa, odak yalnızca klavye kullanılarak o bileşenden uzaklaştırılabilmelidir. Çıkmak için standart olmayan bir yöntem gerekiyorsa, kullanıcılar bu konuda bilgilendirilmelidir. Klavye tuzakları, klavye kullanıcıları için mutlak bir engeldir.
• SC 2.4.3 Focus Order (Seviye A): Bir web sayfası sıralı olarak gezilebiliyorsa, odak sırası anlamı ve kullanılabilirliği korumalıdır. Mantıklı, öngörülebilir bir tab sırası tartışmaya açık değildir.
• SC 2.4.7 Focus Visible (Seviye AA): Klavye ile kullanılabilen her kullanıcı arayüzünün, klavye odak göstergesinin görünür olduğu bir modu olmalıdır. Kullanıcılar sayfada nerede olduklarını her zaman görebilmelidir.
• SC 2.4.11 Focus Not Obscured (Minimum) (Seviye AA — WCAG 2.2’de yeni): Klavye ile odaklanabilir bir öğe odak aldığında, yapışkan başlıklar veya çerez bildirimleri gibi yazar tarafından oluşturulan içerik tarafından tamamen gizlenmemelidir.
• SC 2.4.12 Focus Not Obscured (Enhanced) (Seviye AAA): Odaklanmış bileşenin hiçbir bölümünün yazar tarafından oluşturulan içerik tarafından gizlenmemesini gerektiren daha katı bir sürüm.
• SC 2.5.8 Target Size (Minimum) (Seviye AA — WCAG 2.2’de yeni): Etkileşimli hedefler en az 24x24 CSS piksel olmalıdır; bu da sınırlı motor kontrolü olan kullanıcılar için hataları azaltır.
• SC 2.5.7 Dragging Movements (Seviye AA — WCAG 2.2’de yeni): Sürükleme gerektiren her işlevselliğin tek işaretçiyle kullanılabilen bir alternatifi olmalıdır — bu da dolaylı olarak sürükleme işlemi yapamayan klavye kullanıcılarına fayda sağlar.

WCAG 2.2, WCAG 2.1 ile tamamen geriye dönük uyumludur — ölçütler ekler ama hiçbirini kaldırmaz (artık geçersiz olan 4.1.1 Parsing hariç). Siteniz zaten WCAG 2.1 AA ile uyumluysa, yalnızca altı yeni Seviye AA ölçütünü uygulamanız gerekir. Özellikle klavye erişilebilirliği için, odaklanmış öğelerin hiçbir zaman yapışkan sayfa bileşenleri tarafından tamamen gizlenmemesini sağlamak, WCAG 2.1’in açıkça ele almadığı yaygın bir gerçek dünya sorununa getirilen büyük yeni eklemedir.

WCAG ilkesi ifade etmesi basit, uygulaması zorludur: Tüm işlevsellik klavye kullanılarak gerçekleştirilebiliyorsa, klavye kullanıcıları, konuşma girdisi, ekran klavyeleri ve simüle edilmiş tuş vuruşları üreten çok çeşitli yardımcı teknolojiler tarafından da gerçekleştirilebilir. Bu esnekliğe sahip başka hiçbir girdi biçimi yoktur ve hiçbiri evrensel olarak desteklenmemektedir.

En Yaygın Klavye Erişilebilirliği Hataları (ve Bunlara Ne Sebep Olur)

Manuel denetimler, klavye erişilebilirliği sorunlarının web’deki en yaygın ve en yıkıcı erişilebilirlik engelleri arasında olduğunu tutarlı biçimde ortaya koyuyor. Geniş ölçekli bir çalışmada, form içeren sayfaların %54’ünde, form alanları arasında tab ile geçme, açılır pencereleri kapatma veya Gönder düğmelerine basma gibi kritik kullanıcı eylemlerini etkileyen klavye erişilebilirliği sorunları bulundu. Test uzmanları, yalnızca klavye ile kontrol edemedikleri öğelerde sıkışıp kaldıktan sonra alışveriş sepetlerini terk etmeye veya sayfaları yenilemeye sık sık zorlandı.

Temel nedenler, ayrıntılı incelemeye değer birkaç yinelenen desen etrafında kümelenir.

1. Yalnızca fareye bağlı olay işleyicileri. <div> öğeleri üzerinde eşdeğer klavye olay işleyicileri olmadan onmouseover, onmouseout veya onclick kullanmak en yaygın hatalardan biridir. Tıklama işleyicisine sahip bir <div> bir düğme değildir — örtük bir klavye rolü yoktur, Tab ile odak almaz ve Enter veya Space’e yanıt vermez. ARIA ile role='button' eklemek ekran okuyuculara yardımcı olur ama yine de manuel olarak tabindex='0', onkeydown ve onkeyup işleyicileri eklemenizi gerektirir. Doğru çözüm neredeyse her zaman gerçek bir <button> öğesi kullanmaktır.

2. Bastırılmış odak çizgileri. En yaygın sorunlardan biri, küresel olarak veya odaklanmış öğelere uygulanan outline: none veya outline: 0 CSS kuralıdır. Tasarımcılar, belirli temalarda çirkin göründüğü için tarayıcının varsayılan odak halkasını sıklıkla kaldırır. Sonuç olarak, klavye kullanıcıları sayfada nerede olduklarını hiç bilemez. Bu, WCAG SC 2.4.7’nin doğrudan ihlalidir ve oluşturulması da düzeltilmesi de en kolay sorunlardan biridir.

3. Modallar, bileşenler ve iframe’lerde klavye tuzakları. Odağı doğru şekilde sınırlamayan modal diyaloglar, Tab tuşunun modaldan geçip görünmeyen arka plan içeriğine ilerlemesine izin verir; bu da modalı klavye ile kapatmayı imkânsız hale getirir. Üçüncü taraf bileşenler — sohbet araçları, video oynatıcılar, tarih seçiciler, harita gömülüleri — özellikle buna yatkındır; çünkü iç klavye işleme mantıkları sizin için opaktır.

4. Mantıksız tab sırası. Varsayılan klavye gezinme sırası, DOM kaynak sırasına göre belirlenir. Geliştiriciler, görsel sunumu DOM sırasından bağımsız olarak yeniden düzenlemek için CSS Grid, Flexbox veya CSS konumlandırma kullandığında, Tab odağı ekranda görsel yerleşimle tamamen bağlantısız şekillerde zıplar. Belirli bir sırayı zorlamak için kullanılan pozitif tabindex değerleri (örneğin tabindex='2'), gerçek dünya senaryolarının çoğunda bu sorunu önemli ölçüde kötüleştirir.

5. Yalnızca hover ile açılan açılır menüler. Yalnızca fareyle üzerine gelindiğinde açılan, klavye tetikleyicisi olmayan gezinme menüleri, klavye kullanıcılarını ortada bırakır. Bu, alt menülerin yalnızca :hover ile göründüğü, ancak hiçbir zaman odak tabanlı gezinmeye açılmadığı CSS tabanlı açılır menülerde son derece yaygın bir desendir.

6. Dinamik etkileşimlerden sonra odağın geri verilmemesi. Bir modal, çekmece veya flyout kapatıldığında, odak tetikleyici öğeye geri dönmelidir. Dönmezse — sayfanın en üstüne giderse veya belirsiz bir konuma kaybolursa — kullanıcı tamamen kaybolur. Dinamik tek sayfa uygulamaları bu duruma özellikle açıktır.

Klavye Erişilebilirliğini Doğru İnşa Etmek: Pratik Uygulama

Hata desenlerini akılda tutarak, tipik bir web sitesinin en önemli alanlarında doğru uygulamanın nasıl göründüğüne bakalım.

Önce Anlamsal HTML Kullanın

Yerel HTML öğeleri varsayılan olarak klavye ile erişilebilirdir. Bağlantılar (<a href>), düğmeler (<button>), form girdileri, select’ler ve textarea’lar tab sırasına katılır, standart tuş vuruşlarına yanıt verir ve rolleri hakkında yardımcı teknolojilere bilgi verir — üstelik tek satır ek JavaScript olmadan. Bir <button> öğesi otomatik olarak doğru role sahiptir, klavye ile erişilebilirdir, Enter ve Space’e yanıt verir ve yerleşik doğru odak yönetimine sahiptir. Bir <div> öğesine role='button' eklemek doğru rolü verir ama yine de klavye desteğini ve odak yönetimini manuel olarak uygulamanızı gerektirir. Her zaman anlamsal HTML’yi tercih edin.

<!-- Kaçınılmalı: düğme gibi davranan anlamsal olmayan div -->
<div onclick='doSomething()' class='btn'>Submit</div>

<!-- Doğru: yerel button öğesi -->
<button type='button' onclick='doSomething()'>Submit</button>

Odak Göstergelerinizi Düzeltin

Tarayıcının varsayılan outline’ını kaldırmak yerine, onu stillendirilmiş özel bir odak göstergesiyle değiştirin. WCAG 2.2 SC 2.4.11, odak göstergesi alanının, odaklanmamış bileşenin çevresinde 2 CSS piksel kalınlığında bir çerçeve kadar büyük olmasını ve odaklanmış ve odaklanmamış durumlar arasında en az 3:1 kontrast oranı olmasını gerektirir. Odak göstergelerini yalnızca klavye kullanıcıları için göstermek ve fare etkileşimi estetiğini bozmamak için :focus yerine :focus-visible pseudo-class’ını kullanın.

/* Varsayılanı kaldırın ama yerine daha iyi bir gösterge koyun */
*:focus {
  outline: none;
}

*:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 3px;
  border-radius: 2px;
}

Bu yaklaşım, WCAG uyumluluğunu korurken size tam görsel kontrol sağlar. Özellikle koyu temalı sitelerde veya görseller üzerinde, odak renginin hem arka plana hem de bileşenin kendisine karşı yeterli kontrasta sahip olduğundan emin olun.

Dinamik Etkileşimlerde Odağı Yönetin

İçerik dinamik olarak değiştiğinde — bir modal açmak, yeni içerik yüklemek, bir öğeyi kaldırmak — odağı programatik olarak yönetmeniz gerekir. Bir modal açarken, odağı içindeki ilk odaklanabilir öğeye taşıyın. Kapatırken, odağı tetikleyici öğeye geri verin. Bunun için JavaScript’in .focus() metodunu kullanın. Odağı bir modal içinde doğru şekilde hapsetmek için, Tab ve Shift+Tab tuş olaylarını yakalayın ve odağı diyalog içindeki ilk ve son odaklanabilir öğe arasında döndürün.

// Modal açılırken: odağı içeri taşıyın
function openModal(modalEl, triggerEl) {
  modalEl.removeAttribute('hidden');
  const firstFocusable = modalEl.querySelector(
    'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
  );
  if (firstFocusable) firstFocusable.focus();
}

// Modal kapanırken: odağı tetikleyiciye geri verin
function closeModal(modalEl, triggerEl) {
  modalEl.setAttribute('hidden', '');
  triggerEl.focus();
}

Gezinmeyi Atla Bağlantıları Uygulayın

Klavye kullanıcıları, her sayfa yüklemesinde ana içeriğe gelmeden önce başlıklar, gezinme menüleri, arama çubukları gibi her etkileşimli öğe üzerinden geçmek için Tab tuşuna basmak zorundadır. Gezinmeyi atla bağlantıları çözüm sunar: Sayfanın en üstünde, odak aldığında görünür hale gelen ve kullanıcıları doğrudan ana içerik alanına atlatan, görsel olarak gizli bir bağlantı. Bunlar Seviye A WCAG gereksinimidir ve mevcut en etkili hızlı kazanımlardan biridir.

<!-- <body> içinde ilk öğe olarak yerleştirin -->
<a href='#main-content' class='skip-link'>Skip to main content</a>

<!-- Ana içerik kapsayıcısındaki hedef anchor -->
<main id='main-content' tabindex='-1'>
  <!-- page content -->
</main>

/* Gezinmeyi atla bağlantısını yalnızca klavye odağında gösterin */
.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  background: #000;
  color: #fff;
  padding: 8px 16px;
  z-index: 100;
  transition: top 0.2s;
}

.skip-link:focus {
  top: 0;
}

Erişilebilir Gezinme Menülerini Oluşturun

Açılır alt menülere sahip gezinme menüleri dikkatli bir yaklaşım gerektirir. Bir gezinme menüsü için doğru klavye etkileşim deseni şudur: Tab, üst düzey öğeler arasında hareket eder; Enter veya Space bir alt menüyü açar; ok tuşları alt menü içinde gezinir; Escape alt menüyü kapatır ve odağı tetikleyiciye geri verir. Durumu iletmek için ARIA özniteliklerini kullanın. Yalnızca hover ile açılan ve klavye tetikleyicisi olmayan menüler erişilebilir değildir ve düzeltilmelidir.

<nav aria-label='Main navigation'>
  <ul role='menubar'>
    <li role='none'>
      <button
        aria-haspopup='true'
        aria-expanded='false'
        aria-controls='products-menu'>
        Products
      </button>
      <ul role='menu' id='products-menu' hidden>
        <li role='none'>
          <a role='menuitem' href='/software'>Software</a>
        </li>
        <li role='none'>
          <a role='menuitem' href='/hardware'>Hardware</a>
        </li>
      </ul>
    </li>
  </ul>
</nav>

Açık/kapalı durumu iletmek için JavaScript ile aria-expanded='false' ve aria-expanded='true' arasında geçiş yapın. Bir düğmenin bir menü veya diyalog açtığını belirtmek için aria-haspopup='true' kullanın. Escape tuşunun alt menüyü kapattığından ve odağı düğme tetikleyiciye geri verdiğinden emin olun.

tabindex’i Doğru Kullanın

tabindex için anlamlı üç değer vardır ve her birinin farklı bir amacı vardır. tabindex='0', etkileşimli olmayan bir öğeyi doğal tab sırasına ekler — gerçekten odak alması gereken etkileşimli olmayan bir öğeniz (örneğin özel bir bileşen kapsayıcısı) olduğunda bunu kullanın. tabindex='-1', bir öğeyi tab sırasından çıkarır ama .focus() ile programatik olarak odak almasına izin verir — modalların hedefleri ve gezinmeyi atla bağlantılarının varış noktaları için gereklidir. Pozitif tabindex değerleri (örneğin tabindex='1' veya tabindex='5'), doğal sırayı, çoğu durumda çözdüklerinden daha fazla sorun yaratacak şekilde geçersiz kılar; bunlardan tamamen kaçının ve bunun yerine DOM sırasını düzeltin.

ARIA: Güçlü Bir Araç, Sihirli Bir Çözüm Değil

Accessible Rich Internet Applications (ARIA) öznitelikleri, yerel HTML’nin kapsamadığı sekmeler, akordeonlar, ağaç görünümleri, karuseller, combo box’lar gibi özel bileşenleri yardımcı teknolojilerin anlamasına yardımcı olmak için HTML’nin anlamsal yapısını genişletir. ARIA öznitelikleri ek bağlam sağlayabilir, ancak anlamsal HTML’nin yerini değil, onu tamamlamalıdır. Yaygın ve tehlikeli bir hata, yerel bir HTML öğesinin işi görüp göremeyeceğini düşünmeden ARIA’ya başvurmaktır.

ARIA’nın ilk kuralı şudur: Aynı işi yapabilecek yerel bir HTML öğesi veya özniteliği varsa ARIA kullanmayın. İkinci kural: Kötü ARIA’dansa hiç ARIA olmaması daha iyidir. Yanlış ARIA işaretlemesi — örneğin, uygun role='menuitem' çocuk hiyerarşisi olmadan role='menu' uygulamak veya odak alan bir öğeye aria-hidden='true' vermek — erişilebilirliğe yardımcı olmak yerine aktif olarak zarar verebilir.

ARIA gerçekten gerektiğinde, klavye etkileşimleri için en yaygın yararlı öznitelikler şunlardır: Katlanabilir öğelerde açık/kapalı durumunu iletmek için aria-expanded; bir tetikleyiciyi kontrol ettiği içerikle ilişkilendirmek için aria-controls; bir düğmenin bir menü veya diyalog açtığını belirtmek için aria-haspopup; arka plan içeriğinin etkisiz olduğunu belirtmek için diyalog öğelerinde aria-modal='true'; ve odak taşınmadan ekran okuyucu kullanıcılarına dinamik içerik değişikliklerini duyurmak için aria-live bölgeleri (durum mesajları için polite, acil uyarılar için assertive).

İnce ama önemli bir nokta: NVDA ve JAWS gibi ekran okuyucular kendi klavye kısayollarını kullanır — örneğin NVDA’da H tuşuna basmak, kullanıcıyı sayfadaki bir sonraki başlığa götürür. Geliştiriciler, bu yardımcı teknoloji komutlarıyla çakışan özel uygulama kısayolları oluşturmaktan kaçınmalıdır.

Klavye Erişilebilirliğini Test Etmek

Şu anda çalıştırabileceğiniz en etkili test, hiçbir araca ihtiyaç duymaz: Farenizin fişini çekin ve web sitenizde yalnızca klavyeyi kullanarak gezinin. Etkileşimli öğeler arasında ilerlemek için Tab, geri gitmek için Shift+Tab, bağlantıları ve düğmeleri etkinleştirmek için Enter, onay kutularını değiştirmek ve düğmeleri etkinleştirmek için Space, modalları ve menüleri kapatmak için Escape ve bileşenler içinde gezinmek için ok tuşlarını kullanın. Kendinize şunu sorun: Her etkileşimli öğeye ulaşabiliyor musunuz? Nerede olduğunuzu her zaman görebiliyor musunuz? Yalnızca klavye ile hiçbir yerde sıkışmadan tüm kritik kullanıcı yolculuklarını tamamlayabiliyor musunuz?

Otomatik araçlar, özellikle eksik etiketler, boş düğmeler ve bazı odak yönetimi sorunları gibi klavye erişilebilirliği sorunlarının anlamlı bir alt kümesini yakalayabilir. axe DevTools, WAVE ve Lighthouse gibi araçlar değerli ilk taramalardır. Ancak otomatik araçlar WCAG sorunlarının yalnızca yaklaşık %40’ını tespit eder. Odak görünürlüğü, mantıklı odak sırası ve doğru ARIA durum yönetimi, manuel insan değerlendirmesi gerektirir. En kapsamlı değerlendirme için, otomatik taramayı birden fazla tarayıcıda yalnızca klavye ile yapılan manuel testlerle birleştirin ve NVDA (Windows), JAWS (Windows) veya VoiceOver (macOS/iOS) ile ekran okuyucu testlerini dahil edin.

Yeni bir bileşen veya sayfa yayınladığınız her seferinde manuel olarak test etmeniz gereken bazı özel senaryolar: Yalnızca Tab, Enter ve Escape kullanarak her açılır menüyü, modali ve akordeonu açıp kapatabiliyor musunuz? Bir modal kapandığında, odak tetikleyiciye geri dönüyor mu? Gezinmeyi atla bağlantısı ilk Tab basışında görünüp çalışıyor mu? Tab odağının görünür bir gösterge olmadan kaybolduğu herhangi bir nokta var mı? Sayfada tab ile ilerlerken yapışkan başlıklar veya çerez bildirimleri odaklanmış öğeleri gizliyor mu?

Bileşen kütüphaneleri oluşturan ekipler için, W3C tarafından yayımlanan WAI-ARIA Authoring Practices Guide (APG), akordeonlardan ve karusellerden tarih seçicilere ve ağaç görünümlerine kadar onlarca bileşen türü için klavye etkileşim desenlerinin kesin başvuru kaynağıdır. Her desen, hangi tuşların desteklenmesi gerektiğini ve beklenen davranışın ne olması gerektiğini tam olarak belirtir.

Yapışkan Başlıklar, Sabit Altbilgiler ve Odağın Gizlenmesi

WCAG 2.2’deki en pratik açıdan önemli yeni gereksinimlerden biri, 2.4.11 Başarı Ölçütü: Focus Not Obscured’dur. Modern web’i adeta tanımlayan kadar yaygın bir sorunu ele alır: Sayfa içeriğinin üzerinde duran yapışkan gezinme çubukları, çerez onay bildirimleri, sohbet bileşenleri ve sabit altbilgiler. Bir klavye kullanıcısı, bu sabit katmanlardan birinin arkasına kaydırılmış bir öğeye tab ile geldiğinde, odaklanmış öğe görünmez hale gelir — kullanıcı neyle etkileşimde olduğunu göremez.

Çözüm, CSS ve JavaScript arasında koordinasyon gerektirir. Bir öğe odak aldığında, tarayıcı onu görünür bir alana kaydırmalıdır. Ancak örneğin 80px yüksekliğinde position: fixed bir yapışkan başlık, görünüm alanının üst 80px’inin kalıcı olarak işgal edildiği anlamına gelir. CSS scroll padding bunu telafi edebilir:

html {
  /* Yapışkan başlığınızın yüksekliği + küçük bir tampon */
  scroll-padding-top: 96px;
}

Bu, tarayıcıya kaydırma sabitlemesini belirtilen miktar kadar dengelemesini söyler; böylece odaklanmış bir öğeyi otomatik olarak görünür alana kaydırdığında sabit başlığı hesaba katar. Yapışkan bir altbilginiz varsa, eşdeğer scroll-padding-bottom değerine de ihtiyaç duyabilirsiniz. Görünüp kaybolan çerez bildirimleri veya katmanlar için, odaklanmış öğeyi kapatmayacak z-index değerlerine sahip olduklarından veya bildirim görünürken kaydırma dolgularını dinamik olarak ayarladığınızdan emin olun.

Temel Çıkarımlar

• Anlamsal HTML en iyi ilk hamlenizdir. <button>, <a> ve form kontrolleri gibi yerel öğeler varsayılan olarak klavye ile erişilebilirdir. div’lerden inşa edilen her özel bileşen, ARIA ve JavaScript ile yeniden inşa etmeniz gereken erişilebilirlik maliyeti yaratır.
• Odak göstergelerini yerlerine bir şey koymadan asla bastırmayın. Küresel outline: none kuralı, bir stil sayfasına koyabileceğiniz en zararlı şeylerden biridir. WCAG 2.2’nin minimum boyut ve kontrast gereksinimlerini karşılayan, stillendirilmiş, yüksek kontrastlı bir odak halkası sağlamak için :focus-visible kullanın.
• Her dinamik etkileşim için odağı programatik olarak yönetin. Modallar, çekmeceler, toast bildirimleri ve dinamik içerik değişikliklerinin tümü, odağı içeri taşımak ve kapanışta geri vermek gibi açık odak yönetimi gerektirir. Bunlar olmadan, klavye kullanıcıları arayüz her değiştiğinde bulundukları yeri kaybeder.
• Her sayfanın en üstüne bir gezinmeyi atla bağlantısı ekleyin. 20 satırdan az kodla yapılabilir ve aksi halde her sayfa yüklemesinde tüm başlık ve gezinme üzerinden tab ile geçmek zorunda kalacak klavye kullanıcılarının deneyimini dramatik biçimde iyileştirir.
• Yayınlamadan önce klavyenizle test edin. Otomatik araçlar, klavye erişilebilirliği sorunlarının yalnızca küçük bir kısmını yakalar. En kritik kullanıcı yolculuklarınızın on dakikalık yalnızca klavye ile gözden geçirilmesi, hiçbir tarayıcının bulamayacağı gerçek engelleri ortaya çıkarır — ve ekipteki herhangi bir geliştirici tarafından özel eğitim olmadan yapılabilir.