Mobil Uyumlu Tablo Nasıl Tasarlanır? Kaydırma, Kart ve Erişilebilirlik

Mobil uyumlu tablo, telefonda da okunabilen ve kullanılabilen veri tablosudur. Bu rehberde Talha Aslan ve ekibi olarak sahada en çok kullandığımız yöntemleri anlatıyoruz: yatay kaydırma, sabit ilk sütun, kart görünümüne dönüştürme ve erişilebilir başlıklar. Ayrıca her yöntemin hangi veri tipine uyduğunu, nasıl test edeceğinizi ve yayından önce neyi kontrol etmeniz gerektiğini adım adım göreceksiniz.

Kısacası tek bir doğru çözüm yok. Karşılaştırma yapılan veri, yan yana durmak ister; kayıt listesi ise kart halinde daha rahat akar. Bu yüzden yönteme karar vermeden önce okurun tabloda ne aradığını anlamanız gerekir. Aşağıdaki bölümler bu kararı adım adım vermenize yardım edecek.

Tablolar mobilde neden bozulur?

Masaüstünde rahat duran bir tablo, telefonda genellikle üç tipik soruna yol açar. İlk olarak sütunlar sayfa genişliğini aşar ve tüm sayfa yana kayar. Ardından hücreler daralır, kelimeler harf harf alt satıra iner. Son olarak başlık satırı ekrandan çıkar ve okur hangi sayının neyi anlattığını unutur.

• Taşma: Tablo, sayfanın geri kalanını da yatay kaydırmaya zorlar.
• Sıkışma: Her sütuna eşit pay düşer, uzun metni okumak imkânsızlaşır.
• Bağlam kaybı: Başlıklar ve ilk sütun ekrandan çıkınca hücreler anlamsızlaşır.
• Dokunma sorunu: Hücre içindeki bağlantı ve düğmeler parmakla seçilemeyecek kadar küçük kalır.

Öte yandan sorun yalnız görsel değil. Tabloyu div kutularıyla taklit eden şablonlar, ekran okuyucular için satır ve sütun ilişkisini tamamen siler. Dolayısıyla mobil sorunu çözerken yapıyı bozmamak da en az görünüm kadar önemlidir.

Önce tabloya gerçekten ihtiyacınız var mı?

Her tablo, tablo olmak zorunda değil. İki sütunlu bir "özellik ve açıklama" listesi, telefonda tanım listesi ya da başlıklı paragraflar olarak çok daha rahat akar. Benzer şekilde tek satırlık bir fiyat bilgisi için tablo kurmak gereksiz karmaşa yaratır.

Tablo, verinin iki yönlü bir ilişkisi olduğunda gerçekten gereklidir. Örneğin üç paketin beş özelliğini karşılaştırırken okur hem satır hem sütun boyunca okur. Böyle bir durumda tabloyu kaldırmak yerine onu dar ekrana uyarlarsınız. Kısaca sormanız gereken soru şudur: okur bu veriyi karşılaştırıyor mu, yoksa sadece okuyor mu?

Bu kararı genellikle sayfa planlamasında verirsiniz, tasarım bittikten sonra değil. Mobil öncelikli tasarım yaklaşımında içeriği önce dar ekran için kurgularsınız; böylece tablo ihtiyacı daha baştan netleşir. Sitenizde veri yoğun sayfalar varsa, bu planlamayı web tasarım hizmetimiz kapsamında birlikte yapabilir, size uygun bir teklif hazırlayabiliriz.

Mobil uyumlu tablo için hangi yöntem ne zaman seçilir?

Yöntem seçimini verinin yapısı belirler. Aşağıdaki karşılaştırma, sahada en sık karşılaştığımız dört yaklaşımı özetliyor. Ancak tablo bir başlangıç noktasıdır; kendi verinizle mutlaka deneyin.

Pratikte bu yöntemleri birleştiririz. Örneğin yatay kaydırma ile sabit ilk sütun çoğu zaman birlikte çalışır. Kart görünümü ise sütun sayısı fazla ama satırlar birbirinden bağımsız olduğunda öne çıkar.

