trusty — Website Trust Platform
Accessibility & Trust UX

วิธีวางระบบ Accessible Cookie Banner สำหรับเอเจนซีและฟรีแลนซ์ทำเว็บไซต์แบบเป็นขั้นตอน

เอเจนซีที่ติดตั้ง Cookie Banner ให้ลูกค้าหลายเว็บมักพลาดเรื่องการเข้าถึงด้วยคีย์บอร์ดและโปรแกรมอ่านหน้าจอ บทความนี้เดินตามขั้นตอนตั้งแต่สำรวจ Cookie จริงไปจนถึงทดสอบก่อนส่งมอบงาน

📅 เผยแพร่ 12 สิงหาคม 2569อัปเดตล่าสุด 12 สิงหาคม 2569✍️ เขียนโดย trusty Editorial Team⏱ อ่าน 8 นาที
A group of diverse adults, including those in wheelchairs, smiling in a cafe environment fostering teamwork.
ภาพโดย MART PRODUCTION จาก Pexels

💬 สรุปสั้น ๆ

การวางระบบ Accessible Cookie Banner ให้ลูกค้าต้องเริ่มจากสำรวจ Cookie และ Script ที่ทำงานจริงบนเว็บไซต์ ก่อนออกแบบ Banner ที่ใช้ Semantic HTML และรองรับคีย์บอร์ด แล้วทดสอบว่า Reject All บล็อก Tracking Script ได้จริงก่อนส่งมอบพร้อมหลักฐาน ไม่ใช่แค่ติดปลั๊กอินแล้วถือว่าเสร็จงาน

สารบัญ

ลูกค้าเอเจนซีเว็บไซต์รายหนึ่งส่งข้อความมาว่า “ทำไม Cookie Banner ที่ทีมติดตั้งให้ กด Tab แล้วโฟกัสหลุดออกไปหลังปุ่มปิด” นี่คือปัญหาที่พบบ่อยเมื่อเอเจนซีติดตั้ง Cookie Banner แบบรีบปิดงาน โดยเน้นที่หน้าตาสวยงามและมี Accept/Reject ครบ แต่ไม่ได้ตรวจว่าใช้งานด้วยคีย์บอร์ดหรือโปรแกรมอ่านหน้าจอได้จริงหรือไม่

บทความนี้เดินตามขั้นตอนที่เอเจนซีและฟรีแลนซ์ใช้ได้จริงเมื่อวางระบบ Accessible Cookie Banner ให้ลูกค้าแต่ละราย ตั้งแต่สำรวจ Cookie จนถึงส่งมอบงานพร้อมหลักฐาน โดยอ้างอิงแนวทางจาก W3C WCAG 2.2

ก่อนเลือกเครื่องมือหรือปลั๊กอินใดๆ ต้องรู้ก่อนว่าเว็บไซต์ของลูกค้ามี Script อะไรทำงานอยู่บ้าง โดยเปิดเว็บไซต์ในโหมด Incognito แล้วดู Network Tab ว่ามี Request ไปยัง Google Analytics, Facebook Pixel หรือ Tag Manager ก่อนที่ผู้ใช้จะกดปุ่มใดๆ หรือไม่ พร้อมจดชื่อ Cookie, Domain, ผู้ให้บริการ และวัตถุประสงค์ลงในตาราง Cookie Inventory

ขั้นตอนนี้สำคัญเพราะ Banner ที่สวยแต่ไม่ได้บล็อก Script ก่อน Consent จริง เท่ากับสร้างภาพลวงตาว่าเว็บไซต์ควบคุม Tracking ได้ ทั้งที่ Pixel ยิงไปตั้งแต่โหลดหน้าแรก

แบ่ง Cookie เป็นสี่กลุ่มคือ Necessary, Functional, Analytics และ Marketing โดย Necessary ต้องจำเป็นต่อบริการที่ผู้ใช้ร้องขอจริง เช่น การเข้าสู่ระบบหรือตะกร้าสินค้า ไม่ใช่จัดเป็น Necessary เพียงเพราะลูกค้าอยากได้ข้อมูลผู้ใช้ครบ Cookie ที่ใช้วัดผลหรือโฆษณาต้องอยู่ในหมวดที่ผู้ใช้ปฏิเสธได้จริง

