Erişilebilir web tasarımı: teklif formları için uygulama rehberi

Erişilebilir web tasarımı, farklı görme, hareket ve algılama ihtiyaçları olan insanların aynı işi yapabilmesini hedefler. Bir teklif formunda bu iş basittir: alanları anlamak, bilgileri girmek, hatayı düzeltebilmek ve talebin ulaştığından emin olmak. Formun görsel olarak tamamlanmış olması, bu yolculuğun herkes için çalıştığını göstermez.

Bu rehber, kurumsal web sitesi sahipleri, tasarımcılar ve geliştiriciler için teklif ve iletişim akışlarını ele alır. W3C kaynaklarına bağlı teknik notlar ile önerdiğimiz proje çalışma biçimini ayrı ayrı sunuyoruz. Grafiklerdeki rakamlar bir denetim planını açıklayan örneklerdir. Doğrudan uygulama için alan etiketi örneğine veya test matrisine ilerleyebilirsiniz.

Erişilebilirliği görev üzerinden değerlendirin

Bir sayfayı incelemeye renk paletinden veya araç puanından başlamak kolaydır. Ancak kullanıcı sonuç almak ister. Bu nedenle önce görev cümlesini yazmayı öneriyoruz: “Ziyaretçi hizmet seçip ihtiyacını anlatarak görüşme talebi gönderebilmeli.” Sonra görevin hangi adımlardan oluştuğunu çıkarın. Formu bulmak, zorunlu alanı ayırt etmek ve hata sonrasında devam etmek de bu görevin parçalarıdır.

Örneğin açılır paneldeki form yalnızca imleçle açılıyorsa, alanların etiketlerinin doğru olması tek başına yeterli değildir. Kullanıcı henüz forma ulaşamamıştır. Benzer biçimde gönderim sonrası başarı mesajı ekranın başka yerinde beliriyorsa, işlemin tamamlandığı fark edilmeyebilir. Kabul senaryosu bütün yolculuğu kapsamalıdır.

W3C'nin form öğreticisi, etiketler, talimatlar ve kullanıcı geri bildirimini birlikte ele alır. Bu rehberin kapsamı tam site uygunluk denetimi değildir; form akışlarında işe başlamak için pratik bir çerçevedir. Ticari hedef ve talep tanımı için B2B açılış sayfası rehberimiz ile birlikte kullanılabilir.

Etiket, yardım metni ve alan ilişkisi

Etiket, kullanıcının alana ne yazacağını söyler. Yardım metni ise neden istendiğini veya beklenen biçimi açıklar. Placeholder kalıcı bir etiketin yerini almamalıdır; yazı girildiğinde kaybolur. W3C, etiketin ilgili kontrolle ilişkilendirilmesini açıklar; standart yaklaşım label üzerindeki for değeriyle alanın id değerini eşleştirmektir. Etiketleme rehberi ayrıntıları içerir.

Aşağıdaki HTML, tek bir alanın yapısını gösterir. Çalışan bir formun tamamı değildir; gönderim, sunucu doğrulaması ve hata durumları ayrıca uygulanmalıdır.

<label for="project-email">E-posta adresiniz (zorunlu)</label>
<p id="project-email-help">
  Projeniz hakkında size bu adresten dönüş yapacağız.
</p>
<input
  id="project-email"
  name="email"
  type="email"
  autocomplete="email"
  aria-describedby="project-email-help"
  required
/>

İçerik açısından da alan adını gözden geçirin. “Bilgi” yerine “Projenizde çözmek istediğiniz sorun” yazmak yanıtı yönlendirir. Ancak etiket çok uzun bir açıklamaya dönüşüyorsa kısa başlığı koruyup örneği yardım metnine taşıyın. Kullanıcı, alanlar arasında ilerlerken bütün paragrafı tekrar okumak zorunda kalmamalıdır.

İş telefonu, mevcut site ve bütçe gibi alanları otomatik olarak zorunlu yapmayın. Her birinin ilk görüşmede neden gerekli olduğunu değerlendirin. Alanın amacı belirli değilse hem tasarım hem veri kalitesi açısından sorun vardır. Daha az veri istemek her proje için doğru olmayabilir; fakat her alanın bir gerekçesi olmalıdır.

Klavye akışı ve görünür odak

Basit bir manuel deneme yapın: fareyi bırakın, sayfanın başından başlayarak Tab ile forma ilerleyin, seçenekleri değiştirin ve gönderin. Ardından Shift+Tab ile geri dönün. Odak yerini takip etmekte zorlandığınız her anı not edin. Görsel sırayla klavye sırası birbirinden ayrılıyorsa düzeni yeniden değerlendirin.

