WCAG 2.4.3: Odak Sırası

Bu Kuralın Anlamı

WCAG 2.4.3 Odak Sırası, İşletilebilirlik ilkesinin altında Seviye A başarı ölçütüdür. Şöyle der: "Bir Web sayfası sıralı olarak gezilebiliyorsa ve gezinme sıraları anlamı veya işleyişi etkiliyorsa, odaklanabilir bileşenler, anlamı ve işletilebilirliği koruyan bir sırayla odak alır."

Pratikte bu, bir kullanıcı sayfadaki etkileşimli öğeler arasında — bağlantılar, butonlar, form alanları, özel bileşenler ve diğer tüm odaklanabilir bileşenler — ilerlemek için Tab tuşuna bastığında, bu öğelerin odak alacağı sıranın mantıklı olması gerektiği anlamına gelir. Kullanıcılar kendilerini bir formun ortasından beklenmedik şekilde altbilgi bağlantısına, oradan tekrar bir modal butonuna, sonra da bir gezinme menüsü öğesine atlamış halde bulmamalıdır.

Bu ölçüt, klavye ile sıralı gezinme için geçerlidir; bu, yalnızca klavye kullanan kullanıcıların ve ekran okuyucu kullanıcılarının bir sayfada dolaşmasının birincil yoludur. DOM sırası, tarayıcılarda odak sırasının varsayılan kaynağıdır: öğeler, Belge Nesne Modeli'nde (DOM) göründükleri sırayla tab dizisine girer; CSS veya JavaScript bu sırayı bilerek değiştirmediği sürece. Görsel yerleşim DOM sırasından saptığında (örneğin CSS Flexbox veya Grid ile yeniden sıralama yoluyla) ya da tabindex değerleri doğal olmayan bir sıra dayattığında sorunlar ortaya çıkar.

Geçer sayılan durumlar: Odak sırası mantıklı ve anlamlı olmalıdır — görsel okuma sırasıyla birebir aynı olmak zorunda değildir, ancak kullanıcıların sayfayı anlayıp kullanabileceği kadar tutarlı olmalıdır. Açıldığında odağı kendisine taşıyan, açık olduğu sürece odağı içinde tutan ve kapandığında odağı tetikleyici öğeye geri döndüren bir modal iletişim kutusu bu ölçütü karşılar. Tab tuşunun, kullanıcının dolduracağı sıraya göre (soldan sağa dillerde yukarıdan aşağıya, soldan sağa) her adımda form alanları arasında ilerlediği çok adımlı bir form da bu ölçütü karşılar.

Başarısız sayılan durumlar: Odağın bir oturum açma formundaki "Kullanıcı adı" alanından, "Şifre" alanına gelmeden önce tamamen alakasız bir tanıtım banner’ına atlaması başarısızlıktır. Bir iletişim kutusu açan, ancak odağı arka plandaki sayfada bırakan tek sayfa uygulaması başarısızdır. Sayfa genelinde mantıksız bir tab sırası zorlayan pozitif tam sayı tabindex değerleri (örneğin tabindex='2', tabindex='5') kullanmak da başarısızlıktır.

Resmî istisnalar: WCAG, odak sırasının, anlam ve işletilebilirlik korunduğu sürece, görsel okuma sırasıyla eşleşmek zorunda olmadığını açıkça belirtir. Ayrıca, gezinme sıralarının anlamı veya işleyişi etkilemediği durumlar için de bir esneklik vardır — örneğin, yalnızca tek bir odaklanabilir öğe içeren bir sayfada değerlendirilecek bir sıra yoktur. Ek olarak, anlamı koruyan birden fazla geçerli sıralama olduğunda, bunların herhangi biri kabul edilebilir.

Odak sırasını etkileyen temel HTML ve JavaScript mekanizmaları şunlardır: etkileşimli öğelerin doğal DOM sırası, tabindex özniteliği (özellikle pozitif tam sayı değerler), DOM’u değiştirmeden görsel yerleşimi yeniden sıralayan CSS özellikleri (Flexbox/Grid’deki order, position: absolute ve float gibi), JavaScript odak yönetimi (.focus() çağrıları) ve açık odak yönetimi gerektiren ARIA dialog kalıpları.

