Frontend Geliştirmede Otomatik Erişilebilirlik (A11y) Testleri

Bir butonun çalışması, o butonun herkes tarafından kullanılabildiği anlamına gelmez. Klavyeyle ulaşılamayan bir menü, accessible name taşımayan bir ikon butonu veya modal açıldığında kaybolan focus, fonksiyonel testlerin tamamı geçse bile kullanıcıların önemli bir bölümünü engelleyebilir. On yılı aşan frontend geliştirme deneyimimde erişilebilirlik sorunlarını en düşük maliyetle çözen ekiplerin ortak noktası, kontrolleri geliştirme sürecinin sonuna bırakmamaları oldu. Frontend Geliştirmede Otomatik Erişilebilirlik (A11y) Testleri yaklaşımı axe-core, Playwright, Cypress, Storybook ve component testlerini aynı kalite zincirine bağlayarak bu sorunların önemli bölümünü daha kod production ortamına ulaşmadan yakalamayı sağlar. Bu rehberde otomasyonun neleri gerçekten bulabildiğini, neleri insan değerlendirmesine bırakmak gerektiğini ve WCAG 2.2 hedeflerinin CI/CD sürecine nasıl uygulanabileceğini pratik örneklerle ele alacağız.

Frontend Erişilebilirlik Testi Nedir?

Frontend erişilebilirlik testi, kullanıcı arayüzünün farklı yeteneklere ve yardımcı teknolojilere sahip kişiler tarafından kullanılabilir olup olmadığını değerlendiren kalite sürecidir. Bu süreç yalnızca HTML üzerinde birkaç ARIA attribute kontrol etmekten oluşmaz. Semantik yapı, accessible name, klavye kullanımı, focus davranışı, kontrast, form etiketleri, dinamik mesajlar ve ekran okuyucu deneyimi birlikte ele alınır. Otomatik araçlar bu alanların kurala dönüştürülebilen bölümünü hızlı biçimde tarar. Manuel klavye, ekran okuyucu ve kullanıcı testleri ise otomasyonun yorumlayamadığı deneyim kalitesini tamamlar.

A11y Ne Anlama Gelir?

A11y, İngilizce accessibility kelimesinin yaygın kısaltmasıdır ve ilk harf ile son harf arasındaki on bir karakteri temsil eder. Yazılım ekiplerinde web erişilebilirliği, mobil erişilebilirlik ve yardımcı teknoloji desteği konuşulurken sık kullanılır. A11y yalnızca görme engelli kullanıcılar için ekran okuyucu desteği anlamına gelmez. Motor, işitsel, bilişsel ve geçici engellerin yanında klavye kullanan veya belirli çevresel koşullarda ürüne erişen kullanıcıları da kapsayan geniş bir kullanılabilirlik alanıdır. Teknik ekip açısından hedef, temel görevlerin farklı interaction yöntemleriyle anlaşılır, algılanabilir ve tamamlanabilir olmasını sağlamaktır.

Otomatik Erişilebilirlik Testi Nasıl Çalışır?

Otomatik erişilebilirlik motoru render edilmiş DOM yapısını, element özelliklerini, ARIA ilişkilerini ve hesaplanabilen bazı görsel değerleri belirli kurallar üzerinden inceler. Örneğin bir form input'un accessible name taşıyıp taşımadığı veya ARIA attribute'un kullanılan role için geçerli olup olmadığı algoritmik olarak kontrol edilebilir. axe-core gibi motorlar sonuçları violation, pass ve otomatik karar verilemeyen durumlar şeklinde sınıflandırabilir. Test framework'ü bu sonucu assertion'a dönüştürerek pull request'i başarısız yapabilir. Buna rağmen otomatik tarama gerçek kullanıcının interface'i anlayıp anlayamadığını bütünüyle belirleyemez ve WCAG uyumluluğunun tek kanıtı olarak kullanılmamalıdır.

Fonksiyonel Test ile Erişilebilirlik Testi Arasındaki Fark

Fonksiyonel test bir işlemin ürün gereksinimine göre gerçekleşip gerçekleşmediğine odaklanır. Örneğin kullanıcı giriş butonuna bastığında hesabına girebiliyorsa fonksiyonel senaryo geçebilir. Erişilebilirlik testi aynı butonun doğru role, anlaşılır accessible name'e, klavye kullanımına ve görünür focus davranışına sahip olup olmadığını ayrıca değerlendirir. İki test türü birbirinin yerine geçmez ve çoğu kritik kullanıcı akışında birlikte kullanılmalıdır. En güçlü yaklaşım, fonksiyonel senaryo sırasında ulaşılan gerçek UI state üzerinde axe taraması ve gerektiğinde açık klavye assertion'ları çalıştırmaktır.

Accessibility Tree ile Accessibility Testing Aynı Şey mi?

Accessibility Tree ile accessibility testing birbirine yakın kavramlar olsa da aynı şey değildir. Accessibility Tree, browser'ın DOM ve stil bilgilerinden yardımcı teknolojiler için oluşturduğu erişilebilir temsil katmanıdır. Test motoru ise belirli kuralları kullanarak DOM, computed özellikler ve erişilebilirlik ilişkileri üzerinde hata arar. Bir element accessibility tree içinde doğru role ile görünse bile kullanıcı akışındaki focus sırası yine sorunlu olabilir. Bu nedenle tree incelemesi debugging aracı, erişilebilirlik testi ise daha geniş bir doğrulama süreci olarak görülmelidir.

Accessibility Tree Ne Gösterir?

Accessibility Tree bir elementin yardımcı teknolojiye hangi role, name, state ve ilişkilerle sunulduğunu anlamaya yardımcı olur. Örneğin görsel olarak yalnızca ikon görünen bir butonun erişilebilir adının bulunup bulunmadığı bu temsilde incelenebilir. aria-expanded gibi durumlar menü veya accordion state'inin nasıl aktarıldığını gösterebilir. Browser geliştirici araçları bu bilgileri debugging sırasında görünür hale getirir. Ancak tree'nin doğru görünmesi focus yönetimi, metnin anlaşılır olması veya ekran okuyucu ile bütün akışın kolay kullanılacağı anlamına gelmez.

WCAG Kural Motoru Ne Kontrol Eder?

WCAG odaklı kural motoru makine tarafından güvenilir biçimde değerlendirilebilen belirli accessibility kurallarını kontrol eder. axe-core bu amaçla WCAG 2.0, 2.1, 2.2 ve best-practice etiketleri taşıyan kurallar sunar. Her WCAG başarı kriterinin tamamen otomatik kontrol edilebilir olmadığı unutulmamalıdır. Bir kuralın geçmesi yalnızca motorun o koşulda tespit edilebilir ihlal bulmadığını gösterir. Tam uyumluluk değerlendirmesi otomatik taramanın yanında manuel ve insan değerlendirmesi gerektirir.

Frontend Projelerinde A11y Testleri Neden Otomatikleştirilmeli?

Erişilebilirlik yalnızca release öncesinde yapılan manuel kontrol olarak kalırsa hızlı değişen frontend projelerinde regresyon riski yükselir. Her gün yeni component, yeni state ve yeni route eklendiğinde bütün ekranları insanlar tarafından yeniden denetlemek gerçekçi değildir. Otomasyon tekrar eden ve güvenilir kuralları her commit veya pull request sırasında çalıştırır. Böylece insan zamanı alt metnin anlamı, ekran okuyucu deneyimi ve focus akışı gibi yorum gerektiren konulara ayrılabilir. İyi otomasyon manuel accessibility uzmanlığını azaltmaz, onu daha değerli alanlara yönlendirir.

Erişilebilirlik Regresyonlarını Erken Yakalamak

Daha önce erişilebilir olan bir Button component'i yapılan küçük refactor sonrasında accessible name bilgisini kaybedebilir. Bu sorun production ortamında kullanıcı tarafından bildirildiğinde düzeltme maliyeti çok daha yüksektir. Component axe testi aynı değişikliği geliştiricinin bilgisayarında saniyeler içinde gösterebilir. Shared component'teki tek hata onlarca route'u etkilediği için erken tespit özellikle design system projelerinde değerlidir. Regresyon önleme, otomatik erişilebilirlik testlerinin en güçlü kullanım alanlarından biridir.

Pull Request Aşamasında Sorunları Önlemek

Pull request pipeline'ında accessibility taraması çalıştırmak hatayı kod review tamamlanmadan görünür hale getirir. Developer ihlalin hangi selector, rule ve impact bilgisiyle ilişkili olduğunu doğrudan test çıktısında görebilir. Reviewer manuel olarak her ARIA kullanımını kontrol etmek yerine semantic kararların doğruluğuna odaklanır. Yeni ciddi ihlaller gerektiğinde merge işlemini engelleyebilir. Böylece accessibility kalite kontrolü release ekibinin son dakikadaki sorumluluğu olmaktan çıkar ve kod geliştirme döngüsüne yerleşir.

Manuel Denetim Maliyetini Azaltmak

Manuel testin tamamen kaldırılması doğru değildir, ancak insanların tekrar tekrar aynı temel hataları araması da verimli değildir. Label eksikliği, geçersiz ARIA kullanımı veya adı olmayan buton gibi deterministik problemler otomasyona bırakılabilir. Erişilebilirlik uzmanı zamanını keyboard interaction, screen reader announcement ve karmaşık kullanıcı görevlerine ayırabilir. Manuel denetimin kapsamı daha yüksek değerli senaryolara yönelir. Bu yaklaşım hem maliyeti kontrol eder hem de gerçek kullanıcı deneyimine ayrılan değerlendirme süresini artırır.

Erişilebilirliği Definition of Done İçine Almak

Bir feature yalnızca görsel olarak tamamlandığında ve API entegrasyonu çalıştığında bitmiş sayılmamalıdır. Definition of Done içine semantic HTML, component axe testi, keyboard kontrolü ve gerekli state'lerin erişilebilirlik taraması eklenebilir. Kritik component'lerde ekran okuyucu acceptance kriteri de tanımlanabilir. Bu standart ekipten ekibe değişmek yerine ortak kalite kontratı haline gelir. Accessibility requirement ürün geliştirme planının başlangıcında görünür olduğunda sonradan yapılan pahalı yeniden çalışma önemli ölçüde azalır.

Otomatik A11y Testleri Neleri Bulabilir?

Otomatik motorların güçlü olduğu alanlar DOM ve browser üzerinden objektif biçimde doğrulanabilen kurallardır. Accessible name, label ilişkisi, belirli ARIA kuralları ve bazı kontrast koşulları buna örnektir. Aynı motor component, Storybook ve gerçek browser testinde kullanılabildiği için ekip genelinde tutarlı rule set oluşturulabilir. Tarama kapsamı ve kullanılan ortam sonuçları etkileyebilir. Özellikle JSDOM ile gerçek browser arasında color contrast ve layout bilgisi açısından önemli farklar bulunduğu için test katmanları birbirini tamamlamalıdır.

Eksik veya Hatalı Alt Metinler

Image elementinin gerekli accessible alternative bilgisini taşıyıp taşımadığı otomatik olarak kontrol edilebilir. Decorative image'ın boş alt attribute kullanması ile anlamlı görselin açıklama ihtiyacı farklıdır. Motor markup seviyesindeki eksikliği bulabilir. Buna karşılık yazılan alt metnin görselin gerçek anlamını kullanıcıya doğru aktarıp aktarmadığını güvenilir biçimde değerlendiremez. Bu nedenle otomatik test structural gereksinimi doğrular, content kalitesi insan review'unda değerlendirilir.

Label Olmayan Form Alanları

Form input'un programatik label veya accessible name taşımaması kullanıcıların alanın amacını anlamasını zorlaştırır. axe-core bu tür eksikleri birçok form control için tespit edebilir. Placeholder'ın görünür olması her durumda doğru label ilişkisi anlamına gelmez. Testing Library'de form control'ü role ve accessible name üzerinden bulmaya çalışmak da developer'a erken feedback sağlar. Form validation sırasında error mesajının control ile doğru ilişkilendirilmesi için ayrıca explicit test yazmak gerekebilir.

Accessible Name Olmayan Buton ve Linkler

İkon butonlar görsel olarak anlaşılır görünse de screen reader için accessible name taşımayabilir. Otomatik motor bu durumda ilgili naming rule üzerinden ihlal üretebilir. Link'in yalnızca dekoratif SVG içermesi de benzer probleme yol açabilir. Çözüm çoğu zaman görünür metin, uygun aria-label veya mevcut metin ilişkisinin doğru kurulmasıdır. Ancak verilen adın gerçekten anlaşılır ve görevi doğru açıklayıp açıklamadığı yine insan değerlendirmesi gerektirir.

Hatalı ARIA Role ve Attribute Kullanımı

ARIA attribute'larının belirli role'larla geçerli ilişkileri bulunur. Yanlış element üzerinde desteklenmeyen attribute kullanımı yardımcı teknolojide beklenmedik davranış oluşturabilir. axe-core bu ilişkilerin önemli bölümünü kurallarla denetler. Native HTML elementi aynı semantiği zaten sağlıyorsa gereksiz ARIA kullanımı azaltılmalıdır. Test yalnızca syntax doğruluğunu değil, mümkün olduğunca native semantik tercih edilmesini destekleyen ekip standardıyla birlikte uygulanmalıdır.

Renk Kontrastı Sorunları

Gerçek browser ortamında axe-core belirli foreground ve background kombinasyonlarında kontrast kontrolleri çalıştırabilir. Bu kontrol CSS değerleri ve görünürlük bilgisine ihtiyaç duyduğu için JSDOM tabanlı testler aynı sonucu vermez. jest-axe dokümantasyonu color contrast kuralının JSDOM ortamında çalışmadığını açıkça belirtir. Bu nedenle component unit testinin geçmesi kontrastın doğrulandığı anlamına gelmez. Browser tabanlı Playwright, Storybook veya Cypress taraması contrast coverage için ayrı katman olarak korunmalıdır.

Heading ve Landmark Problemleri

Page-level tarama heading ve landmark yapısındaki belirli yapısal problemleri tespit edebilir. Component isolation ortamında ise bütün document yapısına ilişkin kurallar yanlış sonuç üretebilir. Storybook bu nedenle bazı page-level kuralları component bağlamında farklı ele alır ve varsayılan yapılandırmasında region kuralını devre dışı bırakır. Full page E2E testi document title, main landmark ve heading yapısını değerlendirmek için daha doğru katmandır. Component ve page testlerinin sorumluluğunu ayırmak gereksiz false alarm sayısını azaltır.

Duplicate ID ve DOM Kaynaklı Sorunlar

Tekrarlanan ID özellikle ARIA ilişkisinde referans verilen elementlerin yanlış eşleşmesine neden olabilir. axe-core sürüm ve ruleset'e bağlı olarak erişilebilirlik açısından etkili duplicate reference problemlerini tespit edebilir. Generic DOM validation ile accessibility rule aynı kavram değildir. Bu nedenle HTML validator veya lint kontrolü de ek güvenlik katmanı olarak kullanılabilir. Dynamic component ID generation özellikle modal, label ve description ilişkilerinde integration test ile doğrulanmalıdır.

Otomatik Erişilebilirlik Testleri Neleri Bulamaz?

Accessibility otomasyonunun en önemli sınırı insan anlamını ve gerçek interaction deneyimini tam olarak değerlendirememesidir. Araç bir alt metnin var olduğunu görebilir ancak metnin görseli doğru açıkladığına karar veremez. Focus sırasının teknik olarak ilerlemesi kullanıcı açısından mantıklı olduğu anlamına gelmez. Screen reader ile modal kullanmak, yalnızca ARIA attribute listesini kontrol etmekten daha geniş bir deneyimdir. Bu nedenle başarılı bir axe sonucu erişilebilirliğin başlangıç kalite sinyali olarak görülmeli, nihai uyumluluk kanıtı olarak sunulmamalıdır.

Alt Metnin Anlamlı Olup Olmadığı

Otomasyon bir image üzerinde alt attribute bulunduğunu kontrol edebilir. Fakat alt="görsel" gibi teknik olarak mevcut fakat içerik açısından zayıf açıklamanın yeterli olup olmadığını bağlamdan bağımsız biçimde anlayamaz. Aynı görsel farklı sayfalarda farklı amaç taşıyabilir. Ürün fotoğrafı, dekorasyon ve veri grafiği aynı alt metin stratejisini kullanmaz. Content review bu nedenle erişilebilirlik sürecinin önemli manuel parçalarından biridir.

Mantıklı Klavye Gezinme Sırası