Önerimiz, standart düğme ve form kontrollerini başlangıç noktası olarak kullanmaktır. Tıklanabilir bir kutu görünümü için normal metin elemanına davranış eklemek, klavye etkileşimi ve durum bilgisini ayrıca kurmanızı gerektirir. Tasarımın istediği görünümü gerçek button veya input ile elde etmek çoğu durumda daha yönetilebilir bir çözümdür.

Odak halkasını yalnızca tasarıma uymadığı için kaldırmayın. Bunun yerine tema üzerinde fark edilebilen bir gösterge tasarlayın. Sabit alt iletişim çubuğu veya üst navigasyon odaklanan alanı kapatıyor mu, modal açıldığında kullanıcı yanlışlıkla arka sayfaya mı geçiyor, form kapandığında önceki konuma dönebiliyor mu? Bunlar ekran görüntüsünden anlaşılmayan davranış kontrolleridir.

Hata mesajı bir düzeltme talimatıdır

“Geçersiz değer” ifadesi kullanıcıya neyi değiştirmesi gerektiğini söylemez. “E-posta adresini ad@ornek.com biçiminde girin” daha uygulanabilir bir mesajdır. Yanlış alanı yalnızca kırmızı çerçeveyle belirtmek de yeterli iletişim kurmaz. W3C'nin bildirim rehberi, hatanın açıklanmasını ve kullanıcının ilgili alana ulaşabilmesini ele alır.

Birden fazla hata varsa formun üstünde kısa bir özet ve alanların yanında yerel mesajlar kullanılabilir. Özet bağlantılarının gerçekten ilgili alanlara götürdüğünü test edin. Hata durumu programatik olarak da anlaşılır olmalı; örneğin hatalı alan için aria-invalid ve açıklama ilişkisi kurulabilir. Bu öznitelikleri hata yokken kalıcı olarak açık bırakmayın.

Tablodaki ağ hatası mesajını yalnızca bilgiler gerçekten korunuyorsa kullanın. Arayüz metni, uygulamanın davranışını doğru anlatmalıdır. Kullanıcı bütün açıklamayı yeniden yazmak zorunda kalıyorsa “bilgileriniz korunuyor” yazmak güveni daha fazla zedeler.

Başarı ve ağ hatasını ayrı tasarlayın

Tasarım teslimlerinde çoğu zaman boş form ekranı bulunur; yükleniyor, hata ve başarı durumları sonradan geliştirme sırasında doğaçlanır. Oysa kullanıcı açısından en önemli an gönderim sonrasıdır. Talep alındı mı, tekrar denemek gerekiyor mu, düğmeye ikinci kez basmak iki kayıt üretir mi?

Önerdiğimiz durum listesi: başlangıç, doğrulama hatası, gönderiliyor, kabul edildi ve geçici sistem hatası. Her durum için gösterilecek metni, tekrar deneme davranışını ve odak yönetimini yazın. Gönderiliyor durumunda düğmenin davranışını düşünürken yardımcı teknoloji kullanan kişinin durum değişimini nasıl anlayacağını da test edin.

Sunucu talebi kabul etmeden başarı ekranı göstermeyin. Arayüzde başarılı gibi görünen fakat e-posta veya CRM tarafına ulaşmayan talep, işletme için de kullanıcı için de kayıptır. Doğrulama sorumluluğunu yalnızca tarayıcıya bırakmayın; istemci denetimi kullanım kolaylığı sağlar, sunucu ise veriyi kendi kurallarına göre tekrar değerlendirmelidir.

Mobil düzen, yakınlaştırma ve hedef boyutu

Formu yalnızca tek bir telefon ekranında kontrol etmek yeterli değildir. Ekran klavyesi açıkken son alan ve gönder düğmesi erişilebilir mi, uzun yardım metni kesiliyor mu, yatay kullanımda içerik kayboluyor mu? Küçük ekranda iki sütunlu düzeni tek sütuna indirmek bu sorunların bir kısmını azaltabilir; gerçek metinlerle denenmelidir.

WCAG 2.2'nin 2.5.8 hedef boyutu ölçütü, AA düzeyinde 24 × 24 CSS piksel boyutunu ve aralık, satır içi hedefler gibi istisnaları tanımlar. Bu değeri bütün arayüz için rahat kullanım hedefi gibi görmeyin. Bizim tasarım önerimiz, özellikle birincil gönderim düğmelerini ve sık kullanılan mobil kontrolleri daha geniş, çevresinden ayırt edilebilir hedefler olarak kurmaktır.