Yatay kaydırma doğru nasıl kurulur?

Yatay kaydırmanın temel kuralı şudur: tablo kayar, sayfa kaymaz. Bunun için tabloyu bir sarmalayıcı kutunun içine koyarsınız ve yalnız o kutuya yatay taşma izni verirsiniz. Böylece başlıklar, paragraflar ve menü normal genişlikte kalır.

W3C'nin yeniden akış (reflow) başarı ölçütü bu noktada önemli bir ayrıntı veriyor. Ölçüt, içeriğin 320 CSS piksel genişlikte iki yönlü kaydırma gerektirmeden çalışmasını ister; fakat veri tablolarını istisna sayar, çünkü tablo anlamını iki boyutlu düzenden alır. Yine de tablonun etrafındaki başlık, arama alanı ve sayfalama gibi içerik bu istisnaya girmez.

1. Tabloyu kendine ait bir kaydırma kutusuna alın.
2. Hücrelere makul bir en küçük genişlik verin ki kelimeler harf harf alt satıra kaymasın.
3. Kaydırılabilir içeriğin varlığını görsel olarak belli edin: kesik son sütun, gölge ya da kısa bir not işe yarar.
4. Sayfanın geri kalanının 320 piksel genişlikte taşmadığını kontrol edin.

Bu sayede okur tabloyla çalışırken sayfanın kendisi sabit kalır. Ayrıca sayfa genelindeki kaydırma ritmini bozmamak için scroll deneyimi rehberimize de göz atabilirsiniz.

Kaydırılabilir tablo alanını herkes için kullanılabilir yapmak

Parmakla kaydırmak kolaydır; ancak klavye kullanan biri için kaydırma kutusu çoğu zaman erişilemez kalır. Kutunun içinde odaklanabilir bir bağlantı yoksa, okur sekme tuşuyla oraya gidemez ve yana kaydıramaz. Bu yüzden kaydırma kutusunu odaklanabilir yapmanız gerekir.

Uygulamada kutuya tabindex değeri sıfır verirsiniz, ona bir bölge rolü atarsınız ve kısa bir etiket eklersiniz; örneğin "Paket karşılaştırması, yana kaydırılabilir". Böylece ekran okuyucu bu alanın ne olduğunu duyurur, klavye kullanıcısı da ok tuşlarıyla kaydırabilir. Odak geldiğinde belirgin bir çerçeve göstermeyi de unutmayın.

• Kaydırma kutusu klavyeyle odak alabiliyor mu?
• Odaklandığında belirgin bir çerçeve çıkıyor mu?
• Kutunun etiketi tablonun konusunu anlatıyor mu?
• Kaydırma ipucu yalnız renge değil, metne de dayanıyor mu?

Bu ayrıntılar küçük gibi durur; fakat erişilebilirlik denetimlerinde en sık atlanan noktalardandır. Genel çerçeve için WCAG standartları rehberimiz iyi bir başlangıç sunar.

Sabit ilk sütun nasıl çalışır?

Sabit ilk sütun, okur tabloyu yana kaydırırken satır adlarının yerinde kalmasını sağlar. Örneğin bir paket karşılaştırmasında "Aylık rapor" satırı sola yapışık kalır, okur sağa kaydırdıkça paketlerin değerlerini o satırla eşleştirir. Böylece bağlam hiç kaybolmaz.

Bunu CSS'teki yapışkan konumlandırma ile kurarsınız. MDN'nin position belgesine göre yapışkan öğe konumunu en yakın kaydırma atasına göre belirler ve çalışması için en az bir eşik değeri (örneğin sol kenar için sıfır) gerekir. Eşik vermezseniz öğe normal göreli konumdan farksız kalır. Ayrıca araya taşma ayarı olan başka bir kutu girerse, sütun yanlış kutuya yapışabilir.

