Başvuru Formu Tasarımı: Alan, Etiket ve Hata Mesajı

Başvuru veya iletişim formunun dönüşümü, tek bir sihirli alan sayısına değil üç şeye bağlıdır: her alanın gerçekten gerekli olması, etiket ve yönergelerin ne istendiğini açık söylemesi ve hata anında kullanıcıya nasıl düzelteceğinin gösterilmesi. W3C WAI form eğitimi (yeni sekmede açılır) de aynı yönde, yalnızca işlemi tamamlamak için gereken bilgiyi istemeyi öneriyor. Belgeler kesin bir "en iyi alan sayısı" vermez; bu yüzden karar kendi formunuzun amacına ve ölçümünüze göre verilir.

Yazı, aynı formu birlikte yöneten pazarlamacılar, tasarımcılar ve geliştiriciler için. Sayfa düzeni ve arama görünürlüğü dengesi için açılış sayfası SEO ve dönüşüm dengesi yazımıza da bakabilirsiniz.

Form neden yarım kalır

Bir formu doldurmak, ziyaretçi için küçük bir iştir ve her ek adım bu işi biraz daha ağırlaştırır. Yarım kalmanın nedenlerini tahmin etmek yerine sınıflandırmak daha verimlidir. Aşağıdaki sınıflar, form deneyimlerinde sık görülen sürtünme noktalarını toplar; hangisinin sizin formunuzda baskın olduğunu ölçüm gösterir.

Dört sürtünme türü

Sürtünme genellikle dört başlıkta toplanır: gereksiz bilgi isteği, anlaşılmayan istek, düzeltilemeyen hata ve güven eksikliği. Her biri farklı bir çözüm gerektirir, bu yüzden form sorununu tek bir "çok uzun" etiketiyle kapatmayın.

Formun amacını tek cümleyle yazın

Tasarıma başlamadan önce formun ne için var olduğunu tek cümleyle yazın: "Bu form, ziyaretçinin fiyat teklifi istemesi için vardır." Bu cümle hangi alanların gerekli olduğunu belirler. Cümleyi yazamıyorsanız formun amacı belirsizdir ve alan listesi de rastgele büyür. Aynı cümle, sonuç bölümündeki ölçüm planında da dönüşüm olayının tanımı olacaktır.

Form ile sayfa ayrı sorunlardır

Bazen sorun formun kendisinde değil, formdan önceki sayfada olur: vaat ile istek uyuşmuyorsa ziyaretçi forma gelmeden ayrılır. Bu yüzden formu iyileştirmeye başlamadan önce sayfanın neyi vaat ettiğine ve formun bu vaadin devamı gibi okunup okunmadığına bakın. Düğme metni ayrı bir karar alanıdır.

Alan sayısı ve zorunlu alan kararı

W3C WAI form eğitimi genel ilke olarak yalnızca işlemi tamamlamak için gereken bilgiyi istemeyi önerir. Belge, zorunlu alanlar için ayrı bir sayı sınırı vermez; web.dev Learn Forms de "şu kadar alan en iyisidir" demez. Dolayısıyla sorulacak soru "kaç alan?" değil, "bu alan olmadan işlem tamamlanır mı?" sorusudur.

Alan başına dört soru

Her aday alan için sırayla şu soruları sorun ve yanıtlardan biri "hayır" ise alanı ilk sürümden çıkarın.

1. Bu bilgi olmadan talebi yanıtlayabilir miyim?
2. Bilgiyi şimdi mi istemeliyim, yoksa ilk görüşmede mi sorabilirim?
3. Aynı bilgiyi başka bir yerden, örneğin hesap kaydından veya tarayıcıdan alabilir miyim?
4. Bu alanı kim, hangi iş akışında kullanacak?

Son soru önemlidir. Kimsenin kullanmadığı bir alan, hem doldurma yükü hem de saklanan kişisel veri açısından maliyettir. Kişisel veri tarafında ayrıntı için ilgili gizlilik metninizi ve veri sorumlusu olarak yükümlülüklerinizi ayrıca gözden geçirin.

Telefon alanı zorunlu mu olmalı