Neden Önemlidir

Odak sırası küçük bir teknik ayrıntı değildir — kullanıcıların önemli bir bölümü için web’in gezinme omurgasıdır. Birkaç farklı engel grubu, dijital ürünleri etkin şekilde kullanmak için mantıklı bir odak sırasına ihtiyaç duyar.

Motor engelli kullanıcılar fare kullanamadıkları için tamamen klavyeye (veya sip-and-puff anahtarları, baş işaretleyiciler, göz takip sistemleri gibi klavye eşdeğeri cihazlara) dayanırlar. Bu kullanıcılar için bozulmuş bir odak sırası sadece rahatsız edici değildir — bir sayfayı tamamen kullanılamaz hale getirebilir. Tab tuşu kullanıcıyı sayfanın yanlış bir bölümüne götürürse, ihtiyaç duydukları kontrole verimli bir şekilde ulaşamayabilirler ve ellerini başka bir yere tıklamak için basitçe hareket ettiremezler.

Kör kullanıcılar ve az gören kullanıcılar, NVDA, JAWS veya VoiceOver gibi ekran okuyucular kullanırken, odak bir öğeye geldiğinde o öğenin sesli olarak okunmasını duyarlar. Mantıklı bir odak sırası, aldıkları ses akışının arayüzün tasarlanan akışını yansıtması anlamına gelir. Odak düzensiz şekilde atladığında, kullanıcılar sayfada nerede olduklarına dair zihinsel modellerini kaybederler. Dünya Sağlık Örgütü’ne göre, dünya genelinde yaklaşık 2,2 milyar insanın bir tür görme bozukluğu vardır ve ekran okuyucu kullananların çoğu için odak sırası, sayfa yapısını deneyimlemenin birincil yoludur.

Bilişsel engelli kullanıcılar da öngörülebilir odak sıralarından fayda sağlar. Formun ortasında beklenmedik bir odak atlaması kafa karışıklığına yol açabilir, kullanıcıları iş akışlarını yeniden başlatmaya zorlayabilir veya zorunlu alanları kaçırmalarına neden olabilir. Dikkat güçlüğü veya kısa süreli hafıza zorlukları olan kullanıcıların, bir siteyi kullanma konusunda güven inşa edebilmeleri için tutarlı ve öngörülebilir bir gezinmeye ihtiyaçları vardır.

Somut bir gerçek dünya senaryosu: Bir Türk e-ticaret ödeme sayfası hayal edin. Görsel tasarım, sipariş özetini solda, ödeme formunu sağda göstermek için CSS Grid kullanıyor. Ancak DOM’da ödeme formu önce, sipariş özeti sonra geliyor. Görsel yerleşim, gören fare kullanıcıları için doğru görünür, ancak Tab tuşuna basan bir klavye kullanıcısı, sipariş özetini gözden geçirme fırsatı bulamadan önce ödeme formu alanlarına gelir. Yanlış bir siparişi farkında olmadan onaylayabilir. Daha da kötüsü, pozitif tabindex yanlış yönetimi nedeniyle "Satın Almayı Onayla" butonu, "Kupon Uygula" alanından önce odak alırsa, kullanıcı indirim yapmak istediği bir satın almayı yanlışlıkla tam fiyatla gönderebilir. Bu, bozuk bir odak sırasının doğrudan, gerçek bir finansal sonucudur.

Erişilebilirliğin ötesinde, mantıklı bir odak sırası, hız için klavye gezinmeyi tercih eden ileri düzey kullanıcıların deneyimini iyileştirir. Ayrıca dolaylı olarak SEO’yu destekler: doğal bir odak sırası üreten iyi yapılandırılmış bir DOM, arama motorlarının içerik hiyerarşisini ve önemini anlamak için kullandığı anlamlı semantik işaretlemeyi yansıtma eğilimindedir.

İlgili Axe-core Kuralları

WCAG 2.4.3, kesin değerlendirme için manuel test gerektirir. axe-core gibi otomatik araçlar, belirli bir odak sırasının "anlamı ve işletilebilirliği koruyup korumadığını" algoritmik olarak belirleyemez — bu yargı, sayfanın amacını ve içerik ilişkilerini anlayan bir insan gerektirir. Ancak axe-core ve ilgili araçlar, odak sırası sorunlarının güçlü göstergeleri olan bazı kalıpları işaretleyebilir:

• tabindex (pozitif değerler) — sezgisel uyarı: Bazı lint ve denetim araçları, öğeler pozitif tam sayı tabindex değerleri (0’dan büyük herhangi bir değer) taşıdığında uyarı verir. Pozitif tabindex değerleri, doğal DOM sırasını geçersiz kılar ve bu öğeleri tab dizisinin en önüne yerleştirir; bu da neredeyse her zaman mantıksız ve öngörülemez bir odak sırası yaratır. axe-core’un çekirdek kural seti, (sıralamanın mantıksal doğruluğu hesaplanamadığı için) özel bir "focus-order" otomatik kuralı içermese de, axe DevTools Pro gibi araçlar ve manuel denetimler, vekil gösterge olarak özellikle pozitif tabindex kullanımını kontrol eder.
• scrollable-region-focusable: Axe-core, klavye ile odaklanamayan kaydırılabilir bölgeleri işaretleyen bir kural içerir. Doğrudan bir odak sırası kuralı olmasa da, odak alamayan kaydırılabilir bir bölge, genel gezinme dizisini bozar ve klavye kullanıcılarının etkileşim kurmaları gereken içeriği atlamalarına neden olur.
• CSS ile yeniden sıralanmış içerik için manuel inceleme: Otomatik araçlar, CSS Flexbox order veya Grid yerleşiminin, görsel sıra ile DOM sırası arasında bir uyumsuzluk oluşturduğu durumları tespit edemez. Bir insan testçi, ekrandaki görsel yerleşimi, klavye ile gezinme sırasında gözlemlenen odak sırasıyla görsel olarak karşılaştırmalıdır. Bu, modern duyarlı tasarımlarda 2.4.3 ihlallerinin en yaygın kaynağıdır ve otomatik tarayıcılar için tamamen görünmezdir.
• Dinamik içerikte JavaScript odak yönetimi için manuel inceleme: Tek sayfa uygulamalar, sonsuz kaydırma uygulamaları, modallar ve açılır menüler, içerik değiştikçe odağı uygun şekilde taşımak için JavaScript gerektirir. Otomatik araçlar, DOM’un statik bir anlık görüntüsünü çalıştırır ve bu odak yönetimi senaryolarını tetiklemek için gereken kullanıcı etkileşim dizisini simüle edemez. Yalnızca manuel klavye testi, odağın yeni açılan bir modala taşındığını, kapatıldığında doğru tetikleyiciye döndüğünü ve kullanıcıyı erişilemez bir arka plan katmanında bırakmadığını doğrulayabilir.

Nasıl Test Edilir