Tab tuşuyla bütün interactive elementlere ulaşılabilmesi önemlidir, ancak sıra kullanıcı görevini desteklemiyorsa deneyim yine sorunlu olabilir. Otomatik motor DOM order ve belirli tabindex hatalarını bulabilir. Fakat kullanıcının önce hangi kontrolü görmeyi beklediğini ürün bağlamında değerlendiremez. Özellikle sidebar, sticky header ve dinamik panel bulunan ekranlarda klavye akışı manuel test edilmelidir. Gereksiz positive tabindex değerlerinden kaçınılması da sıra davranışını daha öngörülebilir hale getirir.

Gerçek Ekran Okuyucu Deneyimi

DOM ve ARIA kuralları doğru olsa bile NVDA, VoiceOver veya diğer yardımcı teknolojilerde kullanıcı deneyimi beklenenden farklı olabilir. Announcement sırası, verbosity ve navigation modeli gerçek yazılım üzerinde denenmelidir. Browser ile screen reader kombinasyonları arasında behavior farkı bulunabilir. Kritik satın alma, giriş veya form akışlarında gerçek screen reader testi özellikle değerlidir. Otomasyon bu testlerin sıklığını azaltabilir ancak gerekliliğini ortadan kaldırmaz.

Focus Yönetiminin Kullanılabilirliği

Modal açıldığında focus modal içine taşınabilir ve teknik assertion geçebilir. Buna rağmen focus yanlış kontrole gidiyorsa kullanıcı bağlamını kaybedebilir. Modal kapandığında focus'un tetikleyiciye dönmesi de deneyimin önemli parçasıdır. Route navigation sonrasında focus'un nereye taşınacağı ürün yapısına göre tasarlanmalıdır. Bu kararlar yalnızca WCAG rule motoruna bırakılmamalı ve explicit interaction testleriyle doğrulanmalıdır.

Karmaşık Etkileşimlerin Anlaşılırlığı

Drag and drop, custom combobox, data grid ve çok aşamalı form gibi etkileşimlerde yalnızca ARIA geçerliliği yeterli değildir. Kullanıcı kontrolü nasıl çalıştıracağını anlayabilmelidir. Klavye komutları, live announcement ve error recovery birlikte değerlendirilmelidir. Automated test belirli role ve property kurallarını doğrular. Kullanılabilirlik testi ise pattern'in gerçek kullanıcı tarafından anlaşılır olup olmadığını gösterir.

Otomasyon Geçerse WCAG Uyumluluğu Sağlanmış Olur mu?

Hayır, otomatik taramanın geçmesi WCAG uyumluluğunun tamamlandığını kanıtlamaz. W3C conformance bir sayfanın hedef seviyedeki bütün ilgili başarı kriterlerini karşılamasını gerektirir. axe-core yalnızca otomatik olarak değerlendirilebilen kriterler ve best-practice kontrolleri üzerinde çalışır. W3C ayrıca AA uyumluluğun bütün A ve AA kriterlerini karşılamayı gerektirdiğini belirtir. Bu nedenle otomasyon, manuel test ve gerektiğinde uzman denetimi aynı compliance programının parçalarıdır.

Frontend İçin A11y Test Piramidi

Erişilebilirlik test piramidi sorunları mümkün olduğunca erken ve düşük maliyetli katmanda yakalamayı hedefler. Static analysis saniyeler içinde feedback verirken component testleri render edilmiş küçük UI parçalarını değerlendirir. Storybook shared component state'lerini genişletir ve E2E test gerçek kullanıcı akışlarını tarar. Klavye, screen reader ve kullanıcı testleri piramidin insan değerlendirmesi gerektiren üst katmanını oluşturur. Aynı hatayı her katmanda tekrar test etmek yerine her seviyeye en uygun sorumluluğu vermek CI süresini ve bakım yükünü kontrol eder.

Katman 1: Static Analysis

Static analysis kod browser'da çalışmadan önce erişilebilirlik açısından riskli pattern'leri tespit eder. JSX üzerinde eksik alt text, yanlış role veya bazı event handler problemleri lint aşamasında bulunabilir. Bu katman en hızlı feedback mekanizmasıdır. Render edilmiş computed accessibility bilgisine ulaşamadığı için kapsamı sınırlıdır. Developer hatayı IDE içinde gördüğünde düzeltme maliyeti diğer bütün katmanlardan daha düşüktür.

eslint-plugin-jsx-a11y

eslint-plugin-jsx-a11y React ve JSX tabanlı projelerde accessibility lint kuralları sağlar. Yanlış ARIA property, mouse event ile keyboard desteği arasındaki bazı problemler ve alt text eksikleri kod yazılırken yakalanabilir. Custom component mapping doğru yapılandırılmazsa shared Button veya Link component'i gerçek semantic element gibi değerlendirilmeyebilir. Lint test motorunun yerine geçmez çünkü rendered DOM'u görmez. Yine de erişilebilirlik quality gate'in ilk ve en ucuz katmanı olarak oldukça değerlidir.

IDE ve Pre-commit Kontrolleri

Lint rule IDE içinde gerçek zamanlı çalıştığında developer pull request açmadan önce feedback alır. Pre-commit hook aynı kontrolleri merkezi biçimde zorunlu kılabilir. Hook çok uzun sürerse geliştiriciler onu atlamaya başlayabilir. Bu nedenle pre-commit yalnızca hızlı static kontrolleri çalıştırmalı ve browser testleri CI aşamasına bırakılmalıdır. Aynı configuration package bütün repository'lerde kullanılırsa ekipler arasında erişilebilirlik standardı daha tutarlı olur.

Katman 2: Component Testleri

Component testi gerçek UI parçasını küçük ve kontrollü bir ortamda render ederek DOM-level accessibility kontrolü sağlar. Button, Input veya Alert gibi tekrar kullanılan component'lerde bu katman çok yüksek yatırım getirisi sunar. Default state yanında loading, error ve expanded gibi durumlar ayrı test edilmelidir. JSDOM sınırlamaları nedeniyle browser layout ve contrast kontrollerinin tamamı burada çalışmaz. Component testinin görevi hızlı structural regression feedback sağlamaktır.

Testing Library

Testing Library kullanıcıya görünen role ve accessible name üzerinden element bulmayı teşvik eder. getByRole kullanmak hem functional hem accessibility açısından daha güçlü test yazılmasını sağlar. Bir buton yalnızca test ID ile bulunuyorsa accessible name hatası testten kaçabilir. Role tabanlı query component semantics'inin test API'sinin doğal parçası olmasını sağlar. Bununla birlikte Testing Library tek başına WCAG tarama motoru değildir ve axe ile birlikte kullanılması daha geniş coverage sağlar.

jest-axe

jest-axe axe-core sonucunu Jest matcher yapısına bağlayarak component testlerinde kullanımını kolaylaştırır. Render edilen container axe() fonksiyonuna verilir ve sonuç toHaveNoViolations() ile doğrulanabilir. Projenin mevcut Jest setup'ına kolayca eklenebilir. JSDOM ortamında color contrast kuralı çalışmadığı için gerçek browser taraması ayrıca korunmalıdır. Proje dokümantasyonu da otomasyonun erişilebilirlik garantisi olmadığını açıkça vurgular.

Vitest ile A11y Testleri

Vitest kullanan projelerde axe-core doğrudan çalıştırılabilir veya Vitest matcher sağlayan bir adapter kullanılabilir. vitest-axe jest-axe yaklaşımına benzer API sunar ve matcher'ları Vitest expect yapısına ekler. Proje dokümantasyonu Happy DOM tarafında compatibility problemi bulunduğunu, JSDOM veya gerçek Browser Mode seçiminin değerlendirilmesi gerektiğini belirtir. JSDOM browser'ın bütün rendering davranışlarını emüle etmediği için contrast gibi kontroller yine E2E katmanına bırakılmalıdır. Test environment seçimi accessibility coverage dokümanında açıkça belirtilmelidir.

Katman 3: Storybook A11y Testleri

Storybook component'in bütün varyantlarını uygulamadan bağımsız biçimde görüntülemek için güçlü accessibility çalışma alanıdır. Resmi accessibility addon axe-core kullanarak story üzerinde otomatik tarama çalıştırır. Developer violation, pass ve incomplete sonuçlarını panelde görebilir. Aynı story'ler CI ortamında test edilerek component library regresyonları merge öncesinde yakalanabilir. Design system kullanan kurumlarda bu katman yüzlerce uygulamanın ortak accessibility standardını merkezi hale getirir.

Storybook Accessibility Addon

Storybook'un resmi @storybook/addon-a11y paketi story'ler için axe-core tabanlı accessibility kontrolleri sağlar. Addon Storybook CLI üzerinden kurulabilir ve story görüntülendiğinde ilgili panelde sonuç üretir. Project, component veya individual story seviyesinde configuration yapılabilir. WCAG tag ve axe seçenekleri addon parameters üzerinden yönetilebilir. Shared configuration bütün component'lerin aynı accessibility beklentisiyle değerlendirilmesini sağlar.

Tüm Story'lerde Otomatik axe Taraması

Her story bir component state'i temsil ettiği için yalnızca default story'yi taramak yeterli değildir. Error, disabled, open ve mobile gibi önemli varyantlar story olarak tanımlanmalıdır. Storybook'un güncel test entegrasyonunda accessibility test davranışı off, todo veya error şeklinde yapılandırılabilir. error seçimi CI aşamasında ihlalin testi başarısız yapmasını sağlar. Legacy component'lerde todo geçiş modeli olarak kullanılabilir ancak kalıcı sessiz exception haline gelmemelidir.

Component Regresyonlarını PR Öncesi Yakalamak

Shared component'te accessible name veya ARIA değişikliği birçok ürünü etkileyebilir. Storybook testleri bu nedenle uygulama E2E testinden önce geniş coverage sağlar. Developer local Storybook panelinde hatayı görebilir ve component repository'sinde düzeltebilir. CI bütün story set'ini test ederek yeni ihlali merkezi biçimde engeller. Component release edilmeden accessibility kalite kontrolünün tamamlanması downstream uygulamalardaki tekrar eden sorunları azaltır.

Katman 4: E2E Erişilebilirlik Testleri

E2E accessibility testi component'leri tek tek değil gerçek sayfa ve kullanıcı akışı içinde değerlendirir. Modal açıldıktan, form hata verdikten veya client-side navigation gerçekleştikten sonra tarama yapılabilir. Browser ortamı gerçek style ve rendering bilgilerine daha yakın sonuç üretir. Functional interaction ile accessibility assertion aynı senaryoda birleştirilebilir. Kritik route'ların tamamını körlemesine taramak yerine önemli UI state'leri bilinçli olarak oluşturmak coverage kalitesini artırır.

Playwright

Playwright resmi accessibility test rehberinde @axe-core/playwright entegrasyonunu önerir. AxeBuilder page üzerinde full scan veya belirli alan taraması çalıştırabilir. include(), exclude(), disableRules() ve withTags() gibi configuration seçenekleri test senaryolarına göre kullanılabilir. Chromium, Firefox ve WebKit projeleri aynı test suite içinde çalıştırılabilir. Otomatik taramanın WCAG ihlallerinin tamamını bulamadığı Playwright dokümantasyonunda da açıkça belirtilir.

Cypress

Cypress projelerinde community cypress-axe paketi axe-core'u test sayfasına enjekte edip checkA11y() üzerinden scan çalıştırmayı sağlar. Cypress'in resmi accessibility rehberi bu plugin yaklaşımını mevcut seçeneklerden biri olarak açıklar. Cypress ayrıca güncel Cloud ürününde axe-core tabanlı ayrı accessibility raporlama özellikleri sunar. Test stratejisi kullanılan Cypress altyapısına ve raporlama ihtiyacına göre seçilebilir. Hangi seçenek kullanılırsa kullanılsın otomasyon manuel accessibility değerlendirmesinin yerine geçmemelidir.

Katman 5: Manuel Erişilebilirlik Testleri

Manuel katman otomasyonun cevap veremediği kullanıcı deneyimi sorularını değerlendirir. Klavye sırası, screen reader announcement, focus davranışı ve interaction'ın anlaşılır olması gerçek kullanım üzerinden test edilir. Kritik akışlarda engelli kullanıcılarla araştırma yapılması en güçlü kalite sinyallerinden biridir. Manuel denetim yalnızca release öncesi büyük audit olarak düşünülmemelidir. Component tasarımı sırasında küçük ve düzenli kontroller yapılması sorunların daha erken çözülmesini sağlar.

Klavye

Fare kullanmadan uygulamadaki bütün temel görevlerin tamamlanabilmesi kontrol edilmelidir. Tab ve Shift+Tab sırası görsel ve mantıksal akışla uyumlu olmalıdır. Focus göstergesi her interactive element üzerinde görülebilmelidir. Escape, Enter, Space ve arrow key davranışları component pattern'ine göre test edilmelidir. Klavye testi birkaç dakikalık düzenli kontrolle otomasyonun göremediği birçok ciddi usability problemini ortaya çıkarabilir.

NVDA

NVDA Windows üzerinde yaygın kullanılan ekran okuyuculardan biridir ve web accessibility testinde önemli kombinasyon sunar. Form, dialog, navigation ve live region davranışları gerçek browser ile birlikte değerlendirilebilir. Test yapan kişinin browse ve focus mode farklarını anlaması gerekir. Her assertion yalnızca duyulan metne değil görevin tamamlanabilirliğine odaklanmalıdır. Kritik kurumsal uygulamalarda NVDA ile seçilen browser kombinasyonu release checklist'in kalıcı parçası olabilir.

VoiceOver

VoiceOver macOS ve iOS ekosisteminde gerçek Apple kullanıcı deneyimini değerlendirmeyi sağlar. Safari ile birlikte test yapmak WebKit tabanlı accessibility behavior'ını görmeye yardımcı olur. Rotor navigation, form control ve landmark yapısı özellikle değerlendirilebilir. Desktop screen reader deneyimi mobil VoiceOver kullanımını tamamen temsil etmez. Mobil ürün veya responsive site için dokunmatik VoiceOver etkileşimi ayrıca test edilmelidir.

Gerçek Kullanıcı Testleri

Gerçek kullanıcı testi teknik olarak doğru görünen interaction'ın pratikte kullanılabilir olup olmadığını ortaya çıkarır. Kullanıcının görevi tamamlamak için aldığı süre, karşılaştığı belirsizlik ve kullandığı yardımcı teknoloji önemli gözlemler sağlar. Test katılımcıları yalnızca compliance checklist doğrulayıcısı olarak görülmemelidir. Product discovery ve usability araştırmasının doğal parçası olmalıdır. Otomatik accessibility programı bu kullanıcı araştırmasını destekler fakat onun yerini alamaz.

axe-core Nedir ve Neden Bu Kadar Yaygın Kullanılır?

axe-core web tabanlı kullanıcı arayüzlerinde otomatik erişilebilirlik kontrolleri çalıştırmak için kullanılan açık kaynaklı kural motorudur. Aynı motor Playwright, Storybook, Cypress ve farklı test adaptörleriyle kullanılabildiği için ekipler geliştirme yaşam döngüsünün farklı aşamalarında ortak rule set oluşturabilir. WCAG ve best-practice etiketleri hangi kuralların çalışacağını yönetmeyi kolaylaştırır. Sonuç modeli yalnızca ihlal listesinden oluşmaz ve pass ile incomplete gibi ek bilgiler sunar. Bu taşınabilir yapı Frontend Geliştirmede Otomatik Erişilebilirlik (A11y) Testleri programının ortak teknik çekirdeği olarak axe-core'u güçlü seçenek haline getirir.

axe-core'un Çalışma Mantığı

axe-core render edilmiş sayfa veya DOM context üzerinde belirli accessibility kurallarını çalıştırır. Kural bir veya daha fazla check içerir ve elementin başarılı, başarısız veya manuel inceleme gerektiren durumda olup olmadığını değerlendirir. Test kapsamı bütün document veya belirli selector ile sınırlandırılabilir. Sonuç node selector, HTML snippet, rule ID ve impact gibi debugging açısından yararlı bilgiler içerir. Test framework bu result object'i kendi assertion ve raporlama sistemine bağlar.

axe-core'un Desteklediği WCAG Kuralları

axe-core WCAG 2.0, WCAG 2.1 ve WCAG 2.2 ile ilişkili otomatik kuralların yanında best-practice kontrolleri sunar. Kurallar tag metadata üzerinden belirli standart veya success criterion ile ilişkilendirilir. Örneğin wcag2a, wcag2aa, wcag21aa ve güncel API dokümantasyonunda wcag22aa gibi etiketler bulunur. Belirli WCAG hedefinde eski sürüm seviyelerinin de gerekli olduğu unutulmamalıdır. WCAG 2.2 AA hedeflemek yalnızca yeni 2.2 tag'ini çalıştırmak değil A ve AA kapsamındaki önceki kriterleri de değerlendirmek anlamına gelir.

Violation, Pass ve Incomplete Sonuçları

