POUR İlkeleri Açıklanıyor: Algılanabilir, Kullanılabilir, Anlaşılabilir, Sağlam

Web sitenizin tasarımını mükemmelleştirmek için saatler harcadığınızı, ancak ziyaretçilerinizin önemli bir kısmının onu hiç kullanamadığını keşfettiğinizi hayal edin. Bu, dünya genelinde yaklaşık 1,3 milyar insan — küresel nüfusun yaklaşık %16’sı — için, yani bir tür engelle yaşayan insanlar için gerçek bir durum. WebAIM Million 2025 raporuna göre, web sitelerinin %94,8’inde hâlâ tespit edilebilir en az bir erişilebilirlik hatası bulunuyor ve ortalama ana sayfa 51’den fazla farklı erişilebilirlik hatası barındırıyor. İyi haber şu: Gürültüyü kesip size erişilebilir web içeriğinin tam olarak nasıl olması gerektiğini söyleyen ilkeli bir çerçeve var. Adı POUR.

POUR Nedir ve Nereden Gelir?

POUR, Web İçeriği Erişilebilirlik Yönergeleri’nin (WCAG) temelini oluşturan dört ana ilkenin kısaltmasıdır: Perceivable (Algılanabilir), Operable (Kullanılabilir), Understandable (Anlaşılabilir) ve Robust (Sağlam). World Wide Web Consortium (W3C) tarafından Web Accessibility Initiative (WAI) aracılığıyla yayımlanan ve sürdürülen WCAG, web erişilebilirliği için uluslararası düzeyde tanınan ölçüttür. Mevcut kararlı sürüm — WCAG 2.2 — tüm 13 yönergesini ve bunların onlarca test edilebilir başarı ölçütünü bu dört ilke altında düzenler.

POUR’u, herhangi bir web içeriği parçası hakkında sorduğunuz bir soru hiyerarşisi olarak düşünün. Kullanıcılar onu gerçekten algılayabiliyor mu? Onunla etkileşime girebiliyorlar mı? Anlamlandırabiliyorlar mı? Ve teknoloji geliştikçe çalışmaya devam edecek mi? Bu sorulardan herhangi birine yanıt hayır ise, gerçek bir kişi şu anda sitenizden dışlanıyor demektir. Bu bir varsayım değil — bu, ekran okuyucu kullanıcıları, yalnızca klavye ile gezinmek zorunda olanlar, bilişsel farklılıkları olan kişiler ve eski yardımcı teknolojiler kullanan kullanıcılar için günlük bir deneyim.

POUR’u anlamak, ahlaki yükümlülüğün ötesinde önem taşır. Dünyanın dört bir yanındaki yasa ve düzenlemeler — Amerika Birleşik Devletleri’nde Americans with Disabilities Act (ADA), AB genelinde European Accessibility Act (EAA) ve Birleşik Krallık’ta Equality Act — teknik standart olarak WCAG’ye dayanır. Bir işletme erişilebilirlik davasıyla karşılaştığında, şikâyet neredeyse her zaman POUR ilkelerinden birinin veya birkaçının ihlaline kadar izlenebilir. Yalnızca 2025’te 5.114 ADA dijital erişilebilirlik davası açıldı ve en sık hedef alınan sektör e-ticaret şirketleriydi. Pratik açıdan, POUR’u bilmek hukuki riskinizi bilmek demektir.

Her ilke, yönergelere — geniş hedeflere — ve bu yönergeler de A Düzeyi (asgari), AA Düzeyi (güçlü — en yaygın talep edilen standart) ve AAA Düzeyi (gelişmiş) olarak derecelendirilen, belirli ve test edilebilir başarı ölçütlerine ayrılır. Bu rehberin geri kalanı, her ilkeyi derinlemesine ele alır ve hemen uygulayabileceğiniz pratik örnekler ve kod kalıpları sunar.

İlke 1: Perceivable (Algılanabilir) — Algılayamıyorlarsa, Var Değildir

