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

Mobilde Akordeon: Geri Tuşu, Kapatma ve Erişilebilirlik

Mobil akordeon tasarımında sık atlanan ayrıntılar

Akordeon, mobilde uzun içeriği katlayıp sayfayı kısaltmanın en pratik yolu. Peki kısalan gerçekten sayfa mı, yoksa içeriğin okunma ihtimali mi? Katlanan her bölüm kullanıcıya bir tıklama borcu yazıyor ve bu borcun karşılığını verip vermediği, akordeonun işe yarayıp yaramadığını belirliyor.

Katlamak neyi çözer, neyi erteler

Kazancı açık: başlıklar üst üste dizilince kullanıcı sayfada ne olduğunu tek bakışta görür, ilgilenmediği bölümü kaydırmak zorunda kalmaz. Uzun bir form adımlara bölündüğünde tamamlanma da genelde iyileşir.

Ertelediği şey ise şu: katlanan içerik okunmayan içeriğe dönüşür. Kullanıcı başlığa bakıp içeride ne olduğunu kestiremiyorsa açmaz. Bu yüzden akordeon başlığı bir etiket değil, bir vaat olmalı. "Kargo" yerine "Kargo ne zaman çıkar, kaç günde ulaşır" yazan başlık daha çok açılır, çünkü açtığında ne bulacağını söyler.

Peki bilgi kullanıcının kararı için gerekliyse? O zaman katlamayın. Fiyata neyin dahil olduğunu akordeonun arkasına koymak sayfayı derli toplu gösterir, satın alma kararını zorlaştırır.

Geri tuşu tuzağı

Sık verilen tavsiyelerden biri, akordeon açılışını tarayıcı geçmişine bağlamak: kullanıcı geri tuşuna basınca sayfadan çıkmak yerine açık bölüm kapansın. Kulağa mantıklı geliyor, çünkü açılan bölüm ekranın üstüne taşındığında insan gerçekten yeni bir sayfaya geçmiş gibi hissediyor.

Ama her açılış geçmişe bir kayıt bırakıyorsa maliyeti de sayın: beş bölüm açan kullanıcı sayfadan çıkmak için geri tuşuna altı kez basacak. Bunu bir SSS sayfasında tam olarak böyle gördüm, çıkamayan kullanıcılar sekmeyi kapatıyordu.

Makul orta yol, geçmişe yalnızca ilk açılışı yazmak (sonraki açılışları history.replaceState ile aynı kaydın üzerine bindirirsiniz) ve geri tuşunda açık bölümlerin hepsini birden kapatmak. Böylece geri tuşu "listeye dön" anlamına gelir, "son tıklamayı geri al" anlamına değil.

Açılan bölümden çıkmak

Uzun bir bölüm açıldığında kapatma noktası ekranın epey yukarısında kalır. İki çözüm var, ikisi de ucuz. Başlığı position: sticky ile yapışkan yapmak kullanıcıya her an aynı yerde bir kapatma noktası verir. İkincisi, bölümün sonuna da bir kapatma bağlantısı koymak; yapışkan başlık kadar zarif değil ama mobilde en az onun kadar iş görüyor.

Etiket metni de sanıldığından fazla iş görür. "Kapat" mı "Daralt" mı daha anlaşılır diye tartışmak yerine ok ikonunu döndürüp durumu görselleştirin; kullanıcı kelimeyi okumadan hangisinin açık olduğunu görür.

Erişilebilirlikte doğru öznitelikler

Bu konuda dolaşan listeler çoğu zaman yanlış özniteliği gösteriyor. Akordeon başlığında aranan şey aria-label ya da tabindex değil. Başlığın içine gerçek bir button koyun; klavye erişimi, odak sırası ve Enter ile boşluk tuşu davranışı hazır gelir, tabindex yazmanıza gerek kalmaz. Butona aria-expanded ekleyin (açıkken true, kapalıyken false), açılan panelin id değerini de aria-controls ile gösterin. Ekran okuyucu bu ikisi olmadan bölümün açık mı kapalı mı olduğunu söyleyemiyor.

Panel gizlenirken display: none ya da hidden kullanın. Yükseklik sıfırlanıp içerik ağaçta kalırsa ekran okuyucu kapalı bölümü okumaya devam eder; görsel kullanıcıyla sesli kullanıcı farklı sayfalarda dolaşır.

Arama motorları ve varsayılan açık bölüm

Kapalı akordeon içeriğinin taranması artık tartışma konusu değil. Başlık hiyerarşisini bozmamak yeterli: akordeon başlıkları h2 ya da h3 olsun, buton başlığın içine girsin, dışına değil.

Sayfa açıldığında bir bölümün açık gelip gelmemesi konusunda iki uç tavsiye dolaşıyor. İlk bölümü açık bırakmak genelde kazandırıyor, çünkü kullanıcıya panellerin içinde ne tür bir içerik olduğunu gösterir. Hepsini açık başlatmak ise akordeonu anlamsız kılar; sayfa yine uzun açılır, üstüne bir de kapatma işi çıkar.