1. Başlangıç noktası olarak otomatik tarama: Sayfada axe DevTools (tarayıcı eklentisi) veya Google Lighthouse çalıştırın. Pozitif tabindex değerleri ve işaretlenmiş kaydırılabilir bölgelerle ilgili uyarıları arayın. Otomatik sonuçların temiz olmasının 2.4.3’ün sağlandığı anlamına gelmediğini unutmayın — manuel test her zaman gereklidir. İşaretlenen tüm sorunları daha fazla inceleme için kaydedin.
2. Farenizi çıkarın ve yalnızca Tab ile gezin: Tarayıcı adres çubuğundan veya sayfanın üstünden başlayarak, her odaklanabilir öğe arasında ilerlemek için Tab tuşuna art arda basın. Sırayı dikkatle gözlemleyin. Kendinize şunu sorun: Odak, sayfanın mantıksal okuma ve etkileşim akışıyla uyumlu bir sırada mı ilerliyor? Odağın beklenmedik bir alana atladığı oluyor mu? Kasıtlı bir dialog dışında, odak herhangi bir noktada sıkışıp (ileri veya geri gidemeyecek şekilde) kalıyor mu?
3. Dinamik bileşenleri test edin: Klavye kullanarak tüm modalları, dialogları, açılır menüleri, akordeonları, sekme panellerini, tarih seçicileri ve diğer etkileşimli bileşenleri etkinleştirin. Etkinleştirme sonrasında odağın, yeni açığa çıkan içeriğe derhal taşındığını doğrulayın. Bir dialogu kapattıktan sonra, odağın sayfanın en üstüne veya rastgele bir konuma değil, dialogu tetikleyen öğeye geri döndüğünü doğrulayın.
4. NVDA + Firefox ile test edin: NVDA’yı açın, Firefox’u başlatın ve sayfaya gidin. Tab tuşunu kullanarak etkileşimli öğeler arasında ilerleyin ve yapılan duyuruları dinleyin. Duyurulan sıranın bağlamsal olarak mantıklı olduğunu doğrulayın. NVDA’nın Gözatma Modunu (ok tuşları) kullanarak statik içeriği okuyun ve okuma sırasının, bu içerik içindeki etkileşimli öğelerin odak sırasıyla uyumlu olduğunu doğrulayın.
5. VoiceOver + Safari (macOS/iOS) ile test edin: VoiceOver’ı etkinleştirin ve odaklanabilir öğeler arasında ilerlemek için Tab (masaüstü) veya kaydırma hareketlerini (iOS) kullanın. Odak sırasının mantıklı olduğunu doğrulayın. iOS’ta, modalların ve üst katmanların odağı doğru şekilde hapsettiğini ve kapatıldığında odağı geri verdiğini test edin.
6. JAWS + Chrome ile test edin: JAWS’ın Tab gezinmesini kullanın ve duyurulan odak sırasının tutarlı olduğunu doğrulayın. JAWS’ın sanal imlecini kullanarak okuma sırasını, etkileşimli odak sırasıyla çapraz kontrol edin ve herhangi bir tutarsızlık olup olmadığını belirleyin.
7. DOM ile görsel yerleşimi karşılaştırın: Tarayıcı Geliştirici Araçlarını açın ve DOM yapısını inceleyin. DOM’daki etkileşimli öğelerin sırasını, ekrandaki görsel konumlarıyla karşılaştırın. order, position: absolute veya float gibi CSS özellikleri önemli farklılıklar yaratıyorsa, anlam veya işletilebilirliğin etkilenip etkilenmediğini belirlemek için tab dizisini manuel olarak takip edin.
8. DOM’daki tabindex değerlerini kontrol edin: Tarayıcı konsolunda document.querySelectorAll('[tabindex]') komutunu çalıştırarak, açık tabindex özniteliğine sahip tüm öğeleri listeleyin. Pozitif tam sayı değere sahip her öğeyi inceleyin ve değiştirilmiş tab sırasındaki konumunun mantıklı olup olmadığını değerlendirin.

Nasıl Düzeltilir

Mantıksız sıra oluşturan pozitif tabindex değerleri — Hatalı

<!-- Pozitif tabindex değerleri doğal olmayan bir tab dizisi zorlar -->
<form>
  <label for='email'>Email</label>
  <input type='email' id='email' tabindex='3'>

  <label for='name'>Full Name</label>
  <input type='text' id='name' tabindex='1'>

  <label for='phone'>Phone</label>
  <input type='tel' id='phone' tabindex='2'>

  <button type='submit' tabindex='4'>Submit</button>
</form>
<!-- Tab sırası: Full Name → Phone → Email → Submit
     Görsel/mantıksal sıra: Email → Full Name → Phone → Submit
     Bu uyumsuzluk odak sırasını bozar. -->

Mantıksız sıra oluşturan pozitif tabindex değerleri — Doğru

<!-- Tüm pozitif tabindex değerlerini kaldırın; DOM sırasına güvenin.
     DOM’u mantıksal sıraya uyacak şekilde yeniden düzenleyin. -->
<form>
  <label for='email'>Email</label>
  <input type='email' id='email'>

  <label for='name'>Full Name</label>
  <input type='text' id='name'>

  <label for='phone'>Phone</label>
  <input type='tel' id='phone'>

  <button type='submit'>Submit</button>
</form>
<!-- Tab sırası artık DOM sırasını izler: Email → Full Name → Phone → Submit
     Mantıksal ve görsel sırayla eşleşir. tabindex gerekmez. -->