Telefon, formların en çok tartışılan alanıdır. Belgelerde "telefon alanı zorunlu olsun" ya da "olmasın" diyen bir ifade yok; karar kendi iş akışınıza bağlıdır. Basit bir karar kuralı kullanabilirsiniz:

• Telefonla arayıp süreci gerçekten telefonda yürütecekseniz alanı zorunlu yapın ve nedenini etiketin altında yazın.
• E-postayla da yanıt verebiliyorsanız telefonu isteğe bağlı bırakın ve "Size telefonla ulaşmamızı istiyorsanız yazın" gibi bir açıklama ekleyin.
• Telefona hiç ihtiyaç yoksa alanı kaldırın.

Karar kuralı: Alanın sonucunu kullanmayacaksanız sormayın; kullanacaksanız nedenini söyleyin. Alan zorunlu olduğunda etiket ve alanın gerekçesi aynı yerde görünmelidir.

Zorunlu ve isteğe bağlı işaretleme

web.dev Learn Forms tasarım temelleri dersi (yeni sekmede açılır) zorunlu alanları etiketinde "(required)" gibi bir ifadeyle ve required özniteliğiyle işaretlemeyi önerir; çoğu alan zorunluysa isteğe bağlı olanları işaretlemeyi de anlatır. Burada pratik kural şudur: işaretlemeyi azınlık durumda yapın. Beş alanlı formda dördü zorunluysa, "isteğe bağlı" ifadesini tek alana yazmak daha az gürültü üretir. W3C da zorunluluğu etikette belirtmeyi, formun başında ise genel bir yönerge vermeyi önerir; yıldız işaretini tek başına kullanacaksanız, ne anlama geldiğini formun başında açıklayın.

Alanların sırası

Alanları ziyaretçinin düşünme sırasına göre dizin: önce kim olduğu, sonra ne istediği, en sonda ayrıntılar. Kolay ve kısa alanlar başta durduğunda ziyaretçi forma başlamış olur; bu bir tasarım sezgisidir, belgelerde yer almaz ve kendi verinizle sınanmalıdır. Zor ya da kişisel alanları sona bırakın ve neden istendiğini yanlarında söyleyin. web.dev, sekme sırasının görsel sırayı izlemesini ve formun yalnızca klavyeyle sınanmasını önerir; sıralamayı görsel olarak değiştirdiğinizde sekme sırasının bozulmadığını mutlaka kontrol edin.

Alan türleri ve gruplama

Aynı bilgiyi birden çok alana bölmek ziyaretçiyi yorar. Ad ve soyadı ayrı istemek için bir gerekçeniz yoksa tek "Ad soyad" alanı yeterli olabilir. Birbiriyle ilgili alanlar, örneğin adres satırları, W3C'nin önerdiği gibi fieldset ve legend ile gruplanmalıdır. Gruplama, ekran okuyucu kullanıcılarına bağlam verir ve görsel kullanıcılara da bölümleri ayırır.

Örnek senaryo: üç alanlı ve yedi alanlı form

Örnek senaryo: Bir hizmet sitesi hem fiyat teklifi hem de genel soru için tek form kullanıyor. Form yedi alanlı: ad soyad, e-posta, telefon, şirket adı, bütçe, hizmet türü ve mesaj. Ekip yeni sürümde yalnızca ad, e-posta ve mesajı zorunlu tutuyor; hizmet türünü açılır liste olarak bırakıyor, telefon, şirket ve bütçeyi ilk yanıtta soruyor. İki sürümü karşılaştırırken dönüşüm oranı kadar gelen taleplerin kalitesine de bakmak gerekir: alan sayısını azaltmak hem gönderim sayısını hem de talep kalitesini değiştirebilir. Hangi yöne gittiğini yalnızca kendi verinizle görebilirsiniz.

Etiket, yer tutucu ve yönergeler

Etiket, formun en temel erişilebilirlik ve kullanılabilirlik öğesidir. W3C WAI, her form kontrolünü label öğesiyle tanımlamayı ve for değerinin kontrolün id değeriyle birebir eşleşmesini ister. Etiketin kontrolün amacını anlatması, görünür olması ve kontrole yakın durması beklenir.

