Formlarınızı Erişilebilir Hale Getirme: Etiketler, Hatalar ve Doğrulama

WebAIM’e göre, web sitesi ana sayfalarının %48,6’sında form girdi etiketleri eksik — bu da etiketlenmemiş girdileri web genelindeki en yaygın erişilebilirlik hatalarından biri haline getiriyor. Bunun pratikte ne anlama geldiğini düşünün: bir ekran okuyucu kullanıcısı iletişim formunuza gelir, alanlar arasında gezinmek için Tab tuşuna basar ve tekrar tekrar yalnızca “metin düzenle” ifadesini duyar. Ekran okuyucular form alanı etiketlerini okur — etiketler olmadan kullanıcılar bağlam olmaksızın “metin düzenle” duyar ve hangi bilgiyi girmeleri gerektiğini bilemezler. Formlar genellikle bir web sitesinin iş açısından en kritik kısmıdır — ödeme akışları, kayıt ekranları, iletişim sayfaları, destek talepleri — ve yine de yardımcı teknoloji kullanan kişiler için en tutarlı şekilde bozuk deneyimler arasında yer almaya devam ederler.

Form Erişilebilirliği Sandığınızdan Daha Fazla Neden Önemlidir

ABD’li yetişkinlerin 4’te 1’inin bir engelle yaşadığı düşünüldüğünde, erişilebilir form doğrulaması isteğe bağlı değil; gereklidir. Bu nüfus; kör olan veya az gören kişileri, klavye ile gezinmeye güvenen motor bozukluğu olan kişileri, net talimatlara ihtiyaç duyan bilişsel engelli kişileri ve formları doldurmak için sesle kontrol yazılımı kullanan kişileri içerir. Etiketsiz her alan, belirsiz her hata mesajı ve yalnızca renge dayanan her doğrulama deseni, kitlenizin önemli bir kısmının önünde sessizce kapanan bir kapıdır.

Çoğu engelli kullanıcı bilgi gönderirken hatalarla karşılaşır ve bunları nasıl düzelteceklerine dair net talimatlar almaz — bu da onları iki seçenekle baş başa bırakır: denemeyi bırakıp daha erişilebilir bir form aramak ya da bir başkasından yardım istemek; bunların hiçbiri ideal deneyimler değildir. İş açısından bakıldığında, erişilebilir formlar kullanıcı deneyimini iyileştirir, terk edilme oranlarını azaltır ve yasal gereklilikleri karşılar. Uyum açısından bakıldığında, WCAG 1.3.1 (Bilgi ve İlişkiler) ve 4.1.2 (Ad, Rol, Değer), 2008’de WCAG 2.0 yayınlandığından beri var olan Seviye A gereklilikleridir. Bunlar uç senaryolar veya ileri teknikler değildir — standardın temel beklentileridir.

WebAIM Million raporuna göre, eksik form etiketleri web genelinde en üst düzey erişilebilirlik hataları arasında sürekli olarak yer alır ve uygulama hatalarına ilişkin araştırmalar nedenini gösterir: kuruluşlar, engelli kişilerin hizmetlerini gerçekten kullanmasını sağlayacak temel kalıpları görmezden gelirken karmaşık çözümlere odaklanır. İyi haber şu ki, bu sorunların çoğunu düzeltmek için sıra dışı hiçbir şeye gerek yok — yalnızca kasıtlı, bilgili HTML yeterlidir.

Formları Düzenleyen WCAG Başarı Kriterleri

Uygulamaya dalmadan önce, formlar için hangi spesifik WCAG başarı kriterlerinin geçerli olduğunu bilmek faydalıdır. Web İçeriği Erişilebilirlik Yönergeleri (WCAG), kapsayıcı doğrulama sistemlerinin belkemiğini oluşturan dört temel ilkeyi — Algılanabilir, İşletilebilir, Anlaşılabilir ve Sağlam (POUR) — ortaya koyar. Bu çerçeve içinde, birkaç başarı kriteri doğrudan form tasarımına hitap eder.