Violation axe motorunun belirli kuralın ihlal edildiğine yüksek güvenle karar verdiği sonucu temsil eder. Pass değerlendirilen elementin ilgili kural açısından ihlal üretmediğini gösterir. Incomplete ise motorun otomatik karar veremediği ve insan incelemesi gereken durumlardır. Incomplete sonuçlarını görmezden gelmek accessibility coverage'ın önemli bölümünü sessizce kaybetmeye yol açabilir. Storybook resmi addon'u da sonuçları violations, passes ve incomplete olarak ayrı bölümlerde gösterir.

Impact Seviyeleri

axe-core violation sonuçlarında impact alanı ekiplerin sorunu önceliklendirmesine yardımcı olur. API'de minor, moderate, serious ve critical değerleri kullanılabilir. Impact ürününüzün hukuki uyumluluk seviyesiyle birebir aynı kavram değildir. Bir minor issue yine belirli kullanıcı için gerçek engel oluşturabilir. Bu nedenle CI blocking policy yalnızca severity sıralamasına değil yeni regresyon, kritik kullanıcı akışı ve WCAG hedefi gibi bağlama göre tasarlanmalıdır.

Minor

Minor seviyesi genellikle sınırlı kullanıcı etkisi beklenen veya daha düşük öncelikli violation'ı temsil eder. Bu sınıflandırma sorunun gereksiz olduğu anlamına gelmez. Yeni minor regresyonların sürekli birikmesine izin verilirse accessibility debt zaman içinde büyür. Legacy projede minor sorunlar ilk aşamada warning olarak takip edilebilir. Yeni design system component'lerinde ise mümkün olduğunca sıfır yeni violation hedefi daha sağlıklı bir kalite standardıdır.

Moderate

Moderate violation belirgin accessibility etkisi bulunan fakat serious veya critical seviyesine çıkmayan problemleri ifade eder. CI politikasında yeni moderate sorunlar warning veya blocker olarak değerlendirilebilir. Karar ekip olgunluğu ve mevcut debt düzeyine göre değişebilir. Aynı moderate hata yüzlerce sayfada shared component üzerinden tekrar ediyorsa toplam etki yükselir. Bu nedenle impact ile occurrence sayısı birlikte değerlendirilmelidir.

Serious

Serious violation birçok kurumda yeni code için merge blocker adayıdır. Form control naming, ciddi contrast veya keyboard ile ilgili bazı sorunlar bu seviyelerde görülebilir. Impact alanı kural motorunun teknik öncelik sinyalidir. Product journey içindeki kritik konum ayrıca hesaba katılmalıdır. Checkout veya login alanındaki serious problem düşük trafik alan yardımcı sayfadaki aynı rule'dan daha yüksek iş önceliği taşıyabilir.

Critical

Critical seviye kullanıcının içeriği algılaması veya işlemi tamamlaması açısından çok güçlü engel oluşturabilecek violation'larda kullanılır. Yeni critical issue normal koşullarda production'a taşınmamalıdır. CI pipeline bu seviyeyi doğrudan blocker olarak değerlendirebilir. Legacy baseline içinde mevcut critical sorun varsa ayrı remediation planı açılmalıdır. Exception gerekiyorsa teknik gerekçe, sorumlu kişi ve kesin son kullanma tarihi bulunmalıdır.

Playwright ile Otomatik A11y Testi Nasıl Yapılır?

Playwright ile accessibility testing gerçek browser üzerinde kullanıcı akışlarıyla axe taramasını birleştirir. Resmi rehber @axe-core/playwright paketiyle AxeBuilder kullanımını gösterir. Test page state'ini oluşturduktan sonra analyze() çağrısı yapılır ve violation dizisi assertion ile kontrol edilir. Aynı yaklaşım modal, form error veya navigation gibi dinamik durumlara uygulanabilir. Browser tabanlı çalışması component JSDOM testlerinde bulunmayan style ve rendering bağlamını değerlendirebilmesi açısından önemli avantaj sağlar.

@axe-core/playwright Kurulumu

Playwright projesine axe entegrasyonu development dependency olarak eklenebilir. Test runner zaten kuruluysa yalnızca axe Playwright adapter'ı gerekir. Package version'ları lockfile üzerinden sabitlenmeli ve axe güncellemeleri changelog review ile alınmalıdır. Yeni axe release'i yeni rule veya farklı detection behavior getirebileceği için CI sonucunun değişmesi normaldir. Dependency update ayrı pull request olarak çalıştırıldığında yeni violation'ların kaynağı daha kolay anlaşılır.

npm install -D @axe-core/playwright

İlk Accessibility Testini Yazmak

İlk test page'i açar, UI'ın stabil state'e gelmesini bekler ve AxeBuilder üzerinden analiz yapar. Sonuçtaki violations dizisinin boş olması beklenir. Selector'a bağlı sleep kullanmak yerine gerçek UI condition'ı beklemek daha güvenilir sonuç verir. Test yalnızca page load state'ini taradığı için dinamik modal veya error state coverage sağlamaz. Kritik etkileşimler için aynı senaryoda additional taramalar eklenmelidir.

import AxeBuilder from '@axe-core/playwright';
import { test, expect } from '@playwright/test';

test('sayfa otomatik a11y ihlali içermemeli', async ({ page }) => {
await page.goto('/');

const results = await new AxeBuilder({ page }).analyze();

expect(results.violations).toEqual([]);
});

Tüm Sayfayı Taramak

AxeBuilder context sınırlandırılmadığında page genelinde tarama çalıştırabilir. Full-page scan landmark, document structure ve farklı component'lerin birlikte oluşturduğu problemlerin bulunması için uygundur. Tarama sayfa tamamen hazır olmadan çalışırsa false negative oluşabilir. Async content'in gerçekten DOM'a geldiği condition beklenmelidir. SPA route'larında navigation tamamlandıktan sonra yeni page state ayrıca taranmalıdır.

Belirli Bir Component veya Alanı Taramak

Her testte bütün document'i tekrar taramak CI süresini gereksiz artırabilir. Belirli modal, navigation veya form scope'u include() ile test edilebilir. Scope seçimi component'in bağımlı olduğu label veya description elementlerini dışarıda bırakmamalıdır. Bazı relationship kuralları dış context'e ihtiyaç duyabilir. Full-page smoke test ile scoped interaction testlerinin birlikte kullanılması performans ve coverage açısından iyi denge sağlar.

include()

include() axe analizini belirli selector veya element alanına sınırlar. Playwright resmi rehberi dinamik navigation menüsü gibi state'lerde ilgili bölgeyi bekleyip yalnızca o alanı tarama örneği sunar. Bu yaklaşım test sonucunu interaction'ın değiştirdiği DOM bölgesine odaklar. Çok dar selector gerekli ilişki elementlerini kapsam dışı bırakabilir. Shared helper kullanırken include scope'un neden seçildiği test isminde anlaşılır olmalıdır.

exclude()

exclude() bilinen belirli bir alanı axe taramasının dışında bırakır. Playwright dokümantasyonu bunun seçilen elementin bütün descendant'larını da tüm kurallardan çıkardığı konusunda uyarır. Bu nedenle büyük container'ı exclude etmek yeni problemlerin sessizce kaçmasına yol açabilir. Exception mümkün olduğunca küçük scope'ta tutulmalıdır. Her exclusion bir ticket ve kaldırılma tarihiyle takip edilirse geçici çözümün kalıcı teknik borca dönüşmesi önlenir.

Belirli axe Kurallarını Devre Dışı Bırakmak

Bazı legacy projelerde belirli bir rule yüzlerce mevcut violation nedeniyle ilk günden pipeline'ı kullanılamaz hale getirebilir. Bu durumda geçici rule suppression düşünülebilir. Amaç testleri sessizleştirmek değil yeni otomasyon sistemini kademeli olarak devreye almaktır. Rule exception merkezi fixture içinde belgelenmeli ve business owner tarafından görünür olmalıdır. Existing debt azaldıkça devre dışı kural yeniden etkinleştirilmelidir.

disableRules()

disableRules() belirli axe rule ID'lerini scan sırasında çalıştırmaz. Playwright resmi dokümantasyonu bunu çok sayıda mevcut ihlali olan belirli rule için geçici strateji olarak gösterir. Bir element için tek sorun varsa bütün rule'u kapatmak yerine scoped exclusion daha dar çözüm olabilir. Rule devre dışı bırakıldığında yeni component'lerde oluşacak aynı hata da görünmez hale gelir. Bu nedenle disable kaydı ticket, açıklama ve expiration bilgisi taşımadan kabul edilmemelidir.

WCAG Seviyesine Göre Test Çalıştırmak

axe rule tag'leri belirli WCAG version ve seviyelerine göre scan kapsamını sınırlandırmayı sağlar. Playwright'ta withTags() bu amaçla kullanılabilir. WCAG 2.2 AA hedefi yalnızca wcag22aa tag'ini çalıştırmak değildir, çünkü önceki A ve AA kriterleri de conformance kapsamındadır. Axe API güncel tag listesinin pipeline configuration ile birlikte versionlanması faydalıdır. Best-practice kurallarının WCAG zorunluluğu olmadığı halde ürün kalitesi açısından ayrıca çalıştırılması değerlendirilebilir.

WCAG A

WCAG Level A minimum conformance seviyesidir. W3C tanımına göre Level A uyumluluk için bütün A başarı kriterlerinin karşılanması gerekir. Axe tarafında wcag2a gibi version tag'leri ilgili otomatik kuralları seçmek için kullanılır. Otomatik rule kapsamı bütün A kriterlerinin tamamını temsil etmez. CI scan sonucu manuel A criterion incelemesiyle tamamlanmalıdır.

WCAG AA

Level AA conformance bütün Level A ve Level AA kriterlerini kapsar. Kurumsal web projelerinde yaygın hedeflerden biri AA seviyesidir, ancak gerçek hukuki gereksinim ürün, ülke ve sektör bağlamında ayrıca değerlendirilmelidir. Axe tag configuration önceki version seviyelerini de içermelidir. AA scan'i yalnızca automated subset'i doğrular. Tam conformance claim için W3C'nin full-page ve diğer conformance requirements koşulları da göz önünde bulundurulmalıdır.

WCAG 2.1

WCAG 2.1 önceki 2.0 kriterlerini genişletir ve axe tarafında ilgili wcag21a ile wcag21aa tag'leri bulunur. Bir 2.1 AA automated scan genellikle 2.0 A ve AA tag'leriyle birlikte yapılandırılır. Test helper merkezi tutulduğunda bütün E2E dosyaları aynı kapsamı kullanır. Rule tag listesinin her testte elle tekrar edilmesi configuration drift oluşturabilir. Shared fixture bu nedenle daha güvenilir yöntemdir.

WCAG 2.2

WCAG 2.2 mevcut önceki kriterlerin üzerine yeni başarı kriterleri ekler. Güncel axe API dokümantasyonunda WCAG 2.2 AA için wcag22aa tag'i yer alır ve kural açıklamalarında target-size gibi otomatik değerlendirilebilen kontroller bulunur. Axe dokümantasyonunda bazı WCAG 2.2 kurallarının varsayılan ruleset davranışında özel durumu olabileceği için hedeflenen tag veya rule'un açıkça seçilmesi önemlidir. Pipeline'da kullanılan axe version'ı sabitlenmelidir. WCAG 2.2 hedefi otomatik tag setinden daha geniş manuel kriter coverage'ı gerektirir.

Dinamik UI State'leri Playwright ile Nasıl Test Edilir?

Accessibility problemlerinin önemli bölümü sayfa ilk açıldığında değil kullanıcı etkileşimi sonrasında oluşur. Modal açılması, error mesajının eklenmesi veya accordion'un genişlemesi DOM ve accessibility tree'yi değiştirir. Yalnızca initial page scan bu durumları göremez. Playwright senaryosu önce gerçek interaction'ı gerçekleştirip ilgili state'in oluştuğunu doğrulamalı, ardından axe scan çalıştırmalıdır. State coverage component state modeliyle birlikte tasarlandığında hidden regression alanları önemli ölçüde azalır.

Modal Açıldıktan Sonra A11y Taraması

Test önce modalı açan butona kullanıcı gibi tıklar. Dialog visible ve mümkünse doğru role ile render edildikten sonra axe taraması çalıştırılır. Accessible name, form control ve ARIA ilişkileri bu açık state içinde değerlendirilir. Ardından focus'un modal içine taşındığı ayrıca functional assertion ile kontrol edilmelidir. Axe scan focus trap kullanılabilirliğini tek başına kanıtlamadığı için keyboard testleri aynı senaryonun ikinci bölümünü oluşturmalıdır.

Dropdown ve Menü Açıldıktan Sonra Tarama

Closed menu state içindeki option'lar DOM'da bulunmayabilir. Bu nedenle trigger tıklanıp menu visible olduktan sonra scan yapılmalıdır. Role, accessible name ve expanded state otomatik kurallarla kısmen değerlendirilebilir. Arrow navigation ve Escape behavior explicit keyboard assertion gerektirir. Menu kapanınca focus'un tetikleyiciye dönmesi ayrıca kontrol edilmelidir.

Form Validation Hatalarını Test Etme

Form submit edilip invalid state oluşturulmadan error message accessibility'si test edilemez. Test boş veya hatalı değerle submit yapmalı ve error mesajının render edildiğini beklemelidir. axe scan error state içindeki naming ve relationship problemlerini yakalayabilir. Error'ın ilgili input ile aria-describedby veya uygun başka mekanizmayla ilişkilendiği explicit assertion ile de kontrol edilebilir. İlk hataya focus yönetimi gerekiyorsa bu behavior manuel ve otomatik keyboard testinde doğrulanmalıdır.

Loading State

Loading state birçok uygulamada spinner, skeleton veya disabled button ekler. Spinner yalnızca görsel animasyon olduğunda screen reader kullanıcısı sistemin beklediğini anlamayabilir. Status role veya live announcement gerekli use case'lerde değerlendirilmelidir. axe naming ve ARIA hatalarını tespit edebilir. Loading başladığında focus'un kaybolmaması ve işlem tamamlandığında anlaşılır feedback verilmesi ayrıca interaction testi gerektirir.

Empty State

Empty state genellikle component'in normal data state'inden farklı markup üretir. Açıklayıcı text, action button ve heading structure bu durumda ayrıca test edilmelidir. Data fixture boş döndürülerek state deterministik hale getirilebilir. Axe scan structural sorunları yakalar. Kullanıcının neden içerik olmadığını ve sonraki adımı anlayabilmesi content review gerektirir.

Error State

Network veya server error sırasında uygulama tamamen farklı UI gösterebilir. Retry button'un accessible name'i ve error heading yapısı taramaya dahil edilmelidir. Error message yalnızca color ile belirtilmemelidir. Dynamic error'ın kullanıcıya announcement gerektirip gerektirmediği ürün senaryosuna göre belirlenir. E2E fixture server response'u kontrollü biçimde başarısız yaparak bu state'i her CI çalışmasında tekrar oluşturabilir.

Accordion Expanded/Collapsed State

Accordion trigger doğru button semantics'i ve expanded state bilgisini taşımalıdır. Collapsed durumda content'in accessibility tree davranışı component pattern'iyle uyumlu olmalıdır. Expanded state oluşturulduktan sonra içerik ayrıca axe ile taranabilir. Keyboard interaction Enter ve Space ile doğrulanmalıdır. Birden fazla accordion item bulunduğunda state attribute'larının yanlış elemente bağlanmadığı da kontrol edilmelidir.

aria-live Mesajlarını Kontrol Etme

axe-core live region markup'ındaki bazı structural hataları bulabilir ancak screen reader'ın mesajı doğru zamanda ve doğru sırada duyurduğunu tamamen doğrulayamaz. Playwright DOM üzerinde live region text'inin state değişikliği sonrası güncellendiğini kontrol edebilir. Region'ın sayfa yüklenirken var olması gereken pattern'lerde başlangıç yapısı ayrıca test edilir. Çok sık update kullanıcıya gereksiz announcement yükü oluşturabilir. Kritik flow gerçek NVDA veya VoiceOver testiyle tamamlanmalıdır.

Playwright ile Klavye ve Focus Testleri

Accessibility scan ile keyboard interaction testlerini ayırmak yerine aynı E2E suite içinde birlikte çalıştırmak güçlü sonuç verir. Playwright keyboard API Tab, Enter ve Escape gibi input'ları gerçek browser seviyesinde gönderebilir. Focus assertion hangi elementin aktif olduğunu doğrular. Bu testler axe'in otomatik olarak belirleyemediği navigation davranışını güvence altına alır. Kritik component'lerde keyboard testleri yalnızca accessibility için değil genel kullanılabilirlik regresyonu için de değer sağlar.

Tab ile Gezinme