เอเจนซีควรหลีกเลี่ยงการจัดหมวดจากชื่อ Cookie เพียงอย่างเดียว เพราะบาง Script อาจมีชื่อคล้าย Functional แต่จริงๆ ส่งข้อมูลไปยัง Ad Network ต้องตรวจ Request ปลายทางประกอบด้วยเสมอ

ขั้นตอนที่ 3 ออกแบบ Banner ด้วย Semantic HTML และ Focus Trap ที่ถูกต้อง

โครงสร้าง HTML ที่โปรแกรมอ่านหน้าจอเข้าใจ

ใช้ role="dialog" หรือโครงสร้างที่เทียบเท่า พร้อม aria-label บอกวัตถุประสงค์ของ Banner ปุ่ม Accept, Reject และ Customize ต้องเป็น <button> จริง ไม่ใช่ <div> ที่ใส่ Event Listener เพราะโปรแกรมอ่านหน้าจอจะไม่รู้ว่าเป็นปุ่มที่กดได้

ลำดับ Focus เมื่อ Banner เปิดและปิด

เมื่อ Banner ปรากฏ Focus ควรย้ายไปที่ปุ่มแรกใน Banner โดยอัตโนมัติ และเมื่อกด Tab วนอยู่ภายใน Banner เท่านั้นจนกว่าผู้ใช้จะเลือกตัวเลือกใดตัวเลือกหนึ่ง เมื่อปิด Banner แล้ว Focus ต้องกลับไปยังจุดที่ผู้ใช้อยู่ก่อนหน้า ไม่ใช่หลุดไปที่จุดเริ่มต้นของหน้าเว็บ

ขั้นตอนที่ 4 ทดสอบ Script Blocking ก่อนส่งมอบ

หลังติดตั้ง Banner แล้ว ต้องทดสอบสี่สถานการณ์คือ ก่อนกดปุ่มใดๆ Script ต้องไม่ทำงาน กด Accept All แล้ว Script ทั้งหมดต้องทำงาน กด Reject All แล้ว Script ที่ไม่จำเป็นต้องไม่ทำงานแม้จะรีเฟรชหน้าใหม่ และเมื่อเลือกเฉพาะบางหมวดผ่าน Customize ต้องมีเฉพาะ Script ของหมวดที่เลือกเท่านั้นทำงาน

ควรทดสอบซ้ำใน Session ใหม่และหลังล้าง Cookie เพื่อยืนยันว่า Preference ที่ผู้ใช้เคยเลือกไว้ยังถูกจดจำถูกต้อง ไม่ใช่รีเซ็ตกลับไปยิง Script ทั้งหมดทุกครั้งที่เข้าเว็บไซต์ใหม่

ขั้นตอนที่ 5 ทดสอบด้วยคีย์บอร์ดและโปรแกรมอ่านหน้าจอ

ทดสอบด้วยคีย์บอร์ดอย่างเดียวโดยไม่แตะเมาส์เลย กด Tab ไล่ปุ่มทั้งหมดใน Banner กด Enter หรือ Space เพื่อยืนยันตัวเลือก และกด Escape เพื่อดูว่า Banner ปิดได้หรือไม่ตามพฤติกรรมที่ออกแบบไว้ จากนั้นเปิดโปรแกรมอ่านหน้าจออย่างน้อยหนึ่งตัวเพื่อฟังว่า Banner ประกาศชื่อและบทบาทถูกต้องหรือไม่ ปุ่มแต่ละปุ่มมีชื่อที่สื่อความหมาย ไม่ใช่แค่ “ปุ่ม” เฉยๆ

หากลูกค้าใช้ Google Tag ให้ตั้งค่า Default Consent State ก่อนที่ Tag จะทำงาน แล้วอัปเดตสถานะหลังผู้ใช้เลือก โดย Map หมวด Cookie ของ Banner กับประเภท Consent ของ Google ให้ตรงกัน และทดสอบด้วยเครื่องมือ Tag Assistant หรือเครื่องมือปัจจุบันของ Google ก่อนส่งมอบ Consent Mode ไม่ใช่ตัว Banner เอง และไม่ได้เป็นการเลือกฐานกฎหมายแทนลูกค้า