Etiket konumu ve kısalığı

web.dev etiketleri alanın üstüne koymayı ve kısa tutmayı önerir ("E-posta adresi" gibi); böylece ziyaretçi hızlı tarar ve etiketle alanı kolay eşleştirir. W3C de üstte etiketin dar ekranlarda yatay kaydırmayı azaltabileceğini söyler, ancak en iyi yerleşimin düzene bağlı olduğunu belirtir. Pratikte tek sütunlu bir formda etiketleri üste yerleştirmek mobil ve masaüstü için ortak, sade bir çözümdür. web.dev tek sütunu da önerir ve sekme sırasının görsel sırayı izlemesini ister.

Yer tutucu etiket yerine geçmez

Yer tutucu (placeholder) en sık yapılan hatadır. web.dev "placeholder özniteliğini asla etiket yerine kullanmayın" der ve yer tutucunun yalnızca beklenen biçim için ipucu olmasını söyler. W3C da yer tutucu metnin etiketin yerine geçmediğini ve yardımcı teknolojilerin onu etiket gibi ele almadığını belirtir. Yer tutucu rengi için de yeterli kontrast gereklidir.

Biçim bilgisi nerede durur

W3C form yönergeleri sayfası (yeni sekmede açılır), beklenen biçimin etikette belirtilmesini anlatır ("Son kullanma tarihi (AA/YYYY)" gibi). Yerleşim izin vermiyorsa aria-describedby ile alanın altındaki yönergeye bağlayın. web.dev de kuralları görünür metinle yazmayı ve aria-describedby ile bağlamayı önerir. Telefon gibi alanlarda tek bir biçimi dayatmayın: W3C farklı ayraçları ve rakam gruplamalarını kabul etmeyi öneriyor.

Form başı yönergesi

Genel yönergeler form öğesinden önce verilmelidir, çünkü ekran okuyucular form moduna geçmeden önce bu metni okur. Orada hangi alanların zorunlu olduğu, kabul edilen biçimler ve varsa süre sınırı yazılır. Başvuru formunda kısa bir "Bu form ne için, yanıtı ne zaman alırsınız" cümlesi ayrıca güven verir.

Etiket yazarken kontrol listesi

• Etiket isimle yazıldı mı ("E-posta adresi"), yoksa soruyla mı? Kısa isim daha taranabilir.
• Etiket her zaman görünür mü?
• Yer tutucu yalnızca örnek biçim için mi kullanılıyor?
• Gruplanan alanlar fieldset ve legend ile bağlı mı?
• Sekme sırası görsel sırayla aynı mı?
• Seçenekli alanlarda, "Seçiniz" gibi yönergeyi seçenek olarak mı yoksa etiketle mi veriyorsunuz?

Hata mesajı ve erişilebilirlik

Hata anı, formun dönüşüm açısından en kritik anıdır: kullanıcı niyetini göstermiş ve gönder düğmesine basmıştır. Burada yanlış bir mesaj ya da sessiz bir başarısızlık, bütün emeği boşa çıkarır.

İyi hata mesajının üç parçası

W3C bildirim sayfası, hata mesajlarının düzeltmenin nasıl yapılacağını anlatmasını ister ve örnek olarak bir tarih hatasında beklenen biçimi gösterir. Pratik bir yapı: sorunu adlandırın, gereksinimi söyleyin, örnek verin. Örneğin "Geçersiz giriş" yerine "E-posta adresi eksik görünüyor. İsim@alanadi.com biçiminde yazın" daha işe yarar. Mesaj suçlayıcı olmamalı ve alanı tanıtmalıdır.

Hata nerede gösterilir

web.dev hatayı ilgili kontrolün yanında göstermeyi önerir. W3C ise başarısız gönderimden sonra odağın hata içeren ilk alana taşınmasını söyler. Sayfa yeniden yüklenerek hata gösteriliyorsa, sayfanın başında hata sayısını belirten sade bir özet ve her hatayı ilgili alana bağlayan bağlantılar yararlıdır; W3C bu özetin etiket adını, sorunu ve düzeltme yolunu içermesini önerir.

Erişilebilir bildirim teknikleri