En ilgili kriterler şunlardır: 1.3.1 Bilgi ve İlişkiler (Seviye A), sunum yoluyla aktarılan bilgi, yapı ve ilişkilerin programatik olarak belirlenebilmesini gerektirir; 2.4.6 Başlıklar ve Etiketler (Seviye AA), başlıkların ve etiketlerin konu veya amacı tanımlamasını belirtir; 3.3.2 Etiketler veya Talimatlar (Seviye A), içerik kullanıcı girdisi gerektirdiğinde etiketler veya talimatlar sağlanmasını zorunlu kılar; ve 4.1.2 Ad, Rol, Değer (Seviye A), tüm kullanıcı arayüzü bileşenleri için ad ve rolün programatik olarak belirlenebilmesini gerektirir.

Hata tanımlama, talimatlar, öneriler ve önlemeyi kapsayan 3.3.1’den 3.3.4’e kadar olan WCAG yönergelerine uyarak, tüm kullanıcılar için daha kolay ve daha sezgisel formlar oluşturursunuz. Bunlar keyfi engeller değildir — her kriter gerçek bir kullanıcı ihtiyacını yansıtır. Her kuralın arkasındaki “neden”i anlamak, onu doğru şekilde uygulamayı ve uç durumlarda sağlam muhakeme yapmayı çok daha kolay hale getirir.

Etiketleri Doğru Kullanmak: Erişilebilir Formların Temeli

Bir etiket yalnızca görsel bir ipucu değildir. Bir metin açıklaması ile bir form kontrolü arasındaki programatik bağlantıdır ve yardımcı teknolojilerin bir alanın ne için olduğunu tanımlamasının birincil mekanizmasıdır. Bu bağlantıyı kurmanın en sağlam yolu, HTML <label> öğesi ve ilgili girdinin id değerini işaret eden for özniteliğidir.

<!-- Yanlış: Yalnızca placeholder erişilebilir bir etiket değildir -->
<input type='email' placeholder='Email address'>

<!-- Doğru: for/id ile ilişkilendirilmiş açık etiket -->
<label for='email'>Email address</label>
<input type='email' id='email' name='email'>

Etiketler her zaman görünür olmalıdır — yalnızca placeholder olmamalıdır. Placeholder’lar kullanıcı yazmaya başladığında kaybolur ve bağlam bırakmaz. Bu son derece kritik bir ayrımdır. Placeholder metni hiçbir zaman etiket olarak hizmet vermek üzere tasarlanmamıştır; kullanıcı yazmaya başlar başlamaz kaybolur, genellikle yetersiz renk kontrastına sahiptir ve birçok ekran okuyucu bunu alanın erişilebilir adı olarak güvenilir şekilde sunmaz. Yalnızca placeholder’lara güvenmek, yalnızca yardımcı teknoloji kullananları değil, tüm kullanıcıları yarı yolda bırakır.

İlgili alan gruplarına sahip olduğunuzda — örneğin bir dizi radyo düğmesi veya bir grup onay kutusu — doğru kalıp <fieldset> ve <legend> kullanmaktır. Karmaşık formları daha anlaşılır hale getirmek için onay kutuları ve radyo düğmeleri gibi ilgili seçenekleri fieldset ve legend ile gruplayın.

<fieldset>
  <legend>Preferred contact method</legend>

  <input type='radio' id='contact-email' name='contact' value='email'>
  <label for='contact-email'>Email</label>

  <input type='radio' id='contact-phone' name='contact' value='phone'>
  <label for='contact-phone'>Phone</label>
</fieldset>

Görünür bir etiketin görsel olarak gereksiz olacağı durumlarda — örneğin, açıkça etiketlenmiş bir Search düğmesinin yanındaki tek bir arama alanı — görünür metin göstermeden erişilebilir bir ad sağlamak için aria-label veya aria-labelledby kullanabilirsiniz. Ancak bunu sınırlı kullanın. Ekran okuyucu kullanan kişiler, form kontrolleri etiketler, fieldset’ler ve diğer yapısal öğelerle ilişkilendirildiğinde bunları daha kolay tanımlayıp anlayabilir — ve görünür etiketler, bilişsel engelli görsel kullanıcılar, %400’e kadar yakınlaştırma yapan kullanıcılar ve uzun bir formda geçici olarak yerini kaybeden herkes dahil olmak üzere herkes için faydalıdır.

Ayrıca, gerekli alanlar hem görsel hem programatik olarak, required özniteliği veya aria-required kullanılarak belirtilmelidir. Yalnızca kırmızı bir yıldız yeterli değildir — formun üst kısmına “* ile işaretli alanlar zorunludur” gibi kısa bir not ekleyin ve kullanıcı o alana odaklandığında yardımcı teknolojilerin alanı “gerekli” olarak duyurabilmesi için required özniteliğinin işaretlemede yer aldığından emin olun.