ทุกครั้งที่ผู้ใช้กด Accept, Reject หรือเปลี่ยน Preference ควรบันทึกลง Consent Log พร้อม Timestamp, เวอร์ชันของ Banner และ Policy ที่ผู้ใช้เห็นในขณะนั้น เพื่อให้ลูกค้ามีหลักฐานย้อนหลังหากต้องตรวจสอบ

พร้อมตรวจสอบความน่าเชื่อถือของเว็บไซต์คุณหรือยัง?

ทดลองใช้งาน trusty ฟรี ไม่ต้องใช้บัตรเครดิต เริ่มสแกนได้ทันที

ทดลองใช้งานระบบฟรี

ขั้นตอนที่ 7 ส่งมอบงานพร้อมเอกสารให้ลูกค้า

ก่อนปิดงาน ควรส่งมอบเอกสารสรุป Cookie Inventory, ผลทดสอบ Script Blocking, ผลทดสอบคีย์บอร์ด/โปรแกรมอ่านหน้าจอ และคำแนะนำว่าเมื่อทีมลูกค้าจะเพิ่ม Tag หรือปลั๊กอินใหม่ในอนาคต ต้องแจ้งกลับมาให้ทบทวน Banner ซ้ำ เพราะ Theme หรือปลั๊กอินใหม่อาจฝัง Script ที่ Banner เดิมไม่รู้จัก

เอเจนซีที่ทำงานเป็นทีมควรมีแบบฟอร์มส่งมอบมาตรฐานให้ลูกค้าเซ็นรับทราบ ระบุวันที่ทดสอบ รายการ Script ที่พบ ผลการทดสอบแต่ละข้อ และผู้รับผิดชอบฝั่งเอเจนซีที่ลูกค้าติดต่อได้หากพบปัญหาภายหลัง แบบฟอร์มนี้ไม่ใช่แค่เอกสารทางธุรการ แต่ช่วยให้ทั้งสองฝ่ายเห็นตรงกันว่าอะไรที่ทดสอบแล้วและอะไรที่ยังเป็นความรับผิดชอบของลูกค้าเอง เช่น การอัปเดต Content ในตัว Policy ที่ลิงก์จาก Banner

เครื่องมือที่เอเจนซีใช้ทดสอบได้จริงโดยไม่ต้องเพิ่มงบ

เอเจนซีขนาดเล็กหรือฟรีแลนซ์ที่ทำงานคนเดียวไม่จำเป็นต้องซื้อเครื่องมือราคาแพงเพื่อทดสอบ Accessible Cookie Banner DevTools ของเบราว์เซอร์ที่มีอยู่แล้วเปิด Network Tab ดู Request ก่อนและหลัง Consent ได้ทันที ส่วนการทดสอบคีย์บอร์ดใช้แค่แป้น Tab, Shift+Tab, Enter, Space และ Escape ก็เพียงพอสำหรับตรวจ Focus Trap เบื้องต้น

สำหรับโปรแกรมอ่านหน้าจอ เครื่อง Windows มี Narrator ติดตั้งมาให้แล้ว ส่วนเครื่อง Mac มี VoiceOver เปิดใช้งานได้จากการตั้งค่าระบบ ไม่จำเป็นต้องซื้อโปรแกรมเสริม เพียงฝึกใช้ปุ่มพื้นฐานอย่าง Tab เพื่อไล่ Focus และฟังว่าโปรแกรมประกาศชื่อปุ่มถูกต้องหรือไม่ ก็เพียงพอสำหรับตรวจ Banner ก่อนส่งมอบงานทุกโปรเจกต์ ทีมที่เพิ่งเริ่มฝึกใช้ควรลองปิดหน้าจอแล้วใช้แค่เสียงนำทางทำงานให้ครบขั้นตอนของ Banner หนึ่งรอบ จะเห็นปัญหาที่มองด้วยตาไม่เจอ เช่น ปุ่มที่ประกาศชื่อซ้ำกันหรือลำดับการอ่านที่สลับกับสิ่งที่แสดงบนหน้าจอ