1. İlk sütundaki hücrelere yapışkan konum ve sol kenar eşiği verin.
2. Sabit hücreye opak bir arka plan rengi verin; aksi halde alttan kayan metin üstüne biner.
3. Sabit sütunun sağına ince bir gölge ya da çizgi ekleyin ki ayrım belli olsun.
4. İlk sütunun genişliğini sınırlayın; dar ekranda ekranın üçte birini geçmemesi iyi bir hedeftir.

Yine de sabit sütunu her tabloya eklemeyin. İlk sütun çok uzun metin içeriyorsa, sabitlemek geriye veri için yer bırakmaz. Bu durumda kısa satır adı ya da kart görünümü daha iyi sonuç verir.

Sabit başlık satırı ne zaman işe yarar?

Uzun tablolarda okur aşağı indikçe sütun başlıklarını unutur. Sabit başlık satırı bu sorunu çözer; başlıklar ekranın üstünde kalır ve her satır hangi sütuna ait olduğunu belli eder. Özellikle onlarca satırlık sipariş, stok ya da ders programı tablolarında fark çok belirgindir.

Ancak burada sık yapılan bir hata var. Sitenizde zaten yapışkan bir üst menü varsa, tablo başlığı menünün altına girer ve kaybolur. Bu yüzden tablo başlığının eşik değerini menünün yüksekliğine göre ayarlamanız gerekir. Yapışkan menülerin etkisini sticky header yazımızda ayrıca ele aldık.

Dahası, hem başlık satırı hem ilk sütun yapışkan olduğunda sol üst köşedeki hücre iki yönde de sabit kalmalıdır. Bu hücreye diğerlerinden daha yüksek bir katman sırası verirsiniz. Böylece kaydırma sırasında hücreler üst üste binmez. Kısa tablolarda ise sabit başlık gereksizdir; on satırın altındaki tabloda çoğu zaman eklemeyiz.

Tabloyu kart görünümüne dönüştürmek ne zaman doğru?

Kart görünümünde her satır, dar ekranda kendi kutusuna dönüşür. Başlıklar her değerin yanına etiket olarak gelir; örneğin "Sipariş no", "Tarih", "Tutar" ve "Durum" bir kartın içinde alt alta yer alır. Okur yana kaydırmaz, yalnız aşağı iner.

Bu yöntem satırların birbirinden bağımsız olduğu verilerde parlıyor. Sipariş geçmişi, ilan listesi, etkinlik takvimi ve randevu listesi tipik örneklerdir. Okur burada satırları karşılaştırmaz; belirli bir kaydı bulup ayrıntısına bakar. Dolayısıyla dikey kart düzeni, telefondaki doğal okuma alışkanlığına uyar.

Öte yandan karşılaştırma tablolarında kart görünümü işe yaramaz. Üç paketi beş özellikte karşılaştırırken kartlar okuru ileri geri kaydırmaya zorlar, çünkü aynı özelliği farklı kartlarda araması gerekir. Bu nedenle karar şöyle özetlenebilir: satırlar arası karşılaştırma varsa kaydırma ve sabit sütun, bağımsız kayıtlar varsa kart.

• Satırlar bağımsız mı? Kart görünümü uygun.
• Okur sütun sütun karşılaştırıyor mu? Yatay kaydırma uygun.
• Satır adı her şeyin anahtarı mı? Sabit ilk sütun ekleyin.

Kart görünümünde etiketler nereden gelir?

Kart görünümünde her değerin yanında bir etiket yazmalı; aksi halde okur "12.03" yazısının tarih mi tutar mı olduğunu anlayamaz. En yaygın yöntem, her hücreye kendi sütun başlığını bir veri özniteliği olarak eklemektir. Örneğin "Tarih" sütunundaki her hücre data-label özniteliğinde "Tarih" değerini taşır.

Ardından dar ekranda CSS bu özniteliği okur ve hücrenin önüne etiket olarak yazar. Böylece ayrı bir mobil tablo üretmeniz gerekmez; aynı HTML iki farklı düzende çalışır. Ancak etiketleri elle yazmak hataya açıktır. Bu yüzden içerik yönetim sisteminde ya da şablonda başlıkları otomatik kopyalayan bir yapı kurmanızı öneririz.