DOM sırasıyla uyuşmayan CSS görsel yeniden sıralaması — Hatalı

<!-- DOM’da önce kenar çubuğu, sonra ana içerik var.
     CSS, flexbox order ile bunları görsel olarak ters çeviriyor.
     Klavye kullanıcıları, ana içerik bağlantılarından önce kenar çubuğu
     bağlantıları arasında tab ile dolaşır; bu, gören bir kullanıcının
     ilk gördüğüyle uyuşmaz. -->
<style>
  .layout { display: flex; }
  .sidebar { order: 2; } /* Görsel olarak sağda gösterilir */
  .main    { order: 1; } /* Görsel olarak solda gösterilir */
</style>

<div class='layout'>
  <nav class='sidebar'>
    <a href='/about'>About</a>
    <a href='/contact'>Contact</a>
  </nav>
  <main class='main'>
    <a href='/article'>Read Article</a>
  </main>
</div>
<!-- Odak sırası: About → Contact → Read Article
     Görsel sıra: Read Article → About → Contact
     Uyumsuzluk 2.4.3’ü ihlal eder. -->

DOM sırasıyla uyuşmayan CSS görsel yeniden sıralaması — Doğru

<!-- Çözüm: DOM’u, hedeflenen görsel ve mantıksal sıraya uyacak şekilde yeniden düzenleyin.
     Uyumsuzluğa neden olan CSS 'order' geçersiz kılmalarını kaldırın. -->
<style>
  .layout { display: flex; }
  /* 'order' geçersiz kılmaları yok — DOM sırası hem görsel hem tab sırasını belirler */
</style>

<div class='layout'>
  <main class='main'>
    <a href='/article'>Read Article</a>
  </main>
  <nav class='sidebar'>
    <a href='/about'>About</a>
    <a href='/contact'>Contact</a>
  </nav>
</div>
<!-- DOM sırası, görsel sıra ve odak sırası artık birbirleriyle uyumlu. -->

Odağı yönetmeyen modal dialog — Hatalı

<!-- Buton bir modal açıyor, ancak odak arka plandaki sayfada kalıyor.
     Klavye kullanıcıları dialog ile etkileşime giremez. -->
<button id='open-modal' onclick='document.getElementById("dialog").style.display="block"'>
  Open Settings
</button>

<div id='dialog' style='display:none;'>
  <h2>Settings</h2>
  <label for='theme'>Theme</label>
  <select id='theme'>
    <option>Light</option>
    <option>Dark</option>
  </select>
  <button id='close-modal'>Close</button>
</div>
<!-- Dialog açıldığında, odak arka plandaki #open-modal üzerinde kalır.
     Tab, dialog öğeleri yerine arka plan sayfa öğeleri arasında dolaşmaya devam eder. -->

Odağı yönetmeyen modal dialog — Doğru

<!-- Odağı açılışta dialog içine taşır ve kapanışta tetikleyiciye geri döndürür.
     role='dialog' ve aria-modal='true', ekran okuyuculara bağlam hakkında bilgi verir. -->
<button id='open-modal'>Open Settings</button>

<div id='dialog'
     role='dialog'
     aria-modal='true'
     aria-labelledby='dialog-title'
     style='display:none;'>
  <h2 id='dialog-title'>Settings</h2>
  <label for='theme'>Theme</label>
  <select id='theme'>
    <option>Light</option>
    <option>Dark</option>
  </select>
  <button id='close-modal'>Close</button>
</div>

<script>
  const openBtn = document.getElementById('open-modal');
  const dialog  = document.getElementById('dialog');
  const closeBtn = document.getElementById('close-modal');

  openBtn.addEventListener('click', () => {
    dialog.style.display = 'block';
    // Odağı dialog içindeki ilk odaklanabilir öğeye taşı
    document.getElementById('theme').focus();
  });

  closeBtn.addEventListener('click', () => {
    dialog.style.display = 'none';
    // Odağı dialogu tetikleyen öğeye geri döndür
    openBtn.focus();
  });
</script>
<!-- Odak sırası artık mantıklı: tetikleyici → dialog içeriği → tekrar tetikleyici. -->

Yaygın Hatalar