เมื่อทีมขยายจำนวนลูกค้าและเว็บไซต์ในมือมากขึ้น การใช้เครื่องมือสแกนอัตโนมัติเป็นจุดคัดกรองเบื้องต้นก่อนตรวจมือจะช่วยประหยัดเวลา แต่ต้องระวังว่าเครื่องมือสแกนอัตโนมัติตรวจได้เฉพาะบางเกณฑ์ เช่น Contrast หรือ Label ที่ขาดหาย ส่วนพฤติกรรมการทำงานจริงของ Focus Trap และการบล็อก Script ยังต้องอาศัยคนทดสอบด้วยมืออยู่ดี

รับมือเมื่อ Theme หรือปลั๊กอินของลูกค้าฝัง Script นอกการควบคุม

ปัญหาที่เอเจนซีเจอบ่อยคือลูกค้าใช้ธีมหรือปลั๊กอินที่ฝัง Script ของ Analytics หรือ Chat มาโดยไม่รู้ตัว ทำให้ Script เหล่านี้ทำงานก่อน Consent โดยที่ Banner ที่เอเจนซีติดตั้งไม่รู้จักและควบคุมไม่ได้ ทางแก้คือสำรวจ Theme และปลั๊กอินทั้งหมดที่ติดตั้งไว้ ไม่ใช่แค่ตรวจ Script ที่ทีมพัฒนาเพิ่มเอง

เมื่อพบ Script ที่ฝังมากับ Theme หรือปลั๊กอิน ต้องตัดสินใจว่าจะปิดการทำงานของฟีเจอร์นั้นจนกว่าจะควบคุมผ่าน Consent ได้ หรือเปลี่ยนไปใช้ปลั๊กอินตัวอื่นที่รองรับการหน่วง Script ตาม Consent ควรแจ้งลูกค้าให้เข้าใจข้อจำกัดนี้อย่างตรงไปตรงมา แทนที่จะปล่อยให้ Banner ดูเหมือนควบคุมได้ครบทั้งที่ยังมี Script หลุดอยู่เบื้องหลัง

ทุกครั้งที่ลูกค้าอัปเดตเวอร์ชันธีมหรือเพิ่มปลั๊กอินใหม่ ควรมีขั้นตอนแจ้งเตือนกลับมาให้เอเจนซีทดสอบ Banner ซ้ำ เพราะการอัปเดตอาจเพิ่ม Cookie หรือ Script ใหม่ที่ Inventory เดิมไม่มีบันทึกไว้ การตกลงเรื่องนี้ล่วงหน้ากับลูกค้าในสัญญาว่าจ้างช่วยลดข้อพิพาทภายหลังได้มาก

เช็กลิสต์ปฏิบัติ

  • ทำ Cookie Inventory จาก Network Tab จริง ไม่ใช่คัดลอกจากเว็บไซต์อื่น
  • จัดหมวด Cookie ตามปลายทางของ Request ไม่ใช่ตามชื่อ
  • ใช้ปุ่ม <button> จริงสำหรับ Accept, Reject, Customize
  • ทดสอบ Focus Trap และการคืน Focus เมื่อปิด Banner
  • ทดสอบ Script Blocking ทั้งก่อนและหลังกด Reject All ในเซสชันใหม่
  • ทดสอบด้วยคีย์บอร์ดล้วนและโปรแกรมอ่านหน้าจออย่างน้อยหนึ่งตัว
  • เชื่อม Google Consent Mode และทดสอบด้วย Tag Assistant ก่อนส่งมอบ
  • ส่งมอบเอกสาร Cookie Inventory และผลทดสอบให้ลูกค้าเก็บไว้เป็นหลักฐาน