Gerçekten Yardımcı Olan Hata Mesajları Yazmak

Hata mesajları, çoğu formun kullanıcıları ikinci, katmerli bir şekilde yarı yolda bıraktığı yerdir. Bir kullanıcı doğrulama hatalarını tetikleyen bir form gönderdiğinde, üç şeyi bilmesi gerekir: bir hata oluştuğunu, hangi alanın buna neden olduğunu ve bunu düzeltmek için ne yapması gerektiğini. Çoğu form hatası bu sorulardan yalnızca ilkine yanıt verir — o da çoğu zaman kötü bir şekilde.

"Geçersiz giriş" veya "Hata" gibi belirsiz hata mesajları, kullanıcılara neyin yanlış gittiğini veya bunu nasıl düzelteceklerini söylemez. Her hata mesajı, belirli sorunu tanımlamalı ve somut bir çözüm önermelidir.

Ekran okuyucularla uyumluluğu sağlamak için hata mesajları, aria-invalid="true" ve hata mesajlarını doğrudan ilgili form alanlarına bağlayan aria-describedby gibi ARIA öznitelikleri kullanılarak DOM’a entegre edilmelidir. Doğru işaretlenmiş bir hata durumu şöyle görünür:

<label for='email'>Email address</label>
<input
  type='email'
  id='email'
  name='email'
  aria-invalid='true'
  aria-describedby='email-error'
>
<span id='email-error' role='alert'>
  Please enter a valid email address, for example: [email protected]
</span>

aria-invalid="true" özniteliği, ekran okuyucuya alanın şu anda geçersiz bir değere sahip olduğunu söyler. aria-describedby özniteliği, hata mesajını içeren öğeyi işaret eder; kullanıcı bu girdiye odaklandığında ekran okuyucu bu mesajı okur. Hata span’ine eklenen role="alert", DOM’a eklendiği anda, kullanıcının oraya gitmesini gerektirmeden hemen duyurulmasını sağlar.

Minimalist bir tasarımda, bir alanın geçersiz olduğunu ifade etmek için yalnızca kırmızı bir renk kullanmak cazip gelebilir — ancak WCAG 1.4.1 Renk Kullanımı’nın da belirttiği gibi, yalnızca renge güvenmek yeterli değildir; çünkü insanlar rengi farklı şekillerde algılar ve o kırmızı renk herkes tarafından fark edilmeyebilir. Çözüm, renkli hata durumunu ek bir görsel öğeyle tamamlamaktır — bu bir simge olabilir, ancak bu bile alanın neden geçersiz olduğunu anlamak için yeterli olmayabilir; bu nedenle en kapsayıcı çözüm, açıkça bir metin mesajı göstermektir.

Belirli hata mesajları, özellikle bilişsel zorlukları olan, dikkat süresi azalmış veya ekran okuyucu kullanan kullanıcılar için faydalıdır — çünkü kötü yazılmış geri bildirimler hayal kırıklığına yol açabilir ve hatta kullanıcıların formu tamamen terk etmesine neden olabilir. Hata mesajlarını kullanıcının bakış açısından yazın: ne girmeleri gerekiyordu ve bunu şu anda nasıl düzeltebilirler?

Doğrulama Zamanlaması ve Odak Yönetimi

Ne zaman doğruladığınız, nasıl doğruladığınız kadar önemlidir. Hataları çok erken tetiklerseniz — örneğin kullanıcı hâlâ yazarken — akışlarını erken şikâyetlerle bölme riski taşırsınız. Hataları yalnızca gönderimde tetiklerseniz, kullanıcıyı hangi alanların dikkat gerektirdiğini bulmak için uzun bir formda aşağı yukarı kaydırma yaparken bırakabilirsiniz. Doğru cevap katmanlı bir yaklaşımdır.

Kritik alanlar için gerçek zamanlı geri bildirimi, biçimlendirilmiş girdiler için odak kaybında (on-blur) kontrolleri ve kapsamlı hata incelemeleri için gönderim anında doğrulamayı birleştirin. Pratikte bu, kullanıcı alanı terk ettiğinde (blur olayında) parolalar veya e-posta adresleri gibi karmaşık biçimleri doğrulamak; her tuş vuruşunda tetiklenen satır içi doğrulamayı kesintiye uğratmaktan kaçınmak; ve form gönderiminde tam bir geçiş yaparak tüm hataları bir kerede açıkça iletmek anlamına gelir.