WCAG spesifikasyonu bunu açıkça ifade eder: bilgi ve kullanıcı arayüzü bileşenleri, kullanıcıların algılayabileceği şekillerde sunulabilir olmalıdır. Başka bir deyişle, sayfanızdaki hiçbir şey aynı anda kullanıcının tüm duyularına görünmez olamaz. Yalnızca renkle anlam aktaran bir grafik, renk körü biri için görünmezdir. Altyazısız bir video, işitme engelli biri için fiilen sessizdir. Süsleme amaçlı bir görselin uzun bir alt metin açıklamasına sahip olması, bir ekran okuyucu kullanıcısının zamanını boşa harcar. Algılanabilirlik, her iletişim kanalının, o kanala erişemeyen kullanıcılar için bir yedeğe sahip olmasını sağlamaktır.

Perceivable altında yer alan dört WCAG yönergesi şunlardır: metin alternatifleri, zamana dayalı medya, uyarlanabilir içerik ve ayırt edilebilir içerik. Metin alternatifleri (Yönerge 1.1), her metin dışı öğenin — görseller, simgeler, grafikler, infografikler, ses dosyaları, video — aynı amaca hizmet eden bir metin eşdeğerine sahip olmasını gerektirir. Ana sayfaya bağlantı olarak kullanılan bir görselin alt metni, "Ana sayfaya dön" gibi olmalıdır; "logo.png" ya da boş bir dize değil. Öte yandan süsleme amaçlı görseller, ekran okuyucuların onları tamamen atlaması için alt='' kullanmalıdır; bu da gereksiz gürültüyü önler.

Zamana dayalı medya (Yönerge 1.2), video ve ses içeriği için altyazıları, sesli betimlemeleri ve transkriptleri kapsar. Senkronize altyazılar, işitme engelli veya işitme güçlüğü olan kullanıcıları destekler. Sesli betimlemeler — ekrandaki eylemi anlatan bir anlatım parçası — görme engelli kullanıcıları destekler. Transkriptler her iki gruba da hizmet eder ve ayrıca gürültülü ortamlardaki kullanıcılar veya ses yerine yazılı metni daha kolay işleyen kullanıcılar için de faydalıdır.

Uyarlanabilir içerik (Yönerge 1.3), sunumu kaldırıldığında içeriğinizin hâlâ anlamlı olması gerektiği anlamına gelir. Gören bir kullanıcı, kırmızıyla vurgulanmış zorunlu bir alan görüyorsa, ekran okuyucu kullanan bir kullanıcı da bunun zorunlu olduğunu yalnızca görsel renkle değil, programatik işaretleme ile bilmelidir. "Sağdaki yeşil düğmeye tıklayın" gibi talimatlar, görme engelli bir kullanıcı için tamamen başarısız olur. Kural nettir: talimatlar yalnızca şekil, renk, boyut veya görsel konum gibi duyusal özelliklere dayanamaz.

Ayırt edilebilir içerik (Yönerge 1.4), kontrastı, metin yeniden boyutlandırmayı ve ses kontrolünü düzenler. WCAG 2.2 AA Düzeyi, normal metin için en az 4,5:1 ve büyük metin için 3:1 kontrast oranı gerektirir. Düşük kontrastlı metin, web’deki en yaygın erişilebilirlik hatasıdır: Şubat 2026 WebAIM Million analizinde, düşük kontrastlı metin ana sayfaların %83,9’unda bulundu ve sayfa başına ortalama 34 farklı örnek tespit edildi. Metin ayrıca, içerik veya işlev kaybı olmadan %200’e kadar yeniden boyutlandırıldığında okunabilir kalmalı ve hiçbir içerik, 320 CSS piksel genişliğinde görüntülendiğinde bilgi kaybetmemelidir (Yeniden Akış ölçütü, 1.4.10).

En yaygın Perceivable hataları — eksik alt metin, düşük renk kontrastı ve etiketlenmemiş form alanları — karmaşık mühendislik problemleri değildir. Bunlar, nerede arayacağınızı bildiğinizde genellikle dakikalar içinde düzeltilebilen günlük ihmallerdir.

İşte erişilemez ve erişilebilir görsel işaretlemesinin hızlı bir karşılaştırması:

<!-- Erişilemez: alt niteliği yok -->
<img src='product-chart.png'>

<!-- Erişilebilir: açıklayıcı alt metin -->
<img src='product-chart.png' alt='Q2’ye kıyasla Q3 gelirinde %40 artış gösteren çubuk grafik'>