Test başlangıç noktasından Tab tuşuna basarak beklenen interactive elementlere sırayla ulaşabilir. Her adımda focused element role veya accessible name üzerinden doğrulanmalıdır. CSS selector sırasına aşırı bağlı testler component refactor'larında gereksiz kırılganlık yaratır. Amaç bütün sayfadaki her focusable elementi tek tek hard-code etmek değil kritik akışın mantıklı ilerlediğini doğrulamaktır. Shift+Tab geri yön davranışı modal ve menu gibi component'lerde ayrıca test edilmelidir.

Skip Link Testi

Skip link klavye kullanıcısının tekrar eden navigation içeriğini geçerek ana içeriğe ulaşmasını sağlar. Test ilk Tab sonrası skip link'in görünür ve focus edilmiş olduğunu kontrol edebilir. Enter ile aktive edildiğinde main content focus veya navigation hedefi doğru olmalıdır. Yalnızca link'in DOM'da bulunması yeterli değildir. Sticky header veya SPA layout değişiklikleri skip hedefini bozabileceği için regression testi değerlidir.

Modal Focus Trap Testi

Modal açıldığında focus dialog içindeki uygun ilk kontrole taşınmalıdır. Kullanıcı Tab ile ilerlediğinde modal dışındaki background interactive elementlere geçmemelidir. Son focusable elementten sonra focus modal içinde mantıklı biçimde dönmelidir. Screen reader ve keyboard kullanıcısı background content'e yanlışlıkla ulaşmamalıdır. Test aynı zamanda modal kapandıktan sonra focus'un trigger'a geri döndüğünü doğrulamalıdır.

Escape ile Modal Kapatma

Uygun dialog pattern'inde Escape keyboard interaction sık kullanılan kapatma yöntemidir. Playwright modal açıkken Escape gönderebilir ve dialog'un kapandığını kontrol edebilir. Ardından trigger'ın tekrar focus aldığı assertion yapılmalıdır. Bazı kritik işlemlerde Escape behavior product requirement nedeniyle farklı olabilir. Test semantic beklentiyi ürün tasarımıyla uyumlu olarak kodlamalıdır.

Route Değişiminde Focus Yönetimi

SPA navigation browser'ın klasik document navigation davranışını otomatik tekrar etmez. Route değiştiğinde focus eski link üzerinde kalabilir ve screen reader kullanıcısı yeni içeriğin geldiğini fark etmeyebilir. Uygulama main heading veya uygun container'a programatik focus taşıyabilir. Playwright link'e tıklayıp route değişimi sonrasında active element ve announcement state'ini doğrulayabilir. Focus yönetimi bütün route'larda aynı helper üzerinden uygulanırsa regression coverage daha kolay kurulur.

Cypress ile Otomatik A11y Testleri

Cypress kullanıcı etkileşiminden sonra ortaya çıkan DOM state'lerini test etmek için accessibility workflow'a kolayca dahil edilebilir. Community cypress-axe paketi axe-core'u Cypress command yapısına bağlar. Sayfa ziyaret edildikten sonra axe enjekte edilir ve checkA11y() ile tarama çalıştırılır. Aynı test içinde modal açıp tekrar scan yapmak mümkündür. Cypress resmi dokümantasyonu da community cypress-axe yaklaşımını accessibility seçeneklerinden biri olarak tanımlar.

cypress-axe Kurulumu

Plugin development dependency olarak projeye eklenir ve Cypress support setup içinde import edilir. axe-core bağımlılığı kullanılan package sürümüne göre birlikte gelir veya dependency tree üzerinden çözülür. Package version lockfile ile sabitlenmelidir. Dependency upgrade sonrası rule set değişikliği accessibility snapshot gibi değerlendirilmelidir. CI üzerinde kullanılan Node ve Cypress version compatibility'si package release bilgileriyle kontrol edilmelidir.

npm install -D cypress-axe axe-core

injectAxe()

cy.injectAxe() axe runtime'ını ziyaret edilen document içine enjekte eder. Bu işlem page navigation tamamlandıktan sonra yapılmalıdır. Yeni full document navigation sonrasında injection tekrar gerekebilir. Shared beforeEach helper test setup'ını sadeleştirebilir. SPA içi interaction yalnızca DOM state'i değiştirdiğinde aynı page context üzerinde scan devam edebilir.

checkA11y()

cy.checkA11y() mevcut page veya belirli context üzerinde axe taraması çalıştırır. Test failure davranışı configuration ve callback ile özelleştirilebilir. Scope selector verilerek belirli component state'i taranabilir. Impact filtering legacy adoption sürecinde kullanılabilir. Ancak sadece serious ve critical sonuçları görmek diğer debt'in görünürlüğünü tamamen kaybetmemelidir.

Etkileşim Sonrası Yeniden Tarama

Cypress testinde kullanıcı modal veya menu açtıktan sonra checkA11y() yeniden çalıştırılabilir. Bu yaklaşım initial state'te bulunmayan DOM problemlerini yakalar. Form submission, validation ve success state'leri aynı şekilde ayrı taranabilir. Scan'i her küçük click sonrasında çalıştırmak CI süresini gereksiz artırabilir. Test tasarımında accessibility açısından farklı DOM state oluşturan interaction noktaları seçilmelidir.

Belirli Impact Seviyelerini Test Etme

cypress-axe configuration belirli impact seviyelerindeki violation'ları raporlama veya failure kapsamına alma stratejilerine izin verir. Legacy uygulamada ilk aşamada critical ve serious blocking kullanılabilir. Moderate ve minor sonuçlar raporda görünmeye devam etmelidir. Debt azaldıkça threshold sıkılaştırılır. Impact filtering'in WCAG conformance filtering ile aynı şey olmadığı dokümantasyonda açıkça belirtilmelidir.

Bilinen Problemleri Geçici Olarak Hariç Bırakma

Belirli legacy element veya third-party widget geçici olarak scan dışında tutulabilir. Exclusion mümkün olduğunca dar selector kullanmalıdır. Büyük page container'ını hariç bırakmak içinde oluşacak yeni ihlalleri de gizler. Her exclusion source code veya merkezi config içinde açıklama ve ticket referansı taşımalıdır. Son kullanma tarihi geçen exception CI tarafından warning üretecek şekilde otomatik kontrol edilebilir.

Playwright mı Cypress mı? A11y Testi İçin Hangisi Daha İyi?

Playwright ve Cypress arasında evrensel olarak daha iyi accessibility aracı bulunmaz. Her iki yaklaşım da axe tabanlı scan'i gerçek kullanıcı etkileşimleriyle birleştirebilir. Seçimde mevcut test altyapısı, browser coverage, ekip deneyimi ve CI çalışma süresi daha önemlidir. Sırf accessibility için ikinci bir E2E framework eklemek çoğu projede gereksiz maintenance maliyeti oluşturur. Yeni proje kuruluyorsa accessibility test ihtiyaçları genel functional E2E gereksinimleriyle birlikte değerlendirilmelidir.

Kurulum Kolaylığı

Mevcut Playwright projesinde @axe-core/playwright eklemek oldukça doğrudan bir entegrasyondur. Cypress tarafında cypress-axe mevcut command modeline kolayca oturur. Ekip hangi framework'ü zaten biliyorsa öğrenme maliyeti daha düşük olur. Accessibility test helper'larının merkezi yazılması iki araçta da tekrarları azaltır. Kurulum birkaç komutla tamamlanabilse de doğru state coverage ve CI policy asıl mühendislik işidir.

Cross-Browser Desteği

Playwright Chromium, Firefox ve WebKit projelerini aynı test runner configuration altında çalıştırmayı kolaylaştırır. Bu özellik browser-specific keyboard ve rendering davranışlarını test etmek isteyen ekipler için güçlü avantajdır. Cypress'in browser coverage modeli ve Cloud özellikleri farklı bir workflow sunar. Axe motorunun kendisi modern browser'larda çalışır ancak integration environment farkı sonuç davranışını etkileyebilir. Critical flow için browser matrix seçimi gerçek kullanıcı analytics verisine dayanmalıdır.

CI Performansı

Accessibility scan her test state'inde ek çalışma maliyeti oluşturur. Playwright parallel worker modeli geniş suite'lerde iyi ölçeklenebilir. Cypress de test parallelization ve Cloud workflow'ları sunar. Framework karşılaştırmasında yalnızca tek test süresine değil mevcut infrastructure ve caching davranışına bakılmalıdır. Her PR'da kritik state'leri, nightly süreçte daha geniş matrix'i çalıştırmak çoğu ekip için daha verimli modeldir.

Dinamik UI State Testleri

Her iki framework modal, form, dropdown ve route navigation state'lerini oluşturarak axe scan çalıştırabilir. Fark accessibility yeteneğinden çok test API ve debugging deneyimidir. Ekip functional testlerde zaten bir araç kullanıyorsa aynı user journey içine accessibility assertion eklemek daha mantıklıdır. State creation deterministic olmalıdır. Flaky network veya animation nedeniyle scan yanlış zamanda çalıştırılmamalıdır.

Mevcut Test Altyapısına Göre Seçim

Halihazırda yüzlerce Cypress E2E testi bulunan projede yalnızca a11y için Playwright geçişi yapmak zorunlu değildir. Aynı şekilde Playwright altyapısı olan projeye Cypress eklemek duplicate bakım üretir. Accessibility otomasyonu mevcut functional test investment'ını güçlendirmelidir. Shared axe configuration framework'e özel küçük adapter arkasında tutulabilir. Kurum birden fazla ürün kullanıyorsa ortak WCAG tag ve exclusion policy ayrı package olarak paylaşılabilir.

React Component'lerinde Otomatik A11y Testleri

React component testlerinde accessibility kontrolü design system primitive'lerinden başlayarak genişletilebilir. Testing Library render sonucu axe motoruna verilerek structural violations hızlı biçimde bulunur. Component yalnızca default görünümle değil bütün önemli state'lerle test edilmelidir. JSDOM browser rendering'ini tam temsil etmediği için bu testler Storybook ve E2E browser scan ile tamamlanır. Shared helper boilerplate'i azaltırken bütün ekipte aynı axe configuration kullanılmasını sağlar.

React Testing Library + jest-axe

Testing Library component'i kullanıcıya yakın DOM yaklaşımıyla render eder. jest-axe aynı container üzerinde axe taraması çalıştırır. Role ve accessible name query'leriyle functional assertion eklenmesi testin kalitesini daha da artırır. Color contrast JSDOM limitation nedeniyle burada güvenilir biçimde kontrol edilmez. Browser seviyesindeki Storybook veya Playwright testleri bu açığı tamamlar.

Vitest + axe

Vite tabanlı React projelerinde Vitest component testleri için hızlı runner sağlar. vitest-axe veya doğrudan axe-core kullanımı accessibility assertion eklemeyi kolaylaştırabilir. Environment JSDOM olarak seçildiğinde browser-specific kontroller sınırlı kalır. Vitest Browser Mode gerçek browser testi isteyen ekipler için ayrı seçenek sunar. Tool seçimi yapılırken package maintenance durumu ve framework version compatibility'si düzenli kontrol edilmelidir.

Bir Component'in Tüm State'lerini Test Etme

Component accessibility behavior state değiştikçe değişebilir. Default state'i geçen Alert component error state'te yanlış role kullanabilir. Button loading sırasında visible text kaldırıldığında accessible name kaybolabilir. Accordion expanded olduğunda yeni content DOM'a eklenir. Test matrix component public API'sindeki erişilebilirlik açısından anlamlı bütün varyantları kapsamalıdır.

Default

Default state component'in en sık kullanılan temel görünümüdür. İlk accessibility scan burada çalışmalıdır. Role, name ve temel semantic markup bu testte doğrulanır. Component default hali bile failure üretiyorsa diğer state testlerinin değeri azalır. Shared design system için default story ve component unit testi ikisi de korunabilir.

Loading

Loading state visible label'ı spinner ile değiştiriyorsa accessible name'in korunması gerekir. Control disabled veya busy state taşıyorsa semantics doğru aktarılmalıdır. aria-busy her durumda zorunlu değildir ve doğru region bağlamında kullanılmalıdır. Loading message announcement gerekiyorsa live region test edilir. Unit axe scan yanında interaction test kullanıcının işlemi tekrar tetikleyemediğini doğrulayabilir.

Error

Error state yeni text, icon ve ARIA ilişkileri oluşturur. Input error mesajı ilgili control ile programatik ilişkiye sahip olmalıdır. Renk tek başına hata sinyali olmamalıdır. Axe structural problemleri yakalayabilir. Kullanıcının error'a yönlendirilmesi ve mesajı anlaması manuel veya E2E testle doğrulanmalıdır.

Disabled

Disabled component semantic olarak gerçekten devre dışı olup olmadığını doğru yöntemle ifade etmelidir. Native disabled ile aria-disabled farklı keyboard ve form davranışlarına sahiptir. Tasarım sistemi hangi durumda hangisinin kullanılacağını açıkça tanımlamalıdır. Disabled text contrast değerlendirmesi ürün hedeflerine göre browser testinde ele alınmalıdır. Component test semantic attribute'un doğru uygulandığını doğrular.

Expanded

Expandable component trigger state'ini yardımcı teknolojiye bildirmelidir. aria-expanded target ilişkisinin doğru element üzerinde olması önemlidir. İçerik expanded state'te DOM'a geldiğinde ayrı axe scan çalıştırılabilir. Keyboard operation component pattern'e göre test edilir. Collapsed state'te gizli content'in focusable kalmadığı ayrıca doğrulanmalıdır.

Ortak checkA11y Helper Fonksiyonu Oluşturma

Her component testinde axe setup kodunu tekrar etmek maintenance maliyetini artırır. Shared helper container alıp ortak WCAG configuration ile sonuç döndürebilir. Exception ve rule configuration tek noktada yönetilir. Helper'ın adı accessibility conformance garantisi veriyormuş gibi tasarlanmamalıdır. Örneğin expectNoAutomatedA11yViolations gibi açık isim otomasyon sınırını daha doğru ifade eder.

Vue, Angular, Svelte ve Next.js İçin A11y Test Stratejisi

axe-core framework'ten bağımsız olarak render edilmiş HTML üzerinde çalıştığı için aynı temel yaklaşım Vue, Angular, Svelte ve Next.js uygulamalarında kullanılabilir. Fark test runner, SSR ve hydration lifecycle davranışında ortaya çıkar. Component unit test ile browser E2E test birlikte tutulmalıdır. Server-rendered markup ilk state'i, hydration sonrası DOM ise client behavior'ı temsil eder. Framework değiştirmek accessibility quality modelini değiştirmemeli ve ortak WCAG configuration mümkün olduğunca paylaşılmalıdır.

Framework Bağımsız axe-core Yaklaşımı

axe-core React component modeli veya Angular directive bilgisine ihtiyaç duymaz. Motor sonuçta ortaya çıkan DOM ve accessibility semantics'i değerlendirir. Bu nedenle ortak helper farklı frontend uygulamalarında benzer tag set'i kullanabilir. Framework-specific lint layer ayrıca korunur. Kurumsal organization aynı semantic standardı farklı frontend stack'leri arasında sürdürebilir.

SSR Sonrası DOM'u Test Etmek

SSR uygulamasında ilk HTML kullanıcıya JavaScript çalışmadan önce sunulabilir. Server response üzerinde semantic heading, landmark ve form structure doğru olmalıdır. Playwright JavaScript kapalı ayrı smoke senaryosu çalıştırarak progressive enhancement beklentisini test edebilir. Uygulama tamamen client interactivity gerektiriyorsa scope buna göre belirlenir. SSR a11y hatası hydration tarafından sonradan düzeltilmeye güvenilmemelidir.

Hydration Sonrası Oluşan Sorunlar

Hydration server DOM'una event behavior ve client state eklerken markup değiştirebilir. Duplicate ID, focus reset veya hidden state hataları yalnızca client aşamasında ortaya çıkabilir. Test server page görünür olduktan sonra hydration completion condition'ını beklemelidir. Ardından axe ve keyboard assertions çalıştırılır. SSR scan ile hydrated scan arasındaki fark regression root cause bulmayı kolaylaştırabilir.

Client-Side Routing Sonrası Test

SPA framework'leri route navigation sırasında yeni document oluşturmaz. Bu nedenle page title, focus ve announcement davranışları framework uygulamasının sorumluluğundadır. Test gerçek link interaction'ını kullanıp yeni route'u bekler. Yeni DOM üzerinde axe scan çalıştırılır. Ardından heading ve focus state explicit assertion ile değerlendirilir.

SPA'larda Erişilebilirlik Testleri