Burada dikkat edilmesi gereken önemli bir nokta var. Tablo öğelerinin görüntüleme biçimini değiştirdiğinizde, bazı tarayıcı ve ekran okuyucu ikilileri tablo anlamını kaybedebilir. Bu nedenle kart düzenine geçen tabloyu mutlaka bir ekran okuyucuyla test edin. Gerekirse satır, hücre ve başlık rollerini açıkça tanımlayarak anlamı geri kazandırırsınız.

Erişilebilir tablo başlıkları nasıl kodlanır?

Erişilebilir tablonun temeli doğru hücre tipidir. W3C WAI tablo rehberi, başlık hücrelerinin th, veri hücrelerinin td ile işaretlenmesini ister. Ekran okuyucu bir hücreye geldiğinde ona bağlı başlığı da okur; okur bu sayede "Pro paket, aylık rapor, var" gibi anlamlı bir cümle duyar.

Başlığın yönü belirsiz olduğunda scope özniteliği devreye girer. Sütun başlığı için col, satır başlığı için row değerini kullanırsınız. Birden fazla sütunu kapsayan grup başlığında colgroup, birden fazla satırı kapsayanda rowgroup değeri gerekir. MDN'nin tablo erişilebilirliği sayfası çok katmanlı başlıklarda id ve headers eşleştirmesini de anlatır; fakat bunun çok daha fazla işaretleme istediğini, çoğu durumda scope'un yettiğini belirtir.

1. Tablonun ilk satırını thead içine alın, hücreleri th yapın.
2. Satır adlarını içeren ilk sütunu da th yapın ve row kapsamı verin.
3. Birden fazla sütunu kapsayan başlık hücrelerinde grup kapsamını kullanın.
4. Boş başlık hücresi bırakmayın; köşe hücresine bile kısa bir ad yazın.

Bu yapı aynı zamanda WCAG'nin bilgi ve ilişkiler ölçütüne de hizmet eder. Görsel olarak anlatılan ilişki, yazılım tarafından da okunabilir hale gelir.

Tablo başlığı (caption) ve açıklama metni

Caption, tablonun konusunu anlatan ve ekranda yer alan başlıktır ve tablonun hemen ilk öğesi olarak gelir. MDN, ekran okuyucu kullanıcılarının bu başlığa bakarak tabloyu okuyup okumamaya karar verdiğini belirtir. Dolayısıyla caption, onlarca hücreyi tek tek dinlemekten kurtaran bir kısayoldur.

Mobilde caption'ın bir faydası daha var. Telefonda tablo çoğu zaman ekranı tamamen kaplar ve okur yukarıdaki ara başlığı göremez. Tablonun hemen üstündeki kısa ve net bir caption, "neye bakıyorum?" sorusunu anında yanıtlar. Örneğin "Paketlere göre aylık hizmet kapsamı" gibi bir ifade yeterlidir.

Karmaşık tablolarda caption'ın altına bir cümlelik okuma notu da ekleyebilirsiniz: "Tabloyu sağa kaydırarak tüm paketleri görebilirsiniz." gibi. Ancak eski summary özniteliğini kullanmayın; MDN bu özniteliğin kullanımdan kalktığını ve gören kullanıcılara hiç görünmediğini hatırlatır. Kısacası açıklamayı herkesin görebileceği metin olarak yazın.

Sütun önceliği ve aç kapa sütunlar

Bazı tablolarda her sütun aynı derecede önemli değildir. Bir ürün listesinde ad, fiyat ve stok durumu ana bilgidir; ağırlık, ölçü ve barkod ise ikincil kalabilir. Sütun önceliği yönteminde dar ekranda yalnız ana sütunları gösterir, ikincil olanları okurun isteğine bırakırsınız.

Ancak sütunu tamamen gizlemek risklidir. Okur o verinin var olduğunu bilmezse onu hiç aramaz. Bu yüzden gizlenen sütunlar için mutlaka belirgin bir kontrol koyun: "Tüm sütunları göster" düğmesi ya da sütun seçme menüsü gibi. Ayrıca bu düğmenin durumunu ekran okuyuculara da bildirin.