ข้อผิดพลาดที่พบบ่อย

  • ใช้ <div> แทนปุ่มจริง ทำให้โปรแกรมอ่านหน้าจอไม่รู้ว่ากดได้
  • ลืมทดสอบว่า Reject All บล็อก Script ในเซสชันใหม่ ไม่ใช่แค่ในหน้าที่ Banner เปิดอยู่
  • ติดตั้ง Banner แล้วไม่ทดสอบ Focus Trap ทำให้กด Tab หลุดออกจาก Banner ไปที่เนื้อหาด้านหลัง
  • ตั้ง Google Consent Mode แต่ไม่ Map หมวด Cookie ให้ตรงกับประเภท Consent ของ Google
  • ส่งมอบงานโดยไม่มีเอกสาร Cookie Inventory ทำให้ลูกค้าตรวจสอบย้อนหลังไม่ได้เมื่อมีปัญหา

สรุป

การวางระบบ Accessible Cookie Banner ให้ลูกค้าเป็นงานที่ต้องทำตามลำดับ ตั้งแต่สำรวจ Script จริง จัดหมวดอย่างถูกต้อง ออกแบบด้วย Semantic HTML ทดสอบ Script Blocking และการเข้าถึงด้วยคีย์บอร์ด ไปจนถึงส่งมอบเอกสารให้ลูกค้าเก็บไว้ ทุกขั้นตอนต้องมีหลักฐาน ไม่ใช่แค่ติดปลั๊กอินแล้วปิดงาน เพราะ Banner ที่ดูสวยแต่ใช้งานด้วยคีย์บอร์ดไม่ได้ ยังถือว่าไม่พร้อมส่งมอบ เอเจนซีที่ทำตามลำดับนี้อย่างสม่ำเสมอในทุกโปรเจกต์จะลดเวลาที่ต้องกลับไปแก้งานหลังส่งมอบ และมีเอกสารพร้อมชี้แจงลูกค้าได้ทันทีหากมีคำถามเรื่องการเข้าถึงเว็บไซต์เข้ามาในภายหลัง

แหล่งข้อมูลอ้างอิง

คำถามที่พบบ่อย

เอเจนซีต้องทดสอบ Accessible Cookie Banner ด้วยโปรแกรมอ่านหน้าจอทุกโปรเจกต์หรือไม่

ควรทดสอบอย่างน้อยหนึ่งเครื่องมืออ่านหน้าจอทุกครั้งที่ติดตั้ง Banner ใหม่ เพราะปัญหาการกดปุ่มไม่ได้หรือ Focus หลุดมักตรวจไม่พบด้วยการมองด้วยตาเปล่าอย่างเดียว

ใช้ปลั๊กอินสำเร็จรูปแทนการเขียนเองได้หรือไม่

ใช้ได้ แต่ต้องทดสอบ Script Blocking และคีย์บอร์ดซ้ำทุกครั้งเช่นเดียวกับ Banner ที่เขียนเอง เพราะปลั๊กอินบางตัวไม่ได้ออกแบบมาให้รองรับคีย์บอร์ดหรือโปรแกรมอ่านหน้าจอครบ

Google Consent Mode คือ Cookie Banner หรือไม่

ไม่ใช่ Consent Mode เป็นกลไกส่งสัญญาณ Consent ให้ Tag ของ Google ทำงาน ส่วน Cookie Banner คือส่วนติดต่อผู้ใช้ที่เก็บการตัดสินใจ ต้องใช้คู่กันโดย Map หมวดให้ตรงกัน

ต้องเก็บ Consent Log นานแค่ไหน

ควรกำหนดตามนโยบายเก็บข้อมูลของลูกค้าแต่ละราย โดยเก็บเท่าที่จำเป็นต่อการพิสูจน์การตัดสินใจ ไม่ควรเก็บข้อมูลส่วนบุคคลเกินความจำเป็น

อ่านต่อในหัวข้อเดียวกัน

เนื้อหานี้จัดทำขึ้นเพื่อให้ข้อมูลทั่วไปเท่านั้น ไม่ถือเป็นคำแนะนำทางกฎหมาย กรุณาปรึกษาผู้เชี่ยวชาญด้านกฎหมายหรือ Data Protection Officer ของหน่วยงานท่านก่อนนำไปปฏิบัติจริง

พร้อมตรวจสอบความน่าเชื่อถือของเว็บไซต์คุณหรือยัง?

ทดลองใช้งาน trusty ฟรี ไม่ต้องใช้บัตรเครดิต เริ่มสแกนได้ทันที