Konu Başlıkları
Yükleniyor...

Mobil Uygulama Kullanılabilirliği: Kılavuzda İşe Yarayan Maddeler

Mobil Kullanılabilirlik: Dokunma Hedefi, Kontrast ve Form Ayarları

Google'ın mobil kullanılabilirlik kılavuzu uzun bir liste ama maddelerinin çoğu zaten yaptığınız şeyler. Fark yaratan yerler dar: dokunma hedefinin fiziksel boyutu, formun hata verme anı, bağlantının renk dışında bir işareti olup olmadığı. Listenin kendi içinde çelişen bir maddesi de var.

Dokunma hedefi bir stil tercihi değil

Material'ın 48dp kuralı keyfi bir sayı değil, parmak ucunun ekranda kapladığı alandan geliyor. 48dp, ekran yoğunluğu ne olursa olsun yaklaşık 9 milimetreye denk gelir. Butonun görünen boyutu daha küçük olabilir, sorun olan görünen boyut değil dokunulabilir alanın küçüklüğü.

Kodda kontrolü kolay: 24dp'lik bir ikonun etrafına 12dp padding koyup hedefi 48dp'ye tamamlayın, iki hedef arasında en az 8dp boşluk bırakın. iOS tarafında karşılığı 44pt. Bu sayılar tasarım dosyasında değil çalışan uygulamada ölçülür; Android'de Layout Inspector, iOS'ta view debugger yeter.

Yazı boyutu tek başına okunabilirlik demek değil

Listelerde sık geçen 11 punto ve üzeri tavsiyesi mobilde yanlış birime bakıyor. Android'de metni sp ile verirsiniz ve sp, kullanıcının sistemdeki yazı tipi ölçeğine bağlıdır. Boyutu dp veya px ile sabitlerseniz, sistem ayarından yazıyı büyütmüş bir kullanıcı için hiçbir şey değişmez.

İkinci sayı kontrast: normal metinde 4.5:1, 18pt ve üzerinde (ya da 14pt kalında) 3:1. Bunlar WCAG eşikleri, otomatik ölçülür, açık gri üstüne biraz daha koyu gri koyan her ekran burada düşer.

Altı çizili bağlantı tavsiyesi kendi içinde çelişiyor

Aynı listede iki madde yan yana durur: altı çizili klasik bağlantı stilinden kaçının, ve ekran okuyucularla uyumlu geliştirin. İkincisi bu konuda zaten sorun değil, ekran okuyucu bağlantıyı rolüyle duyurur, alt çizgiyle işi yoktur. Sorun gören ama rengi ayırt edemeyen kullanıcıda çıkıyor: bağlantıyı yalnızca renkle işaretlediğinizde WCAG'nin 1.4.1 maddesini, yani bilgiyi tek başına renkle taşıma yasağını çiğniyorsunuz.

Alt çizgiyi kaldıracaksanız yerine başka bir işaret koyun: ikon ekleyin, ağırlığı artırın ya da öğeyi tamamen butona çevirin. Bir haber uygulamasında metin içi bağlantıların altını kaldırmıştık, birkaç gün sonra destek kutusuna mavi yazılar tıklanmıyor diye kayıtlar düşmeye başladı; tıklanıyorlardı, kimse tıklanabilir olduklarını fark etmiyordu.

Formda asıl sorun zamanlama

Hata mesajını kullanıcı yazarken değil, alandan çıkınca gösterin. Yazarken doğrulama, e-posta adresinin üçüncü harfinde kırmızı uyarı vermek demektir. Mesaj alanın hemen altında ve metinle olsun; kırmızı çerçeve tek başına yine 1.4.1 problemi.

Klavye tipini alana göre ayarlayın, inputmode ve autocomplete niteliklerini doldurun, adres ve kart alanlarında tarayıcının otomatik doldurmasına izin verin. Kart ve şifre alanlarında iki iş birbirine karışıyor: alanı kolay doldurulur yapmak tasarım işi, veriyi taşımak ve saklamak sunucu işi. İkisini aynı kefeye koyan ekipler tokenizasyonu atlayıp formun altına güvenlik rozeti koymakla yetiniyor.

Neye bakılacak

Kılavuza uymak testin yerine geçmez. Uygulama içinde izlenecek birkaç somut şey var: aynı noktaya art arda yapılan dokunuşlar, yani kullanıcının tıklanabilir sandığı bir şeye vurması; form alanlarında ileri gidip geri dönmeler; ilk açılıştan ilk anlamlı işleme kadar geçen süre. Bunlar analitikten çıkar. Kullanıcı görüşmesi de gerekir ama başka bir soruya cevap verir, bu üçünün yerini tutmaz.

Güncel kalmak için Google Material ve Material Design Accessibility kılavuzları yeterli.