<!-- Süsleme amaçlı görsel: yardımcı teknolojilere atlamasını söyleyin -->
<img src='divider-wave.png' alt='' role='presentation'>

İlke 2: Operable (Kullanılabilir) — Her İşlev Her Girdi Yöntemiyle Çalışmalı

Operable, etkileşimle ilgilidir. WCAG, kullanıcı arayüzü bileşenlerinin ve gezinmenin kullanılabilir olması gerektiğini belirtir — yani arayüz, kullanıcının gerçekleştiremeyeceği bir etkileşimi zorunlu kılamaz. Bunun en net ifadesi klavye erişilebilirliğidir. Motor engeli olan, tekrarlayan zorlanma yaralanmaları yaşayan veya görme engelli birçok kullanıcı, web’de gezinmek için tamamen klavyeye (veya anahtarlı cihaz, nefesle kontrol edilen cihaz, sesle giriş yazılımı gibi klavye öykünmeli yardımcı teknolojilere) güvenir. Açılır menünüz yalnızca fareyle üzerine gelindiğinde açılıyorsa, bu kullanıcılar dışlanmış demektir.

Yönerge 2.1, tüm işlevlerin klavyeden erişilebilir olmasını gerektirir. Bu, her etkileşimli öğenin — bağlantılar, düğmeler, form kontrolleri, özel bileşenler, kaydırıcılar, tarih seçiciler, modal pencereler — Tab tuşuyla erişilebilir ve klavye komutlarıyla kullanılabilir olması anlamına gelir. Kritik olarak, klavye tuzaklarının olmaması da gerekir: odak, bir modal gibi bir bileşenin içine taşındığında, kullanıcılar yalnızca klavyeyi kullanarak odağı tekrar dışarı taşıyabilmelidir (genellikle Escape tuşuyla). Tuzak içine alınmış bir kullanıcının, tarayıcısını kapatmaktan başka çaresi yoktur.

En az bunun kadar önemli olan, odak görünürlüğüdür (Yönerge 2.4, Başarı Ölçütü 2.4.7). Gören klavye kullanıcılarının, odağın her zaman nerede olduğunu görebilmesi gerekir. Estetik nedenlerle popüler hâle gelen varsayılan tarayıcı odak çizgisini kaldırmak, bir geliştiricinin verebileceği en zararlı erişilebilirlik kararlarından biridir. Odak görünmez olduğunda, klavye kullanıcısı karanlıkta gezinir. Varsayılan tarayıcı odak stillerini geçersiz kılarsanız, çevreleyen arka plana karşı en az 3:1 kontrast oranına sahip görünür bir alternatif sağlamalısınız.

<!-- Erişilemez: odak çizgisi global olarak bastırılmış -->
* { outline: none; }

<!-- Erişilebilir: özel, görünür odak stili -->
:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
  border-radius: 2px;
}

Yönerge 2.2, zamanlamayı ele alır. Bazı kullanıcıların içeriği okumak, formları doldurmak veya oturum zaman aşımı uyarılarına yanıt vermek için önemli ölçüde daha fazla zamana ihtiyacı vardır. İçeriğinizin belirlediği her zaman sınırı için, kullanıcılar onu kapatabilmeli, uzatabilmeli (en az varsayılan sürenin 10 katına kadar) veya süresi dolmadan önce uyarılmalı ve basit bir eylemle yanıt vermeleri için en az 20 saniye verilmelidir. Otomatik ilerleyen karuseller, zamanlı testler ve oturum süresi doldu pencereleri bu konuda yaygın sorun kaynaklarıdır.

Yönerge 2.3, saniyede üç kereden fazla yanıp sönen içeriği yasaklar; çünkü bu tür içerik, ışığa duyarlı nöbetleri tetikleyebilir. Yönerge 2.4, gezinilebilirliği kapsar — kullanıcıların içeriği bulabilmesini ve nerede olduklarını bilebilmesini sağlar. Pratik gereklilikler arasında tekrarlayan gezinme bloklarını atlamanın bir yolu (en basit uygulama "Ana içeriğe geç" bağlantısıdır), açıklayıcı sayfa başlıkları, mantıklı odak sırası, anlamlı bağlantı metni ("Q3 raporunu okuyun" gibi, "buraya tıklayın" değil) ve görünür odak göstergeleri yer alır. WCAG 2.2 ayrıca, girdi biçimlerini kapsayan Yönerge 2.5’i ekledi: çok noktalı veya yol tabanlı hareketler (yakınlaştırmak için sıkıştırma, kaydırma) kullanan tüm işlevler, tek bir işaretçiyle de kullanılabilir olmalı ve dokunma hedefleri asgari boyut gerekliliklerini karşılamalıdır.

