Bir kayıt formu ile başlayalım. Çoğu şirket, kullanıcılarıyla uzun vadeli ilişkiler kurmak ister. Bunu yapmak için kullanıcıların kaydolmaları gerekir. Ve bunu yapmak için , karşılığında kullanıcılara değer vermeleri gerekir. Hiç kimse hizmetinize kaydolmak istemez - yalnızca sunduğunuz her şeye veya bir sonraki ziyaretlerinde daha hızlı bir deneyim vaadine erişmek isterler.

Kayıt formunun temel görünümüne rağmen, dikkate alınması gereken birçok şey vardır: bir formu oluşturan ilkel öğeler (etiketler, düğmeler ve girdiler), çabayı azaltma yolları (bunun gibi küçük formlarda bile), forma kadar doğrulama.

Bu kadar basit bir formu seçerken, iyi tasarlanmış formlarda bulunan temel nitelikleri yakınlaştırabiliriz.

## Nasıl Görünebilir

Form, dört alan ve bir gönder düğmesinden oluşur. Her alan bir kontrolden (giriş) ve bununla ilişkili etiketten oluşur.

İşte HTML:

 <form> <label for="firstName">First name</label> <input type="text" name="firstName"> <label for="lastName">Last name</label> <input type="text" name="lastName"> <label for="email">Email address</label> <input type="email" name="email"> <label for="password">Create password</label> <input type="password" name="password" placeholder="Must be at least 8 characters"> <input type="submit" value="Register"> </form>

Etiketler tartışmamızın başladığı yer.

## Etiketler

Herkes İçin Erişilebilirlik'te Laura Kalbag, herkes için kullanıcı deneyimini iyileştiren dört geniş parametre ortaya koyuyor:

• Görsel : görmeyi kolaylaştırır.
• İşitsel : İşitmeyi kolaylaştırın.
• Motor : etkileşimi kolaylaştırır.
• Bilişsel : Anlamayı kolaylaştırın.

Etiketlere bu bakış açılarının her birinden bakarak etiketlerin ne kadar önemli olduğunu görebiliriz. Görme engelli kullanıcılar bunları okuyabilir, görme engelli kullanıcılar ekran okuyucu kullanarak duyabilir ve motor engelli kullanıcılar daha geniş vuruş alanı sayesinde alana daha kolay odaklanabilir. Bunun nedeni, bir etikete tıklamak, odağı ilişkili form öğesine odaklar.

Bu nedenlerle, girdi kabul eden her denetimin bir yardımcı <label> olması gerekir. Gönder düğmeleri girişi kabul etmez, bu nedenle yardımcı bir etikete ihtiyaç duymazlar - düğmenin içindeki metni oluşturan value özelliği erişilebilir etiket görevi görür.

Bir girdiyi bir etikete bağlamak for , girdinin id ve etiketin özniteliği sayfayla eşleşmeli ve benzersiz olmalıdır. E-posta alanı söz konusu olduğunda, değer "e-posta"dır:

 html < label for = "email" > Email address </ label > < input id = "email" >

Bir etiket eklememek, fiziksel ve bilişsel bozuklukları olanlar da dahil olmak üzere birçok kullanıcının ihtiyaçlarını göz ardı etmek anlamına gelir. Engelli insanların önündeki bilinen engellere odaklanarak formlarımızı herkes için daha kolay ve daha sağlam hale getirebiliriz.

Örneğin, motor engelli kullanıcılar için daha büyük bir vuruş alanı çok önemlidir, ancak engeli olmayanlar için de vurmak daha kolaydır.

## Yer tutucular

Yer placeholder özelliğinin bir ipucu saklaması amaçlanmıştır. Bir alanı doldururken kullanıcılara ekstra rehberlik sağlar - özellikle şifre alanı gibi karmaşık kuralları olan alanlar için kullanışlıdır.

Yer tutucu metin gerçek bir değer olmadığından, kullanıcı tarafından girilen değerlerden ayırt edilebilmesi için gri renktedir.

Etiketlerin aksine ipuçları isteğe bağlıdır ve doğal olarak kullanılmamalıdır. placeholder özelliğinin mevcut olması, onu kullanmamız gerektiği anlamına gelmez. Etiket "Ad" olduğunda, "Adınızı girin" yer tutucusuna ihtiyacınız yoktur - bu gereksiz tekrardır.

Yer tutucular, minimal, yerden tasarruf sağlayan estetikleri nedeniyle çekicidir. Bunun nedeni, yer tutucu metnin alanın içine yerleştirilmiş olmasıdır. Ancak bu, kullanıcılara bir ipucu vermenin sorunlu bir yoludur.

İlk olarak, kullanıcı yazdığında kaybolurlar. Kaybolan metnin hatırlanması zordur; bu, örneğin kullanıcı parola kurallarından birini yerine getirmeyi unutursa hatalara neden olabilir. Kullanıcılar genellikle bir değer için yer tutucu metni karıştırır, bu da alanın atlanmasına neden olur ve bu da daha sonra hatalara neden olur. Beyaz üzerine gri metin yeterli kontrasttan yoksundur ve bu da genellikle okunmasını zorlaştırır. Üstüne üstlük, bazı tarayıcılar yer tutucuları desteklemez, bazı ekran okuyucular bunları duyurmaz ve uzun ipucu metni kesilebilir.

Esasen sadece metin olan şey için bu çok fazla sorun. Tüm içeriğin, özellikle de bir form ipucunun olması hoş görülmemelidir. Bu nedenle, yer tutucular kullanmak yerine ipucu metnini kontrolün üzerine şu şekilde yerleştirmek daha iyidir:

 <div class="field"> <label for="password"> <span class="field-label">Password</span> <span class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</span> </label> <input type="password" name="password"> </div>

İpucu, etiketin içine ve <span> içine yerleştirilmiştir, böylece farklı şekilde biçimlendirilebilir. Etiketin içine yerleştirerek ekran okuyucular tarafından okunacak ve isabet alanını daha da genişletecektir.

Tasarımdaki çoğu şeyde olduğu gibi, bu işlevselliğe ulaşmanın tek yolu bu değildir. İpucunu girdiyle ilişkilendirmek için ARIA özniteliklerini kullanabiliriz:

 <div class="field"> <label for="password">Password</label> <p class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</p> <input type="password" name="password"> </div>

aria-describedby niteliği, ipucunu id bağlamak için kullanılır - tıpkı etiketlerdeki for niteliği gibi, ancak tersi. Kontrolün etiketine eklenir ve kısa bir aradan sonra okunur. Bu örnekte, "parola [duraklat] en az bir sayı ve bir büyük harf içeren sekiz artı karakter içermelidir."

Başka farklılıklar da var. İlk olarak, ipucuna (bu durumda a <p> ) tıklamak kontrolü odaklamaz, bu da isabet alanını azaltır. İkincisi, ARIA'nın artan desteğine rağmen, hiçbir zaman yerel öğeler kadar iyi desteklenmeyecek. Bu özel durumda, Internet Explorer 11 aria-describedby desteklemez. Bu nedenle ARIA'nın ilk kuralı ARIA kullanmamaktır:

"Bir öğeyi yeniden amaca uygun hale getirmek ve erişilebilir hale getirmek için bir ARIA rolü, durumu veya özelliği eklemek yerine, zaten yerleşik olarak ihtiyaç duyduğunuz anlambilim ve davranışa sahip yerel bir HTML öğesi veya özniteliği kullanabiliyorsanız, bunu yapın."