W3C kullanıcı bildirimleri sayfası (yeni sekmede açılır) satır içi hataların aria-describedby ile alana bağlanmasını, hata özeti kapsayıcısında role="alert" kullanılmasını ve yazarken verilen geri bildirimde aria-live="polite" tercih edilmesini anlatır. Tarih gibi alanlarda canlı denetimin çoğu zaman hata göstereceği için odak değiştiğinde denetim yapılması önerilir. web.dev de gerçek zamanlı geri bildirim için alandan çıkıldığında (blur) doğrulama yapılmasını söyler. Hata durumunu yalnızca renkle göstermeyin: web.dev yalnızca renge güvenilmemesini, metin veya simge eklenmesini ister ve W3C örneklerinde renk her zaman metin ve simgeyle birlikte verilir.

Hata önleme, hata düzeltmeden ucuzdur

En iyi hata mesajı hiç gösterilmeyen mesajdır. Alanın biçimi belliyse etikette veya yönergede söyleyin, uygun girdi türünü seçin, çok katı biçim kurallarından kaçının ve ziyaretçinin yazdığı değeri olabildiğince esnek kabul edin. Telefon numarasında boşluk, tire veya parantezi sunucuda temizlemek, ziyaretçiye "yalnızca rakam" hatası göstermekten çok daha az sürtünme yaratır. W3C de ayraçlar ve rakam gruplamaları konusunda esnek davranmayı önerir.

Tarayıcı doğrulaması ve özel mesaj

Tarayıcının yerleşik doğrulaması required, type="email", pattern, minlength ve maxlength ile çalışır. web.dev doğrulama dersi (yeni sekmede açılır), özel mesaj için invalid olayında setCustomValidity() kullanılabileceğini anlatır; özel mesaj tanımlarsanız alan geçerli olunca mesajı temizleyin. :invalid kullanıcı etkileşimi olmadan da eşleşir, bu yüzden etkileşimden sonra biçimlendirmek için :user-invalid önerilir. W3C ve web.dev ortak bir noktada birleşir: istemci tarafı doğrulama güvenlik sağlamaz, sunucuda da doğrulayın.

Başarı bildirimi

Gönderimden sonra ne olduğunu açıkça yazın. W3C başarılı işlemin net bir başlıkla onaylanmasını örnekler. "Teşekkürler" yeterli değildir; talebin alındığını, yanıtın hangi kanaldan geleceğini ve beklenen süreyi (siz taahhüt edebiliyorsanız) belirtin. Başarı sayfası aynı zamanda ölçüm noktasıdır.

Hata testi nasıl yapılır

Formu boş gönderin, bilerek geçersiz e-posta girin, çok uzun metin yapıştırın, yalnızca klavyeyle ilerleyin ve ekran okuyucuyla bir tur atın. Her hata için şu soruyu sorun: kullanıcı ne yanlış yaptığını, nerede olduğunu ve nasıl düzelteceğini bu mesajdan anlıyor mu?

Mobil klavye ve otomatik doldurma

Mobilde form doldurmak, her zaman masaüstünden zordur: küçük hedefler, ekran klavyesi ve dikkat dağınıklığı. İyi haber, birkaç doğru öznitelikle bu yükün önemli kısmı hafifletilebilir.

Doğru girdi türü

web.dev, type özniteliğinin ekran klavyesini ve doğrulama kurallarını değiştirdiğini anlatır; telefon ve e-posta alanlarında type="tel" ve type="email" bu yüzden uygun seçimdir. Ayrıca çok satırlı metin için textarea, şartları kabul için checkbox gibi uygun öğeyi seçmeyi önerir. Telefon numarası için type="number" yerine type="tel" kullanın.

autocomplete öznitelikleri

web.dev otomatik doldurma dersi (yeni sekmede açılır), tarayıcıların gönderilen değerleri alanın name özniteliğine göre kaydettiğini ve doğru autocomplete değerinin otomatik doldurmayı kolaylaştırdığını anlatır. Örnek değerler arasında email, new-password, current-password, one-time-code ve adres için shipping ile billing önekleri geçer. Tek kullanımlık kodlarda autocomplete="off" kullanılabilir. Faydası bellidir: kullanıcı daha hızlı doldurur ve aynı veriyi tekrar yazmaz; web.dev bunun erişilebilirlik faydası da olduğunu söyler, çünkü kişinin bilgileri hatırlaması veya elle yazması gerekmez.