Klavye erişilebilirliği, niş bir kaygı değildir. Görme engelli kullanıcılar, güç kullanıcıları, motor engeli olan kullanıcılar ve touchpad’i bozulan herkes buna bağlıdır. Klavye öncelikli geliştirme, dayanıklılık için geliştirmektir.

İlke 3: Understandable (Anlaşılabilir) — Açıklık Opsiyonel Değildir

İçerik algılanabilir ve her etkileşim kullanılabilir olsa bile, içerik kafa karıştırıcıysa kullanıcı tamamen kaybolabilir. Understandable ilkesi, hem sunulan bilginin hem de arayüzün çalışma biçiminin kullanıcılar için anlaşılır olmasını gerektirir. Bu ilke, özellikle bilişsel engelleri olan, öğrenme farklılıkları bulunan, düşük dijital okuryazarlığa sahip kullanıcılar veya sitenizi ana dili olmayan bir dilde kullanan herkes için önemlidir.

Yönerge 3.1, okunabilirliği kapsar. En temel gereklilik, sayfanın dilinin kodda belirtilmesidir — <html> öğesindeki lang niteliği. Bu tek nitelik, ekran okuyucuların uygun telaffuz motoruna geçmesini sağlar. 2025 WebAIM verilerinde, ana sayfaların %15,8’inde dil bildiriminin eksik olduğu bulundu; bu da, kullanıcının varsayılan dil ayarı farklıysa, ekran okuyucunun bir İngilizce sayfayı Fransız aksanıyla (veya tam tersi) okuyabileceği anlamına gelir. Bir sayfa içerik ortasında dil değiştirdiğinde — çok dilli sitelerde yaygındır — ilgili öğeye lang niteliği uygulanmalıdır.

<!-- Sayfa dili bildirimi -->
<html lang='en'>

<!-- Satır içi dil değişimi -->
<p>The phrase <span lang='fr'>joie de vivre</span> means joy of living.</p>

Yönerge 3.2, öngörülebilirliği kapsar. Sayfalar ve bileşenler tutarlı ve beklenen şekillerde davranmalıdır. Gezinme menüleri, sayfalar arasında aynı konumda ve sırada görünmelidir. Bir açılır listede değer seçmek, uyarı olmadan otomatik olarak başka bir sayfaya yönlendirmemelidir — otomatik gönderim davranışına ihtiyacınız varsa, kullanıcılar bilgilendirilmelidir. Siteniz genelinde aynı görünen bileşenler (yalnızca simge içeren bir kapatma düğmesi, bir arama alanı) aynı şekilde davranmalıdır. Beklenmedik bağlam değişiklikleri — haber verilmeden açılan yeni bir sekme, otomatik yenilenen bir sayfa — yönünü şaşırtır ve özellikle değişikliği hemen fark edemeyebilecek ekran okuyucu kullanıcıları için sorunludur.

Yönerge 3.3, girdi yardımını ele alır — erişilebilirlik açısından en pratik etkisi olan alanlardan biridir. Kullanıcılar form doldururken hata yaptığında, üç şeyi bilmeleri gerekir: bir hata oluştuğunu, hataya hangi alanın neden olduğunu ve bunu nasıl düzelteceklerini. Yalnızca hatalı alanı kırmızıya boyamak yeterli değildir — hata mesajı metin tabanlı olmalı, ilgili alanla programatik olarak ilişkilendirilmiş olmalı ve eyleme geçirilebilir olacak kadar spesifik olmalıdır. "Bu alan zorunludur" hiçbir şey olmamasından biraz daha iyidir. "Lütfen e-posta adresinizi [email protected] formatında girin" gerçekten yardımcıdır. WCAG 2.2 ayrıca Başarı Ölçütü 3.3.7’yi (Redundant Entry) ve 3.3.8’i (Accessible Authentication) ekledi; ikincisi, bulmacalar veya hafıza testleri gibi bilişsel işlev testlerini tek kimlik doğrulama mekanizması olarak yasaklar ve bu tür engellerin bilişsel engeli olan kullanıcıları orantısız şekilde etkilediğini kabul eder.