• Ana sütunları kullanıcı araştırmasıyla ya da destek taleplerinden belirleyin.
• Gizlenen sütunu tamamen silmeyin; yalnız görünürlüğünü değiştirin.
• Seçilen sütunları sayfa yenilense bile hatırlamayı düşünün.
• Arama motoru ve ekran okuyucu için verinin HTML içinde kalmasına özen gösterin.

Böylece hem sade bir ekran hem de verinin tamamına ulaşma imkânı sunarsınız. Bu yaklaşım özellikle yönetim panellerinde ve uzun ürün kataloglarında işe yarar.

Sayılar, birimler ve hücre içeriği mobilde nasıl okunaklı olur?

Dar ekranda her karakter değerlidir. Bu yüzden hücre içeriğini sadeleştirmek, tablo düzeninden bile daha büyük fark yaratabilir. Örneğin her hücrede "TL" yazmak yerine birimi sütun başlığına taşırsınız: "Tutar (TL)" gibi. Böylece hücre yalnız sayıyı taşır.

• Sayıları sağa hizalayın; basamaklar alt alta gelince karşılaştırma kolaylaşır.
• Metinleri sola hizalayın, ortalamayın.
• Eşit genişlikli rakam ayarını açın ki sayılar titremesin.
• Uzun metni hücre içinde iki satırla sınırlayın, ayrıntıyı bağlantıya taşıyın.
• Var ve yok bilgisini yalnız simgeyle değil, metinle de verin.

Renk konusu da önemlidir. "Kırmızı hücre stok yok demek" gibi yalnız renge dayanan anlatım, renk ayırt edemeyen okur için bilgi kaybıdır. Bu nedenle durumu bir kelimeyle de yazın. Metin ile arka plan arasındaki farkı ayarlarken kontrast rehberimizdeki ilkeleri uygulayabilirsiniz. Son olarak satırları ayırmak için zebra deseni yerine ince çizgiler kullanmak, küçük ekranda daha temiz bir görünüm verir.

Dokunma, yakınlaştırma ve tablo içi etkileşim

Tablo hücrelerinde bağlantı, düğme ya da onay kutusu varsa, mobilde parmakla seçilebilir olmaları gerekir. Sıkışık hücrelerde iki bağlantı yan yana durursa okur sık sık yanlış olana basar. Bu yüzden etkileşimli öğelere yeterli iç boşluk verir, aralarına mesafe koyarsınız.

Yakınlaştırmayı engellemek de yaygın bir hatadır. Bazı şablonlar, tablo düzenini korumak için sayfanın yakınlaştırılmasını kapatır. Oysa küçük yazıyı okumak isteyen kullanıcı için yakınlaştırma en temel araçtır. Dolayısıyla yakınlaştırmayı kapatmak yerine tabloyu yakınlaştırmaya dayanıklı kurmalısınız.

Ayrıca tablo içindeki önemli eylemleri ekranın erişilebilir bölgesine yerleştirmek işinizi kolaylaştırır. Örneğin satır sonundaki "Detay" düğmesi, yana kaydırdığınız bir tablonun en sağında kalırsa okur onu hiç görmeyebilir. Bu durumda düğmeyi ilk sütuna yakın tutarsınız. Başparmakla rahat ulaşılan alanları thumb zone yazımızda ayrıntılı anlattık.

Örnek senaryo: hizmet paketi karşılaştırma tablosu

Örnek senaryo olarak üç paketli bir hizmet sayfası düşünelim. Masaüstünde dört sütun var: özellik adı ve üç paket. Telefonda ise bu dört sütun 360 piksel genişliğe sığmıyor ve okur paketleri karşılaştıramıyor.

Bu senaryoda kart görünümü yanlış seçim olur, çünkü okurun asıl işi karşılaştırmaktır. Bunun yerine şu kurguyu uygularız:

1. Tabloyu odaklanabilir bir kaydırma kutusuna alırız.
2. Özellik adlarını içeren ilk sütunu sola sabitleriz ve genişliğini sınırlarız.
3. Başlık satırında paket adlarını kısa tutarız; uzun pazarlama adlarını kısaltırız.
4. Var ve yok değerlerini simge artı metin olarak yazarız.
5. Tablonun üstüne "Paketleri görmek için sağa kaydırın" notunu ekleriz.

Böylece okur ilk sütuna bakarak her satırın neyi anlattığını bilir ve parmağıyla paketler arasında gezer. Alternatif olarak paket sekmesi de kurulabilir; ancak sekmeler aynı anda iki paketi görme imkânını ortadan kaldırır. Bu nedenle karşılaştırmanın kendisi önemliyse kaydırmalı tabloyu tercih ederiz.

Örnek senaryo: sipariş geçmişi ve kayıt listesi

İkinci örnek senaryo bir müşteri panelindeki sipariş geçmişi olsun. Her satırda sipariş numarası, tarih, ürün sayısı, tutar, durum ve bir "Detay" bağlantısı var. Kullanıcı genellikle belirli bir siparişi bulmak ister; satırları birbiriyle karşılaştırmaz.

Bu yüzden burada kart görünümü en doğru seçimdir. Dar ekranda her sipariş bir karta dönüşür. Kartın en üstünde sipariş numarası ve durum yer alır, çünkü kullanıcının ilk aradığı bilgi budur. Ardından tarih ve tutar gelir, en altta da tam genişlikte bir "Detay" bağlantısı durur.

• Durum bilgisini hem renk hem kelimeyle verin: "Kargoda", "Tamamlandı" gibi.
• Kartlar arasına belirgin boşluk koyun ki satırlar birbirine karışmasın.
• Uzun listelerde sayfalama ya da "daha fazla yükle" kontrolü ekleyin.
• Filtre ve arama alanını kartların üstünde, normal genişlikte tutun.

Masaüstünde ise aynı veri klasik tablo olarak kalır. Yani tek bir HTML yapısı, ekran genişliğine göre iki farklı düzende çalışır. Bu yaklaşım bakım maliyetini düşürür ve içerik tutarlılığını korur.

Tablo verisi neden görsel değil HTML olarak kalmalı?

Bazı siteler mobil sorunu çözmek için tabloyu ekran görüntüsü olarak sayfaya ekler. Bu kısa vadede pratik gelir; ancak uzun vadede üç ayrı kayıp yaratır. İlk olarak telefonda görsel küçülür ve yakınlaştırmadan okumak zorlaşır. Ardından ekran okuyucular görseldeki hücrelere hiç ulaşamaz. Son olarak arama motorları da görseldeki veriyi metin kadar iyi anlamaz.

Dahası, görsel tabloyu güncellemek her seferinde yeni bir dosya üretmeyi gerektirir. Fiyat ya da kapsam değiştiğinde ekip bu adımı unutursa, sayfada eski bilgi kalır. Bu yüzden veriyi her zaman HTML tablosu olarak tutarız; mobil düzeni ise CSS ile çözeriz. Böylece içerik tek yerde yaşar, her ekranda aynı doğrulukla çıkar.

Hazır tablo eklentileri ne zaman yeterli olur?

İçerik yönetim sistemlerinde mobil tablo özelliği sunan pek çok eklenti var. Basit bir blog tablosu için bu eklentiler çoğu zaman iş görür. Ancak seçmeden önce birkaç noktaya bakmanızı öneririz, çünkü bazı eklentiler tabloyu div kutularıyla yeniden kurar ve erişilebilir yapıyı siler.

• Eklenti çıktıda gerçek table, th ve td öğelerini kullanıyor mu?
• Caption ve scope değerlerini girebiliyor musunuz?
• Kaydırma kutusu klavyeyle odak alıyor mu?
• Eklenti sayfaya ne kadar ek kod yüklüyor?

Bu sorulardan birine "hayır" cevabı çıkıyorsa, temaya özel küçük bir tablo bileşeni yazmak çoğu zaman daha sağlıklıdır. Örneğin ağır bir eklenti yerine birkaç satırlık CSS, hem hızı hem erişilebilirliği korur.