Kayan Etiketler

Matt Smith'in kayan etiket deseni, etiketi yer tutucu olarak kullanan bir tekniktir. Etiket kontrolün içinde başlar, ancak kullanıcı yazarken kontrolün üzerinde yüzer, dolayısıyla adı. Bu teknik, genellikle ilginç, minimalist ve yerden tasarruf sağlayan nitelikleri nedeniyle övülür.

Ne yazık ki, bu yaklaşımla ilgili birkaç sorun var. İlk olarak, etiket ve ipucu bir ve aynı olduğundan ipucu için yer yoktur. İkincisi, tipik olarak tasarlandıkları için zayıf kontrastları ve küçük metinleri nedeniyle okunması zordur. (Kullanıcıların gerçek bir değer ile bir yer tutucu arasında ayrım yapma şansına sahip olmaları için daha düşük kontrast gereklidir.) Üçüncüsü, yer tutucular gibi bir değerle karıştırılabilirler ve kırpılabilirler.

Ve kayan etiketler aslında yerden tasarruf etmez. Etiketin ilk etapta taşınması için alana ihtiyacı var. Yerden tasarruf etseler bile, bu, formların kullanılabilirliğini azaltmak için pek iyi bir neden değil.

"Girdilerin üzerine basitçe etiketler koyabildiğinizde ve tüm faydaları elde edebileceğiniz/sorunların hiçbirini elde edemediğinizde çok fazla çaba gibi görünüyor."
— Luke Wroblewski şamandıra etiketlerinde

İlginç ve minimalist arayüzler, kullanıcıları harika hissettirmez - bariz, kapsayıcı ve sağlam arayüzler yapar. Bunun gibi formların yüksekliğini yapay olarak azaltmak hem zorlayıcı hem de sorunlu.

Bunun yerine, tasarım sürecinin başlangıcında her zaman mevcut, kolayca bulunabilen bir etikete (ve gerekirse ipucu) yer açmaya öncelik vermelisiniz. Bu şekilde içeriği küçük bir alana sıkıştırmanız gerekmeyecek.

Kısa süre içinde formların boyutunu küçültmek için daha az yapay olan birkaç tekniği tartışacağız.

## Soru Protokolü

Bir formun boyutunu küçültmenin güçlü ve doğal bir yolu, bir soru protokolü kullanmaktır. Her soruyu neden sorduğunuzu veya bir form alanı dahil ettiğinizi bilmenize yardımcı olur.

Kayıt formunun ad, soyad, e-posta adresi ve şifreyi toplaması gerekiyor mu? Deneyimi basitleştiren bu bilgiyi istemenin daha iyi veya alternatif yolları var mı?

Her durumda, kaydolmaları için kullanıcının adını ve soyadını sormanız gerekmez. Bu bilgiye daha sonra ihtiyaç duyarsanız, herhangi bir nedenle, o zaman isteyin. Bu alanları kaldırarak formun boyutunu yarıya indirebiliriz. Hepsi yeni ve sorunlu kalıplara başvurmadan.

### Şifresiz Oturum Açma

Kullanıcılardan parola istemekten kaçınmanın bir yolu, parolasız oturum açma düzenini kullanmaktır. E-postanın (zaten bir şifreye ihtiyacı olan) güvenliğini kullanarak çalışır. Kullanıcılar yalnızca e-posta adreslerini girer ve hizmet, gelen kutularına özel bir bağlantı gönderir. Bunu takiben, kullanıcıyı hemen hizmete kaydeder.

Bu, formun boyutunu yalnızca bir alana indirgemekle kalmaz, aynı zamanda kullanıcıları başka bir parolayı hatırlamak zorunda bırakmaz. Bu, formu ayrı ayrı basitleştirirken, başka şekillerde kullanıcı için ekstra karmaşıklık ekler.

İlk olarak, kullanıcılar bu yaklaşıma daha az aşina olabilir ve birçok kişi çevrimiçi güvenlik konusunda endişelidir. İkincisi, özellikle şifrelerini bilen veya bir şifre yöneticisi kullanan kullanıcılar için uygulamadan e-posta hesabınıza geçmek uzun soluklu bir iştir.

Bir teknik her zaman diğerinden daha iyi değildir. Bir soru protokolü bizi bunu tasarım sürecinin bir parçası olarak düşünmeye teşvik ediyor. Aksi takdirde, forma düşüncesizce bir şifre alanı ekler ve onunla işiniz biter.

### Parolalar

Parolalar genellikle kısadır, hatırlanması zordur ve kırılması kolaydır. Kullanıcılar genellikle en az bir büyük ve bir küçük harf ve bir sayıdan oluşan sekiz karakterden fazla bir parola oluşturmak zorundadır. Bu mikro etkileşim pek ideal değil.

"Üzgünüm ama şifreniz büyük harf, sayı, haiku, çete işareti, hiyeroglif ve bir bakirenin kanı içermeli."
— Anonim internet memesi

Parola yerine, kullanıcılardan bir parola isteyebiliriz. Parola, “monkeysinmygarden” gibi bir dizi kelimedir (üzgünüz, akla ilk gelen bu). Genellikle parolalardan daha kolay hatırlanırlar ve uzunlukları nedeniyle daha güvenlidirler - parolalar en az 16 karakter uzunluğunda olmalıdır.

Dezavantajı, parolaların daha az yaygın olarak kullanılması ve bu nedenle tanıdık olmamasıdır. Bu, çevrimiçi güvenlik konusunda zaten endişe duyan kullanıcılar için endişeye neden olabilir.

Parolasız oturum açma düzeni veya parolalar olsun, yalnızca kapsamlı ve çeşitli kullanıcı araştırmaları yaptıktan sonra geleneksellikten uzaklaşmalıyız. Bilmeden bir dizi sorunu bir başkasıyla değiştirmek istemezsiniz.

## Alan Stili

Form bileşenlerinizi şekillendirme şekliniz, en azından kısmen, ürününüz veya şirketinizin markası tarafından belirlenecektir. Yine de, etiket konumu ve odak stilleri önemli hususlardır.

### Etiket Konumu

Matteo Penzo'nun göz izleme testleri, etiketin (yanının aksine) üstüne yerleştirilmesinin form kontrolünün en iyi sonucu verdiğini gösterdi.

"Giriş alanının hemen üzerine bir etiket yerleştirmek, kullanıcıların her iki öğeyi de tek bir göz hareketiyle yakalamasına izin verdi."

Ancak etiketi alanın üstüne koymak için başka nedenler de var. Küçük görünüm pencerelerinde kontrolün yanında yer yoktur. Ve büyük görünüm alanlarında, yakınlaştırma metnin ekrandan kaybolma olasılığını artırır.

Ayrıca, bazı etiketler çok fazla metin içerir, bu da kontrolün yanına yerleştirilirse görsel ritmi bozacak şekilde birden çok satıra sarılmasına neden olur.

Etiketleri kısa tutmayı amaçlamalısınız, ancak bu her zaman mümkün değildir. Etiketleri kontrolün üzerinde konumlandırarak değişen içeriği barındıran bir model kullanmak iyi bir stratejidir.

### Görünüm, Boyut ve Boşluk

Form alanları, form alanları gibi görünmelidir. Ama bu tam olarak ne anlama geliyor?