Anlaşılabilir tasarım, içeriği basitleştirmekle ilgili değildir. Gereksiz sürtünmeyi ortadan kaldırmakla ilgilidir. Sade dil, tutarlı kalıplar ve yardımcı hata mesajları, yalnızca engelli kullanıcılar için değil, tüm kullanıcılar için faydalıdır.

İlke 4: Robust (Sağlam) — Teknolojiler Arasında Kalıcı Olacak Şekilde İnşa Edilmiş

Robust, tasarım aşamasında en az dikkat çeken ve zaman içinde en çok sorun çıkaran ilkedir. Gereklilik, içeriğin çok çeşitli kullanıcı ajanları — yardımcı teknolojiler dâhil — tarafından güvenilir şekilde yorumlanacak kadar sağlam olmasıdır; teknolojiler geliştikçe de içerik erişilebilir kalmalıdır. Pratik açıdan bu, temiz, geçerli, semantik HTML yazmak ve ARIA’yı düşünerek kullanmak anlamına gelir; böylece hem bugünün ekran okuyucuları hem de yarının tarayıcı motorları içeriğinizi anlayabilir.

Yönerge 4.1, WCAG 2.2’de Robust altında yer alan tek yönergedir ve en önemli kalan başarı ölçütü 4.1.2’dir: Name, Role, Value (Ad, Rol, Değer). Her kullanıcı arayüzü bileşeni için — formlar, bağlantılar, düğmeler, özel bileşenler — ad (nasıl adlandırıldığı), rol (ne tür bir şey olduğu) ve değer veya durum (bir onay kutusunun işaretli olup olmadığı, bir akordeonun açık olup olmadığı) programatik olarak belirlenebilir olmalıdır. Yardımcı teknolojilerin, kullanıcıya neyle etkileşimde olduklarını söylemek için erişilebilirlik ağacından okuduğu bilgi budur.

4.1.2’yi karşılamanın en güvenilir yolu, yerel HTML öğelerini kullanmaktır; bunlar, erişilebilirlik ağacına otomatik olarak yansıtılan yerleşik anlamsal özellikler taşır. Bir <button> öğesi, doğası gereği bir düğmedir — doğru role sahiptir, varsayılan olarak odaklanabilirdir ve hem Enter hem de Space ile etkinleşir. Bir düğme gibi görünecek şekilde stillendirilmiş bir <div>, role='button', tabindex='0' ve hem klavye hem de işaretçi olayları için JavaScript olay işleyicileri manuel olarak eklenmedikçe bu özelliklerin hiçbirine sahip değildir. Yerel anlamsallık ücretsizdir; özel uygulamalar bu temel seviyeye ulaşmak için sürekli bakım gerektirir.

<!-- Erişilemez özel düğme -->
<div class='btn' onclick='submitForm()'>Submit</div>

<!-- Erişilebilir: yerel öğe -->
<button type='submit'>Submit</button>

<!-- Özel bir bileşen kaçınılmaz olduğunda -->
<div
  role='button'
  tabindex='0'
  aria-pressed='false'
  onkeydown='handleKey(event)'
  onclick='toggleState()'
>
  Toggle
</div>

Başarı Ölçütü 4.1.3 (Durum Mesajları, AA Düzeyi), önemli durum mesajlarının — form gönderim onayları, yükleme göstergeleri, hata bildirimleri, alışveriş sepeti güncellemeleri — klavye odağının onlara taşınmasını gerektirmeden yardımcı teknoloji kullanıcılarına duyurulmasını zorunlu kılar. Standart mekanizma ARIA canlı bölgeleridir: acil olmayan güncellemeler için aria-live='polite' ("Değişiklikleriniz kaydedildi") ve acil kesintiler için aria-live='assertive' ("Oturumun süresi doldu"). Bu olmadan, ödeme işlemi yapan bir ekran okuyucu kullanıcısı bir formu gönderebilir ve hiçbir şey duymayabilir — ne onay ne hata — ve siparişinin gerçekleşip gerçekleşmediğini bilemez.