• Odak sırasını "kontrol etmek" için pozitif tam sayı tabindex değerleri (örneğin tabindex='1', tabindex='5') kullanmak, DOM yapısını düzeltmek yerine. Pozitif tabindex değerleri, öğeleri sayfadaki tüm doğal olarak odaklanabilir öğelerin önüne yerleştirir; bu da son derece zor bakım yapılan, kaotik bir global tab dizisi yaratır ve neredeyse her zaman hatalara yol açar.
• İçeriği DOM’u yeniden sıralamadan, yalnızca görsel olarak yeniden sıralamak için Flexbox veya CSS Grid’de CSS order uygulamak ve ardından klavye gezinmesini test etmemek. Görsel yerleşim gören kullanıcılar için doğru görünür, ancak tab dizisi görsel sıraya değil DOM sırasına uyar — klavye kullanıcıları için görünmez ama ciddi bir tutarsızlık.
• JavaScript’in .focus() metodunu kullanarak bir modal veya dialog açıldığında odağı programatik olarak içine taşımamak. Ekran okuyucu ve klavye kullanıcıları arka plan içerikte mahsur kalır ve çoğu zaman dialogu bulamaz veya onunla etkileşime giremez.
• Bir modal, çekmece veya açılır menü kapatıldıktan sonra odağı tetikleyici öğeye geri döndürmemek. Odağı sayfanın en üstüne döndürmek veya artık görünmeyen bir öğe üzerinde bırakmak, kullanıcıları potansiyel olarak uzun bir sayfanın başından itibaren yeniden gezinmeye zorlar ve bulundukları yeri kaybetmelerine neden olur.
• Dinamik olarak yüklenen içeriği (örneğin satır içi hata mesajı, toast bildirimi veya tembel yüklenen bir bölüm) görsel olarak kendisinden önce gelen odaklanabilir öğelerden sonra DOM’a eklemek, böylece klavye kullanıcılarının yeni içeriğe sırasız şekilde veya hiç ulaşamamasına neden olmak.
• Kullanıcıların klavye ile erişmesi gereken öğeleri, alternatif bir erişim yolu sağlamadan tab dizisinden çıkarmak için tabindex='-1' kullanmak. tabindex='-1' kendi başına geçerli bir araçtır (bir öğeyi programatik olarak odaklanabilir yapar, ancak doğal tab sırasından çıkarır); ancak bunu gerçekten erişilmesi gereken kontrollere uygulamak, bu kontrolleri klavye kullanıcılarından fiilen gizler.
• Tek sayfa uygulama rota geçişlerini, odağı yeni sayfa başlığına veya bir gezinme atlama işaretine taşımak yerine belge gövdesine veya tarayıcı arayüzüne sıfırlamak. Kullanıcılar, her rota değişikliğinde tüm gezinme öğeleri arasında tekrar Tab ile dolaşmak zorunda kalır.
• Ok tuşu gezinmesinin uygulanmadığı ve Tab tuşunun odağı her gizli slayt arasında dolaştırdığı özel carousel veya slider bileşenleri oluşturmak, böylece kullanıcıları, sonraki sayfa içeriğine ulaşmadan önce onlarca ekran dışı öğe arasında Tab ile dolaşmaya zorlamak.
• DOM’da her zaman display:none olan "görünmez" bir gezinme atlama bağlantısı yerleştirmek (bunu görsel olarak gizlemek için .sr-only / clip tekniği kullanmak yerine). display:none olan bir bağlantı tab dizisinden tamamen çıkarılır ve hiçbir fayda sağlamaz; oysa doğru uygulanmış bir atlama bağlantısı, Tab ile odak alır ve görünür hale gelir, ana içeriğe mantıklı bir odak akışını doğrudan destekler.
• Etkileşimli öğeleri başka etkileşimli öğelerin içine yerleştirmek (örneğin bir <button> öğesini bir <a> etiketinin içine koymak); bu, tarayıcıya göre değişen tab davranışları üretir ve odağın aynı mantıksal kontrol üzerinde birden fazla kez durmasına veya onu tamamen atlamasına neden olabilir.

Türkiye’nin Erişilebilirlik Mevzuatıyla İlişkisi

