ปัญหาไม่ได้อยู่ที่จอเล็กอย่างเดียว แต่อยู่ที่ความสัมพันธ์ของข้อมูล
เมื่อทีมการตลาดย่ออินโฟกราฟิกจากจอคอมพิวเตอร์ลงมาอยู่บนมือถือ ตารางที่เคยเห็นครบทุกคอลัมน์อาจเหลือเพียงชื่อรายการกับตัวเลขแรก ผู้ใช้ต้องเลื่อนไปด้านข้างเพื่อดูค่าอื่น แต่ระหว่างเลื่อนกลับจำไม่ได้แล้วว่าค่านั้นเป็นของแถวไหน ปัญหานี้ไม่ใช่เพียงเรื่องความสวยงาม เพราะคนอ่านอาจเปรียบเทียบผิด ตีความหน่วยผิด หรือมองไม่เห็นข้อจำกัดที่อยู่คอลัมน์ท้ายสุดได้ บทความนี้จึงมุ่งแก้ประสบการณ์อ่านตารางข้อมูลบนหน้าจอแคบโดยเฉพาะ ไม่ได้สอนเขียน Alt Text หรือแปลงกราฟเป็นคำอธิบายยาวซึ่งมีบทความแยกอยู่แล้ว
ก่อนลงมือแก้ ให้แยกวัตถุสองชนิดออกจากกัน ภาพอินโฟกราฟิกที่มีตารางฝังอยู่เป็นพิกเซล กับตาราง HTML ที่มีเซลล์ข้อมูลจริง ภาพสามารถย่อได้แต่ข้อความอาจเล็กจนอ่านไม่ออก ส่วนตาราง HTML สามารถเลื่อนหรือปรับรูปแบบได้โดยรักษาความสัมพันธ์ระหว่างหัวตารางกับค่าไว้ การตัดสินใจว่าจะแสดงอย่างไรต้องเริ่มจากคำถามว่า คนอ่านต้องเทียบข้อมูลข้ามแถวหรือข้ามคอลัมน์พร้อมกันหรือไม่
ตรวจงานต้นฉบับก่อนเลือกรูปแบบมือถือ
เริ่มจากขอชุดข้อมูลที่ตรวจสอบได้ ไม่ใช่เพียงไฟล์ภาพสำเร็จ ต้องมีชื่อคอลัมน์ หน่วยของตัวเลข คำอธิบายเครื่องหมายพิเศษ ช่วงเวลา และเจ้าของข้อมูลที่ตอบคำถามได้ หากตารางมีค่าเว้นว่าง ต้องรู้ว่าไม่มีข้อมูล ไม่เกี่ยวข้อง หรือเป็นศูนย์ เพราะทั้งสามความหมายไม่เหมือนกัน การเตรียมต้นฉบับแบบนี้สัมพันธ์กับ การจัด Source Pack ก่อนออกแบบ Infographic แต่ขั้นตอนของบทความนี้จะต่อจากข้อมูลที่พร้อมแล้วไปสู่การทดสอบการอ่านจริง
ลองเขียนงานที่ผู้อ่านต้องทำเป็นประโยคเดียว เช่น เปรียบเทียบระยะเวลาของบริการสามแบบ หรือดูว่าสาขาใดมีรายการค้างในเดือนล่าสุด จากนั้นทำเครื่องหมายคอลัมน์ที่จำเป็นต่อการตัดสินใจ คอลัมน์ที่ใช้ระบุตัวตนของแถว และคอลัมน์เสริมที่ย้ายไปคำอธิบายได้ หากลบคอลัมน์ใดแล้วคำตอบเปลี่ยน แปลว่าคอลัมน์นั้นไม่ควรถูกซ่อนเพื่อให้หน้าจอดูโล่ง
อย่าตัดหัวตารางทิ้งเพื่อประหยัดพื้นที่
การย้ายหัวตารางออกไปไว้เหนือภาพหนึ่งครั้งอาจดูเรียบร้อย แต่เมื่อเลื่อนลงหลายแถว คนอ่านอาจลืมว่าตัวเลขแต่ละช่องหมายถึงอะไร โดยเฉพาะคอลัมน์ที่มีหน่วยคล้ายกัน เช่น จำนวนรายการและจำนวนวัน ถ้าแสดงข้อมูลเป็น HTML ให้ใช้หัวตารางที่สัมพันธ์กับเซลล์ ไม่ใช่ใช้ตัวหนาหรือสีแทนความหมายเพียงอย่างเดียว แนวทาง Information Hierarchy สำหรับ Infographic ช่วยกำหนดว่าอะไรต้องเห็นก่อน แต่ไม่ได้แทนการกำหนดความสัมพันธ์ของตารางในโค้ด
สามทางเลือกเมื่อความกว้างไม่พอ
ทางเลือกแรก: ตารางเลื่อนแนวนอนในกรอบของตัวเอง
เหมาะเมื่อผู้ใช้ต้องเปรียบเทียบค่าหลายคอลัมน์พร้อมกันและการเปลี่ยนเป็นรายการแนวตั้งทำให้ความสัมพันธ์เสียไป ให้วางตารางไว้ในกรอบที่เลื่อนได้เฉพาะส่วน ไม่บังคับให้ทั้งหน้าเว็บเลื่อนซ้ายขวา ป้ายบอกว่าตารางเลื่อนได้ควรอยู่ก่อนกรอบ และควรมีวิธีใช้ด้วยแป้นพิมพ์สำหรับผู้ที่ไม่ได้สัมผัสหน้าจอ ถ้าแถวมีชื่อรายการยาว ต้องตรวจว่าชื่อยังอ่านได้ครบ ไม่ถูกตัดด้วยจุดไข่ปลาที่ไม่มีทางขยาย
ข้อควรระวังคือการตรึงคอลัมน์แรกไม่ได้แก้ทุกปัญหา หากคอลัมน์ที่ตรึงกินพื้นที่มากจนเหลือพื้นที่ดูค่าจริงเพียงนิดเดียว ผู้ใช้จะเลื่อนเหนื่อยกว่าเดิม การตรึงหัวตารางหรือคอลัมน์ยังอาจเกิดปัญหาซ้อนทับเมื่อซูมข้อความ ต้องทดลองกับข้อมูลยาวจริงและคำภาษาไทย ไม่ใช่ตรวจเฉพาะตารางตัวอย่างสั้น ๆ
ทางเลือกที่สอง: แสดงแต่ละแถวเป็นการ์ดที่มีชื่อฟิลด์
เหมาะกับข้อมูลที่ผู้อ่านสนใจทีละรายการ เช่น สถานะคำขอแต่ละงาน การ์ดหนึ่งใบควรมีชื่อรายการเป็นหัว แล้วตามด้วยคู่ป้ายกำกับและค่า เช่น ระยะเวลา: สองวัน หรือสถานะ: รอตรวจ อย่าแสดงเพียงตัวเลขลอย ๆ โดยหวังว่าคนจะจำตำแหน่งคอลัมน์เดิมได้ แต่ถ้างานหลักคือเทียบตัวเลขของหลายรายการพร้อมกัน การ์ดอาจทำให้ต้องเลื่อนขึ้นลงและจำค่ามากเกินไป จึงไม่ควรเปลี่ยนทุกตารางเป็นการ์ดโดยอัตโนมัติ
ทางเลือกที่สาม: สรุปประเด็นสำคัญแล้วเปิดตารางเต็มต่อ
ถ้าตารางมีหลายสิบคอลัมน์และเป็นหลักฐานประกอบข้อสรุป ควรเขียนสรุปที่ตรวจสอบได้ไว้ก่อน แล้วให้ผู้อ่านเปิดตารางเต็มเพื่อสำรวจรายละเอียด การสรุปต้องบอกเกณฑ์และช่วงเวลาที่ใช้ ไม่ใช้ถ้อยคำว่า ดีที่สุด หรือเติบโตสูงสุด หากยังไม่ได้ตรวจค่าจริง การแยกบทสรุปออกจากตารางไม่ได้หมายความว่าสามารถตัดข้อมูลที่ไม่สนับสนุนข้อสรุปทิ้งได้ ตารางต้นฉบับควรยังเข้าถึงได้
ตัวอย่างสมมติ: ตารางเปรียบเทียบขั้นตอนรับงานสามแบบ
สมมติทีมบริการต้องอธิบายขั้นตอนรับงานแบบ A, B และ C โดยแต่ละแบบมีผู้รับผิดชอบ เอกสารที่ต้องใช้ และจุดอนุมัติ ตัวอย่างนี้สร้างขึ้นเพื่อสาธิตการจัดหน้าจอเท่านั้น ไม่ใช่ข้อมูลบริการจริง หากวางทุกอย่างในภาพกว้างแล้วบีบลงมือถือ คนอ่านอาจเห็นชื่อแบบ A แต่ไม่เห็นจุดอนุมัติที่อยู่ด้านขวา ซึ่งเป็นข้อมูลสำคัญต่อการตัดสินใจ
วิธีแรกคือแสดงตาราง HTML สามคอลัมน์ ได้แก่ รูปแบบ ผู้เตรียมข้อมูล และผู้อนุมัติ พร้อมหัวตารางชัดเจนและกรอบเลื่อนเฉพาะตาราง วิธีที่สองคือสร้างการ์ดแยก A, B, C โดยในแต่ละการ์ดมีทั้งผู้เตรียมและผู้อนุมัติ วิธีเลือกไม่ได้ขึ้นกับความชอบของนักออกแบบ แต่ขึ้นกับคำถามของผู้อ่าน ถ้าต้องเปรียบเทียบว่าแบบใดใช้ผู้อนุมัติคนเดียวกัน ตารางยังมีประโยชน์มากกว่า หากต้องตรวจรายการของแบบ B ทีละขั้น การ์ดอาจอ่านง่ายกว่า
เมื่อมีข้อความว่า รออนุมัติ ต้องกำหนดด้วยว่าใครเป็นผู้อนุมัติและรออะไร มิฉะนั้นการย้ายข้อมูลจากตารางไปการ์ดอาจคงรูปแบบไว้แต่สูญเสียความหมาย หากข้อมูลเปลี่ยนในภายหลัง ต้องแก้ทั้งข้อความสรุปและตารางจากแหล่งเดียวกัน ไม่ปล่อยให้ภาพเก่าขัดกับข้อความใหม่
การเรียงลำดับอ่านต้องตรงกับลำดับความเข้าใจ
บนจอใหญ่ คนอาจกวาดสายตาเห็นทั้งแถวในครั้งเดียว แต่ผู้ใช้มือถือและผู้ใช้คีย์บอร์ดมักอ่านทีละส่วน ลำดับของ HTML จึงสำคัญ หาก CSS ย้ายคอลัมน์ด้านขวาขึ้นมาอยู่เหนือชื่อรายการโดยที่ลำดับ DOM ยังเป็นอีกแบบ ผู้ใช้เทคโนโลยีช่วยเหลืออาจได้รับข้อมูลคนละลำดับกับที่มองเห็นได้ ควรจัดโครงสร้างข้อมูลให้มีลำดับที่เข้าใจได้แม้ปิด CSS แล้ว และทดสอบการนำทางจริงก่อนอนุมัติ
ตารางข้อมูลควรใช้ <table>, <th> และ <td> ตามหน้าที่ ไม่สร้างตารางด้วยภาพหรือกล่องข้อความที่วางเรียงให้ดูเหมือนช่องตาราง สำหรับหัวคอลัมน์และหัวแถวที่อาจสับสน ใช้ scope="col" และ scope="row" ตามความสัมพันธ์ หากหัวหลายระดับซับซ้อน ควรพิจารณาลดความซับซ้อนของตารางหรือกำหนดความสัมพันธ์แบบชัดเจนตามคำแนะนำ W3C WAI ไม่ใช่เพิ่ม ARIA ทุกอย่างโดยไม่ตรวจผล
ตรวจ Reflow โดยไม่เข้าใจข้อยกเว้นผิด
เกณฑ์ WCAG 2.2 เรื่อง Reflow อธิบายว่าข้อความทั่วไปควรใช้งานได้เมื่อพื้นที่แสดงผลแคบเทียบเท่า 320 CSS pixels โดยไม่ต้องเลื่อนสองทิศทางเพื่ออ่านข้อความ แต่ตารางข้อมูลที่จำเป็นต้องรักษาความสัมพันธ์สองมิติเป็นหนึ่งในข้อยกเว้นสำคัญ ข้อยกเว้นนี้ไม่ได้อนุญาตให้ทั้งหน้าเว็บหรือคำอธิบายรอบตารางล้นจอไปด้วย และไม่ได้หมายความว่าตัวหนังสือในเซลล์จะอ่านยากเท่าไรก็ได้
จึงควรทดลองทั้งจอแคบ การขยายข้อความ และการซูมสูง ไม่ใช่ดูเฉพาะภาพจำลองมือถือที่ตั้งความกว้างไว้ค่าหนึ่ง ตรวจว่าหัวข้อก่อนตาราง ป้ายอธิบายการเลื่อน ปุ่มดาวน์โหลด และข้อความสรุปยังอยู่ในหน้าจอและใช้งานได้ หากตารางเลื่อนด้านข้าง ให้ทดสอบว่ากลับมาคอลัมน์แรกได้ง่ายและไม่เกิดการเลื่อนทั้งหน้าตามโดยไม่ตั้งใจ
เช็กลิสต์ตรวจรับสำหรับทีมออกแบบและทีมเว็บไซต์
แบ่งการตรวจเป็นสามรอบ รอบข้อมูลให้เจ้าของข้อมูลยืนยันชื่อคอลัมน์ หน่วย ช่วงเวลา ค่าว่าง และข้อความสรุป รอบโครงสร้างให้ผู้พัฒนาเว็บตรวจหัวตาราง ความสัมพันธ์ของเซลล์ ลำดับ DOM และการใช้งานแป้นพิมพ์ รอบประสบการณ์ให้ผู้ตรวจลองอ่านบนจอแคบ ซูมข้อความ เลื่อนตารางและย้อนกลับไปหาหัวแถวเดิม แล้วจดตำแหน่งที่อ่านผิดหรือหลงทางจริง แทนการให้ผ่านเพราะภาพหน้าจอดูสวย
หากงานออกแบบต้องใช้ทั้งภาพ Infographic และตาราง HTML ให้ระบุว่าไฟล์ใดเป็นเจ้าของข้อมูลและใครอัปเดตเมื่อมีการแก้ไข การมีภาพที่ตัวเลขถูกต้องแต่ตารางประกอบเก่าไม่ใช่งานที่ผ่าน QC หากยังตัดสินใจไม่ได้ว่าควรใช้ภาพเดียวหรือชุดสไลด์ สามารถกลับไปอ่าน เกณฑ์เลือก Infographic กับ Carousel ก่อนกำหนดชิ้นงาน ไม่ควรแก้ปัญหาด้วยการแบ่งตารางเป็นหลายภาพโดยไม่คิดถึงการเปรียบเทียบข้ามภาพ
สำหรับทีมที่ต้องส่งงานให้ผู้รับจ้างออกแบบ ควรเขียนข้อกำหนดตรวจรับให้ชัด เช่น ต้องอ่านค่าทุกคอลัมน์ได้บนมือถือ ต้องมีข้อความกำกับการเลื่อน ต้องไม่ซ่อนหมายเหตุหน่วย และต้องส่งตารางข้อมูลที่แก้ไขได้ ข้อกำหนดเหล่านี้เป็นตัวอย่างเกณฑ์คุณภาพ ไม่ใช่คำรับประกันว่าผ่านมาตรฐาน Accessibility ทั้งหมด หากต้องวางขอบเขตงานผลิตสื่อและข้อมูลต้นทางร่วมกับทีม สามารถดู บริการออกแบบ Infographic สำหรับธุรกิจ เพื่อกำหนดสิ่งส่งมอบที่ตรงกับการใช้งาน
สรุป: อย่าปล่อยให้การย่อภาพเปลี่ยนความหมายของตัวเลข
การทำตาราง Infographic ให้ใช้ได้บนมือถือไม่ใช่การแข่งขันว่าใครย่อคอลัมน์ได้มากที่สุด แต่เป็นการรักษาความสัมพันธ์ระหว่างชื่อรายการ หัวตาราง ค่า และหน่วยให้ผู้อ่านตรวจสอบได้ เลือกตารางเลื่อนเมื่อจำเป็นต้องเทียบหลายค่า เลือกการ์ดเมื่ออ่านทีละรายการเหมาะกว่า และใช้สรุปพร้อมตารางเต็มเมื่อรายละเอียดมากเกินกว่าจะอ่านรวดเดียว สุดท้ายต้องตรวจจากข้อมูลจริงและพฤติกรรมการอ่าน ไม่ใช่ดูแค่ภาพก่อนส่ง
คำถามที่พบบ่อย
ตารางบนมือถือเลื่อนแนวนอนถือว่าผิด WCAG เสมอหรือไม่?
ไม่เสมอไป เกณฑ์ Reflow มีข้อยกเว้นสำหรับตารางข้อมูลที่ต้องรักษาความสัมพันธ์สองมิติ แต่ข้อความและองค์ประกอบรอบตารางไม่ควรล้นจอตามไปด้วย และต้องตรวจว่าผู้ใช้ยังเข้าถึงข้อมูลทั้งหมดได้จริง
เปลี่ยนตารางเป็นการ์ดแล้วจะอ่านง่ายกว่าเสมอไหม?
ไม่เสมอไป การ์ดช่วยให้อ่านรายละเอียดทีละรายการได้ แต่ถ้าผู้อ่านต้องเปรียบเทียบหลายแถวในเวลาเดียวกัน ตารางอาจเหมาะกว่า ควรทดสอบกับคำถามที่คนอ่านต้องตอบ ไม่ใช่เลือกตามรูปแบบยอดนิยม
ใช้ภาพตารางพร้อม Alt Text อย่างเดียวพอหรือไม่?
หากมีข้อมูลหลายช่องและต้องสำรวจค่า การมีตาราง HTML ที่มีหัวเซลล์ถูกต้องมักช่วยให้เข้าถึงข้อมูลได้ดีกว่าการฝากทุกอย่างไว้ในภาพหรือ Alt Text เพียงบรรทัดเดียว แนวทางการเขียนคำอธิบายภาพซับซ้อนเป็นอีกขั้นตอนหนึ่งที่ต้องพิจารณาตามหน้าที่ของภาพ
ใครควรเป็นคนอนุมัติตารางก่อนเผยแพร่?
เจ้าของข้อมูลควรยืนยันความหมายและความถูกต้องของค่า ทีมออกแบบตรวจลำดับการอ่าน ส่วนทีมเว็บไซต์ตรวจโครงสร้างและการใช้งานจริง การให้คนเดียวดูเพียงภาพหน้าจออาจไม่พบปัญหาที่เกิดเมื่อซูมหรือใช้แป้นพิมพ์
แหล่งอ้างอิง
W3C WAI — Tables Tutorial อธิบายหัวตารางและความสัมพันธ์ของเซลล์ และ W3C WAI — Understanding Reflow อธิบายเกณฑ์ Reflow และข้อยกเว้นของตารางข้อมูล
ดูขอบเขตบริการที่เกี่ยวข้อง วิธีทำงาน และข้อมูลที่ควรเตรียมก่อนให้ทีมประเมิน
ดูบริการที่เกี่ยวข้องส่งรายละเอียดงานให้ทีมประเมิน
กรอกชื่อ เบอร์โทร และรายละเอียดที่อยากให้ช่วย ทีมจะติดต่อกลับเพื่อประเมินแนวทาง