Bu, bir metin kutusunun bir metin kutusu gibi görünmesi gerektiği anlamına gelir. Boş kutular, bir boyama kitabı gibi, boş olmaları nedeniyle “beni doldur” anlamına gelir. Bu, yer tutucuların yardımcı olmama nedeninin bir parçası olabilir. Aksi takdirde boş bir metin kutusunun sağlayacağı algılanan uygunluğu kaldırırlar.

Bu aynı zamanda boş alanın kutulanması (kenarlıklı) gerektiği anlamına gelir. Örneğin, sınırın kaldırılması veya yalnızca bir alt sınırın olması, algılanan uygunlukları ortadan kaldırır. Alt kenarlık ilk başta bir ayırıcı gibi görünebilir. Bir şeyi doldurmanız gerektiğini bilseniz bile, değer çizginin üstünde mi yoksa altında mı?

Uzamsal olarak etiket, önceki alanın denetimine değil, form denetimine en yakın olmalıdır. Birbirine yakın görünen şeyler, onların birbirine ait olduğunu düşündürür. Eşit boşluklara sahip olmak estetiği iyileştirebilir, ancak kullanılabilirlik pahasına olacaktır.

Son olarak, etiket ve metin kutusunun kendisi okunacak ve dokunulacak kadar büyük olmalıdır. Bu, muhtemelen en az 16 piksellik bir yazı tipi boyutu ve ideal olarak en az 44 piksellik genel bir hafifçe vurma hedefi anlamına gelir.

### Odak Stilleri

Odak stilleri daha basit bir olasılıktır. Varsayılan olarak, tarayıcılar, özellikle klavye kullananlar olmak üzere kullanıcıların nerede olduklarını bilmeleri için odaktaki öğenin çevresine bir anahat koyar. Varsayılan stil ile ilgili sorun, genellikle soluk ve görülmesi zor ve biraz çirkin olmasıdır.