WCAG 2.4.3 Odak Sırası, Türkiye’nin dönüm noktası niteliğindeki erişilebilirlik mevzuatıyla doğrudan ilişkilidir: 21 Haziran 2025’te 32933 sayılı Resmî Gazete’de yayımlanan 2025/10 sayılı Cumhurbaşkanlığı Genelgesi. Bu genelge, Türkiye’de faaliyet gösteren çok sayıda kamu ve özel sektör kuruluşu için zorunlu web erişilebilirliği standartları belirler ve 2.4.3’ün de aralarında bulunduğu tüm WCAG 2.x Seviye A başarı ölçütlerine uyumu gerektirir.

Genelge, geniş bir kurum yelpazesini kapsar. Kamu kurumları — bakanlıklar, belediyeler, devlet üniversiteleri ve kamu kurumları dahil — genelgenin yayım tarihinden itibaren bir yıl içinde tam uyum sağlamak zorundadır. Kapsam dahilindeki özel sektör kuruluşları ise aynı uyum seviyesine iki yıl içinde ulaşmalıdır. Kapsamdaki özel sektör kategorileri arasında e-ticaret platformları, bankalar ve finans kuruluşları, hastaneler ve özel sağlık hizmeti sağlayıcıları, 200.000 veya daha fazla abonesi olan telekomünikasyon şirketleri, seyahat acenteleri, özel ulaşım şirketleri ve Millî Eğitim Bakanlığı (MEB) izniyle faaliyet gösteren özel okullar yer alır.

Tüm bu kuruluşlar için bozuk veya mantıksız bir odak sırası, yalnızca kullanılabilirlik eksikliği değildir — genelgenin yaptırım hükümleri kapsamında kurumu hukuki ve idari sonuçlara maruz bırakabilecek bir mevzuata aykırılıktır. Örneğin, bir Türk bankasının internet bankacılığı portalında, para transferi ekranındaki odak sırasının, tutar alanından alıcı IBAN alanını atlayarak doğrudan onay butonuna atlaması durumunu düşünün. Yalnızca klavye kullanan bir kullanıcı — örneğin motor engelli bir müşteri — tüm zorunlu alanları düzgün doldurmadan yanlışlıkla bir transfer başlatabilir. Bu senaryo, aynı anda hem bir WCAG 2.4.3 ihlali, hem genelge gerekliliklerinin bir ihlali, hem de kullanıcı için potansiyel olarak ciddi bir finansal zarardır.

Benzer şekilde, genelge kapsamındaki bir e-ticaret sitesi, görsel olarak çekici bir ürün sayfası göstermek için CSS Grid yeniden sıralaması kullanıyor, ancak tab dizisi, "Sepete Ekle" butonuna gelmeden önce ürün görsellerinden altbilgi bağlantılarına atlıyorsa, 2.4.3’ü doğrudan ihlal ediyor ve dolayısıyla genelgeye aykırı hale geliyordur. Bir ve iki yıllık son tarihler, kuruluşların odak sırası iyileştirmesini erişilebilirlik yol haritalarında öncelik olarak ele almaları gerektiği anlamına gelir — ertelenmiş bir geliştirme olarak değil. Odak sırası sorunlarının çoğu, DOM yapısı ve JavaScript etkileşim kalıplarına ilişkin mimari kararlardan kaynaklandığından, bunları geliştirme sürecinin erken aşamalarında ele almak, lansman sonrasında yamalamaya kıyasla çok daha düşük maliyetlidir.

Accsible’ın overlay SDK’sı, yapılandırılabilir odak yönetimi iyileştirmeleri sağlayarak kuruluşların uyum yolculuğunu destekler; ancak overlay çözümlerinin, uygulamanın kendi kod tabanındaki doğru semantik HTML yapısı ve sorumlu odak yönetiminin yerine değil, onunla birlikte en iyi şekilde çalıştığını belirtmek önemlidir. 2025/10 sayılı Cumhurbaşkanlığı Genelgesi’ne sürdürülebilir ve denetlenebilir uyum sağlamak, temel ürünün 2.4.3’ü doğru geliştirme uygulamalarıyla karşılamasını gerektirir.