SPA accessibility testing yalnızca route component markup'ını taramakla tamamlanmaz. Kullanıcı klasik sayfa yenilemesi olmadan yeni içeriğe geçtiği için focus ve announcement davranışı ayrıca tasarlanmalıdır. Screen reader kullanıcısı URL değiştiği halde yeni sayfaya geçtiğini fark etmeyebilir. Route-level E2E test bu behavior'ı gerçek navigation üzerinden doğrular. Shared router accessibility helper kullanmak uygulamanın bütün route'larında tutarlı deneyim sağlar.

Route Change Announcement

Client-side route değişimi screen reader tarafından otomatik olarak yeni document navigation gibi duyurulmayabilir. Uygulama title değişikliği veya live region üzerinden uygun notification tasarlayabilir. Announcement kısa ve kullanıcının bulunduğu sayfayı anlamasına yetecek bilgi vermelidir. Aynı mesajın iki kez duyurulmaması gerekir. Gerçek ekran okuyucu testi implementation'ın pratik davranışını doğrulamalıdır.

Focus'un Yeni Sayfa İçeriğine Taşınması

Route değişiminden sonra focus eski navigation link'inde kalırsa keyboard kullanıcısı yeni content başlangıcını bulmakta zorlanabilir. Main heading veya uygun content container programatik focus hedefi olabilir. Hedef normal tab order'ı bozmamalıdır. Playwright active element assertion ile behavior'ı otomatik doğrulayabilir. Focus target seçimi bütün route layout'larıyla uyumlu olmalıdır.

Dynamic Content Announcement

Filter result, cart update veya asynchronous error gibi önemli değişiklikler kullanıcı focus'u değişmeden gerçekleşebilir. Gereken durumlarda live region kullanıcıya yeni state'i bildirir. Her küçük güncellemeyi duyurmak ekran okuyucu deneyimini yorucu hale getirebilir. Business critical değişiklikler seçilmelidir. Automation text update'i doğrular, announcement kalitesi ise gerçek assistive technology testinde değerlendirilir.

Client-Side Navigation Sonrası Axe Taraması

Route navigation tamamlandıktan sonra yeni sayfa DOM'u axe ile taranmalıdır. Initial app shell'in bir kez geçmesi bütün route'ların erişilebilir olduğu anlamına gelmez. Shared layout ile route-specific content birlikte değerlendirilir. Critical route listesi trafik ve business importance üzerinden belirlenebilir. Nightly suite düşük trafik alan bütün route'ları daha geniş biçimde tarayabilir.

Storybook ile A11y Regresyon Testleri

Storybook design system accessibility'sini uygulama feature'larından bağımsız yönetmek için güçlü ortam sağlar. Component story'leri state inventory görevi görür. Accessibility addon her story üzerinde axe taraması çalıştırabilir ve sonucu developer'a görsel olarak gösterir. CI integration aynı stories set'ini otomatik quality gate'e dönüştürür. Böylece shared component release edilmeden önce accessibility regression büyük ölçüde yakalanabilir.

Accessibility Addon Kurulumu

Storybook resmi addon'u CLI üzerinden projeye eklenebilir. Installation gerekli configuration değişikliklerini otomatikleştirebilir. Addon axe-core üzerine kurulu olduğu için rule options mevcut axe modeline benzer. Global preview configuration bütün story'lere ortak test standardı uygular. Component-specific istisnalar yalnızca gerçek gerekçe bulunduğunda local parameter ile tanımlanmalıdır.

npx storybook add @storybook/addon-a11y

Her Story'de axe Çalıştırmak

Story açıldığında accessibility addon otomatik analiz çalıştırabilir. CI test behavior parameters.a11y.test üzerinden kontrol edilebilir. Yeni projede error kullanmak ihlalleri doğrudan failure yapabilir. Legacy story'lerde todo planlı geçiş için değerlendirilebilir. off yalnızca accessibility testinin gerçekten anlamlı olmadığı özel demo veya anti-pattern story'lerde kullanılmalıdır.

Tüm Story'leri CI'da Test Etmek

Storybook Vitest addon veya uygun test runner entegrasyonu story'leri CI'da çalıştırabilir. Accessibility behavior error olarak yapılandırıldığında violation test sonucunu başarısız hale getirir. Test runner browser process kullandığı için component JSDOM testinden daha gerçekçi environment sunabilir. Çok büyük story sayısında shard veya parallel execution kullanılabilir. A11y suite yalnızca main branch gecelik çalışmak yerine kritik component'ler için pull request aşamasında da aktif olmalıdır.

Design System İçin Accessibility Quality Gate

Design system component'i yüzlerce ekrana yayıldığı için accessibility standardı uygulama feature'ından daha sıkı olabilir. Yeni component bütün documented state'lerinde otomatik violation olmadan release edilmelidir. Keyboard pattern ve focus behavior ayrıca interaction testleriyle doğrulanır. Legacy component exception'ları release note ve debt dashboard'unda görünür tutulur. Shared package accessibility başarısı downstream uygulamalardaki toplam riskin önemli bölümünü azaltır.

Test Sonuçlarını JSON veya Rapor Olarak Kaydetmek

axe result object'i JSON formatında saklanabilir ve custom reporting pipeline'a dönüştürülebilir. Storybook test sonuçları CI artifact olarak korunabilir. Rapor yalnızca violation count değil rule, story, component ve impact bilgisi taşımalıdır. Historical trend erişilebilirlik debt'inin gerçekten azalıp azalmadığını gösterir. Raporlama build sonucunu anlamayı kolaylaştırmalı ve developer'ı yüzlerce satır ham JSON okumaya zorlamamalıdır.

WCAG 2.2 İçin Otomatik Test Stratejisi

WCAG 2.2 test stratejisi yalnızca axe'e yeni bir tag eklemekten daha geniştir. Conformance seviyesi hangi başarı kriterlerinin tamamının karşılanması gerektiğini belirler. Otomatik motor bunların yalnızca programatik olarak güvenilir biçimde test edilebilen bölümünü kapsar. Manuel checklist kalan kriterleri ve kullanıcı deneyimi testlerini yönetir. Kurum ayrıca hangi sayfa, route, responsive variation ve third-party content'in conformance kapsamına girdiğini açıkça belirlemelidir.

A, AA ve AAA Seviyeleri

W3C'ye göre Level A minimum seviyedir. Level AA bütün A ve AA success criteria'nın karşılanmasını gerektirir. Level AAA ise A, AA ve AAA kriterlerini kapsar. W3C bütün site için AAA seviyesinin genel politika olarak zorunlu tutulmasını önermediğini ayrıca belirtir, çünkü bazı content türlerinde bütün AAA kriterlerini karşılamak mümkün olmayabilir. Proje hedefi sektör, kullanıcı kitlesi ve ilgili mevzuat dikkate alınarak belirlenmelidir.

axe-core Tag Yapısı

Axe rules metadata içinde standart ve criterion ilişkisini ifade eden tag'ler taşır. wcag2a, wcag2aa, wcag21a, wcag21aa ve wcag22aa güncel API dokümantasyonunda örneklenen tag'ler arasındadır. best-practice ise doğrudan WCAG conformance criterion olmayan yararlı kontrolleri gruplar. Target standard için tag listesi shared configuration olarak tutulmalıdır. Dependency update sırasında tag ve rule değişiklikleri review edilmelidir.

Otomatik Kontrol Edilebilen Kriterler

Programatik semantik, ARIA validity, belirli accessible name kuralları ve bazı contrast koşulları automation için iyi adaydır. Sonucun güvenilir olması browser'ın gerekli bilgiyi sağlayabilmesine bağlıdır. Bazı criterion yalnızca belirli teknik pattern'lerde otomatik değerlendirilebilir. Aynı başarı kriterinin tamamı değil yalnızca belirli failure pattern'i yakalanabilir. Test coverage dokümanı hangi WCAG alanlarının otomatik olarak değerlendirildiğini açıkça göstermelidir.

Manuel Test Gerektiren Kriterler

Content anlamı, navigation mantığı, screen reader usability ve bazı cognitive experience alanları insan değerlendirmesi gerektirir. Keyboard testi bir kısmı otomatikleştirilebilse de bütün kullanıcı akışının mantıklı olması manuel review gerektirir. Zoom ve reflow gerçek layout üzerinde ayrıca test edilmelidir. Multimedia alternative kalitesi yalnızca markup varlığıyla değerlendirilemez. Automated pass report manuel test backlog'unu kapatmamalıdır.

Proje İçin Doğru WCAG Hedefini Belirlemek

WCAG hedefi yalnızca frontend ekibinin teknik kararı değildir. Product, hukuk, erişilebilirlik uzmanı ve gerektiğinde kamu veya sektör gereksinimleri birlikte değerlendirilmelidir. Hedef level ve version Definition of Done içinde açık biçimde yazılmalıdır. Yeni component ve page'ler aynı standardı kullanmalıdır. Kullanılan test configuration hedefle eşleşmeli fakat otomatik test kapsamının conformance hedefinden daha dar olduğu açıkça belirtilmelidir.

A11y Testlerini CI/CD Pipeline'ına Nasıl Ekleriz?

CI/CD entegrasyonu accessibility testlerini isteğe bağlı developer alışkanlığından sürdürülebilir kalite mekanizmasına dönüştürür. Static lint ilk aşamada, component testleri ikinci aşamada ve kritik E2E accessibility senaryoları browser test job'unda çalıştırılabilir. Pipeline sonucu pull request'e annotation veya artifact olarak eklenebilir. Severity ve yeni regresyon bilgisi build policy belirlemek için kullanılabilir. Frontend Geliştirmede Otomatik Erişilebilirlik (A11y) Testleri ancak bu geri bildirim döngüsü her değişiklikte çalıştığında kalıcı ürün standardı haline gelir.

GitHub Actions ile Playwright A11y Testi

GitHub Actions job'u dependency'leri yükleyip gerekli Playwright browser binary'lerini kurduktan sonra accessibility test script'ini çalıştırabilir. Test sonucu standart exit code üzerinden pull request'i başarısız yapar. HTML veya JSON raporlar artifact olarak yüklenebilir. Browser cache ve dependency cache CI süresini azaltır. Kritik accessibility suite ayrı job olduğunda failure nedeni functional testlerden daha kolay ayırt edilir.

- run: npm ci
- run: npx playwright install --with-deps chromium
- run: npm run test:a11y

GitLab CI Yaklaşımı

GitLab CI aynı test script'ini pipeline stage olarak çalıştırabilir. Container image içinde browser dependency'leri hazır tutmak job başlangıç süresini azaltabilir. JSON, HTML veya JUnit uyumlu test çıktıları artifact olarak saklanabilir. Merge request policy accessibility job'un başarılı olmasını zorunlu yapabilir. Tool-specific CI configuration yerine ortak npm run test:a11y command kullanmak local ve CI behavior'ını eşit tutar.

Pull Request Üzerinde Test Çalıştırmak

PR aşamasında hızlı feedback en önemli hedeftir. Static analysis, component a11y ve kritik route E2E testleri birkaç dakika içinde sonuç vermelidir. Full cross-browser ve geniş route matrix nightly pipeline'a taşınabilir. Changed component bilgisi Storybook story subset seçiminde kullanılabilir. Ancak yalnızca değişen dosyayı test etmek shared CSS veya layout etkisini kaçırabileceği için minimum kritik smoke suite her zaman korunmalıdır.

Build'i Hangi İhlaller Durdurmalı?

Bütün legacy violation'ları ilk günden blocker yapmak pipeline'ın ekip tarafından devre dışı bırakılmasına yol açabilir. Yeni projede yeni axe violation'ın tamamını fail etmek daha uygulanabilir olabilir. Legacy sistemde critical ve serious yeni regresyonlar blocker yapılırken existing baseline ayrı tutulabilir. Moderate ve minor sonuçlar görünür raporda izlenir ve zaman içinde policy sıkılaştırılır. Ayrıca severity tek başına karar vermemeli, login veya ödeme gibi kritik kullanıcı yolculuğundaki etkiler de hesaba katılmalıdır.

Critical

Yeni critical violation normal şartlarda build'i durdurmalıdır. Bu sorunların kullanıcıyı temel görevi tamamlamaktan alıkoyma riski yüksektir. Shared component'teki critical failure daha geniş etki nedeniyle ayrıca önceliklidir. Exception production incident gibi özel durumlarda bile yazılı gerekçe taşımalıdır. Takip ticket'ı olmadan suppression kabul edilmemelidir.

Serious

Serious yeni ihlaller birçok ekip için doğrudan quality gate olabilir. Legacy code içindeki existing serious debt baseline ile ayrıştırılabilir. New-code policy sayesinde teknik borç en azından büyümez. Backlog sprint kapasitesiyle kademeli azaltılır. Critical ve serious toplam trend engineering leadership dashboard'unda görünür tutulabilir.

Moderate

Moderate ihlaller projenin olgunluğuna göre blocker veya warning olarak yönetilebilir. Design system ve yeni component'lerde daha sıkı politika tercih edilebilir. Legacy application'da başlangıç aşamasında warning mantıklı olabilir. Aynı moderate rule çok sayıda occurrence üretiyorsa aggregate kullanıcı etkisi yükselir. Policy yalnızca tek violation severity'sine göre değil kapsamla birlikte değerlendirilmelidir.

Minor

Minor violation'ın build'i durdurmaması onun görmezden gelineceği anlamına gelmemelidir. Scorecard ve debt trend içinde görünür olmalıdır. Yeni projede ekip bütün automated violation'ları blocker yapmayı seçebilir. Büyük legacy projede minor debt ayrı remediation planına alınabilir. Zaman içinde yeni minor regression'ları da engellemek kalite çıtasını sürekli yükseltir.

Legacy Projelere A11y Otomasyonu Nasıl Eklenir?

Yüzlerce mevcut accessibility hatası olan uygulamada sıfır hata koşulunu ilk commit'te zorlamak gerçekçi değildir. İlk amaç mevcut debt'i görünür hale getirip yeni ihlallerin eklenmesini durdurmaktır. Baseline mevcut violation set'ini geçici olarak tanımlar. Yeni code bu baseline'ı büyütemez. Ekip daha sonra en yüksek kullanıcı etkisinden başlayarak baseline'ı küçültür ve threshold'u düzenli biçimde sıkılaştırır.

İlk Tarama ve Accessibility Debt

İlk full scan route, component ve impact seviyesinde mevcut durum envanteri çıkarır. Aynı shared component hatasının yüzlerce occurrence üretmesi tek tek yüzlerce ticket açılması gerektiği anlamına gelmez. Root component veya template bazında issue grouping yapılmalıdır. Critical flow'lar ayrıca manuel keyboard ve screen reader testine alınır. Debt envanteri product backlog'a business etkisiyle birlikte taşınmalıdır.

Baseline Oluşturmak

Baseline kabul edilmiş doğru durum değil, bilinen mevcut borcun ölçümüdür. Rule ID, stable selector ve component bilgisi mümkün olduğunca kaydedilir. Dynamic selector değişiklikleri baseline'ın sürekli kırılmasına yol açmamalıdır. Baseline version control içinde review edilebilir olmalıdır. Yeni entry eklemek normal code change kadar gerekçeli süreç gerektirmelidir.

Sadece Yeni Regresyonları Engellemek

CI current scan sonucunu baseline ile karşılaştırabilir. Existing violation testi geçici olarak bloklamaz, fakat yeni rule veya yeni element occurrence failure oluşturur. Bu model ekiplerin automation sistemini tamamen kapatmadan geliştirmeye devam etmesini sağlar. Aynı zamanda debt büyümesini durdurur. New regression count sıfır hedefi zamanla ekip kültürünün doğal parçası haline gelir.

Mevcut Sorunları Kademeli Olarak Azaltmak

Debt remediation critical ve high-traffic user flow'lardan başlamalıdır. Shared design system sorunu düzeltilirse birçok route tek değişiklikle iyileşebilir. Her sprint belirli accessibility kapasitesi ayrılabilir. Fixed violation baseline'dan silinerek geri dönmesi engellenir. Trend dashboard gerçek ilerlemeyi görünür hale getirir.

Threshold'u Zaman İçinde Sıkılaştırmak

Başlangıçta yalnızca yeni critical ve serious ihlaller fail edilebilir. Debt azaldıkça moderate ve minor policy'ye dahil edilir. Belirli tarihte deprecated exclusion'lar otomatik failure'a dönebilir. Böylece erişilebilirlik standardı tek seferlik büyük migration yerine kontrollü süreçle yükselir. Threshold değişiklikleri ekip tarafından önceden duyurulmalı ve migration süresi verilmelidir.

A11y İhlallerini Nasıl Yönetmeliyiz?

Accessibility testing yalnızca test sonucu üretmek değil, bulunan sorunları güvenilir biçimde yönetmek anlamına gelir. Violation doğrudan düzeltilebilirken incomplete sonuç insan review gerektirir. Gerçek exception ile kolay suppression birbirinden ayrılmalıdır. Rule veya element exclusion geçici ve izlenebilir olmalıdır. Issue ownership bulunmadığında accessibility report kısa sürede kimsenin bakmadığı bir listeye dönüşür.