Durum böyleyken, onu kaldırmaya kalkışmayın, çünkü bunu yapmak, ekranı klavyeyle dolaşanlar için kullanıcı deneyimini büyük ölçüde azaltacaktır. Daha net ve estetik olarak daha hoş hale getirmek için varsayılan stili geçersiz kılabiliriz.

 input:focus { outline: 4px solid #ffbf47; }

## E-posta Alanı

Basit görünümüne rağmen, sahanın inşasına giren ve deneyimi etkileyen bazı önemli detaylar var.

Daha önce belirtildiği gibi, bazı alanlarda etikete ek olarak bir ipucu da vardır, bu nedenle etiket bir alt aralığın içindedir. field-label sınıfı, onu CSS aracılığıyla stillendirmemize izin verir.

 <div class="field"> <label for="email"> <span class="field-label">Email address</span> </label> <input type="email" name="email"> </div>

Etiketin kendisi “E-posta adresi”dir ve cümle büyüklüğünü kullanır. John Saito, “Harf davası için dava açma”da, cümle durumunun (başlık davasının aksine) genellikle daha kolay okunduğunu, daha dostça olduğunu ve isimleri tespit etmeyi kolaylaştırdığını açıklıyor. Bu tavsiyeye uyup uymamak size kalmış, ancak hangi stili seçerseniz seçin, tutarlı bir şekilde kullandığınızdan emin olun.

Girişin type özelliği, mobil cihazlarda e-postaya özel ekran klavyesini tetikleyen email olarak ayarlanır. Bu, kullanıcılara @ ve 'ye kolay erişim sağlar . (nokta) her e-posta adresinin içermesi gereken simgeler.

Desteklenmeyen bir tarayıcı kullanan kişiler standart bir metin girişi görür ( <input type="text"> ). Bu, kapsayıcı deneyimler tasarlamanın temel taşı olan aşamalı bir geliştirme biçimidir.

### Aşamalı Geliştirme

Aşamalı geliştirme, kullanıcılarla ilgilidir. Sadece tasarımcılar ve geliştiriciler olarak hayatımızı kolaylaştırıyor. Bir dizi tarayıcıya ve cihaza ayak uydurmak yerine (ki bu imkansız!) sadece özelliklere odaklanabiliriz.

Her şeyden önce, aşamalı geliştirme, tarayıcıları, cihazları veya bağlantı kalitesi ne olursa olsun kullanıcılara her zaman makul bir deneyim sunmakla ilgilidir. İşler ters gittiğinde – ki olacak – kullanıcılar hala işleri halledebilecekleri için acı çekmeyecekler.

Bir deneyimin yanlış gidebileceği birçok yol vardır. Stil sayfası veya komut dosyası yüklenemiyor olabilir. Belki her şey yüklenir, ancak kullanıcının tarayıcısı bazı HTML, CSS veya JavaScript'i tanımıyor. Ne olursa olsun, deneyimler tasarlarken aşamalı geliştirmeyi kullanmak, kullanıcıların özellikle kötü bir zaman geçirmesini engeller.

Yapı ve içerik için HTML ile başlar. CSS veya JavaScript yüklenmiyorsa, içerik orada olduğu için sorun yoktur.

Her şey yolundaysa, çeşitli HTML öğeleri tanınmayabilir. Örneğin, bazı tarayıcılar <input type="email"> anlamıyor. Yine de sorun değil, çünkü kullanıcılar bunun yerine bir metin kutusu ( <input type="text"> ) alacak. Kullanıcılar yine de bir e-posta adresi girebilir; sadece mobil cihazlarda e-postaya özel bir klavye almıyorlar.

Belki tarayıcı bazı süslü CSS'leri anlamıyor ve onu görmezden gelecek. Çoğu durumda, bu bir sorun değildir. Diyelim ki border-radius: 10px olan bir düğmeniz var. Bu kuralı tanımayan tarayıcılar, köşeleri açılı bir düğme gösterecektir. Muhtemelen, düğmenin algılanan uygunluğu azalır, ancak kullanıcılar zarar görmez. Diğer durumlarda, özellik sorgularını kullanmak yararlı olabilir.

Sonra daha karmaşık olan JavaScript var. Tarayıcı tanımadığı yöntemleri ayrıştırmaya çalıştığında, bir tıslama uyarısı verir. Bu, diğer (geçerli ve desteklenen) komut dosyalarınızın başarısız olmasına neden olabilir. Komut dosyanız, kullanmadan önce yöntemlerin var olduğunu (özellik algılama) ve çalıştığını (özellik testi) kontrol etmezse, kullanıcılar bozuk bir arayüz alabilir. Örneğin, bir düğmenin tıklama işleyicisi tanınmayan bir yöntemi çağırırsa, düğme çalışmaz. Bu kötü.

Böylece geliştirirsiniz. Ancak daha iyi olan şey, bir iyileştirmeye hiç ihtiyaç duymamaktır. Biraz CSS içeren HTML, kullanıcılara mükemmel bir deneyim sunabilir. Önemli olan içeriktir ve bunun için JavaScript'e ihtiyacınız yoktur. İçeriğe (HTML) ve stile (CSS) ne kadar çok güvenirseniz o kadar iyidir. Bunu yeterince vurgulayamam: Çoğu zaman, temel deneyim en iyi ve en performanslı olanıdır. Değer katmıyorsa bir şeyi geliştirmenin bir anlamı yoktur (bkz. kapsayıcı tasarım ilkesi 7).

Elbette, temel deneyimin olabileceği kadar iyi olmadığı zamanlar vardır - işte o zaman geliştirme zamanıdır. Ancak yukarıdaki yaklaşımı izlersek, bir CSS veya JavaScript parçası tanınmadığında veya yürütülmediğinde, işler yine de işe yarayacaktır.

Aşamalı geliştirme, işler başarısız olduğunda ne olduğu hakkında düşünmemizi sağlar. Pişmiş bir esneklikle deneyimler inşa etmemizi sağlar. Ancak aynı şekilde, bir iyileştirmeye ihtiyaç olup olmadığı hakkında düşünmemizi sağlar; ve eğer öyleyse, bu konuda en iyi nasıl gidilir.

## Şifre Alanı

Daha önce tartışılan e-posta alanıyla aynı işaretlemeyi kullanıyoruz. Bir şablon dili kullanıyorsanız, her iki alan türünü de barındıran bir bileşen oluşturabilirsiniz. Bu, kapsayıcı tasarım ilkesi 3'ün tutarlı olmasına yardımcı olur.

 <div class="field"> <label for="password"> <span class="field-label">Choose password</span> <span class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</span> </label> <input type="password" name="password"> </div>

Şifre alanı bir ipucu içerir. Biri olmadan, kullanıcılar gereksinimleri anlayamaz ve bu da devam etmeye çalıştıklarında bir hataya neden olabilir.

type="password" özelliği, kullanıcının yazdıklarını küçük siyah noktalarla değiştirerek girişin değerini maskeler. Bu, yakınlarda olduklarında insanların yazdıklarınızı görmesini engelleyen bir güvenlik önlemidir.

### Parola Gösterimi

Kullanıcı yazarken değeri gizlemek, yazım hatalarını düzeltmeyi zorlaştırır. Bu nedenle, bir giriş yapıldığında, tüm girişi silmek ve yeniden başlamak genellikle daha kolaydır. Çoğu kullanıcı, omzunun üzerinden bakan bir kişinin olduğu bir bilgisayar kullanmadığı için bu sinir bozucu.

Artan yazım hatası riski nedeniyle, bazı kayıt formlarında ek bir “Şifreyi onayla” alanı bulunur. Bu, kullanıcının aynı parolayı iki kez girmesini gerektiren, çabayı iki katına çıkaran ve kullanıcı deneyimini bozan bir önlemdir. Bunun yerine, kullanıcıların sırasıyla 4. ve 5. ilkelere hitap eden parolalarını açıklamalarına, kontrol vermelerine ve seçim yapmalarına izin vermek daha iyidir. Bu şekilde kullanıcılar, kimsenin bakmadığını bildiklerinde şifrelerini açığa çıkarmayı seçebilir ve yazım hatası riskini azaltır.

Internet Explorer ve Microsoft Edge'in son sürümleri bu davranışı yerel olarak sağlar. Kendi çözümümüzü oluşturacağımız için, CSS kullanarak bu özelliği şu şekilde bastırmalıyız:

 input[type=password]::-ms-reveal { display: none; }

İlk olarak girdinin yanına bir buton enjekte etmemiz gerekiyor. <button> öğesi, JavaScript ile herhangi bir şeyi değiştirmek için ilk öğeniz olmalıdır - yani, bağlantıların amacı olan konumu değiştirmek dışında. Tıklandığında, type niteliğini password ve text arasında değiştirmelidir; ve düğmenin "Göster" ve "Gizle" arasındaki etiketi.

 function PasswordReveal(input) { // store input as a property of the instance // so that it can be referenced in methods // on the prototype this.input = input; this.createButton(); }; PasswordReveal.prototype.createButton = function() { // create a button this.button = $('<button type="button">Show password</button>'); // inject button $(this.input).parent().append(this.button); // listen to the button's click event this.button.on('click', $.proxy(this, 'onButtonClick')); }; PasswordReveal.prototype.onButtonClick = function(e) { // Toggle input type and button text if(this.input.type === 'password') { this.input.type = 'text'; this.button.text('Hide password'); } else { this.input.type = 'password'; this.button.text('Show password'); } };

#### JavaScript Sözdizimi ve Mimari Notlar

JavaScript'in pek çok çeşidi ve bileşenleri tasarlamanın farklı yolları olduğu için, parola belirleme bileşenini oluşturmak için kullanılan seçenekleri ve kitapta gelecek tüm bileşenleri inceleyeceğiz.

İlk olarak, bir kurucu kullanıyoruz. Yapıcı, geleneksel olarak büyük harfle yazılmış bir işlevdir - passwordReveal değil, PasswordReveal . Bileşenin birkaç örneğini oluşturmak için aynı kodu kullanmamıza izin veren new anahtar sözcüğü kullanılarak başlatılır:

 var passwordReveal1 = new PasswordReveal(document.getElementById('input1')); var passwordReveal2 = new PasswordReveal(document.getElementById('input2'));

İkinci olarak, bileşenin yöntemleri prototipte tanımlanır - örneğin, PasswordReveal.prototype.onButtonClick . Prototip, yöntemleri aynı bileşenin birden çok örneği arasında paylaşmanın en performanslı yoludur.

Üçüncüsü, jQuery öğeleri oluşturmak ve almak ve olayları dinlemek için kullanılıyor. jQuery gerekli veya tercih edilmese de, bu kitabın kullanılması, bu kitabın tarayıcılar arası bileşenlerin karmaşıklığına değil, formlara odaklanabileceği anlamına gelir.

Biraz kod yazan bir tasarımcıysanız, jQuery'nin her yerde bulunabilmesi ve girişe karşı düşük bariyeri yardımcı olacaktır. Aynı şekilde, jQuery kullanmamayı tercih ederseniz, bileşenleri tercihinize göre yeniden düzenlemekte sorun yaşamayacaksınız.

$.proxy işlevinin kullanıldığını da fark etmiş olabilirsiniz. Bu, jQuery'nin Function.prototype.bind uygulamasıdır. Olayları dinlemek için bu işlevi kullanmamış olsaydık, olay işleyicisi öğenin bağlamında ( this ) çağrılırdı. Yukarıdaki örnekte this.button tanımsız olacaktır. Ancak bunun yerine, özelliklerine ve yöntemlerine erişebilmemiz için this yerine parola ifşa nesnesi olmasını istiyoruz.

#### Alternatif Arayüz Seçenekleri

Yukarıda oluşturduğumuz parola gösterme arayüzü, düğmenin etiketini “Şifreyi göster” ve “Şifreyi gizle” arasında değiştirir. Düğmenin etiketi değiştirildiğinde bazı ekran okuyucu kullanıcılarının kafası karışabilir; bir kullanıcı bir düğmeyle karşılaştığında, bu düğmenin kalıcı olmasını bekler. Düğme kalıcı olsa da , etiketin değiştirilmesi yokmuş gibi görünmesini sağlar.

Araştırmanız bunun bir sorun olduğunu gösteriyorsa, iki alternatif yaklaşımı deneyebilirsiniz.

İlk olarak, kalıcı bir "Şifre göster" etiketine sahip bir onay kutusu kullanın. Durum, checked öznitelik tarafından bildirilecektir. Ekran okuyucu kullanıcıları "Şifreyi göster, onay kutusu, işaretli" (veya benzeri) sözlerini duyar. Gören kullanıcılar onay kutusunun onay işaretini görecektir. Bu yaklaşımla ilgili sorun, onay kutularının arayüzü kontrol etmek için değil, veri girmek için olmasıdır. Bazı kullanıcılar şifrelerinin sisteme açıklanacağını düşünebilir.

Veya ikinci olarak, etiketi değil düğmenin state değiştirin. Durumu ekran okuyucu kullanıcılarına iletmek için, aria-pressed niteliğini true (basılmış) ve false (basılmamış) arasında değiştirebilirsiniz.

 <button type="button" aria-pressed="true"> Show password </button>

Düğmeye odaklanırken, ekran okuyucular "Şifreyi göster, geçiş düğmesi, basıldı" (veya benzeri) duyurusunu yapacaktır. Gören kullanıcılar için, öznitelik seçiciyi aşağıdaki gibi kullanarak düğmeyi basılı veya basılmamış görünecek şekilde biçimlendirebilirsiniz:

 [aria-pressed="true"] { box-shadow: inset 0 0 0 0.15rem #000, inset 0.25em 0.25em 0 #fff; }

Basılmamış ve basılmamış stillerin belirgin ve farklı olduğundan emin olun, aksi takdirde gören kullanıcılar aralarındaki farkı anlamakta zorlanabilirler.

### Mikrokopi

Etiket, "Şifre" yerine "Şifre seç" olarak ayarlanmıştır. İkincisi biraz kafa karıştırıcıdır ve kullanıcıdan zaten sahip olduğu bir parolayı yazmasını isteyebilir ve bu bir güvenlik sorunu olabilir. Daha incelikli olarak, kullanıcının zaten kayıtlı olduğunu ve bilişsel bozukluğu olan kullanıcıların bunun yerine oturum açtıklarını düşünmelerine neden olabilir.

“Şifre” belirsiz olduğunda, “Şifre seç” netlik sağlar.

## Düğme Stilleri

Düğme nedir? Bir web sayfasındaki birçok farklı bileşen türünü düğme olarak adlandırıyoruz. Aslında, onları çağırmadan iki farklı düğme türünü zaten ele aldım. Şimdi yapalım.

Form gönderen düğmeler “gönder düğmeleri”dir ve genellikle <input type="submit"> veya <button type="submit"> olarak kodlanırlar. <button> öğesi, diğer öğeleri içine yerleştirebildiğiniz için daha yumuşaktır. Ancak buna nadiren ihtiyaç duyulur. Gönder düğmelerinin çoğu yalnızca metin içerir.

Not: Internet Explorer'ın eski sürümlerinde, birden fazla <button type="submit"> niz varsa, form, hangisinin tıklandığına bakılmaksızın tüm düğmelerin değerini sunucuya gönderir. Hangi düğmenin tıklandığını bilmeniz gerekecek, böylece doğru hareket tarzını belirleyebilirsiniz, bu yüzden bu öğeden kaçınılmalıdır.

JavaScript deneyimini geliştirmek için arayüze başka düğmeler eklenir - daha önce tartışılan parola açığa çıkarma bileşeninde yaptığımız gibi. Bu aynı zamanda bir <button> idi, ancak type button olarak ayarlandı ( submit ).

Her iki durumda da, düğmeler hakkında bilinmesi gereken ilk şey, bunların bağlantı olmadığıdır. Bağlantıların tipik olarak altı çizilir (kullanıcı aracısı stilleri tarafından) veya özel olarak konumlandırılır (bir gezinme çubuğunda), böylece normal metinler arasında ayırt edilebilirler. Bir bağlantının üzerine geldiğinizde, imleç bir işaretçiye dönüşecektir. Bunun nedeni, düğmelerin aksine, bağlantıların algılanan uygunluğunun zayıf olmasıdır.

Resilient Web Design'da Jeremy Keith, maddi dürüstlük fikrini tartışıyor. Şöyle diyor: “Bir malzeme diğerinin yerine kullanılmamalıdır. Aksi takdirde sonuç aldatıcı olur.” Bir bağlantının bir düğme gibi görünmesini sağlamak, maddi anlamda dürüst olmayan bir davranıştır. Kullanıcılara, olmadıklarında bağlantıların ve düğmelerin aynı olduğunu söyler.

Bağlantılar, düğmelerin yapamadığı şeyleri yapabilir. Örneğin, bağlantılar yeni bir sekmede açılabilir veya daha sonra kullanılmak üzere işaretlenebilir. Bu nedenle, düğmeler bağlantı gibi görünmemeli ve bir işaretçi imlecine sahip olmamalıdır. Bunun yerine, düğmeleri, doğal olarak güçlü algılanan karşılanabilirliğe sahip düğmeler gibi göstermeliyiz. Yuvarlatılmış köşeleri, alt gölgeleri ve kenarlıkları olup olmadığı size bağlıdır, ancak ne olursa olsun düğmeler gibi görünmelidirler.

Düğmeler, örneğin arka plan rengini değiştirerek fareyle üzerine gelindiğinde (ve odakta) geri bildirim vermeye devam edebilir.

### Yerleştirme

Gönder düğmeleri genellikle formun altına yerleştirilir: çoğu formda kullanıcılar alanları yukarıdan aşağıya doğru doldurur ve ardından gönderir. Ancak düğme sola mı, sağa mı yoksa ortaya mı hizalanmalıdır? Bu soruyu cevaplamak için, kullanıcıların onu doğal olarak nerede arayacağını düşünmemiz gerekiyor.

Alan etiketleri ve form kontrolleri sola hizalanır (soldan sağa okuma dillerinde) ve yukarıdan aşağıya doğru çalışır. Kullanıcılar, sonuncunun altındaki bir sonraki alanı arayacaktır. Doğal olarak, gönder düğmesi de o konuma yerleştirilmelidir: sola ve doğrudan son alanın altına. Bu aynı zamanda, sağa hizalanmış bir düğme ekran dışında daha kolay kaybolabileceğinden, yakınlaştıran kullanıcılara da yardımcı olur.

### Metin

Düğmenin metni, stili kadar önemlidir. Metin, yapılan eylemi açıkça tanımlamalıdır. Ve bu bir eylem olduğu için bir fiil olmalıdır. Okuması daha hızlı olduğu için mümkün olduğunca az kelime kullanmayı hedeflemeliyiz. Ancak, netlik pahasına kelimeleri çıkarmamalıyız.

Tam kelimeler markanızın ses tonuyla eşleşebilir, ancak netliği tuhaflıkla değiştirmeyin.

Basit ve sade bir dil herkesin anlayabileceği şekildedir. Kesin kelimeler hizmetin türüne bağlı olacaktır. Kayıt formumuz için “Kayıt Ol” yeterlidir, ancak hizmetinize bağlı olarak “Katıl” veya “Kaydol” daha uygun olabilir.

## Doğrulama

Kapsayıcı, basit ve sorunsuz bir kayıt deneyimi yaratma çabalarımıza rağmen, insan hatasını ortadan kaldıramıyoruz. İnsanlar hata yapar ve yaptıklarında onları düzeltmeyi mümkün olduğunca kolaylaştırmalıyız.

Form doğrulama söz konusu olduğunda, dikkate alınması gereken bir dizi önemli ayrıntı vardır. Geri bildirimin ne zaman verileceğinin seçiminden, bu geri bildirimin nasıl gösterileceğine ve iyi bir hata mesajının formüle edilmesine kadar - tüm bunların dikkate alınması gerekir.

### HTML5 Doğrulaması

HTML5 doğrulaması bir süredir ortalarda. Destekleyen tarayıcılar, yalnızca birkaç HTML özelliği ekleyerek, form gönderildiğinde hatalı alanları işaretleyecektir. Desteklenmeyen tarayıcılar, sunucu tarafı doğrulamaya geri döner.

Normalde, genellikle daha performanslı, sağlam ve erişilebilir olduğu için tarayıcının ücretsiz olarak sağladığı işlevleri kullanmanızı öneririm. Söz değil, daha fazla site standart işlevselliği kullanmaya başladıkça kullanıcılar için daha tanıdık hale geliyor.

HTML5 doğrulama desteği oldukça iyi olsa da, aynı şekilde uygulanmamaktadır. Örneğin, gerekli öznitelik, alanları başlangıçtan itibaren geçersiz olarak işaretleyebilir ve bu arzu edilmeyen bir durumdur. Firefox 45.7 gibi bazı tarayıcılar, kullanıcı kutuya bir şey girse bile “Lütfen bir e-posta adresi girin” hatası gösterirken, örneğin Chrome “Lütfen e-posta adresine bir '@' ekleyin” diyor. hangisi daha faydalıdır.

Ayrıca, sunucuda veya istemcide hatalar yakalanmış olsun, kullanıcılara aynı arayüzü vermek istiyoruz. Bu nedenlerle kendi çözümümüzü tasarlayacağız. Yapılacak ilk şey HTML5 doğrulamasını kapatmaktır: <form novalidate>

### Gönderimi İşleme

Kullanıcı formu gönderdiğinde hata olup olmadığını kontrol etmemiz gerekiyor. Varsa, formun ayrıntıları sunucuya göndermesini engellememiz gerekir.

 function FormValidator(form) { form.on('submit', $.proxy(this, 'onSubmit')); } FormValidator.prototype.onSubmit = function(e) { if(!this.validate()) { e.preventDefault(); // show errors } };

Düğmenin tıklama olayını değil, formun gönderme olayını dinlediğimizi unutmayın. İkincisi, odak alanlardan birinin içindeyken Enter tuşuna basarak kullanıcıların formu göndermesini durduracaktır. Bu aynı zamanda örtük form gönderme olarak da bilinir.

### Geri Bildirim Görüntüleme

Her şey hataların varlığını çok iyi tespit ediyor, ancak bu noktada kullanıcılar daha akıllı değil. Arayüzün güncellenmesi gereken üç farklı parçası vardır. Şimdi bunların her biri hakkında konuşacağız.

#### Belge başlığı

Belgenin <title> , bir web sayfasının ekran okuyucular tarafından okunacak ilk bölümüdür. Bu nedenle, gönderimlerinde bir şeylerin yanlış gittiğini kullanıcılara hızlı bir şekilde bildirmek için kullanabiliriz. Bu, özellikle bir sunucu isteğinden sonra sayfa yeniden yüklendiğinde kullanışlıdır.

JavaScript ile istemcideki hataları yakalayarak kullanıcı deneyimini iyileştiriyor olsak da, tüm hatalar bu şekilde yakalanamıyor. Örneğin, bir e-posta adresinin daha önce alınmadığını kontrol etmek yalnızca sunucuda kontrol edilebilir. Ve her durumda, JavaScript başarısızlığa meyillidir, bu nedenle yalnızca kullanılabilirliğine güvenemeyiz.

Orijinal sayfa başlığının "[servis] için kaydolun" şeklinde olabileceği durumlarda, hata durumunda "(2 hata) [servis] için kaydolun" (veya benzeri) şeklinde olmalıdır. Tam ifade biraz görüşe bağlıdır.

Aşağıdaki JavaScript başlığı günceller:

 document.title = "(" + this.errors.length + ")" + document.title;

Yukarıda belirtildiği gibi, bu öncelikle ekran okuyucu kullanıcıları içindir, ancak çoğu zaman kapsayıcı tasarımda olduğu gibi, bir kullanıcı grubuna yardımcı olan şey diğer herkese de yardımcı olur. Bu sefer, güncellenen başlık, sekmede bir bildirim görevi görür.

Hata Özeti

Başlık öğesiyle karşılaştırıldığında, hata özeti daha belirgindir ve bu, gören kullanıcılara bir şeylerin yanlış gittiğini söyler. Ancak, kullanıcıların neyin yanlış gittiğini ve nasıl düzeltileceğini anlamalarını sağlamaktan da sorumludur.

Sayfanın en üstüne yerleştirilmiştir, böylece kullanıcılar bir sayfa yenilendikten sonra görmek için aşağı kaydırmak zorunda kalmazlar (sunucuda bir hata yakalanırsa). Geleneksel olarak, hatalar kırmızı renktedir. Ancak, yalnızca renge güvenmek, renk körü kullanıcıları hariç tutabilir. Özete dikkat çekmek için konum, boyut, metin ve ikonografi kullanmayı da düşünün.

Panel, sorunu belirtmek için "Bir sorun var" başlığını içerir. Dikkat edin, çok kolay olmayan “Hata” kelimesini söylemez. Bir galeriden araba satın almak için bilgilerinizi doldurduğunuzu ve bir hata yaptığınızı hayal edin. Satış görevlisi "Hata" demez - aslında bunu söylemeleri garip olurdu.

 <div class="errorSummary" role="group" tabindex="-1" aria-labelledby="errorSummary-heading"> <h2>There's a problem</h2> <ul> <li><a href="#emailaddress">Enter an email address</a></li> <li><a href="#password">The password must contain an uppercase letter</a></li> </ul> </div>

Kapsayıcı, bir dizi arabirim öğesini gruplamak için kullanılan group role sahiptir: bu durumda başlık ve hata bağlantıları. tabindex niteliği -1 olarak ayarlanmıştır, bu nedenle JavaScript ile programlı olarak odaklanabilir (form hatalarla gönderildiğinde). Bu, hata özeti panelinin görünüme kaydırılmasını sağlar. Aksi takdirde, arayüz gönderildiğinde yanıt vermiyor ve bozuk görünüyor.

Not: tabindex="0" kullanılması, 2.4.3 Odak Sırası WCAG hatası olan Sekme tuşu yoluyla kalıcı olarak odaklanılabileceği anlamına gelir. Kullanıcılar bir şeye sekme yapabilirlerse, gerçekten bir şey yapmasını beklerler.

 FormValidator.prototype.showSummary = function () { // ... this.summary.focus(); };

Altında, hata bağlantılarının bir listesi var. Bir bağlantıya tıklamak, kullanıcıların forma hızlı bir şekilde atlamalarını sağlayan hatalı alana odaklanacaktır. Bağlantının href özelliği, kontrolün kimliğine ayarlanır ve bu, bazı tarayıcılarda odağı ona ayarlamak için yeterlidir. Ancak, diğer tarayıcılarda, bağlantıya tıklamak, girişi odaklamadan yalnızca görünüme kaydırır. Bunu düzeltmek için girdiyi açıkça odaklayabiliriz.

 FormValidator.prototype.onErrorClick = function(e) { e.preventDefault(); var href = e.target.href; var id = href.substring(href.indexOf("#"), href.length); $(id).focus(); };

Herhangi bir hata olmadığında özet paneli gizlenmelidir. Bu, sayfada yalnızca bir özet panelinin olmasını ve hataların istemci veya sunucu tarafından oluşturulup oluşturulmadığına bakılmaksızın aynı konumda tutarlı bir şekilde görünmesini sağlar. Paneli gizlemek için bir hidden sınıf eklememiz gerekiyor.

 <div class="errorSummary hidden" ...></div>

 .hidden { display: none; }

Not: Bir öğenin görünürlüğünü değiştirmek için hidden özniteliği/özelliği kullanabilirsiniz, ancak bunun için daha az destek vardır. Kapsayıcı tasarım, insanları dışlama olasılığının düşük olduğunu bildiğiniz kararlar almakla ilgilidir. Bir sınıf kullanmak bu felsefeyle uyumludur.

#### Satır İçi Hatalar

İlgili hata mesajını alanın hemen üstüne koymamız gerekiyor. Bu, kullanıcıları hata mesajını kontrol etmek için sayfayı yukarı ve aşağı kaydırmaktan kurtarır ve formda aşağı doğru hareket etmelerini sağlar. Mesaj alanın altına yerleştirilmişse, tarayıcının otomatik tamamlama paneli veya ekran klavyesi tarafından gizlenme şansını artırırdık.

 <div class="field"> <label for="blah"> <span class="field-error"> <svg width="1.5em" height="1.5em"><use xmlns:xlink="https://www.w3.org/1999/xlink" xlink:href="#warning-icon"></use></svg> Enter your email address. </span> <span class="field-error">Enter an email address</span> </label> </div>

Daha önce bahsedilen ipucu deseni gibi, hata mesajı etiketin içine enjekte edilir. Alan odaklandığında, ekran okuyucu kullanıcıları mesajı bağlam içinde duyacak ve böylece özete başvurmak zorunda kalmadan formda özgürce hareket edebileceklerdir.

Hata mesajı kırmızıdır ve kullanıcıların dikkatini çekmek için bir SVG uyarı simgesi kullanır. Bir hatayı belirtmek için yalnızca bir renk değişikliği kullansaydık, bu renk körü kullanıcıları hariç tutardı. Yani bu, gören kullanıcılar için gerçekten işe yarıyor - peki ya ekran okuyucu kullanıcıları?

Hem gören hem de görmeyen kullanıcılara eşdeğer bir deneyim sunmak için iyi desteklenen aria-invalid özniteliğini kullanabiliriz. Kullanıcı girişe odaklandığında, artık ekran okuyucularda "Geçersiz" (veya benzeri) olarak bildirilecektir.

 <input aria-inval>

Not: Kayıt formu yalnızca metin girişlerinden oluşur. Bölüm 3, “Bir Uçuş Rezervasyon Formu”nda, radyo düğmeleri gibi alan grupları için erişilebilir bir şekilde hataların nasıl enjekte edileceğine bakacağız.

### Formu Tekrar Gönderme

Formu ikinci kez gönderirken, mevcut hataları görünümden temizlememiz gerekiyor. Aksi takdirde, kullanıcılar yinelenen hatalar görebilir.

 FormValidator.prototype.onSubmit = function(e) { this.resetPageTitle(); this.resetSummaryPanel(); this.removeInlineErrors(); if(!this.validate()) { e.preventDefault(); this.updatePageTitle(); this.showSummaryPanel(); this.showInlineErrors(); } };

### Başlatma

FormValidator bileşenini tanımlamayı bitirdikten sonra, şimdi onu başlatmaya hazırız. FormValidator örneğini oluşturmak için form öğesini ilk parametre olarak iletmeniz gerekir.

 var validator = new FormValidator(document.getElementById('registration'));

Örneğin, e-posta alanını doğrulamak için addValidator() yöntemini çağırın:

 validator.addValidator('email', [{ method: function(field) { return field.value.trim().length > 0; }, message: 'Enter your email address.' },{ method: function(field) { return (field.value.indexOf('@') > -1); }, message: 'Enter the 'at' symbol in the email address.' }]);

İlk parametre kontrolün name , ikincisi ise bir dizi kural nesnesidir. Her kural iki özellik içerir: method ve message . method , true veya false döndürmek için çeşitli koşulları test eden bir işlevdir. False, alanı, daha önce tartışıldığı gibi arayüzü hatalarla doldurmak için kullanılan bir hata durumuna sokar.

#### Önemsiz Hataları Affetmek

The Design of Everyday Things'de Don Norman hata için tasarlamaktan bahsediyor. İnsanların konuşma şekillerinden bahsediyor:

“Bir kişi yanlış olduğuna inandığımız bir şey söylerse, sorgular ve tartışırız. Bir uyarı sinyali vermiyoruz. Biz bip sesi çıkarmayız. Hata mesajları vermeyiz. […] İki arkadaş arasındaki normal konuşmalarda, yanlışlıklar, gerçekte kastedilenin yaklaşıkları olarak normal kabul edilir.”

İnsanlardan farklı olarak, makineler çoğu eylemin anlamını belirleyecek kadar zeki değiller, ancak çoğu zaman hatalarını olması gerekenden çok daha az bağışlıyorlar. Jared Spool, "Tasarım Metrik Olarak Karşıt mı?" bölümünde bununla ilgili bir şaka yapıyor. (yaklaşık 42 dakika):

"Bir telefon numarası almak ve tüm tireleri, parantezleri ve boşlukları çıkarmak için bir satır kod, içinde bıraktığınız bir hata mesajı yazmak için on satır kod gerekir."

addValidator yöntemi (yukarıda gösterilmiştir), önemsiz hataları affetmeleri için doğrulama kurallarının nasıl tasarlanacağını gösterir. Örneğin ilk kural, uzunluğunu kontrol etmeden önce değeri kırparak kullanıcı üzerindeki yükü azaltır.

### Canlı Satır İçi Doğrulama

Canlı satır içi doğrulama, kullanıcılara yazarken veya alandan çıktıklarında ( onblur ) geri bildirim verir. Canlı satır içi doğrulamanın, uzun formlarda doğruluğu artırdığını ve tamamlama sürelerini azalttığını gösteren bazı kanıtlar var. Bu kısmen, alanın gereksinimleri kullanıcıların zihninde taze olduğunda kullanıcılara geri bildirim vermekle ilgilidir. Ancak canlı satır içi doğrulama (veya kısaca canlı doğrulama) çeşitli sorunlar doğurur.

Belirli sayıda karakter gerektiren girişler için, ilk tuş vuruşu her zaman geçersiz bir giriş oluşturacaktır. Bu, kullanıcıların erkenden kesintiye uğrayacakları anlamına gelir; bu, bilgi girmekten düzeltmeye kadar zihinsel bağlamları değiştirmelerine neden olabilir.

Alternatif olarak, bir hata göstermeden önce kullanıcının yeterli sayıda karakter girmesini bekleyebiliriz. Ancak bu, kullanıcıların yalnızca doğru bir değer girdikten sonra geri bildirim alması anlamına gelir ki bu biraz anlamsızdır.

Kullanıcı alandan ayrılana kadar bekleyebilirdik ( onblur ), ancak kullanıcı bir sonraki alan için zihinsel olarak hazırlandığı (ve genellikle yazmaya başladığı) için bu çok geç. Ayrıca, bazı kullanıcılar bir formu kullanırken pencereleri değiştirir veya bir şifre yöneticisi kullanır. Bunu yapmak blur olayını tetikleyecek ve kullanıcının işini bitirmeden önce bir hatanın gösterilmesine neden olacaktır. Hepsi çok sinir bozucu.

Sayfa yenilemeden kullanıcılara geri bildirim vermenin sorun olmadığını unutmayın. Hata mesajlarını satır içi (alanların yanında) koymakla ilgili bir sorun da yok - bunu zaten yaptık. Canlı geri bildirimle ilgili sorun, kullanıcıları çok erken veya çok geç kesintiye uğratması ve bunun da genellikle sarsıcı bir deneyimle sonuçlanmasıdır.

Kullanıcılar sık ​​sık hata görüyorsa, muhtemelen başka bir yerde yanlış giden bir şeyler vardır. Formunuzu kısaltmaya ve daha iyi rehberlik sağlamaya odaklanın (iyi etiketleme ve ipucu metni). Bu şekilde kullanıcılar tek hatadan fazlasını görmemelidir. Bir sonraki bölümde daha uzun formlara bakacağız.

### Kontrol Listesi Olumlama Modeli

Canlı doğrulamanın bir varyasyonu, kullanıcı yazarken kuralları işaretlemeyi (bunları eksiksiz olarak işaretlemeyi) içerir. Bu, canlı doğrulamadan daha az müdahalecidir ancak her tür alan için uygun değildir. Parola alanı için bu tekniği kullanan MailChimp'in kayıt formunun bir örneğini burada bulabilirsiniz.

Kuralları alanın üstüne koymalısınız. Aksi takdirde ekran klavyesi geri bildirimi engelleyebilir. Sonuç olarak, kullanıcılar geri bildirimi kontrol etmek için yazmayı bırakıp klavyeyi gizleyebilir.

### Gönder Düğmelerini Devre Dışı Bırakma Üzerine Bir Not

Bazı formlar, tüm alanlar geçerli hale gelene kadar gönder düğmesini devre dışı bırakacak şekilde tasarlanmıştır. Bununla ilgili birkaç sorun var.

İlk olarak, kullanıcılar girişlerinde gerçekte neyin yanlış olduğunu merak ediyor. İkincisi, devre dışı bırakılan düğmeler odaklanabilir değildir, bu da görme engelli kullanıcılar tarafından Sekme tuşunu kullanarak gezinmeyi zorlaştırır. Üçüncüsü, devre dışı bırakılan düğmelerin grileştikleri için okunması zordur.

Kullanıcılara net geri bildirim sağladığımız için, kullanıcı beklediğinde, düğmeyi devre dışı bırakarak kontrolü kullanıcıdan almak için iyi bir neden yoktur.

### İyi Bir Hata Mesajı Oluşturma

İçerikten daha önemli bir şey yoktur. Kullanıcılar web sitenize tasarımın keyfini çıkarmak için gelmezler. Bir hizmeti kullanmanın içeriğinden veya sonucundan zevk almaya gelirler.

Hata mesajları oluşturmak için kullanılan kelimeleri görmezden gelirsek, en iyi düşünülmüş, kapsayıcı ve güzel tasarlanmış deneyim bile hiçbir şey ifade etmez. Bir çalışma, özel hata mesajlarının gösterilmesinin dönüşümleri %0,5 artırdığını ve bunun da yıllık gelirde 250.000 £'den fazlaya eşit olduğunu gösterdi.

“İçerik, kullanıcı deneyimidir.”
— Ginny Kırmızımsı

Etiketler, ipuçları ve diğer herhangi bir içerik gibi, iyi bir hata mesajı da mümkün olduğunca az kelimeyle netlik sağlar. Normalde, bir arayüzün tasarımını içeriğe dayalı olarak yürütmeliyiz - tam tersi değil. Ancak bu durumda, hata mesajlarını nasıl ve neden gösterdiğinizi anlamak, kelimelerin tasarımını etkiler. Bu nedenle Jared Spool, “içerik ve tasarım ayrılmaz iş ortaklarıdır” diyor.

Mesajları ekranın üst kısmındaki özette ve alanların yanında gösteriyoruz. Aynı mesajın iki versiyonunu sürdürmek, ikna edici olmayan bir kazanç için zor bir satıştır. Bunun yerine, her iki yerde de çalışan bir hata mesajı tasarlayın. “Bir 'at' sembolü girin” ifadesinin anlamlı olması için alan etiketindeki bağlam gerekir. “E-posta adresinizin bir 'at' sembolüne ihtiyacı var” her iki yerde de işe yarar.

Her hata mesajına "Lütfen" ile başlamak gibi hoş şeylerden kaçının. Bir yandan, bu kibar görünüyor; diğer yandan, araya giriyor ve bir seçim anlamına geliyor.

Hangi yaklaşımı seçerseniz seçin, içeriğin doğası gereği bir miktar tekrar olacaktır. Ve test etme genellikle herhangi bir bilgi girmeden formu göndermeyi içerir. Bu, tekrarı bariz bir şekilde açık hale getirir ve bu da aklımızı kaçırmamıza neden olabilir. Ama bu ne sıklıkla böyle? Çoğu kullanıcı arayüzü kırmaya çalışmıyor.

Farklı hatalar farklı biçimlendirme gerektirir. “Adınızı girin” gibi talimatlar doğaldır. Ancak "35 karakter veya daha kısa bir ad girin" ifadesi, "Adın 35 karakter veya daha az olması gerekir" gibi bir açıklamadan daha uzun, daha uzun ve daha az doğaldır.

İşte bir kontrol listesi:

• Özlü olun. Gerekenden fazla kelime kullanmayın, ancak netlik pahasına kelimeleri atlamayın.
• Tutarlı ol. Baştan sona aynı tonu, aynı kelimeleri ve aynı noktalama işaretlerini kullanın.
• Açık ol. Bir şeylerin neden yanlış gittiğini biliyorsanız, söyleyin. "E-posta geçersiz." belirsizdir ve yükü kullanıcıya yükler. “E-postanın bir 'at' sembolüne ihtiyacı var” açıktır.
• İnsan olun, jargondan kaçının. Geçersiz, yasak, zorunlu gibi kelimeler kullanmayın.
• Sade bir dil kullanın. Hata mesajları, markanızın mizahi ses tonunu tanıtmak için bir fırsat değildir.
• Aktif sesi kullanın. Bir hata bir talimat olduğunda ve kullanıcıya ne yapacağını söylediğinizde. Örneğin, “Ad girilmelidir” değil, “Adınızı girin”.
• Kullanıcıyı suçlamayın. Neyin yanlış gittiğini ve nasıl düzeltileceğini bilmelerini sağlayın.

## Özet

Bu bölümde, basit bir kayıt formunun çok ötesinde uygulanabilir olan birkaç temel form tasarımı sorununu çözdük. Pek çok açıdan, bu bölüm ne yapmamız gerektiği kadar ne yapmamamız gerektiğiyle ilgiliydi. Dahil ettiğimiz alanların sayısını azaltmaya odaklanmak için yeni ve yapay yerden tasarruf sağlayan modellerden kaçınarak, formları daha hoş hale getirirken aynı anda birkaç kullanılabilirlik hatasından kaçınıyoruz.

### Kaçınılması Gereken Şeyler

• Yer placeholder niteliğini, etiket ve ipucu metnini depolamak için bir mekanizma olarak kullanma.
• Yanlış giriş türleri kullanma.
• Stil düğmeleri ve bağlantılar aynı.
• Alanlar kullanıcı yazarken doğrulanıyor.
• Gönder düğmelerini devre dışı bırakma.
• Karmaşık jargon ve markadan etkilenen mikroskopi kullanma.

Ve bu kadar. Form Tasarım Kalıpları'nın bu ilk bölümünü beğendiyseniz, kitabı hemen edinebilirsiniz. Mutlu okumalar!