Gönderimden sonra, kullanıcıları verimli bir şekilde yönlendirmek için odağı otomatik olarak ilk hataya yönlendirin. Birden fazla hata varsa, en erişilebilir kalıp, odağı formun üst kısmındaki, ilgili alanlara atlayan bağlantılar olarak listelenmiş tüm hataları içeren bir özete taşımaktır. Bu, kullanıcının gönderir göndermez hata özetini duymasını, düzeltilmesi gerekenlerin kapsamını tam olarak anlamasını ve her soruna doğrudan gidebilmesini sağlar.

<!-- Formun üst kısmına yerleştirilmiş, programatik olarak odaklanan hata özeti -->
<div id='error-summary' role='alert' tabindex='-1'>
  <h2>2 errors found. Please correct the following:</h2>
  <ul>
    <li><a href='#email'>Email address: Please enter a valid email</a></li>
    <li><a href='#phone'>Phone number: Please use the format (555) 555-5555</a></li>
  </ul>
</div>

Kullanıcıların formlarda fare kullanmadan, mantıklı bir sekme sırası ve görünür odak göstergeleriyle gezinebildiğinden emin olun. Varsayılan tarayıcı odak halkası yasal ve işlevsel bir taban çizgisidir — ancak birçok tasarım ekibi CSS’lerinde outline: none kullanarak bunu bir yedek sunmadan bastırır. Bu, formu yalnızca klavye kullanan kullanıcılar için fiilen kullanılamaz hale getirir. Net, yüksek kontrastlı bir odak göstergesi, WCAG 2.4.7 (Seviye AA) ve WCAG 2.2’deki daha sıkı 2.4.11 kapsamında gereklidir. Marka yönergeleriniz varsayılan odak halkasıyla çelişiyorsa, onu kaldırmayın — değiştirin.

Hatalar Oluşmadan Önce Talimatlar ve İpuçları Sağlamak

En iyi form hatası, hiç görünmek zorunda kalmayan hatadır. İyi yerleştirilmiş talimatlar ve ipuçları, baştan hataları önler; bu da her kullanıcı için daha iyidir. Zorunlu girdiler veya belirli bir biçim, değer veya uzunluk gerektiren girdiler, bu bilgiyi öğenin etiketi içinde veya programatik olarak ilişkilendirilmiş talimatlarında sağlamalıdır.

Alan etiketi, neyin doldurulacağına dair ilk görsel talimattır; gerektiğinde bunu bir açıklama izler. Görsel kullanıcılar bir açıklamayı görebildiği gibi, ekran okuyucu kullanıcılarının da bunun farkında olması gerekir — ve açıklamayı, açıklama öğesini işaret eden bir id kabul eden aria-describedby özniteliğini kullanarak girdiye bağlayabilirsiniz; bu da kullanıcı alana odaklandığında ekran okuyucunun açıklamayı otomatik olarak okumasını sağlar.

<label for='phone'>Phone number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-describedby='phone-hint'
>
<span id='phone-hint'>Format: (555) 555-5555</span>

Mümkün olduğunda, beklentileri netleştirmek için örnekler sağlayın — örneğin, bir tarih alanı MM/DD/YYYY biçimini gerektiriyorsa, "Tarihi 12/25/2024 şeklinde girin" gibi bir örnek ekleyin. Parola alanları için, kullanıcı her kuralı ihlal ettikçe tek tek ortaya çıkarmak yerine gereklilikleri en baştan belirtin. Mümkünse, formlar kullanıcıların kendi hızlarında tamamlayabilmeleri için bir zaman sınırına tabi olmamalıdır — ve bir zaman sınırı gerekiyorsa, kullanıcının bunu kapatma veya uzatma seçeneği olmalıdır.

autocomplete özniteliği, sıklıkla gözden kaçan bir başka erişilebilirlik mekanizmasıdır. autocomplete="email", autocomplete="given-name" veya autocomplete="street-address" gibi değerleri ayarlamak, tarayıcıların ve parola yöneticilerinin alanları doğru şekilde otomatik doldurmasını sağlar; bu da motor bozukluğu olan, bilişsel engelli veya tekrarlayan yazmayı zor bulan herkes üzerindeki yükü önemli ölçüde azaltır. WCAG 1.3.5 (Girdi Amacını Belirleme, Seviye AA), kişisel bilgi toplayan alanlar için bunu gerektirir.