False Positive ile Gerçek Hata Arasındaki Fark

Bir sonuç yanlış görünüyorsa önce kuralın help bilgisi ve WCAG ilişkisi incelenmelidir. Çoğu zaman developer'ın false positive sandığı durum gerçek semantic problem olabilir. Browser state ve component context doğru şekilde yeniden oluşturulmalıdır. Gerçek engine bug'ı varsa küçük reproduction hazırlanıp upstream issue açılabilir. Rule'u sessizce kapatmak son seçenek olmalıdır.

Incomplete Sonuçlar Nasıl İncelenir?

Incomplete axe'in otomatik olarak pass veya violation kararı veremediği durumları temsil eder. Bu sonuçlar CI'da otomatik failure yapılmak zorunda değildir. Ancak manuel review queue içinde görünür tutulmalıdır. Reviewer ilgili element, rule açıklaması ve kullanıcı etkisini değerlendirir. Sonuç pass kabul edilirse gerekçe kaydedilebilir ve aynı pattern için kurumsal guidance oluşturulabilir.

Bir Kural Ne Zaman Devre Dışı Bırakılabilir?

Rule yalnızca ürün bağlamında uygulanamayacağı kanıtlandığında veya geçici legacy migration gerekçesi bulunduğunda kapatılmalıdır. “Çok fazla hata veriyor” tek başına yeterli gerekçe değildir. Devre dışı bırakma merkezi configuration içinde yapılmalıdır. Kapsam mümkün olduğunca tek component veya route ile sınırlandırılmalıdır. Her rule disable kararı belirli tarihte yeniden review edilmelidir.

Exclusion'ların Teknik Borca Dönüşmesini Önlemek

Accessibility exclusion koddan sessizce görünmez olmamalıdır. Exception metadata engineering backlog sistemiyle ilişkilendirilmelidir. Ticket bulunması sahiplik ve remediation planı sağlar. Son kullanma tarihi exception'ın sonsuza kadar kalmasını önler. CI tarihi geçen exclusion için warning veya failure oluşturabilir.

Ticket Numarası

Her exclusion ilgili issue tracker kaydıyla bağlantılı olmalıdır. Ticket problemi, kullanıcı etkisini ve planlanan çözümü açıklamalıdır. Aynı issue birden fazla occurrence içeriyorsa scope açıkça yazılmalıdır. Closed ticket ile exclusion otomatik veya manuel olarak kaldırılmalıdır. Ticket bulunmayan exception code review'da kabul edilmemelidir.

Açıklama

Açıklama rule'un neden geçici olarak uygulanmadığını net biçimde belirtmelidir. “Legacy” gibi tek kelimelik not yeterli değildir. Hangi component, hangi user flow ve hangi çözüm engelinin bulunduğu yazılmalıdır. Yeni ekip üyesi aylar sonra exception'ın nedenini anlayabilmelidir. Açıklama teknik borcun görünürlüğünü artırır.

Sorumlu Kişi

Her issue belirli ekip veya owner taşımalıdır. Tek kişiye bağımlı model çalışan değiştiğinde borcu sahipsiz bırakabilir. Team ownership daha sürdürülebilir olabilir. Responsible owner remediation tarihini ve priority'yi takip eder. Accessibility ekibi danışmanlık sağlar ancak bütün uygulama hatalarının tek sahibi olmamalıdır.

Son Kullanma Tarihi

Exception sonsuz süre geçerli olmamalıdır. Expiration date geldiğinde CI yeniden değerlendirme isteyebilir. Problem çözüldüyse exclusion kaldırılır. Çözülmediyse uzatma yeni review ve gerekçe gerektirir. Bu basit mekanizma suppression'ların unutulmasını önemli ölçüde azaltır.

A11y Test Raporlama Stratejisi

İyi rapor developer'a neyin bozuk olduğunu, nerede bulunduğunu ve nasıl araştıracağını hızlıca göstermelidir. Sadece “17 accessibility error” yazmak aksiyon üretmek için yeterli değildir. Rule ID, impact, selector, component, route ve help bilgisi raporda bulunabilir. Farklı hedef kitleler için terminal, HTML ve dashboard formatları kullanılabilir. Raporlama conformance score üretme yarışına dönüşmemeli ve gerçek issue remediation'ını kolaylaştırmalıdır.

Terminal Çıktısı

Local geliştirmede terminal output en hızlı feedback formatıdır. Violation rule, impact ve element selector kısa biçimde gösterilebilir. Çok uzun HTML snippet çıktısı okunabilirliği azaltabilir. İlk birkaç occurrence gösterilip full result artifact'e yönlendirilebilir. Renk ve emojiye bağlı bilgi terminal erişilebilirliği açısından tek gösterim yöntemi olmamalıdır.

HTML Rapor

HTML report ekiplerin violation'ları browser üzerinden incelemesini kolaylaştırır. Her rule altında affected elements ve çözüm rehberi gruplanabilir. CI artifact olarak oluşturulup pull request link'inden erişilebilir. Raporun kendisi de erişilebilir olmalıdır. Historical report archive release bazlı karşılaştırma için kullanılabilir.

JSON Rapor

JSON axe result'ını başka sistemlere taşımak için en esnek formattır. Data warehouse, issue tracker veya custom dashboard bu çıktıyı işleyebilir. Raw HTML ve selector bilgisi sensitive content taşıyabileceği için artifact erişim politikası belirlenmelidir. Schema axe version değişikliğinde kontrol edilmelidir. JSON rapor insan yerine otomasyon tüketimi için tasarlanmalıdır.

SARIF Rapor

SARIF static analysis sonuçlarını code scanning araçlarına taşıyan standart formattır. axe sonucu custom adapter veya reporter ile SARIF'e dönüştürülebilir. Rule ID ve location bilgisi repository annotation ile ilişkilendirilebilir. DOM selector'ın source file satırına doğrudan eşlenmesi her framework'te kolay değildir. SARIF kullanımı mevcut security ve quality reporting altyapısıyla birleşme değeri sağlıyorsa tercih edilmelidir.

Pull Request Annotation

PR annotation developer'ın ayrı rapor açmadan ilgili erişilebilirlik problemini görmesini sağlar. Rule ID, component ve kısa çözüm açıklaması comment içinde gösterilebilir. Aynı issue her commit'te tekrar tekrar comment spam oluşturmamalıdır. Bot mevcut comment'i güncelleyebilir. New regression ile existing debt görsel olarak ayrılmalıdır.

Accessibility Scorecard

Scorecard toplam violation, new regression ve critical issue trendini yönetim seviyesinde özetleyebilir. Tek yüzde accessibility conformance anlamına gelmemelidir. Otomatik scan coverage ve manuel audit status ayrı metrikler olarak gösterilmelidir. Design system component pass rate faydalı ek KPI olabilir. Scorecard'ın amacı ekipleri puan yarışına sokmak değil risk ve ilerlemeyi görünür hale getirmektir.

A11y Test Metrikleri Nasıl Takip Edilir?

Accessibility metric seçerken sayının gerçekten davranış değişikliği üretmesi önemlidir. Toplam violation tek başına yanıltıcıdır çünkü bir shared component aynı sorunu yüzlerce kez üretebilir. New regression, severity ve component ownership daha iyi operasyon sinyalleri sağlar. Historical debt trend remediation programının işe yarayıp yaramadığını gösterir. Metrikler manuel accessibility kalitesini tamamen temsil etmediği için dashboard üzerinde bu sınır açıkça belirtilmelidir.

Toplam Violation Sayısı

Toplam violation sistemin genel otomatik debt büyüklüğünü gösterir. Ancak tek component fix yüzlerce occurrence azaltabileceği için issue ve occurrence ayrımı yapılmalıdır. Route sayısı arttıkça toplam sayı doğal olarak büyüyebilir. Normalize edilmiş page veya component rate ek bağlam sağlar. Metric trend tek başına ekip performans değerlendirmesi için kullanılmamalıdır.

Critical ve Serious Sorun Sayısı

High-impact violation sayısı risk önceliklendirmesi için daha doğrudan sinyal sağlar. Critical kullanıcı akışlarında ayrıca route breakdown yapılmalıdır. New ve existing issue ayrımı korunmalıdır. Shared component owner'ları dashboard'da görünür olabilir. Hedef zaman içinde yeni serious ve critical violation sayısını sıfırda tutmaktır.

Yeni Regresyon Sayısı

New regression CI kalitesinin en önemli metriklerinden biridir. Existing debt büyük olsa bile yeni sorun eklenmemesi erişilebilirliğin daha kötüye gitmesini durdurur. Release başına regression count takip edilebilir. Başarısız build sayısı tek başına kötü ekip performansı değildir ve automation'ın sorunları erken yakaladığını da gösterebilir. Asıl hedef merge edilen yeni violation sayısının sıfıra yaklaşmasıdır.

Component Bazında A11y Borcu

Issue'ları Button, Modal, Form veya Navigation gibi component'lere bağlamak remediation effort'u daha etkili yönlendirir. Design system fix birçok page'i tek seferde iyileştirebilir. Shared component usage count impact önceliğini artırabilir. Component owner otomatik olarak issue notification alabilir. Component debt dashboard'u uygulama bazlı toplam sayıdan daha aksiyon odaklıdır.

Zaman İçinde Accessibility Debt Trendi

Weekly veya release bazlı debt grafiği programın yönünü gösterir. Yeni issue sayısı düşükken mevcut debt azalmıyorsa remediation kapasitesi yetersiz olabilir. Axe version update yeni rules eklediğinde trend kırılması açıklanmalıdır. Rule engine change ile code regression birbirinden ayrılmalıdır. Dashboard deployment ve tooling upgrade tarihlerini annotation olarak gösterebilir.

Cross-Browser A11y Testleri

Accessibility yalnızca DOM rule scan'inden oluşmadığı için tek browser engine bütün kullanıcı deneyimini temsil etmez. Focus behavior, native control ve accessibility API mapping farklılıkları bulunabilir. Playwright browser matrix kritik interaction testlerini Chromium, Firefox ve WebKit üzerinde tekrar çalıştırmayı kolaylaştırır. Bütün test suite'i her PR'da üç browser'da çalıştırmak maliyetli olabilir. Risk bazlı matrix kritik flow'u geniş, düşük riskli testleri daha dar browser set'iyle çalıştırabilir.

Chromium

Chromium modern web geliştirme araçları ve geniş kullanıcı kitlesi nedeniyle accessibility automation'da yaygın ilk browser seçeneğidir. axe-core ve Playwright integration bu ortamda güçlü debugging sağlar. Ancak Chromium pass sonucu Firefox veya Safari behavior'ının aynı olduğunu garanti etmez. Chrome DevTools accessibility tree debugging için ek görünürlük sağlar. CI smoke suite Chromium üzerinde hızlı çalıştırılıp diğer engine'ler nightly genişletilebilir.

Firefox

Firefox farklı rendering ve accessibility platform entegrasyonu sunar. NVDA kullanıcıları için Firefox belirli test matrix'lerinde ayrıca değerli olabilir. CSS ve native control behavior farklılıkları keyboard testlerinde ortaya çıkabilir. Playwright Firefox project aynı E2E specification'larını tekrar kullanabilir. Browser-specific failure hemen uygulama bug'ı kabul edilmeden engine ve assistive technology combination üzerinden incelenmelidir.

WebKit

WebKit Safari ekosistemine daha yakın browser engine coverage sağlar. macOS ve iOS kullanıcı deneyiminin tümünü Playwright WebKit birebir temsil etmese de önemli regression sinyali sunar. VoiceOver testi yine gerçek Safari ortamında manuel olarak yapılmalıdır. Focus ve form control davranışları cross-engine karşılaştırılabilir. Critical customer journey WebKit CI job'una dahil edilmelidir.

Neden Tek Tarayıcı Yeterli Değildir?

Browser'lar accessibility semantics'i işletim sistemi accessibility API'lerine farklı implementation'larla aktarabilir. Native element behavior ve CSS rendering de değişebilir. Automation rule sonucu aynı olsa bile gerçek screen reader interaction farklı olabilir. Bu nedenle cross-browser E2E ile assistive technology manual matrix birbirini tamamlar. Kullanıcı analytics hangi browser kombinasyonlarının öncelikli olduğunu belirlemelidir.

CI Matrix Oluşturma

CI matrix browser, viewport ve gerekirse operating system boyutlarını kapsayabilir. Kombinasyon sayısı hızla büyüdüğü için risk bazlı seçim yapılmalıdır. Her PR'da Chromium critical flow, nightly süreçte Firefox ve WebKit full suite uygulanabilir. Release branch'te bütün kritik combination zorunlu hale getirilebilir. Flaky test rate matrix kararında göz önünde bulundurulmalı ve failure sessizce retry ile gizlenmemelidir.

Responsive ve Mobil Erişilebilirlik Testleri

Responsive layout yalnızca farklı ekran boyutlarında görsel tasarım testi değildir. Navigation menu, focus order ve touch target behavior viewport küçüldüğünde tamamen değişebilir. WCAG zoom ve reflow gereksinimleri content'in büyütüldüğünde kullanılabilir kalmasını bekler. Desktop accessibility scan mobile menu state'ini test etmez. Mobil ve desktop state'leri ayrı story ve E2E scenario olarak ele alınmalıdır.

Farklı Viewport'lar

Breakpoints UI component yapısını değiştirebilir. Desktop navigation links mobile hamburger menü içine taşınabilir. Her önemli breakpoint'te axe scan ve keyboard interaction test edilmelidir. Sadece pixel snapshot layout usability'sini doğrulamaz. Kullanıcı analytics representative viewport set'ini belirlemeye yardımcı olabilir.

200% ve 400% Zoom

Text resize ve zoom accessibility testlerinde content'in kaybolmaması, overlap oluşturmaması ve görevlerin tamamlanabilir kalması önemlidir. 200% text enlargement ve 400% seviyesine karşılık gelen reflow senaryoları WCAG değerlendirmelerinde farklı başarı kriterleriyle ilişkilidir. Browser zoom otomasyonu her framework'te basit olmayabilir. Manual test veya dar CSS viewport simülasyonu kullanılabilir. Kritik content ve controls horizontal scrolling veya clipping nedeniyle erişilemez hale gelmemelidir.

Reflow

Reflow testi content'in dar viewport koşulunda anlamını ve functionality'sini koruyarak yeniden yerleşmesini değerlendirir. Fixed width dialog veya table kullanıcıyı iki yönlü scrolling'e zorlayabilir. Data table gibi gerçek iki boyutlu content için istisna davranışları ayrıca değerlendirilir. Automation viewport daraltıp overflow ve hidden element assertion'ları ekleyebilir. Kullanılabilirlik yine manuel inceleme gerektirir.

Touch Target Kontrolleri

WCAG 2.2 target size criterion dokunmatik hedefler için yeni AA gereksinimlerinden biridir. axe-core güncel rule description içinde target-size kuralını WCAG 2.2 AA ile ilişkilendirir. Otomatik sonuç layout bilgisine bağlıdır. Mobile browser state gerçek spacing ile test edilmelidir. Küçük icon button yalnızca görsel büyütme değil gerçek hit area açısından değerlendirilmelidir.

Mobil Menü ve Modal Testleri

Mobile navigation çoğu zaman desktop'tan farklı DOM ve focus behavior kullanır. Menu açıldığında background content erişimi kontrol edilmelidir. Close button accessible name ve touch target açısından değerlendirilebilir. Viewport küçükken modal content scroll edilebilir kalmalıdır. Keyboard ve mobile screen reader davranışı ayrı test katmanlarında doğrulanmalıdır.

Third-Party Bileşenlerde A11y Testleri

Kontrol etmediğiniz third-party component kullanıcı açısından yine ürününüzün parçasıdır. Payment iframe, chat widget veya embedded content erişilebilirlik riski oluşturabilir. Otomatik test cross-origin iframe içeriğine her zaman erişemez. Buna rağmen integration boundary, focus behavior ve surrounding labels test edilebilir. Vendor sorumluluğu risk kaydını ortadan kaldırmaz ve ürün ekibi alternatif veya remediation planı oluşturmalıdır.

Chat Widget'ları

Chat launcher sayfanın sonunda focus alan küçük button olabilir. Accessible name, focus indicator ve keyboard activation kontrol edilmelidir. Widget açıldığında cross-origin iframe nedeniyle iç DOM axe tarafından taranamayabilir. Vendor accessibility statement ve manuel screen reader testi ek evidence sağlar. Chat zorunlu olmayan yardımcı özellikse erişilemez durumda alternatif destek kanalı sunulmalıdır.