Dokunma hedefleri ve yazı boyutu

web.dev dokunma hedeflerinin en az 48 piksel olmasını ve kontroller arasında boşluk bırakılmasını önerir. Form kontrollerinde en az 1rem yazı boyutu, iOS Safari'de odaklanınca sayfanın yakınlaştırılmasını engeller. Bu değerler web.dev'in önerisidir; cihaz ve tasarım sisteminize göre test edin.

Mobil için kontrol listesi

• Tek sütun mu, ve kaydırmasız okunuyor mu?
• Telefon, e-posta, URL alanlarında doğru type seçildi mi?
• Her alanda doğru autocomplete değeri var mı?
• Gönder düğmesi klavye açıkken de erişilebilir mi?
• Dokunma hedefleri yeterince geniş mi?
• Hata mesajı klavyenin altında kalmıyor mu?

Alanları ihtiyaca göre göstermek

Koşullu alanlar, örneğin "Diğer" seçilince açılan kutu, formu kısa tutmanın bir yoludur. Ancak koşullu alan açıldığında ekran okuyucu kullanıcısına duyurulmalı ve sekme sırası bozulmamalıdır. Şüpheniz varsa alanı kalıcı gösterin.

Çok adımlı form mu, tek sayfa mı

W3C, uzun formları mantıksal adımlara bölmeyi ve kullanıcıya ilerlemeyi göstermeyi önerir. Ancak bu, "her form çok adımlı olmalı" demek değildir. Beş alanı geçmeyen bir iletişim formunu adımlara bölmek yalnızca tıklama sayısını artırır.

Karar kuralı

Adımlara böldüyseniz her adımda ne kadar kaldığını gösterin, geri dönüldüğünde verilerin korunduğundan emin olun ve son adımda girilen bilgileri özetleyin. Ödeme veya sözleşme içeren formlar gibi geri alınamaz işlemlerde ayrıca onay ve özet adımı düşünün; talep formu geri alınabilir bir işlem olduğu için genelde ayrı onay adımı gerektirmez.

Zaman sınırları

Formda zaman sınırı varsa bunu form başındaki yönergede belirtin. Form oturumunun sessizce dolması ve doldurulan verinin kaybolması, düzeltilemeyen bir hatadır.

Formu ölçmek ve iyileştirmek

Değişiklikten önce "başarılı" neyi ifade ediyor, onu tanımlayın. Analytics Yardım (yeni sekmede açılır) sayfasına göre önemli etkinlik (key event), işiniz için özellikle önemli bir eylemi ölçen etkinliktir ve topladığınız herhangi bir etkinlik önemli etkinlik olarak işaretlenebilir. Rapordaki "Key events" sütunu, açılış sayfası gibi boyutlara göre kaç kez tetiklendiğini gösterir. Arayüzü Türkçe kullanıyorsanız menü adları farklı görünebilir.

Hangi olayları ölçmeli

• Form görüntüleme (formun ekrana gelmesi)
• Forma ilk etkileşim (ilk alana yazma)
• Başarılı gönderim (önemli etkinlik olarak işaretlenecek olay)
• Doğrulama hatası sayısı ve hangi alanda olduğu (kişisel veri içermeden)

Alan içeriğini asla analitik olaylarına yazmayın; yalnızca alanın adını ve hata türünü gönderin. Bu yaklaşım hem kişisel veri korumasına hem de ölçüm sadeliğine uygundur. Telefon tıklaması gibi formsuz dönüşümlerin ölçümü için GA4 WhatsApp ve telefon tıklaması dönüşüm olayı yazımızı okuyabilirsiniz.

Önce hangi değişiklik denenir

Ölçüm olmadan on değişikliği birden yapmak, hangisinin işe yaradığını gizler. Şu sırayı izleyin:

1. Gereksiz alanları kaldırın veya isteğe bağlı yapın.
2. Etiket ve yer tutucu hatalarını düzeltin.
3. Hata mesajlarını yeniden yazın ve odak davranışını düzeltin.
4. Mobil girdi türleri ve autocomplete değerlerini ekleyin.
5. Gerekirse çok adımlı yapıyı deneyin.

Sonucu yorumlarken

Dönüşüm oranı yükseldiğinde, gelen taleplerin kalitesine de bakın. Alan azaldığında gönderim sayısı da gelen taleplerin niteliği de değişebilir. Kalite için birkaç haftalık dönemi kendi öncesiyle karşılaştırın ve mevsimsellik gibi dış etkileri gözden geçirin. Değişikliğin arama görünürlüğüne etkisi beklenmediği için bu değişiklikler SEO testi değil, kullanılabilirlik testidir.

İş tarafıyla paylaşılan tanım

Satış veya destek ekibiyle "nitelikli talep" tanımını önceden yazın. Aksi halde form dönüşümü yükseldiğinde ekip bunu başarı sayarken satış tarafı kalite düştüğünü söyleyebilir. Ortak tanım, deneyin hangi ölçüyle değerlendirileceğini baştan belirler.

Talep formunda içerik ve güven

Teknik doğruluk, formun yalnızca yarısıdır. Ziyaretçi bilgisini vermeden önce ne olacağını bilmek ister.

Gönder düğmesinin çevresi

Düğmeyi "Gönder" yerine ne olacağını anlatan bir ifadeyle yazmayı düşünebilirsiniz ("Teklif iste", "Mesajı gönder"). Bu konu başlı başına bir karar alanıdır. Düğmenin yanında, bilgilerin ne amaçla kullanılacağını söyleyen kısa bir cümle ve gizlilik metnine bağlantı, güven eksikliğini azaltır.

Rıza ve ek kutular

Pazarlama iletisi izni gibi ek kutuları, hizmet talebinin zorunlu parçası gibi sunmayın. İzin ve gizlilik tarafındaki gereklilikleri ticari elektronik ileti izni ve KVKK uyumlu e-bülten aboneliği yazımızdaki çerçevede değerlendirin.

Yanıt süresi sözü

Başarı mesajında yanıt süresi veriyorsanız, uyabileceğiniz bir süre yazın. Sözü tutmayan bir mesaj, formun dönüşümünden çok sonraki güveni zedeler.

Talep kapsamını yazılı hale getirmek

Hizmet talebi formlarında, bilgi eksikliği ilk görüşmeyi uzatır. Hizmetin kapsamını yazılı hale getiren form tasarımı için backlink hizmeti talep formu kapsamı yazımızı inceleyebilirsiniz. Bu yaklaşım, alan sayısını artırmadan beklentiyi netleştirmenin bir yoludur: serbest metin alanına yönergeler eklemek ve seçenekli alanları net adlandırmak çoğu zaman yeni bir alandan daha etkilidir.

Alan etiketlerinde dil

Etiketlerde iç jargon kullanmayın. "Lead türü", "kampanya hedefi" gibi ekip dilini ziyaretçi anlamayabilir. Ziyaretçinin kendi kullandığı sözcükleri tercih edin ve TR ve EN sürümlerinde etiketlerin ve hata mesajlarının eşdeğer olduğunu doğrulayın.

Yayın öncesi kontrol listesi

Aşağıdaki liste bir formu yayına almadan önce son kontroldür. Her madde bir kanıt gerektirir: ekran görüntüsü, test notu veya ölçüm planı.

Tasarım ve içerik

• Formun amacı tek cümleyle yazıldı.
• Her alanın kullanılacağı yer ve kişi belli.
• Telefon gibi tartışmalı alanlar için karar kuralı uygulandı.
• Zorunlu alanlar etikette ve required ile işaretli.
• Etiketler görünür, kısa ve alanın üstünde.
• Yer tutucular yalnızca örnek biçim gösteriyor.
• Yönergeler kalıcı metin olarak veriliyor.

Hata ve erişilebilirlik