<!-- Acil olmayan durumlar için nazik canlı bölge -->
<div aria-live='polite' aria-atomic='true' class='sr-only'>
  <!-- Dinamik olarak eklenecek: 'Profiliniz güncellendi.' -->
</div>

<!-- Acil uyarılar için baskın canlı bölge -->
<div role='alert' aria-live='assertive'>
  <!-- Dinamik olarak eklenecek: 'Hata: Ödeme başarısız oldu. Lütfen tekrar deneyin.' -->
</div>

WCAG 2.2’nin, daha önce sıkı HTML doğrulaması gerektiren eski Başarı Ölçütü 4.1.1’i (Parsing) kaldırdığını unutmayın. Modern tarayıcılar ve yardımcı teknolojiler, hatalı biçimlendirilmiş HTML’yi eskisine göre çok daha sorunsuz işler, bu da bu ölçütü geçersiz kılar. Odak tamamen anlamlı anlamsallığa ve ARIA’nın doğru kullanımına kaymıştır.

Dört İlke Birlikte Nasıl Çalışır?

POUR, işaretlenecek bağımsız kutulardan oluşan bir kontrol listesi değildir — entegre bir çerçevedir. Bir ilkedeki başarısızlık, neredeyse her zaman diğerlerinde de başarısızlıklara yol açar. Yalnızca <div> öğeleri ve CSS ile oluşturulmuş özel bir açılır liste menüsü, genellikle aynı anda dört ilkenin tümünde başarısız olur: ekran okuyucu için algılanamaz (anlamsal rol yoktur), klavye ile kullanılamaz (odak yönetimi yoktur), ekran okuyucu kullanıcısı tarafından anlaşılamaz (durum duyuruları yoktur) ve yardımcı teknoloji API’leri geliştikçe sağlam olmayacaktır (programatik ad veya değer yoktur).

Tersine, bir ilkeyi doğru uygulamak genellikle diğerlerini de iyileştirir. Semantik HTML yazmak (Robust), içeriği yardımcı teknolojiler için otomatik olarak daha algılanabilir hâle getirir. Görseller için metin alternatifleri sağlamak (Perceivable), görseli göremeyen kullanıcılar için bu içeriğin anlaşılabilirliğini de artırır. Görünür odak göstergeleri eklemek (Operable), mevcut etkileşim bağlamını netleştirerek arayüzü daha anlaşılır kılar. Bu karşılıklı bağlılık kasıtlıdır — W3C, POUR’u modüler bir kontrol listesi değil, bütüncül bir mercek olarak tasarlamıştır.

Erişilebilirlik programı oluşturan uyum yöneticileri için POUR, iyileştirme çalışmalarını kategorize etmenin ve önceliklendirmenin en iyi yolunu sunar. Bir siteyi denetlediğinizde ve 50 erişilebilirlik sorunu bulduğunuzda, bunları ilkeye göre gruplamak, algılanabilirlik sorununuz (belki içerik ekibiniz görselleri alt metin olmadan yüklüyor), kullanılabilirlik sorununuz (ön uç ekibiniz klavye desteği olmayan özel bileşenler kullanıyor), anlaşılabilirlik sorununuz (UX ekibiniz tutarsız gezinme kalıpları tasarlıyor) veya sağlamlık sorununuz (geliştiricileriniz ARIA’yı yanlış kullanıyor veya hiç kullanmıyor) olup olmadığını gösterir. Farklı sorunlar, farklı organizasyonel çözümler gerektirir.

Uygulamada POUR: Çerçeveyi Web Sitenize Uygulamak

Teoriyi bilmek başlangıçtır. POUR’u uygulamaya koymak, erişilebilirliği ürün yaşam döngüsünün her aşamasına entegre eden tutarlı bir süreç gerektirir — projenin sonunda yapılan tek seferlik bir denetim değil. Her ilke için en etkili adımlar şunlardır.

Perceivable için, WAVE veya Axe gibi bir araçla otomatik tarama yaparak başlayın; eksik alt nitelikleri, kontrast hatalarını, eksik form etiketlerini ve eksik sayfa dilini yakalayın. Bu otomatik kontroller, WCAG sorunlarının yaklaşık %30–40’ını tespit edebilir. Ardından geri kalanlar için manuel denetim yapın: NVDA veya VoiceOver gibi bir ekran okuyucunun bir sayfayı okumasını izleyin, bir renk körlüğü simülatörü kullanarak renk körü bir kullanıcının ne gördüğünü izleyin ve görsel olarak aktarılan her anlam parçasının metin veya yapı ile de aktarıldığını doğrulayın.