Ödeme Bileşenleri

Payment provider component'i checkout'un kritik bölümüdür. Iframe focus sırası ve field labels kullanıcı için doğrudan önem taşır. Cross-origin content automated scanner tarafından sınırlı görülebilir. Vendor tarafından sağlanan accessibility documentation ve gerçek keyboard test birlikte değerlendirilmelidir. Payment method erişilemezse kullanıcının purchase tamamlamasını engellediği için risk seviyesi yüksektir.

Harici Embed İçerikleri

Video, map ve document embed'leri farklı accessibility davranışları taşır. Iframe title veya surrounding description first-party markup tarafından sağlanabilir. Embedded provider interface'in kendisi ayrıca değerlendirilmelidir. Alternatif content veya link kullanıcının bilgiye başka yolla ulaşmasını sağlayabilir. Automated scan'in iframe'i atlaması issue'nun olmadığı anlamına gelmez.

exclude() Ne Zaman Kullanılmalı?

Third-party DOM üzerinde düzeltme yetkiniz gerçekten yoksa belirli selector geçici olarak exclude edilebilir. Exclusion yalnızca third-party subtree'yi kapsamalıdır. Wrapper ve kendi integration markup'ınız taranmaya devam etmelidir. Vendor issue ticket ve risk acceptance kaydı tutulmalıdır. Alternatif component bulunduğunda exclusion kaldırılmalıdır.

Kontrol Etmediğimiz Kod İçin Risk Nasıl Kaydedilmeli?

Risk register vendor adı yerine component görevi, affected flow ve kullanıcı etkisini açıklayabilir. Business owner ve teknik owner atanmalıdır. Vendor'a açılan destek kaydı referans olarak eklenir. Alternatif çözüm ve review tarihi belirlenir. Third-party dependency upgrade sonrası accessibility yeniden test edilir.

A11y Testlerinin CI Performansını Optimize Etme

Accessibility test suite çok yavaşlarsa developer feedback döngüsü zayıflar. Her state'i bütün browser'larda her commit'te taramak gerekli değildir. Test katmanları risk ve hız açısından bölünmelidir. Component testleri hızlı çalışırken kritik E2E flow PR aşamasında, full matrix ise nightly süreçte çalışabilir. Parallel execution ve stable fixtures toplam süreyi azaltırken coverage korunabilir.

Her PR'da Hangi Testler Çalışmalı?

Lint ve component accessibility testleri her PR için uygun hızlı kontrollerdir. Shared component değişikliği varsa ilgili Storybook stories mutlaka çalıştırılmalıdır. Login, navigation, checkout ve form gibi kritik E2E flow'lar küçük browser set'inde taranabilir. Değişiklik impact analysis ek test seçebilir. Minimum smoke suite change detection hatasına karşı her PR'da korunmalıdır.

Nightly Testler

Nightly pipeline daha geniş route, browser ve viewport kombinasyonunu çalıştırabilir. Legacy debt report burada güncellenebilir. Low-traffic page'ler ve bütün Storybook catalog kapsamı gece testlerine taşınabilir. Sonuç sabah ekip dashboard'una özet olarak gelir. Nightly failure günlerce göz ardı edilmemeli ve belirli owner'a otomatik atanmalıdır.

Kritik Kullanıcı Akışlarını Önceliklendirmek

Authentication, ödeme, arama ve temel navigation accessibility açısından yüksek priority taşır. Bu akışlar her pull request'te daha geniş keyboard ve axe coverage alabilir. Düşük riskli dekoratif page'ler daha seyrek taranabilir. Business criticality ile accessibility severity birlikte kullanılmalıdır. Kullanıcıların üründeki ana görevleri test planının merkezinde olmalıdır.

Paralel Test Çalıştırmak

Playwright worker veya CI shard kullanımı test suite'i parallel çalıştırabilir. Testlerin birbirine bağlı state kullanmaması gerekir. Shared account veya database data race flaky sonuç oluşturabilir. Axe scan CPU kullandığı için worker sayısını makine kapasitesinin çok üstüne çıkarmak ters etki yaratabilir. CI timing verisi ideal parallelism seviyesini belirlemek için kullanılmalıdır.

Flaky A11y Testlerinden Kaçınmak

Accessibility scan yanlış zamanda çalıştırılırsa asynchronous component henüz tamamlanmadan false pass veya failure üretebilir. Sabit timeout yerine visible state, network response veya loading indicator removal beklenmelidir. Animation deterministic hale getirilebilir. Storybook resmi dokümantasyonu async React component'lerde taramanın çok erken çalışabilme riskine ayrıca dikkat çeker. Test environment'ın gerçekten hangi state'i taradığı debugging screenshot ve DOM attachment ile doğrulanabilir.

Open Source ve Ekip İçi İşbirliği ile A11y Kalitesini Artırmak

Erişilebilirlik kalitesi tek bir uzmanın bütün kodu incelemesiyle ölçeklenmez. Ortak configuration, helper ve design system pattern'leri bilgiyi ekip geneline dağıtır. Open source accessibility tooling sorunların tekrar üretilebilir test case'lerle tartışılmasına imkan verir. Ekip içinde bulunan bir edge case upstream projeye katkı haline gelebilir. Diyarbakır Yazılım Topluluğu gibi teknik paylaşım ortamları gerçek component'ler üzerinden accessibility workshop ve ortak test çalışmaları için de uygun alan oluşturabilir.

axe-core Ekosisteminin Rolü

axe-core farklı test araçları tarafından ortak motor olarak kullanılabildiği için accessibility configuration standardizasyonunu kolaylaştırır. React unit testi, Storybook ve Playwright aynı temel rule ID'lerini konuşabilir. Engine update yeni detection davranışı getirdiğinde bütün katmanlar etkilenebilir. Bu nedenle version governance ve changelog review önemlidir. Ortak ekosistem ekiplerin her test framework'ü için farklı accessibility mantığı geliştirmesini azaltır.

Ortak Test Helper'ları Oluşturmak

Shared helper WCAG tags, standard exclusions ve report formatting'i merkezi hale getirir. Developer her yeni testte AxeBuilder detayını tekrar yazmaz. Helper aynı zamanda organization-specific component selector normalization yapabilir. Çok fazla abstraction debugging'i zorlaştırmamalıdır. Testte hangi DOM scope'un tarandığı ve hangi kuralların kapalı olduğu her zaman görünür olmalıdır.

Paylaşılan A11y Config Paketi

Birden fazla repository bulunan kurumda accessibility configuration ayrı internal package olarak dağıtılabilir. WCAG hedefi, axe tag set'i ve exception schema ortak olur. Package semantic versioning ile güncellenir. Yeni rule standardı bütün uygulamalara kontrollü release olarak yayılır. Her product'ın config'i fork etmesi yerine extension noktaları sunulmalıdır.

Design System ve Uygulamalar Arasında Aynı Kuralları Kullanmak

Design system component'i bir rule set ile, application başka rule set ile test edilirse sonuçlar karşılaştırılamaz. Ortak automated standard iki katmanda da korunmalıdır. Page-level kurallar component isolation için gerektiğinde ayrı configuration kullanabilir. Farklar dokümante edilmelidir. Shared component bir uygulamada yeni context problemi oluşturabileceği için app-level scan yine gereklidir.

Open Source Projelere A11y Katkısı

Open source contribution accessibility debugging becerisini geliştirmek için güçlü pratiktir. Küçük bir button naming bug'ı bile gerçek kullanıcı etkisi taşıyabilir. Sorun tekrar üretilebilir minimal case ile açıklandığında maintainer için çözüm süresi kısalır. Fix yanında regression test eklemek aynı hatanın geri gelmesini önler. Topluluk içinde accessibility contribution yalnızca tool geliştirmek değil mevcut web projelerini daha kullanılabilir hale getirmek anlamına gelir.

Issue Açmak

İyi issue kullanılan browser, yardımcı teknoloji, beklenen davranış ve mevcut davranışı açıklar. Yalnızca “erişilebilir değil” ifadesi çözüm üretmek için yeterli değildir. Axe rule ID varsa eklenebilir fakat kullanıcı etkisi ayrıca anlatılmalıdır. Reproduction URL veya küçük repository maintainer'ın problemi doğrulamasını kolaylaştırır. Sensitive production data issue içine eklenmemelidir.

Reproduction Hazırlamak

Minimal reproduction problemi etkileyen en az kodu içermelidir. Framework dependency ve version bilgisi sabitlenir. Keyboard veya screen reader adımları açıkça yazılır. Axe false positive şüphesi varsa raw result ve DOM sample eklenebilir. Gereksiz application code çıkarıldığında engine veya component bug'ının kaynağı daha hızlı bulunur.

Test Case Eklemek

Bug fix regression testi olmadan tekrar ortaya çıkabilir. Component repository'sinde axe assertion veya keyboard interaction test eklenebilir. Engine issue'larında rule fixture expected result'i temsil eder. Test yalnızca bug'ı değil istenen semantic behavior'ı anlatmalıdır. Future contributor failure gördüğünde neden var olduğunu test isminden anlayabilmelidir.

Pull Request ile Katkı Sağlamak

Pull request küçük ve odaklı tutulduğunda accessibility change review'u kolaylaşır. Before-after davranışı açıklanmalıdır. Test ve documentation aynı değişiklik içinde güncellenebilir. Breaking ARIA veya keyboard API değişikliği migration notu gerektirebilir. Diyarbakır Yazılım Topluluğu'nun proje çalışmalarını görmek için https://www.diyarbakiryazilim.com.tr/projects adresi incelenebilir.

Frontend Ekibi İçin Önerilen A11y Test Akışı

Sağlam accessibility workflow tek bir tool seçmek yerine farklı aşamalara doğru kontrolü yerleştirir. Developer kod yazarken lint feedback alır. Component geliştirilirken Testing Library ve Storybook devreye girer. Pull request sırasında browser axe ve keyboard testleri çalışır. Release ve periyodik süreçlerde cross-browser, screen reader ve gerçek kullanıcı testleri otomasyonun kapsamadığı alanları tamamlar.

Kod Yazarken

Accessibility semantic HTML seçimiyle başlar. Native button yerine clickable div kullanmak daha sonra onlarca ARIA ve keyboard düzeltmesi gerektirebilir. IDE lint developer'a erken uyarı verir. Component API accessible name ve state bilgisini doğal olarak desteklemelidir. Kod review'a gelmeden temel semantic problem büyük ölçüde çözülmelidir.

ESLint

Accessibility lint rule'ları hızlı ve düşük maliyetlidir. JSX üzerinde yanlış ARIA property veya eksik text alternative gibi sorunları yakalayabilir. Shared configuration bütün ekipte aynı rule set'i uygular. Rule'u kapatmak local comment ile kolay olmamalıdır. Gerçek exception açıklaması code review gerektirmelidir.

Semantik HTML

Native HTML doğru kullanıldığında accessibility davranışının önemli bölümünü browser sağlar. Button, link, heading ve form label için gerçek element kullanmak custom ARIA implementation ihtiyacını azaltır. “No ARIA is better than bad ARIA” yaklaşımının temel nedeni budur. CSS styling ihtiyacı element seçimini yanlış semantiğe yönlendirmemelidir. Component library native semantics'i varsayılan API olarak sunmalıdır.

Component Geliştirirken

Component isolation farklı state'leri sistematik biçimde test etmeyi kolaylaştırır. Unit axe testi structural problemi hızlı yakalar. Storybook browser ortamında contrast ve visual context dahil daha geniş feedback sağlar. Interaction test keyboard behavior'ı doğrular. Component release olmadan bu kontrollerin tamamlanması downstream uygulama maliyetini düşürür.

Testing Library

Testing Library query'lerinde role ve accessible name tercih edilmesi component semantics'ini görünür hale getirir. Test ID yalnızca başka anlamlı query bulunmadığında kullanılmalıdır. User-event keyboard interaction component behavior'ını test edebilir. axe scan farklı rule set sağlar. İki yaklaşım birlikte daha güçlü component test katmanı oluşturur.

Storybook A11y

Storybook addon developer'a component'i tarayıcı içinde incelerken anlık accessibility feedback verir. Violation elementi panelden bulunabilir. Default, error ve open gibi bütün önemli stories taranmalıdır. CI integration regresyonu release öncesinde engeller. Design ve frontend ekipleri aynı story üzerinden problemi birlikte değerlendirebilir.

Pull Request Açıldığında

Pull request hızlı fakat yeterli accessibility quality gate çalıştırmalıdır. Component tests ve Storybook taramaları ilk katmanı oluşturur. Kritik interaction route'larında Playwright veya Cypress scan devreye girer. Yeni serious veya critical issue merge'i durdurabilir. Rapor reviewer'a yalnızca hata sayısı değil düzeltme için gerekli context'i sunmalıdır.

Component Tests

Changed component state matrix axe ile taranır. Unit test birkaç saniyede sonuç verebildiği için bütün PR'larda çalışabilir. New component otomatik violation ile merge edilmemelidir. JSDOM limitation report'ta bilinmelidir. Browser test coverage ayrıca korunur.

Playwright veya Cypress

Existing E2E framework kritik route'ları gerçek browser üzerinde tarar. Modal, form error ve navigation state'leri özellikle oluşturulur. Her interaction sonrası scan yerine anlamlı state boundary'leri seçilir. Keyboard assertions axe sonucuna eklenir. Test output accessibility artifact olarak PR'a bağlanır.

Deployment Öncesinde

Release öncesi test PR kapsamından daha geniş olabilir. Critical user journey bütün desteklenen browser set'inde çalıştırılır. Responsive viewport ve cross-browser behavior değerlendirilir. Known exception expiration kontrol edilir. Release candidate accessibility debt'i beklenmedik biçimde artırmışsa yayın durdurulabilir.

Critical Flow Testleri

Login, checkout, account recovery ve temel navigation gibi görevler release öncesi tam senaryo olarak test edilmelidir. Axe scan her önemli dynamic state'te çalışır. Keyboard-only kullanıcı görevi tamamlayabilmelidir. Error recovery dahil edilmelidir. Screen reader manual smoke seçili release'lerde veya önemli UI değişikliğinde eklenebilir.

Cross-Browser Test

Chromium hızlı PR default'u olabilir. Release pipeline Firefox ve WebKit critical flow'ları ekleyebilir. Browser-specific failure ayrı triage edilir. Native controls ve focus behavior özellikle incelenir. Gerçek assistive technology test matrix supported user analytics'e göre planlanır.

Periyodik Olarak

Otomasyon her release'te çalışsa bile periyodik manuel audit gereklidir. Yeni design pattern ve third-party dependency'ler automation coverage dışı problem oluşturabilir. Accessibility debt trend ile birlikte user feedback değerlendirilmelidir. Büyük feature launch öncesi focused audit yapılabilir. Yıllık tek büyük kontrol yerine daha sık küçük manuel review daha sürdürülebilir sonuç verir.

Klavye Testi

Belirli aralıklarla ana ürün akışları fare kullanılmadan tamamlanmalıdır. Focus visibility, order ve keyboard shortcuts değerlendirilir. Test sadece developer tarafından değil accessibility konusunda eğitimli farklı ekip üyesi tarafından da yapılabilir. Yeni modal veya navigation pattern özellikle kontrol edilir. Bulunan problem automated regression test'e dönüştürülebiliyorsa suite'e eklenmelidir.

Screen Reader Testi

NVDA ve VoiceOver representative browser'larla birlikte kullanılabilir. Heading navigation, forms, dialog ve live updates ana odak alanlarıdır. Test script kullanıcının gerçek görevini temsil etmelidir. Her küçük announcement kelimesini snapshot gibi sabitlemek brittle automation üretmemelidir. Kritik behavior gözlemi documentation'a eklenmelidir.

Gerçek Kullanıcı Testi

Engelli kullanıcıların ürünü kendi yardımcı teknolojileriyle kullanması ekibin varsayımlarını test eder. Araştırma yalnızca accessibility problemi bulmak için değil genel product experience'i geliştirmek için yapılmalıdır. Katılımcılara uygun ödeme ve erişilebilir araştırma ortamı sağlanmalıdır. Bulgular product backlog'a diğer usability feedback'leri gibi taşınmalıdır. Accessibility automation bu feedback'ten yeni regression test pattern'leri çıkarabilir.

Otomatik A11y Testleri İçin Best Practices

Accessibility otomasyonunun değeri test sayısından değil doğru state ve doğru policy seçiminden gelir. Sadece homepage taramak geniş uygulama coverage sağlamaz. Dynamic state'ler kullanıcı deneyiminin önemli bölümünü oluşturur. Rule suppression görünür ve geçici olmalıdır. En önemli ilke otomasyonun manuel accessibility testinin yerine geçmediğini ekip kültüründe sürekli korumaktır.

