Web Sitesi Tasarımı ve Yazılımı
Kuzguncuk Web Tasarım — Karşılaştırma Tablolarını Küçük Ekranda Okunur Kılma
Veri tablolarında başlık-hücre ilişkisini kurun; mobilde tabloyu ayrı kaydırma alanında sunup gerçek kullanıcı görevleriyle sınayın.

Bir ziyaretçi iki hizmet paketini karşılaştırmak için web sayfasındaki tabloyu telefonda açıyor. Başlıklar görünümden çıkmış, satırdaki değerlerin hangi sütuna ait olduğu anlaşılmıyor. Sayfayı yakınlaştırınca bu kez satırın başına dönmek gerekiyor. Sorun yalnızca tablonun ekrana sığmaması değildir: bilgi ilişkisi, hareket alanı ve okuma bağlamı birlikte tasarlanmalıdır. Bu rehber, işletme sitelerinde anlam taşıyan karşılaştırma tablolarını planlama, küçük ekranda sunma ve kabul etme yöntemini anlatır. Belirli bir Kuzguncuk işletmesi, fiyatı veya sonucu varsaymaz. Örnekler genel web tasarım senaryolarıdır; erişilebilirlik uygunluğu ya da sertifikası garantisi vermez.
Önce gerçekten tablo gerekip gerekmediğini belirleyin
Her yan yana duran içerik veri tablosu değildir. Sayfa yerleşimini sütunlara bölmek için tablo kullanmak, küçük ekranda ve yardımcı teknolojilerde gereksiz karmaşa çıkarabilir. Önce hücreler arasında satır ve sütuna göre anlamlı bir karşılaştırma bulunup bulunmadığını sorun. Örneğin aynı ürün ailesindeki seçeneklerin teslim süresi, destek kapsamı ve dahil işler bakımından karşılaştırılması tabloya uygun olabilir. Her seçeneğin uzun açıklaması, görseli ve farklı çağrı düğmesi varsa ayrı kartlar daha rahat okunabilir.
İçerik sahibi tabloya girecek ölçütleri seçmelidir. Bir satırın neyi anlattığı, bir sütunun neyi karşılaştırdığı tek başına anlaşılabilmelidir. “Paket A, Paket B” gibi başlıklar gerçek karar ölçütünü saklıyorsa önce metni düzeltin. Hücreleri küçültmek, belirsiz bir karşılaştırmayı anlaşılır yapmaz. Kullanıcıdan beklenen işi yazın: seçenek farkını bulmak, bir satırdaki tutarı incelemek veya bir özelliğin hangi seçenekte bulunduğunu görmek. Tasarımın kabul ölçütü bu görev olmalıdır.
Başlıkları veri hücreleriyle ilişkilendirin
Görsel olarak kalın yazılmış ilk satır, tek başına yapısal sütun başlığı anlamına gelmez. W3C Web Erişilebilirlik Girişimi’nin tablolar rehberi, başlık hücreleri ile veri hücrelerinin sayfa yapısında ayrı işaretlenmesini ve ilişkilendirilmesini önerir. Sayfa işaretleme dili olan HTML’de th öğesi başlık hücresini, td öğesi veri hücresini belirtir. Basit tablolarda satır veya sütun başlığının yönünü doğru tanımlamak, ekran okuyucunun hücreyle başlık arasında bağ kurmasına yardım eder. Bu, yalnızca renk veya konumla anlam vermekten daha sağlamdır.
Bir tablo için kısa ve anlamlı bir açıklama başlığı verin. Kolon başlıklarını gerçek ölçütlerle adlandırın; “1. seçenek” gibi bağlamsız adlar yerine neyin karşılaştırıldığını açık edin. Satır başlığı varsa onu da başlık hücresi olarak tanımlayın. W3C’nin yönergeleri basit tablo ile birden fazla başlık katmanı olan karmaşık tabloyu ayırır. Bir üst başlık birkaç sütunu kapsıyor ya da satırlar gruplara ayrılıyorsa, başlık kapsamını teknik olarak ilişkilendirmek gerekebilir. Her tabloya karmaşık işaretleme eklemek yerine yapıyı önce sadeleştirmeyi değerlendirin.
Çok katmanlı yapıyı okunur hâle getirin
Bir tabloda bölüm başlığı, alt başlık ve satır başlığı birlikte bulunuyorsa hücreye hangi başlığın bağlam verdiğini kullanıcı da geliştirme ekibi de anlamalıdır. W3C WAI, düzensiz başlıklarda satır ve sütun gruplarını tanımlama, gerekirse başlıkları belirli veri hücrelerine açıkça bağlama örnekleri sunar. Bu örnekler her projede aynı kodu kopyalamak gerektiği anlamına gelmez. Tablo yapısı belirgin değilse sütunları ayırmak, ölçütleri farklı tablolar hâlinde sunmak veya içeriği listeye dönüştürmek daha anlaşılır olabilir.
Başlıklar çok uzunsa tümünü dar ekranda tekrar tekrar göstermek yerine kısa ama anlamı koruyan ifadeler kullanın. Kısaltma gerekiyorsa ilk kullanımda açıklayın. Sadece simgeyle gösterilen işaretler, renkli hücreler veya tik ve çarpılar, metinsel karşılıkları olmadan yorum yükünü ziyaretçiye bırakabilir. Değer bilinmiyorsa boş hücre bırakmak yerine “belirtilmedi” gibi tutarlı bir ifade seçin. “Uygulanamaz” ile “bilgi eksik” aynı şey değildir; bunları tek bir çizgi işaretiyle karıştırmayın.
Küçük ekranda tabloya kendi hareket alanını verin
W3C’nin yeniden akış açıklaması, veri tabloları gibi iki boyutlu içeriğin kendi içinde yatay kaydırılabilmesini örnek istisna olarak ele alır. Bu, bütün sayfayı sağa sola taşıran bir tasarımı gerekçelendirmez. Tabloyu çevreleyen metin ve düğmeler ekran genişliğine göre yerleşmeye devam ederken yalnız tablonun kendi alanı yatay hareket edebilir. Ziyaretçi parmağıyla bu alanı kaydırdığında tablo dışındaki başlık, açıklama ve gezinme öğeleri yerinden oynamamalıdır.
Dar ekranda ilk sütun sabitlenirse hangi seçeneğin satırda incelendiği akılda kalabilir; ancak sabit sütun diğer değerleri örtmemeli ve odakla okuma sırasını bozmamalıdır. Bu davranış tüm cihazlarda aynı varsayımla kabul edilmemelidir. Gerçek telefonlarda ve büyütme açıkken deneme yapın. Yatay kaydırmanın bulunduğunu yalnızca görsel tasarımdan anlamak zor olabilir; kısa bir açıklama veya tasarımın doğal kaydırma işareti yardımcı olabilir. Ziyaretçiye her değeri görmek için aşırı hassas bir hareket yaptırmayın.
Her tabloyu dar ekranda kartlara bölmek de otomatik çözüm değildir. Sütun başlıklarının her kartta tekrarlanması okunurluğu artırabilir, fakat satır-sütun karşılaştırmasını kaybettirebilir. Kullanıcının görevi tek bir seçeneğin ayrıntısını okumaksa kart görünümü işe yarayabilir. Birkaç seçeneği aynı ölçüte göre kıyaslamak gerekiyorsa tablo ilişkisini korumak daha doğru olabilir. Sunum biçimini görsel moda göre değil, karşılaştırma görevine göre seçin.
Bilgi kaybını ve yanlış kıyası test edin
Kabul testinde aynı gerçek veri setini geniş ve dar görünümde inceleyin. En uzun başlığı, en uzun hücreyi, boş veya bilinmeyen değeri ve en çok sütun içeren örneği seçin. Birinci sütundaki satır başlığı kaydırma boyunca anlaşılabiliyor mu? Sütun başlığı değerle birlikte takip edilebiliyor mu? Kullanıcı başlangıç konumuna döndüğünde hangi satırda olduğunu bulabiliyor mu? Yakınlaştırma yapıldığında başlıklar veya düğmeler kesiliyor mu? Bu sorulara ekran görüntüsünden değil, tabloyu gerçekten kullanarak yanıt verin.
Klavye ve ekran okuyucu denemelerini iki ayrı hareket modeliyle yapın. Tab tuşu statik tablo hücrelerinde durmaz; tablodaki bağlantı ve düğme gibi etkileşimli öğelere ilerler. Kaydırılabilir alanın klavyeyle kullanılabilmesi için uygulamada bu alanın erişilebilir biçimde odak alıp alamadığını ayrıca sınayın. Bu öğelerin odak çizgisi görünür mü, kaydırma alanına klavyeyle erişiliyor mu, alandan çıkış yolu anlaşılır mı? Ekran okuyucuda ise tablo gezinme komutlarıyla satır ve sütun başlığı ile hücre bağlamının duyulup duyulmadığını sınayın. Basit tablo ile çok katmanlı tabloyu ayrı deneyin. Otomatik araçlar bazı yapısal eksikleri işaretleyebilir; bir insanın gerçek hücre ilişkisini ve karşılaştırma görevini doğrulamasının yerini tutmaz. Deneme notunda kullanılan sayfa adresini, tabloyu, cihazı, görünüm boyutunu, tarayıcıyı, test eden kişiyi ve sonucu yazın. Bir sorun bulunursa hangi veri örneğinde çıktığını da kaydedin.
Tablonun çevresindeki açıklamayı hücrelerin içine sıkıştırmayın. Ölçümlerin hangi döneme veya birime göre verildiği, tablo başlamadan önce kısa ve görünür biçimde açıklanabilir. Kullanıcıya aynı tabloda para birimi, süre veya kapsam gibi farklı eksenler sunuluyorsa sütun başlığının hangi ekseni anlattığını açıkça yazın. Değerlerin hepsi sayısal görünse bile birim farkı gerçek kıyası değiştirebilir. Tabloda kullanılan kısaltmalar ve semboller için bir açıklama ekleyin; bu bilgi yalnız fare üzerine gelince görünen bir balona bağlı kalmamalıdır. Uzun tablolarda bir bölüm başlığıyla tabloyu parçalara ayırmak veya ölçütleri ayrı tablolar hâlinde sunmak, yatay hareket miktarını azaltabilir. Ancak bölme, aynı karşılaştırma grubunun bütünlüğünü bozuyorsa kullanıcının iki tablo arasında gidip gelmesi gerekebilir; bunu görev üzerinden deneyin.
İçerik güncellemelerini tasarım kararına bağlayın
Tablolar genellikle yeni satır ve sütunlarla değişir. İçerik ekibi bir ölçüt eklediğinde mobil görünüm taşabilir, anlamı belirsiz bir başlık ortaya çıkabilir veya ekran okuyucu ilişkisi eksik kalabilir. Yayın akışında tablo değişikliklerini ortak bileşen veya şablon değişikliği olarak işaretleyin. Yeni bir satır her zaman tüm sayfayı baştan sınamayı gerektirmez; fakat tablo başlık düzeni, sabit sütun, yatay kaydırma alanı veya sütun sayısı değiştiyse ilgili senaryoyu yeniden çalıştırın.
Tasarım tesliminde tablonun sahibi, içerik ölçütlerinin sahibi ve teknik kabul sorumlusu belli olsun. Başlıkların kim tarafından değiştirilebileceğini, bilinmeyen değerin nasıl gösterileceğini ve yeni ölçüt eklenince kimden onay alınacağını açıklayın. İçerik yönetim sistemi tablo araçları sunuyorsa bu araçların başlık hücresi oluşturup oluşturmadığını gerçek bir taslakla deneyin. Ekip HTML koduna erişemiyorsa geliştiriciden yayınlanan kaynak yapıyı doğrulamasını isteyin. Yalnız yönetim panelindeki görsel editöre güvenerek yapının doğru olduğunu varsaymayın.
Kararı görünür kabul ölçütüyle tamamlayın
İyi bir tablo, geniş ekranda hizalı göründüğü için değil, kullanıcı karşılaştırmayı doğru tamamlayabildiği için başarılıdır. Bir kabul notunda tablo amacı, başlık-hücre ilişkisi, mobil görünüm, kaydırma davranışı, klavye/ekran okuyucu denemesi, bilinmeyen değer sunumu ve açık kalan sorunları birlikte kaydedin. W3C’nin açıklayıcı rehberleri tasarım ve uygulama kararlarına yardımcı olur; tek bir örneğin incelenmesi bütün sayfanın veya sitenin tüm ölçütlere uyduğunu kanıtlamaz. Sonuç, yalnız gerçekten denenen tablolar ve senaryolar için yazılmalıdır.
Web tasarım hizmeti, mobil uyum ve genel erişilebilirlik başlangıcı için ilgili rehberlere de bakabilirsiniz: Web Tasarım hizmetini inceleyin, küçük ekranda gerçek kullanım testini, web erişilebilirliği kontrollerini ve ekran ile yazdırma görünümünün ayrımını okuyun.
Sık Sorulan Sorular
Karşılaştırma içeriğini her zaman tablo olarak mı sunmalıyım?
Hayır. Aynı satır ve sütun ölçütleri üzerinden gerçek bir kıyas gerekiyorsa tablo yararlı olabilir. Her seçeneğin uzun açıklaması, görseli ve farklı işlem düğmesi varsa kartlar ya da ayrı bölümler daha kolay izlenebilir. Biçimi, ziyaretçinin yapacağı işe göre belirleyin.
Mobilde tabloyu tamamen kartlara çevirmek daha erişilebilir mi?
Her durumda değil. Kartlar seçenek ayrıntısını tek tek okumayı kolaylaştırabilir, fakat sütunlar arasındaki doğrudan karşılaştırmayı zorlaştırabilir. Kullanıcı aynı ölçütü birkaç seçenek arasında karşılaştıracaksa tablo ilişkisini koruyan, kendi içinde kaydırılabilen bir alan uygun olabilir.
Tabloda kalın başlık yazmak ekran okuyucu için yeterli olur mu?
Görsel kalınlık tek başına hücrenin başlık olduğunu yapısal olarak belirtmez. Başlık ve veri hücreleri doğru işaretlenmeli, gerekiyorsa satır veya sütun yönü açıklanmalıdır. Geliştirme ekibi, kullanılan içerik aracının gerçekten bu yapıyı üretip üretmediğini kontrol etmelidir.
Bir başlık birden fazla sütuna yayılıyorsa ne yapmalıyım?
Önce yapının kullanıcıya gerekli olup olmadığını sorgulayın; birden fazla tabloya bölmek daha anlaşılır olabilir. Birden çok başlık katmanı korunacaksa gruplar ve veri hücreleri arasındaki ilişki açık tanımlanmalı, karmaşık örnek hem kaynak yapıda hem ekran okuyucu ile denenmelidir.
Yatay kaydırma erişilebilirliği bozmaz mı?
Tek başına bozduğu söylenemez. W3C’nin yeniden akış açıklaması, iki boyutlu anlam taşıyan veri tablolarını sayfanın geri kalanından ayrı kaydırılabilir alan içinde sunmayı örnek verir. Uygulamada çevredeki içerik ekrana sığmalı ve kullanıcı kaydırma alanını bulup kullanabilmelidir.
Sütun başlıklarını kaydırırken sabit tutmak zorunlu mudur?
Hayır. Sabitleme tabloyu anlamayı kolaylaştırabilir, ancak dar ekranda veri hücrelerini örtüyorsa veya odak sırasını bozuyorsa yeni bir engel oluşturur. Sabit başlık kararını cihaz, yakınlaştırma ve uzun veri örneğiyle test ederek verin.
Tablodaki boş değerleri nasıl göstermeliyim?
Önce boşluğun ne anlama geldiğini belirleyin: bilgi henüz girilmemiş mi, ilgili değil mi, yoksa değer sıfır mı? Bunları aynı işaretle göstermeyin. Kısa metin açıklaması kullanın ve gerekiyorsa tablo öncesinde işaretlerin anlamını anlatın.
Otomatik erişilebilirlik taraması tabloyu onaylamak için yeterli midir?
Hayır. Otomatik kontrol bazı işaretleme ve kontrast sorunlarını gösterebilir; tablonun okuyucunun gerçek karşılaştırma görevini desteklediğini tek başına doğrulamaz. Temsilî satırları klavye ve ekran okuyucu ile inceleyin, kullanılan senaryoyu ve sınırlamaları kabul kaydında belirtin.