Operable için, farenizi çıkarın ve her sayfada ve her etkileşimli akışta yalnızca Tab, Enter, Space, Escape ve ok tuşlarını kullanarak gezinin. Odağın asla kaybolmadığını, asla tuzağa düşmediğini ve her zaman mantıklı bir okuma sırasına göre ilerlediğini kontrol edin. Tüm zamanlı etkileşimleri gözden geçirin ve kullanıcıların bunları uzatabildiğinden veya devre dışı bırakabildiğinden emin olun. Dokunmatik cihazlarda test yaparak, hareket tabanlı etkileşimlerin işaretçi alternatiflerine sahip olduğunu doğrulayın.

Understandable için, tüm şablonlarınızda sayfa dil bildirimlerinizi denetleyin. Her formu net, ilişkilendirilmiş etiketler için gözden geçirin ve her hata durumunu test ederek mesajların spesifik, metin tabanlı ve ilgili girdiyle programatik olarak bağlantılı olduğundan emin olun. Bir okunabilirlik metriği kullanarak içerik incelemesi yapın — kitlenize uygun bir Flesch-Kincaid okuma düzeyini hedefleyin ve karmaşık bölümler için sade dil yeniden yazımlarıyla bunu destekleyin. Siteniz genelindeki gezinme kalıplarını tutarlılık açısından gözden geçirin.

Robust için, HTML’nizi doğrulayın. Tarayıcı geliştirici araçlarını ve erişilebilirlik ağacı inceleyicisini (Chrome, Firefox ve Safari Geliştirici Araçları’na yerleşiktir) kullanarak her etkileşimli öğenin anlamlı bir erişilebilir ada, doğru role ve doğru durum bilgisine sahip olduğunu doğrulayın. Her özel bileşeni denetleyin. Sitenizi birden fazla ekran okuyucuyla çalıştırın — JAWS, NVDA ve VoiceOver’ın her birinin biraz farklı davranışları vardır — ve form hataları, yükleme durumları ve toast bildirimleri gibi dinamik güncellemelerin canlı bölgeler aracılığıyla doğru şekilde duyurulduğunu doğrulayın.

Temel Çıkarımlar

• POUR, WCAG’nin omurgasıdır. WCAG 2.2’deki her başarı ölçütü, dört ilkeden birine — Perceivable, Operable, Understandable, Robust — karşılık gelir ve ilkeleri anlamak, yalnızca bir kontrol listesinin peşinden gitmek yerine erişilebilirlik hakkında düşünmenize yardımcı olur.
• En yaygın hatalar önlenebilirdir. Düşük kontrastlı metin (sayfaların %83,9’unda bulunur), eksik alt metin, etiketlenmemiş form alanları ve eksik sayfa dil bildirimleri, otomatik taramanın tespit edebileceği ve geliştiricilerin hızla düzeltebileceği POUR hatalarıdır.
• Klavye erişilebilirliği, kullanılabilirliğin temelidir. Her etkileşimli öğe, yalnızca klavye ile erişilebilir, kullanılabilir ve çıkılabilir olmalıdır — motor engeli olan, görme engelli ve durumsal kısıtlamalar yaşayan kullanıcıları kapsar.
• Semantik HTML, sağlamlık için en iyi stratejinizdir. Yerel HTML öğeleri, doğru adları, rolleri ve durumları erişilebilirlik ağacına otomatik olarak yansıtır. Anlamsal olmayan öğeler üzerine inşa edilen özel bileşenler, bu temel seviyeye ulaşmak için önemli ek çalışma ve sürekli bakım gerektirir.
• Erişilebilirlik, bir proje aşaması değil, sürekli bir pratiktir. POUR temelli düşünmeyi tasarım incelemelerine, kod inceleme kontrol listelerine ve içerik iş akışlarına entegre edin. Otomatik araçlar sorunların yalnızca bir kısmını yakalar — farkı kapatan, sürdürülebilir insan testi ve kapsayıcı tasarım süreçleridir.