Sadece Ana Sayfayı Test Etmeyin

Homepage başarılı olsa bile checkout, dashboard veya form route'larında tamamen farklı component'ler bulunabilir. Route template inventory accessibility coverage planının temelidir. High-traffic ve critical-flow sayfalar PR testlerine alınmalıdır. Düşük trafik route'ları nightly suite içinde taranabilir. Shared layout değişikliği birçok page'i etkileyebileceği için representative full-page scans korunmalıdır.

Etkileşim Sonrası UI State'lerini Tarayın

Modal kapalıyken içindeki erişilebilirlik hatası görünmeyebilir. Form error yalnızca submit sonrasında oluşur. Menu item'ları open state'te DOM'a eklenebilir. E2E test meaningful state transition sonrasında scan yapmalıdır. State inventory component Storybook stories ile ortak tutulursa coverage boşlukları daha kolay görülür.

Her Hatayı Körü Körüne Build Blocker Yapmayın

Legacy projede yüzlerce mevcut ihlal bütün pipeline'ı kullanılamaz hale getirebilir. New regression policy daha uygulanabilir başlangıç sunar. Critical ve serious blocker, lower impact warning yaklaşımı geçici olarak kullanılabilir. Hedef zaman içinde threshold'u sıkılaştırmaktır. Exception sistemi automation'ı tamamen kapatmanın bahanesine dönüşmemelidir.

disableRules Kullanımını Belgeleyin

Devre dışı rule test coverage'da görünmeyen büyük boşluk yaratır. Kuralın neden kapatıldığı ve hangi issue ile takip edildiği config yanında yazılmalıdır. Expiration date kullanılmalıdır. Rule update veya component fix sonrasında tekrar etkinleştirilmelidir. Shared package exception sayısını metric olarak raporlayabilir.

Accessibility Testlerini Functional Testlerden Ayırmayın

Kullanıcı accessibility ile functional behavior'ı ayrı deneyimlemez. Button çalışmalı ve erişilebilir olmalıdır. Functional E2E senaryosunda oluşturulan modal state aynı anda accessibility taraması için değerlidir. Ayrı test suite bazı durumlarda reporting için faydalı olsa da kullanıcı akışı bilgisini paylaşmalıdır. Aynı state'i iki kez pahalı biçimde kurmak CI süresini gereksiz artırabilir.

Otomasyonu Manuel Testin Yerine Koymayın

axe scan pass sonucunun gerçek ekran okuyucu deneyimini doğrulamadığı açıkça kabul edilmelidir. Keyboard order ve content anlamı insan judgment gerektirir. W3C conformance otomatik ruleset'ten daha geniştir. Accessibility programı manual coverage calendar ve user research içermelidir. Otomasyon insan testlerini ortadan kaldırmak yerine onların en değerli alanlara odaklanmasını sağlar.

Frontend Accessibility Testing Checklist

Checklist ekiplerin hangi aşamada hangi kontrolün beklendiğini hızlı biçimde görmesini sağlar. Liste herkes için aynı düzeyde test çalıştırmak yerine katmanlı yaklaşımı desteklemelidir. Commit aşaması hızlı, release aşaması daha geniş olmalıdır. Periodic manual audit otomatik coverage boşluğunu tamamlar. Checklist repository documentation ve onboarding sürecinde erişilebilir yerde tutulmalıdır.

Her Commit

Her commit saniyeler içinde çalışabilen kontrollerle korunmalıdır. Accessibility lint ve semantic code review bunun temelidir. Browser E2E'yi pre-commit yapmak developer experience'i gereksiz yavaşlatabilir. IDE feedback sorunları commit öncesinde gösterir. Commit hook başarısızsa developer doğru fix yolunu kolayca görebilmelidir.

Lint

JSX ve template lint accessibility risklerini source seviyesinde yakalar. Shared configuration bütün team için aynı standardı uygular. Warning'lerin aylarca birikmesine izin verilmemelidir. New code mümkün olduğunca zero warning hedefiyle geliştirilmelidir. Lint rule exception gerekçesiz inline disable ile geçilmemelidir.

Semantik Kontrol

Developer yeni UI yazarken önce doğru native element seçimini kontrol etmelidir. Button yerine div, label yerine placeholder kullanmak sonraki test katmanlarında gereksiz problem üretir. Heading seviyeleri content hierarchy'yi temsil etmelidir. ARIA native semantiğin yerine rastgele eklenmemelidir. Code review checklist bu alışkanlığı destekler.

Her Pull Request

PR yeni code'un otomatik accessibility regression üretip üretmediğini gösterir. Component axe testleri hızlı structural coverage sağlar. Storybook design system state'lerini tarar. Kritik E2E flow gerçek browser behavior'ını test eder. New serious issue merge edilmeden çözülmelidir.

Component axe Testleri

Changed component default ve önemli state'leri taranır. Shared helper standard ruleset kullanır. Test output hangi rule'un fail olduğunu açık gösterir. JSDOM limitation bilinmelidir. Browser coverage sonraki katmanda tamamlanır.

Storybook

Storybook visual state inventory accessibility addon ile birlikte değerlendirilir. Error ve open gibi state'ler story olarak bulunmalıdır. CI story tests violation'ı failure yapabilir. Designer aynı panel üzerinden issue'yu görebilir. Shared component release accessibility review'dan geçer.

Kritik E2E A11y Testleri

Login, navigation veya checkout gibi birkaç önemli flow gerçek browser üzerinde çalıştırılır. Dynamic states axe ile taranır. Keyboard assertions eklenir. Full suite yerine risk bazlı subset PR feedback süresini kontrol eder. Nightly pipeline daha geniş coverage sağlar.

Her Release

Release candidate daha geniş browser ve responsive coverage almalıdır. Known exception'lar yeniden gözden geçirilir. Manual keyboard smoke uygulanabilir. Zoom ve reflow kritik layouts üzerinde test edilir. High-risk UI redesign screen reader review gerektirebilir.

Cross-Browser

Critical flows Chromium, Firefox ve WebKit üzerinde tekrarlanabilir. Browser-specific failures triage edilir. axe scan yanında native keyboard behavior incelenir. Supported browser policy test matrix'i belirler. Düşük kullanım oranı olan browser tamamen göz ardı edilmeden risk bazlı schedule'a alınabilir.

Klavye

Release candidate ana görevleri sadece keyboard ile tamamlamalıdır. Focus indicator kaybolmamalıdır. Modal ve menu interaction pattern'leri doğrulanır. Skip link ve route focus behavior kontrol edilir. Bulunan tekrar üretilebilir hata automated test'e dönüştürülür.

Zoom ve Reflow

Content büyütüldüğünde önemli controls görünür ve kullanılabilir kalmalıdır. Sticky navigation content'i kapatmamalıdır. Modal küçük viewport'ta scroll edilebilir olmalıdır. Horizontal overflow kaynağı tespit edilir. Responsive visual testing accessibility zoom testinin yerini tamamen almaz.

Periyodik Denetim

Periyodik audit automation coverage dışında kalan kriterleri sistematik inceler. Yeni WCAG guidance ve browser behavior değişiklikleri değerlendirilir. User feedback audit planını yönlendirebilir. Audit sonuçları backlog ve automated test improvements üretmelidir. Aynı manuel problem tekrar bulunuyorsa otomasyona dönüştürülebilir bölümü araştırılmalıdır.

NVDA

Windows ve representative browser kombinasyonunda critical journey test edilir. Navigation, heading, forms ve dialogs üzerinde task-based yaklaşım kullanılır. Announcement sırası gözlemlenir. Kullanıcı browse ve focus mode arasında kaybolmamalıdır. Bulgu issue tracker'a açık reproduction adımlarıyla eklenir.

VoiceOver

macOS Safari ve gerektiğinde iOS Safari üzerinde test yapılır. Rotor ve touch navigation mobile deneyimde değerlendirilir. Custom controls native behavior ile karşılaştırılır. Focus ve announcement farkları documentation'a eklenir. Browser automation bu gerçek assistive technology testinin yerini almaz.

Manuel WCAG İncelemesi

Automated engine kapsamı dışında kalan success criteria checklist üzerinden değerlendirilir. Content alternatives, instructions ve interaction understandability insan review gerektirir. Full-page conformance scope açıkça tanımlanmalıdır. Responsive variations de assessment kapsamına alınmalıdır. Sonuç yalnızca tool skoruna değil criterion evidence'a dayanmalıdır.

Sık Sorulan Sorular

Frontend accessibility testing konusunda en fazla karıştırılan konu otomatik araçların gerçek kapsamıdır. axe-core, Playwright, Cypress ve Storybook hızlı ve sürekli feedback sunar. Buna rağmen hiçbir automated scanner bütün WCAG kriterlerini veya gerçek yardımcı teknoloji deneyimini tek başına doğrulayamaz. Doğru araç seçimi mevcut frontend ve test mimarisine göre yapılmalıdır. Aşağıdaki yanıtlar ekiplerin automation strategy oluştururken en sık karşılaştığı sorulara pratik çerçeve sunar.

A11y Nedir?

A11y accessibility kelimesinin yaygın teknik kısaltmasıdır. Web uygulamalarının farklı engel durumlarına sahip kullanıcılar ve yardımcı teknolojiler tarafından kullanılabilir olmasını ifade eder. Semantic HTML, keyboard support, readable contrast ve screen reader behavior bu alanın parçalarıdır. A11y yalnızca ARIA yazmak anlamına gelmez. İyi accessibility çoğu zaman doğru native web özelliklerini doğru interaction tasarımıyla kullanmakla başlar.

axe-core Nedir?

axe-core HTML tabanlı kullanıcı arayüzlerinde otomatik erişilebilirlik kontrolleri çalıştıran açık kaynak kural motorudur. WCAG ile ilişkili kurallar ve best-practice kontrolleri sunar. Playwright, Cypress ve Storybook gibi farklı test ortamlarına entegre edilebilir. Sonuçlar violation, pass ve manual review gerektiren bilgiler içerebilir. Otomasyonun geçmesi tam accessibility garantisi değildir.

Playwright ile Erişilebilirlik Testi Yapılabilir mi?

Evet, Playwright resmi rehberinde @axe-core/playwright ile axe-core entegrasyonu gösterilir. AxeBuilder full page veya belirli component alanını tarayabilir. Dynamic state oluşturulduktan sonra analiz çalıştırılabilir. withTags, include, exclude ve disableRules gibi configuration seçenekleri bulunur. Keyboard ve focus testleri de aynı Playwright senaryosuna eklenebilir.

Cypress ile A11y Testi Nasıl Yapılır?

Cypress projelerinde community cypress-axe paketi sık kullanılan seçeneklerden biridir. Page ziyaret edildikten sonra injectAxe() çağrılır ve checkA11y() ile scan yapılır. Modal veya error state oluşturulduktan sonra scan tekrar çalıştırılabilir. Cypress ayrıca kendi güncel accessibility tooling seçeneklerine de sahiptir. Kullanılan yöntemin otomatik coverage sınırları manuel test planıyla tamamlanmalıdır.

Lighthouse A11y Testleri İçin Yeterli mi?

Lighthouse hızlı accessibility audit için yararlıdır ancak sürdürülebilir test stratejisinin tamamı değildir. Kullanıcının oluşturduğu bütün dynamic UI state'leri kendiliğinden gezmez. Component regression ve keyboard interaction testleri ayrıca gerekir. CI içinde Lighthouse kullanılabilir fakat Playwright veya Cypress state-aware coverage daha hedefli sonuç sağlar. Manual screen reader ve keyboard test yine korunmalıdır.

Otomatik Testler WCAG'ın Tamamını Kontrol Edebilir mi?

Hayır, automated scanner bütün WCAG criteria'yı tam olarak değerlendiremez. İnsan anlamı, usability ve yardımcı teknoloji interaction'ı otomasyona tamamen çevrilemez. Playwright ve Cypress accessibility dokümantasyonları da automated scan'in bütün ihlalleri kanıtlayamayacağını açıkça belirtir. WCAG conformance hedef seviyedeki bütün kriterleri karşılamayı gerektirir. Bu nedenle automation manual testing'in güçlü tamamlayıcısıdır.

WCAG 2.2 axe-core ile Test Edilebilir mi?

axe-core WCAG 2.2 ile ilişkili otomatik kurallar içerir. Güncel API dokümantasyonunda wcag22aa tag'i bulunur ve rule descriptions içinde target-size gibi 2.2 AA kontrolleri yer alır. Ancak 2.2 uyumluluğu yalnızca bu tag'in pass olmasıyla kanıtlanmaz. Önceki A ve AA criteria ile manuel olarak değerlendirilecek 2.2 kriterleri de kapsamda kalır. Project configuration kullanılan axe version'ı ve target tags'i açıkça versionlamalıdır.

Playwright mı Cypress mı Tercih Edilmeli?

Mevcut E2E altyapınız hangi aracı kullanıyorsa çoğu durumda accessibility testini aynı framework'e eklemek en verimli çözümdür. Playwright geniş browser matrix ve resmi axe adapter'ı ile güçlü seçenek sunar. Cypress mevcut command ve debugging modeliyle cypress-axe kullanımını kolaylaştırır. İkinci bir framework yalnızca a11y için eklenmeden önce bakım maliyeti değerlendirilmelidir. Erişilebilirlik kalitesi araç isminden çok doğru state coverage ve CI policy'ye bağlıdır.

Storybook'ta Otomatik A11y Testi Yapılabilir mi?

Evet, Storybook resmi accessibility addon axe-core kullanır. Story görüntülendiğinde otomatik scan çalışabilir. Test behavior off, todo veya error olarak yapılandırılabilir. CI integration story violation'larını failure haline getirebilir. Design system component'lerinde bu yöntem regression prevention açısından özellikle değerlidir.

CI Pipeline Bir A11y Hatasında Durdurulmalı mı?

Yeni projelerde otomatik olarak doğrulanmış yeni violation'ları blocker yapmak güçlü kalite standardıdır. Legacy projede bütün mevcut debt'i tek anda blocker yapmak workflow'u kullanılamaz hale getirebilir. Yeni critical ve serious regressions ilk aşamada engellenebilir. Existing issues baseline ve remediation planıyla azaltılır. Zaman içinde moderate ve minor policy de sıkılaştırılabilir.

Mevcut Yüzlerce A11y Hatası Olan Bir Projede Nereden Başlanmalı?

Önce bütün sorunlar taranıp page ve component bazında gruplandırılmalıdır. Critical user flows ve shared components yüksek öncelik almalıdır. Baseline oluşturularak yeni regression'lar anında engellenir. Existing debt sprintler içinde düzenli kapasiteyle azaltılır. Her fix baseline'dan kaldırıldığında aynı sorun gelecekte yeniden merge edilemez.

Sonuç: Erişilebilirliği Test Sonrası Kontrol Değil, Frontend Geliştirme Sürecinin Parçası Yapmak

Frontend Geliştirmede Otomatik Erişilebilirlik (A11y) Testleri başarılı olduğunda erişilebilirlik release sonunda açılan ayrı kontrol listesi olmaktan çıkar ve günlük geliştirme pratiğine dönüşür. Static analysis problemi developer yazarken, component axe testleri component geliştirilirken, Storybook shared UI seviyesinde ve Playwright veya Cypress gerçek kullanıcı akışında yakalar. Klavye, NVDA, VoiceOver ve gerçek kullanıcı testleri ise otomasyonun değerlendiremeyeceği deneyim alanlarını tamamlar. CI/CD üzerinde yeni regresyonların engellenmesi ve legacy debt'in ölçülebilir biçimde azaltılması uzun vadede çok daha güvenilir sonuç verir. Frontend kalite süreçleri, erişilebilir component mimarisi ve sürdürülebilir test otomasyonu üzerine Diyarbakır Yazılım Topluluğu ile iletişim kurmak için https://www.diyarbakiryazilim.com.tr adresini kullanabilirsiniz.

Erişilebilirlik açısından güçlü bir ürünün hedefi yalnızca axe sonucunda sıfır violation görmek değildir. Asıl hedef klavye, ekran okuyucu, zoom, mobil cihaz ve farklı interaction yöntemleri kullanan kişilerin temel görevlerini anlaşılır biçimde tamamlayabilmesidir. Otomatik testler bu hedefe giderken tekrar eden teknik hataları erkenden durdurur ve manuel uzmanlığın daha değerli konulara ayrılmasını sağlar. Kendi ekibinizin component, Storybook ve CI/CD pratiğini değerlendirmek için önce mevcut accessibility debt'inizi ölçebilir, ardından yeni regresyonları engelleyen küçük bir quality gate ile başlayabilirsiniz. Topluluk ve yürütülen çalışmalar hakkında ek bilgi için https://www.diyarbakiryazilim.com.tr/about adresini inceleyebilirsiniz.