• Hata mesajları sorunu, gereksinimi ve örneği içeriyor.
• Hatalar alanın yanında ve aria-describedby ile bağlı.
• Gönderimde odak ilk hatalı alana gidiyor.
• Hata yalnızca renkle gösterilmiyor.
• Sunucu tarafında doğrulama yapılıyor.
• Yalnızca klavyeyle form tamamlanabiliyor.

Mobil ve ölçüm

• type ve autocomplete değerleri doğru.
• Dokunma hedefleri yeterli, yazı boyutu en az 1rem.
• Başarılı gönderim bir önemli etkinlik olarak ölçülüyor.
• Doğrulama hataları kişisel veri olmadan izleniyor.
• Başarı mesajı ve yanıt süresi gerçekçi.

Bir sonraki tur

Yayından sonra ilk iki hafta verileri toplayın ve değişikliği tek tek değerlendirin. Hata sayısı en yüksek alan çoğu zaman en çok sorun çıkaran alandır; o alanın etiketine, biçim yönergesine ve hata mesajına önce bakın. Belgelerdeki ilkeler güncellenebilir; uygulamadan önce W3C ve web.dev sayfalarının güncel hâline bakın.

Sık Sorulan Sorular

Bir formda en iyi alan sayısı kaçtır?

Belgeler böyle bir sayı vermez. W3C WAI genel ilke olarak yalnızca işlemi tamamlamak için gereken bilgiyi istemeyi önerir. Her alan için bu bilgi olmadan talebe yanıt verip veremeyeceğinizi sorun ve kendi verinizle karşılaştırarak karar verin.

Telefon alanı zorunlu olmalı mı?

Telefonla gerçekten arayacaksanız zorunlu yapın ve nedenini etiketin altında yazın. E-postayla yanıt verebiliyorsanız isteğe bağlı bırakın. Hiç kullanmayacaksanız alanı kaldırın.

Yer tutucu etiket yerine kullanılabilir mi?

Hayır. web.dev placeholder özniteliğini asla etiket yerine kullanmamayı söyler, W3C de ekran okuyucuların yer tutucuyu etiket olarak ele almadığını belirtir. Yer tutucu yalnızca örnek biçim için kullanılmalıdır.

İyi bir hata mesajı neleri içermelidir?

Sorunu adlandırmalı, gereksinimi söylemeli ve mümkünse örnek vermelidir. Mesaj ilgili alanın yanında görünmeli, alana programatik olarak bağlanmalı ve yalnızca renge dayanmamalıdır.

Çok adımlı form her zaman daha iyi midir?

Hayır. W3C uzun formları mantıksal adımlara bölmeyi önerir, ancak birkaç alanlı bir iletişim formunu bölmek yalnızca tıklamayı artırır. Karar için kendi formunuzun uzunluğuna ve ölçümüne bakın.

Form dönüşümünü Google Analytics'te nasıl izlerim?

Başarılı gönderimi bir etkinlik olarak toplayıp önemli etkinlik olarak işaretleyebilirsiniz. Analytics Yardım'a göre topladığınız herhangi bir etkinlik önemli etkinlik olabilir. Alan içeriğini olaylara yazmayın.

Formda kişisel veri toplamak hukuki bir konu mudur?

Kişisel veri ve rıza metinleri hukuki gereklilikler içerir. Formu yayına almadan önce gizlilik ve rıza metinlerinizi kendi hukuk danışmanınızla gözden geçirin.

Sonuç

Başvuru ve iletişim formunda dönüşüm kararı üç adımda verilir: yalnızca gerekli alanları isteyin, etiket ve yönergelerle ne beklendiğini açık söyleyin, hata anında düzeltme yolunu gösterin. Belgeler tek bir ideal alan sayısı vermez; bu yüzden değişiklikleri sırayla uygulayıp önemli etkinlik ölçümüyle ve talep kalitesiyle değerlendirin. Mobilde doğru girdi türü ve autocomplete değeri yükü azaltır, erişilebilir hata bildirimi de herkes için işe yarar.

Formu doldurup talep gönderecek ziyaretçileri çekmek için reklam görünürlüğü de arıyorsanız Akua Adforce'ta reklam alanlarını inceleyebilirsiniz; kapsam ve koşullar ilgili ürün sayfasında yazılıdır.