İçeriğin yeniden akışı ölçütü, dikey kaydırılan içerikte 320 CSS piksel genişliğe eşdeğer koşullarda bilgi ve işlev kaybı olmadan kullanım konusunu ele alır; iki boyutlu düzen gerektiren içerikler için istisnalar vardır. Form kontrolünde metin büyütmeyi ve tarayıcı yakınlaştırmasını ayrıca deneyin. Dar alanda okunamayan hata mesajı başarılı sayılmaz.

Grafikler ve bilgiyi tek kanala hapsetmemek

Bir grafiğin yalnızca rengiyle iki grubu ayırması, o farkı göremeyen kişi için bilgi kaybı oluşturur. Etiketler, çizgi biçimleri ve metin açıklamaları birlikte kullanılabilir. Ayrıca karmaşık sayısal içeriğin tablo karşılığını sunmak hem ekran okuyucuyla hem de veriyi dikkatle karşılaştırmak isteyen okuyucuyla uyumludur.

Bu yazıdaki grafiklerin altında açılır veri tabloları bulunur. Grafik, genel dağılımı hızlı okumaya; tablo, tekil değerleri incelemeye yarar. Açıklamada sayıların kaynağını belirtmek de gereklidir. Test planındaki örnek bir sayıyı sektör araştırması gibi sunmak okuyucunun yanlış sonuç çıkarmasına neden olur.

Bu dağılım bütçe veya denetim standardı değildir. Projenizde çok adımlı başvuru, dosya yükleme veya özel tarih seçici varsa plan genişler. Kontrolleri saymak başlangıçta kapsamı görünür kılar; asıl kabul ölçütü görevin engel olmadan tamamlanmasıdır.

Uygulanabilir test matrisi

Test matrisini cihaz listesiyle sınırlamayın; kullanıcı görevi ve beklenen sonuç da bulunsun. Aynı cihazda farklı giriş yöntemleri başka sorunlar gösterebilir. Her bulguya tekrar adımları, etkilenen bölüm ve beklenen davranış eklemek, düzeltmenin geliştirici tarafından doğrulanmasını kolaylaştırır.

Ekran okuyucu denemesinde yalnızca metinlerin okunmasına bakmayın. Kullanıcı hangi alanın hatalı olduğunu bulabiliyor mu ve tekrar forma dönebiliyor mu? Test eden kişi uygulamayı ezbere biliyorsa bazı belirsizlikleri fark etmeyebilir. Mümkün olduğunda ilk kez kullanan bir kişinin gözlemini de ekleyin.

Otomatik araçlar belirli yapısal kontroller için faydalıdır; ancak uygun mesajın ne olduğunu ve görevin anlaşılır olup olmadığını tek başına çözmez. Otomatik raporu manuel bulgularla tek bir listede birleştirin, yinelenenleri ayırın ve kullanıcıyı engelleyenlere öncelik verin.

Düzeltme önceliği ve tekrar test

Önceliği yalnızca bulgu sayısına göre vermeyin. On küçük açıklama sorunu, bütün klavye kullanıcılarının gönderim yapmasını engelleyen tek bir sorundan daha düşük öncelikli olabilir. Etkilenen görev, sorunun yaygınlığı ve geçici bir alternatifin bulunup bulunmadığı birlikte değerlendirilmelidir.

Bu örnekte iki açık madde kalmasına rağmen görevi engelleyen bulgular kapanmıştır. Gerçek projede kalan maddeleri silmek yerine sorumlu ve hedef tarihle takip edin. Düzeltme sonrası aynı adımları tekrar uygulayın; özellikle ortak bir form bileşeni değiştiyse onu kullanan diğer sayfalardan da örnek seçin.

Bakım sürecine nasıl yerleşir

Erişilebilirlik, ilk yayında yapılan tek seferlik kontrol olarak kalırsa yeni kampanya formunda veya dil sürümünde gerileyebilir. Tasarım sistemine etiket, hata, başarı ve odak örneklerini ekleyin. İçerik ekibine alan adlarını ve yardım metinlerini nasıl yazacağını gösterin. Geliştirme kabulüne de en kritik görevlerin kısa manuel tekrarını koyun.

Yeni tasarıma geçiyorsanız site yenileme kontrol listemiz ile bu matrisi aynı teslim dosyasında tutabilirsiniz. Performansla birlikte değerlendirmek için hızlı web sitesi rehberimiz tamamlayıcı bir okumadır; hızlı açılmak ile kullanılabilir olmak farklı testler gerektirir.

Piton Studios ile mevcut form akışınızı değerlendirmek için iletişim sayfamızdan projenizi paylaşabilirsiniz. Öncelikle kullanıcının tamamlamasını istediğiniz görevi, bilinen sorunları ve kullanılan cihazları belirleyip uygulanabilir bir iyileştirme kapsamı çıkarabiliriz.