Formlarınızı Erişilebilirlik Açısından Test Etmek

Kuralları bilmek bir şeydir; formlarınızın gerçekten bu kurallara uyup uymadığını bilmek başka bir şeydir. Birleşik bir test stratejisi en güvenilir yaklaşımdır. Lighthouse ve WAVE gibi araçlar sorunları otomatik olarak tespit etmeye yardımcı olurken, yalnızca klavye ile gezinme ve ekran okuyucular kullanılarak yapılan manuel testler, gerçek dünya kullanılabilirlik sorunlarını tespit etmek için gereklidir.

Klavye testi için, farenizi çıkarın ve formu tamamlamayı deneyin. Yalnızca Tab, Shift+Tab, ok tuşları ve Enter/Boşluk kullanarak her alana ulaşabilmeli, her düğmeyi etkinleştirebilmeli ve her hata mesajını alabilmelisiniz. Takılıp kalırsanız, bu bir hatadır. Ekran okuyucu testi için, Windows’ta Firefox ile NVDA veya macOS’te Safari ile VoiceOver kullanın. Ekran okuyucular birbirlerinden biraz farklı davranır — farklı kısayollar, farklı anlamsal duyurular ve farklı özellik desteği; örneğin NVDA, Firefox ile daha iyi çalışırken VoiceOver, Safari ile en iyi şekilde çalışır. En az iki kombinasyonla test yapmak, en geniş sorun yelpazesini yakalayacaktır.

WAVE ve Axe gibi araçlar, eksik etiketler, hatalı ARIA öznitelikleri ve zayıf renk kontrastı için formları taramak açısından harikadır. Bu otomatik araçlar, üretime ulaşmadan önce gerilemeleri yakalamak için doğrudan CI/CD hattınıza entegre edilebilir. Ancak erişilebilirlik yönergeleri nüanslı olduğundan, otomatik araçlar WCAG sorunlarının yalnızca yaklaşık %30’unu tespit edebilir — bu nedenle otomatik katman, manuel inceleme ve ideal olarak yardımcı teknolojiye güvenen gerçek kullanıcılarla test ile desteklenmelidir.

İşaretlemenizi manuel olarak incelerken, her form alanı için şu soruları sorun: Görünür bir etiketi var mı? Bu etiket for/id veya ARIA aracılığıyla programatik olarak ilişkilendirilmiş mi? Herhangi bir ipucu metni aria-describedby ile bağlanmış mı? Her hata durumu aria-invalid="true" ayarlıyor ve hata mesajına aria-describedby ile referans veriyor mu? Zorunlu alanlarda required özniteliği mevcut mu? Yalnızca klavye kullanarak her etkileşimli öğeye ulaşabiliyor ve onu kullanabiliyor musunuz?

Temel Çıkarımlar

• Her girdinin programatik bir etikete ihtiyacı vardır. Tüm form alanları için <label for='...'> kullanın — asla yalnızca placeholder metnine güvenmeyin. Her form alanının istisnasız programatik bir etikete ihtiyacı vardır — placeholder metni bir etiket değildir.
• Hata mesajları sorunu adlandırmalı ve bir çözüm önermelidir. Hata mesajları sorunu tanımlamalı ve nasıl düzeltileceğini önermeli ve aria-describedby kullanılarak alanlarıyla ilişkilendirilmelidir.
• Asla yalnızca renge güvenmeyin. Herhangi bir durum göstergesi için yalnızca renge güvenmeyin — renk ipuçlarının yanında metin, simgeler ve diğer renk dışı göstergeler kullanın.
• Gönderimden sonra odağı yönetin. Hata açıkça tanımlanmalı, sorunlu öğeye hızlı erişim sağlanmalı ve kullanıcı hatayı kolayca düzeltip formu yeniden gönderebilmelidir. Başarısız gönderimden sonra odağı bir hata özetine taşımak altın standarttır.
• Yalnızca varsayımlarla değil, gerçek araçlarla test edin. Formların erişilebilir kalmasını sağlamak tek seferlik bir görev değildir — uyumlu ve kullanıcı dostu kalmaları için düzenli test ve güncellemeler gerektirir. Her önemli form güncellemesinde otomatik taramayı, yalnızca klavye ile gezinme ve ekran okuyucu testleriyle birleştirin.