Mobil uyumlu tablo nasıl test edilir?

Mobil uyumlu tablo testi, yalnız telefonda sayfayı açıp bakmaktan ibaret değildir. Sistemli bir kontrolde farklı genişlikleri, klavyeyi ve ekran okuyucuyu birlikte denersiniz. Aşağıdaki sırayı projelerimizde düzenli olarak uygularız.

1. Tarayıcının geliştirici araçlarında 320 piksel genişliğe inin ve sayfanın yana taşıp taşmadığına bakın.
2. Masaüstünde sayfayı yüzde 400 yakınlaştırın; içerik yine okunabilmeli.
3. Yalnız klavyeyle tabloya ulaşın ve yana kaydırmayı deneyin.
4. Bir ekran okuyucuyla birkaç hücreyi dinleyin; başlıkları hücreyle birlikte duyuyor musunuz, kontrol edin.
5. Gerçek bir telefonda dikey ve yatay ekran yönünü deneyin.

Hızlı bir ön kontrol için mobil uyumluluk testi aracımızı kullanabilirsiniz; ancak araç sonuçlarını manuel denemenin yerine koymayın. Ayrıca büyük tablolar sayfa hızını da etkileyebilir. Özellikle binlerce satırlık tablolarda sayfalama yapmak, Core Web Vitals değerlerini korumanıza yardım eder.

Mobil uyumlu tablo için yayın öncesi kontrol listesi

Yayına almadan önce aşağıdaki listeyi tek tek işaretleyin. Bu kontrol listesi, sahada en sık gördüğümüz hataları kapsar ve birkaç dakikanızı alır.

• Tablo gerçekten gerekli mi, yoksa liste daha mı iyi?
• Sayfanın geri kalanı 320 piksel genişlikte yana taşmıyor mu?
• Tablo kendi kaydırma kutusunda mı, kutu klavyeyle odak alıyor mu?
• Başlık hücreleri th, kapsamları doğru mu?
• Tablonun ekranda bir caption'ı var mı?
• Gerekliyse ilk sütun ya da başlık satırı sabit mi, arka planı opak mı?
• Kart görünümünde her değerin etiketi doğru mu?
• Sayılar sağa, metinler sola hizalı mı, birimler başlıkta mı?
• Durum bilgisi yalnız renge mi dayanıyor?
• Yakınlaştırma açık mı, dokunma alanları yeterli mi?
• Ekran okuyucuyla testi yaptınız mı?

Her madde tek başına küçük bir düzeltmedir. Ancak hepsi bir araya geldiğinde, telefonda gerçekten işe yarayan bir tablo ortaya çıkar.

Tablo tasarımını sitenizde kim kurmalı?

Tek bir tabloyu düzeltmek çoğu zaman kolaydır. Zorluk, yüzlerce sayfada farklı içerik editörlerinin tablo eklediği sitelerde başlar. Böyle sitelerde kalıcı çözüm, tablo bileşenini şablon düzeyinde kurmaktır: kaydırma kutusu, caption alanı, başlık kapsamları ve kart düzeni otomatik gelir. Böylece editör yalnız veriyi girer, yapı her zaman doğru çıkar.

Bu kurguyu sitenizde biz kurarız. Veri yoğun sayfalarınızı inceler, her tablo tipi için uygun yöntemi seçer, bileşeni temanıza ekler ve erişilebilirlik testlerini tamamlarız. Kapsamı netleştirmek için web tasarım sayfamızdan teklif talebinizi iletebilirsiniz; sayfa sayısına ve tablo çeşitliliğine göre size özel bir teklif hazırlarız.

Özetle iyi bir mobil tablo; doğru yöntem, doğru HTML yapısı ve gerçek cihaz testinin birleşimidir. Bu üç adımı atladığınızda tablo masaüstünde güzel, telefonda ise işe yaramaz kalır. Hangi yöntemi seçerseniz seçin, önce okurun tabloda ne aradığını sorun.