Flowtica

AI ตรวจ Web Accessibility ตาม European Accessibility Act 2025: โจทย์ใหม่ของ SME อีคอมเมิร์ซไทยที่ขายยุโรป

โดย ทีม Flowtica
การตลาด & ลูกค้า

ลองจินตนาการว่าแบรนด์กระเป๋าไทยในเชียงใหม่เปิดเว็บขายถึงลูกค้าเยอรมันได้เดือนละหลายร้อยออเดอร์ แต่ยังมีผู้ซื้อตาบอดจำนวนมากใน EU ที่ไม่สามารถกดปุ่มเพิ่มสินค้าลงตะกร้าได้ เพราะปุ่มมีคอนทราสต์ต่ำและไม่มี label ชัดเจน หลังวันที่ 28 มิถุนายน 2025 ร้านค้าออนไลน์ที่ให้บริการผู้บริโภคใน EU เข้าข่ายต้องดูแล European Accessibility Act (EAA) และนี่คือโจทย์ที่ SME ไทยต้องตอบ ไม่ใช่เพียงเพราะเป็นกฎหมาย แต่เพราะการทำเว็บให้ทุกคนเข้าถึงได้ยังช่วยให้แบรนด์ไทยติดอันดับ SEO และดูน่าเชื่อถือในตลาดสากล

European Accessibility Act 2025 คืออะไร และเริ่มบังคับเมื่อใด

EAA หรือ Directive 2019/882 เป็นกฎหมายระดับสหภาพยุโรปที่วางกรอบให้สินค้าและบริการดิจิทัลต้องใช้งานได้กับคนทุกกลุ่ม รวมถึงคนพิการทางสายตา การได้ยิน การเคลื่อนไหว และการเรียนรู้ ประเทศสมาชิก EU ต้องนำข้อกำหนดไปบังคับใช้จริง และตั้งแต่วันที่ 28 มิถุนายน 2025 เป็นต้นมา ผู้ให้บริการต้องปฏิบัติตามเมื่อวางบริการใหม่ในตลาด EU กฎหมายนี้ครอบคลุมหลายภาคส่วน หนึ่งในนั้นคือบริการอีคอมเมิร์ซ และบริการที่เกี่ยวข้องอย่างการชำระเงินออนไลน์ การสมัครสมาชิก และการติดต่อฝ่ายบริการลูกค้าผ่านเว็บหรือแอป

แม้ตัวบท EAA จะไม่ได้เขียนคำว่า WCAG ไว้เป็นชื่อเดียว แต่ข้อกำหนดด้านการรับรู้ การใช้งานได้ ความเข้าใจได้ และความแข็งแรงของระบบ สอดคล้องกับมาตรฐาน EN 301 549 และแนวปฏิบัติ WCAG ที่ผู้พัฒนาทั่วโลกใช้กัน โดยเฉพาะ WCAG 2.2 ระดับ AA ซึ่งกลายเป็นเกณฑ์ปฏิบัติที่ตลาดเริ่มใช้เทียบเคียง ดังนั้น SME ไทยที่กำลังออกแบบเว็บขายของให้ยุโรป ควรมอง WCAG 2.2 เป็นภาษาเดียวกันกับผู้ซื้อและแพลตฟอร์ม EU มากกว่าจะมองเป็นเอกสารราชการที่ไกลตัว

เว็บอีคอมเมิร์ซของ SME ไทยที่ขายตรง EU เข้าข่าย EAA หรือไม่

คำตอบสั้น ๆ คือ เข้าข่ายได้ หากเว็บหรือแอปนั้นเปิดให้ผู้บริโภคใน EU สั่งซื้อสินค้าได้จริง คำว่า “ให้บริการใน EU” ไม่ได้หมายความว่าต้องมีสำนักงานหรือคลังสินค้าอยู่ในยุโรป ร้านเสื้อผ้า ร้านเครื่องหอม ผู้ผลิตเครื่องใช้ในครัว หรือโรงงานเฟอร์นิเจอร์ไทยที่เปิดหน้าเว็บหลายภาษา มีการคิด VAT หรือส่งสินค้าไปเบลเยียม เยอรมนี ฝรั่งเศส ล้วนอยู่ในสายตาของการค้าออนไลน์ข้ามพรมแดนแล้ว

แน่นอนว่าในทางปฏิบัติ การบังคับใช้อาจไม่ได้เริ่มจากตำรวจดิจิทัลบุกตรวจทุกร้าน แต่เริ่มจากลูกค้า EU ที่ใช้ assistive technology เช่น screen reader แล้วพบว่าเว็บใช้งานไม่ได้ พวกเขาสามารถร้องเรียนต่อหน่วยงานกำกับดูแลประเทศที่อาศัยอยู่ได้ และเมื่อหน่วยงานสอบถามไปยังผู้ให้บริการนอก EU หลักฐานการตรวจและแนวทางการแก้ก็เป็นสิ่งที่ต้องแสดงได้ ยิ่งกว่านั้นถ้าขายผ่านตลาดออนไลน์ขนาดใหญ่ ตลาดอาจขอเอกสาร confirming accessibility จากผู้ขายเอง ดังนั้นพ่อค้าแม่ค้าไทยที่ขายตรงสู่ผู้บริโภค EU ไม่ควรถือว่า “เว็บเราไม่ได้จดทะเบียน EU แล้วไม่ต้องทำ” เพราะการเข้าถึงได้คือคุณภาพบริการ ไม่ใช่เพียงที่อยู่ของบริษัท

ทำไม AI ถึงเหมาะกับโจทย์ตรวจ WCAG 2.2 สำหรับธุรกิจขนาดเล็ก

SME ไทยส่วนใหญ่ไม่มีตำแหน่ง accessibility specialist หรืองบจ้างที่ปรึกษาเต็มเวลา แต่มีทีมพัฒนาเว็บที่มีอยู่แล้วและมีเครื่องมือ AI ราคาไม่แพง วิธีที่ฉลาดคือใช้ AI ตรวจเว็บเป็น “ผู้ช่วย” ที่ทำงานได้เร็ว ตรวจซ้ำได้ทุกครั้งก่อนปล่อยหน้าใหม่ และไม่รู้จักเบื่อ แทนที่จะให้คนไล่คลิกทุกหน้าเป็นรอบ ๆ

AI audit ทำงานโดยสแกน DOM, accessibility tree, ไฟล์ CSS และบางครั้งวิเคราะห์ภาพหน้าจอด้วยโมเดล vision ผลลัพธ์คือรายงานตำแหน่งปัญหาที่ระบุบรรทัดโค้ดและคำแนะนำ เช่น “ปุ่มสีเทาบนพื้นขาว contrast 1.8:1 ควรเพิ่มเป็น 4.5:1” หรือ “Input ที่อยู่ไม่มี label เชื่อมโยงด้วย for/id” ซึ่งทีมพัฒนานำไปแก้ต่อได้ทันที โดยรวมค่าใช้จ่ายต่ำกว่าการจ้างผู้เชี่ยวชาญมานั่งตรวจทั้งเว็บมาก

อย่างไรก็ตาม AI ไม่ได้ทดแทนมนุษย์ทั้งหมด งานวิจัยและผู้ให้บริการเครื่องมือหลายรายยอมรับว่า automated scan จับปัญหาได้ราว 20-50% ของเกณฑ์ทั้งหมด (ตัวเลขขึ้นกับประเภทเว็บและเครื่องมือ) ส่วนที่เหลือต้องใช้มนุษย์ทดสอบร่วมกับ assistive technology ข้อดีคือ AI ช่วยกรองงานซ้ำซ้อนออกไป ทำให้ผู้เชี่ยวชาญหรือเจ้าของธุรกิจมีเวลาสนใจปัญหาที่ต้องตัดสินใจเชิงบริบทจริง ๆ

AI ตรวจพบปัญหาใดบ้าง ตั้งแต่สี ฟอร์ม ARIA ไปจนถึงคีย์บอร์ด

จุดแข็งของ AI อยู่ที่การตรวจกฎที่ไม่ต้องใช้ดุลยพินิจมาก ตัวอย่างแรกคือสีและคอนทราสต์ AI สามารถคำนวณอัตราส่วน contrast ของข้อความปกติได้ต้องไม่ต่ำกว่า 4.5:1 และข้อความขนาดใหญ่หรือส่วนประกอบของ UI ต้องไม่ต่ำกว่า 3:1 ตาม WCAG 2.2 เครื่องมือยังจับได้ด้วยว่าคนตาบอดสีไม่ควรเห็นข้อมูลสำคัญจากสีเพียงอย่างเดียว

ปัญหาที่สองคือคีย์บอร์ดและการใช้งานทางเลือก AI อ่านโค้ดแล้วพบว่า “ปุ่ม” สร้างจาก div แล้วผูก onClick โดยไม่มี role="button" หรือไม่สามารถ focus ได้ด้วยแป้น Tab ซึ่งผิดหลักการ operable ข้อนี้พบเยอะในธีมเว็บราคาถูกและหน้าเว็บที่ใช้ JavaScript สร้างฟีเจอร์ซับซ้อน

ปัญหาที่สามคือรูปภาพที่ไม่มี alt text หรือมี alt text ซ้ำซ้อน ภาพสินค้าหลายร้อยชิ้นถูกอัปโหลดจากหลังบ้านโดยไม่ได้กรอกคำอธิบาย AI จะไล่สแกนทุกภาพในหน้าสินค้าและชี้เป้าให้ทีมแก้ไข ต่อมาคือ ARIA ที่ผิด เช่น ใช้ aria-hidden="true" กับ element ที่รับ focus ได้ หรือ aria-labelledby ชี้ไปยัง id ที่ไม่มีอยู่จริง ซึ่งทำให้ screen reader สับสน

ท้ายสุด AI ช่วยตรวจ semantic HTML ตั้งแต่ heading hierarchy ที่ข้ามระดับ ปุ่มที่ใช้ tag ผิด label ฟอร์มที่ใช้ placeholder อย่างเดียว แต่ไม่มี label จริง และลิงก์ที่มีข้อความว่า "คลิกที่นี่" โดยไม่บอกปลายทาง ตัวอย่างร้านขายเครื่องเทศไทยที่ส่งออกไปเนเธอร์แลนด์อาจพบว่า หน้าโปรดักต์ทุกอันใช้รูปพริกแห้งโดยไม่มี alt text และปุ่มสั่งซื้อซ่อน label ไว้ในไอคอนตะกร้าเท่านั้น ปัญหาเหล่านี้ AI ตรวจเจอเป็นลิสต์ชัด และทีมสามารถแก้เป็นระบบเดียวกันได้ทั้งเว็บ

ใช้ Generative AI เขียน alt text และปรับ Semantic HTML อย่างไรให้ทีมพัฒนาเอาไปใช้ได้จริง

Generative AI ไม่ใช่แค่ตัวสแกน แต่เป็นผู้ช่วยผลิตเนื้อหาต้นฉบับได้ ประโยชน์ที่ SME เห็นผลทันทีคือการเขียน alt text สำหรับภาพสินค้าจำนวนมาก แต่ต้องตั้งพรอมต์ให้ถูกต้อง เช่น “บรรยายภาพสินค้าอีคอมเมิร์ซใน 3-15 คำ ให้ข้อมูลสี ลวดลาย วัสดุ และรุ่น ห้ามขึ้นต้นว่า รูปภาพ ห้ามเดาราคา” ถ้าเป็นภาพตกแต่ง ให้ตอบว่า alt='' เพื่อให้คนใช้ screen reader ข้ามภาพนั้นไปได้ และอย่าลืมให้คนที่รู้จักสินค้าจริงตรวจทานอีกครั้ง AI อาจเข้าใจวัตถุผิดในภาพมุมเอียง หรือบรรยายสีเพี้ยนเพราะแสงในสตูดิโอ

สำหรับ semantic HTML ทีมพัฒนาสามารถวางโค้ดหน้าเว็บลงใน prompt แล้วถาม AI ว่า “มีส่วนไหนที่ screen reader อ่านแล้วเข้าใจผิด และควรแก้เป็น semantic HTML อะไร” ผลลัพธ์ที่ได้คือคำแนะนำเชิงปฏิบัติ เช่น เปลี่ยนจาก div ที่ปิดทับด้วย aria-label เป็น button จริง ใช้ label ครอบข้อความในฟอร์ม เชื่อม for/id ให้ถูกต้อง หรือเพิ่ม aria-describedby สำหรับคำแนะนำการกรอกข้อมูล การทำแบบนี้ช่วยให้ทีมไม่ต้องไปนั่งไล่อ่าน WCAG ทั้งหมด แต่ยังได้โค้ดที่มีต้นตอมาจากหลักการที่ถูกต้อง

อย่างไรก็ตามควรระวัง AI ที่เขียนโค้ดใหม่ให้แล้วแต่ไม่เคยทดสอบกับ screen reader จริง วิธีปลอดภัยคือให้ AI เสนอเป็น code diff แล้วให้มนุษย์ code review และทดสอบบนเบราว์เซอร์อย่างน้อยสองตัวก่อน merge เพราะปัญหาบางอย่าง เช่น ลำดับ focus หรือการจัดการ modal ยังต้องทดสอบบนเครื่องมือจริง

วิธีวาง Workflow AI + Human-in-the-loop สำหรับทีมเล็ก

การทำ accessibility หนึ่งครั้งแล้วจบไม่พอ เพราะเว็บอีคอมเมิร์ซมีการเพิ่มสินค้า เปลี่ยนธีม อัปเดตปลั๊กอินอยู่ตลอด ทีมเล็กควรวางระบบที่ทำให้การตรวจเกิดขึ้นทุกครั้งก่อนปล่อยหน้าเว็บ เริ่มจากกำหนดเทมเพลตหลักในกระบวนการซื้อขาย จากนั้นเอา automated scan เข้าไปอยู่ใน CI/CD เช่น ใช้ axe-code รันเมื่อมี pull request ใหม่ ทุกครั้งที่นักพัฒนาแก้ CSS สีปุ่ม ระบบจะเตะ fail ทันที ถ้า contrast ไม่ผ่าน

ขั้นต่อไปคือให้ AI อ่านโค้ดที่เปลี่ยนไปและเพิ่มข้อเสนอแนะใน PR เช่น “Label ของช่องรหัสไปรษณีย์หายไป” หรือ “Modal นี้ยังไม่มี role=dialog และ aria-modal” ข้อเสนอแนะเหล่านี้ช่วยให้คนที่ไม่ได้เชี่ยวชาญ accessibility เข้าใจว่าต้องแก้ตรงไหน จากนั้นมนุษย์ซึ่งเป็นเจ้าของสินค้าหรือผู้จัดการฝ่ายการตลาดจะตรวจ alt text และเนื้อหาที่ AI เขียน เพื่อยืนยันความถูกต้อง หลังจากแก้แล้วให้ทดสอบด้วยคีย์บอร์ดและ screen reader เฉพาะหน้าที่มีการเปลี่ยนแปลง ไม่ต้องทดสอบทุกหน้าซ้ำทุกครั้ง บันทึกผลลงใน accessibility statement แล้วทีมก็พร้อมรับการตรวจจากคู่ค้าหรือหน่วยงาน EU

ระวัง Accessibility Overlay หรือ Plugin ที่เคลมว่า “ติดแล้วจบ”

ในตลาดมีเครื่องมือ accessibility overlay หรือ widget จำนวนมากที่โฆษณาว่าติดโค้ดหนึ่งบรรทัดแล้วเว็บจะ “ผ่าน” กฎหมายทันที วิธีทำงานของ overlay คือการฉีด JavaScript เข้าไปในหน้าเว็บเพื่อปรับแต่งสี เพิ่มปุ่มปรับขนาดฟอนต์ หรือสร้างเวอร์ชันอ่านง่าย แต่เครื่องมือเหล่านี้ไม่ได้แก้ที่โครงสร้าง HTML ต้นทาง และมักสร้างภาระให้ผู้ใช้ screen reader เนื่องจากมี layer ซ้อนทับ โฟกัสเคลื่อน หรือปุ่มลอยที่ทำให้การนำทางสับสน

หน่วยงานด้านเว็บ accessibility หลายแห่งจึงไม่แนะนำให้ใช้ overlay เป็นทางออกหลัก เพราะการเข้าถึงได้จริงต้องเกิดจากการออกแบบเนื้อหา โครงสร้าง และปฏิสัมพันธ์ที่ดีตั้งแต่ต้น ไม่ใช่การร้อยรั้วปิดจุดด้วยสคริปต์ชั่วคราว หากเว็บมี overlay แล้วประกาศว่า “WCAG Compliant” แต่ผู้ใช้ตาบอดยังสั่งสินค้าไม่ได้ แบรนด์ก็จะเสียความน่าเชื่อถือมากกว่าการไม่มี overlay ซะอีก

AI ที่เราพูดถึงในบทความนี้ไม่ใช่ overlay แต่เป็นเครื่องมือที่ใช้ตรวจและให้คำแนะนำเพื่อให้ทีมแก้ที่โค้ดจริง ไม่ใช่การปะผุหน้าเว็บในเบราว์เซอร์ของผู้ใช้ ดังนั้นเมื่อผู้บริหาร SME เห็นคำโฆษณาว่า “ติด AI แล้วจบ” ควรถามกลับให้ชัดว่าติดเพื่อตรวจ หรือติดเพื่อแก้หน้างาน และถามว่าหลักฐานอะไรจะแสดงต่อหน่วยงานรัฐ EU ได้บ้าง

ทำไมการเข้าถึงแบบ POUR จึงเป็น Trust และ SEO ระยะยาวของแบรนด์ไทย

ถ้าอยากเข้าใจหัวใจของ WCAG ให้คิดถึงหลัก POUR ตัว P แรกคือ Perceivable หมายถึงผู้ใช้ต้องรับรู้ข้อมูลได้ไม่ว่าจะมองเห็นหรือได้ยิน เช่น มี alt text ภาพ มีคำบรรยายวิดีโอ และมีสี contrast พอ ส่วน O คือ Operable ต้องใช้งานด้วยคีย์บอร์ดหรืออุปกรณ์ช่วยเหลือได้ ไม่มีกับดักโฟกัส U คือ Understandable ต้องมีภาษาที่อ่านง่าย เมนูเป็นระเบียบ และ R คือ Robust ต้องทำงานกับ assistive technology ทั้งในปัจจุบันและอนาคต

การทำ POUR ไม่ใช่เพียงการติ๊กว่ารูปมี alt text แต่คือการออกแบบเส้นทางของผู้ซื้อให้ไม่มีกำแพงตั้งต้น ตัวอย่างจริงคือร้านผ้าไทยขายกระเป๋าไปสเปน ลูกค้าสูงอายุที่สายตาไม่ดีสามารถซื้อของได้เพราะปุ่มกดใหญ่และ contrast ชัด ขณะเดียวกัน Google ที่ส่งบอตมาเก็บข้อมูลเว็บก็เข้าใจโครงสร้าง heading และ alt text ได้ดีขึ้น ทำให้หน้าเว็บติดค้นหาในคำที่เกี่ยวข้องกับสินค้าแม้ยังไม่มีโฆษณาจำนวนมาก

แม้ Google จะไม่ประกาศว่า accessibility score เป็นปัจจัยจัดอันดับโดยตรง แต่เว็บที่เข้าถึงได้มักเป็นเว็บที่โหลดเร็ว มี semantic HTML ชัด มีข้อความอธิบายภาพ และผู้ใช้ไม่ปิดหน้ากลางคันเพราะใช้เมาส์ไม่ได้หรืออ่านสีไม่รู้เรื่อง ลูกค้า EU จำนวนมากเริ่มมองหาสัญลักษณ์หรือคำว่าสินค้าจากผู้ประกอบการที่ใส่ใจทุกคน การที่ร้านไทยมีหน้า “Accessibility Statement” เปิดเผย จึงเป็นเหมือนตรารับรองคุณภาพที่ทำให้แบรนด์เล็กดูเป็นมืออาชีพและน่าเชื่อถือในตลาดสากล

สรุป: เริ่มตรวจตอนนี้ ดีกว่ารอให้ลูกค้าถามหา

European Accessibility Act 2025 ไม่ใช่ข่าวเทคโนโลยีไกลตัว แต่เป็นเกณฑ์การค้าที่ SME ไทยต้องเรียนรู้ โดยเฉพาะร้านที่ขายตรงสู่ผู้บริโภค EU ต้นทุนที่แท้จริงไม่ใช่การจ้างผู้เชี่ยวชาญราคาแพงเพียงอย่างเดียว แต่เป็นการปล่อยให้เว็บมีจุดบกพร่องสะสมจนต้องแก้ทีหลัง

AI ควรถูกมองเป็นสมาชิกในทีมที่คอยตรวจ WCAG 2.2 เขียนร่าง alt text ชี้จุดที่ ARIA ผิด และแนะนำ semantic HTML ให้ทีมพัฒนานำไปใช้จริง ส่วนมนุษย์ต้องทำหน้าที่ตัดสินใจ ทดสอบด้วยคีย์บอร์ดและ screen reader และดูแลกระบวนการอย่างต่อเนื่อง เมื่อตั้ง workflow AI + Human-in-the-loop สำเร็จ เว็บร้านค้าไทยจะไม่ใช่แค่สวยงามและขายเก่ง แต่เป็นพื้นที่ที่ทุกคนเข้าถึงได้ และนั่นคือข้อได้เปรียบที่คู่แข่งในตลาด EU หลายรายยังตามไม่ทัน

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

เว็บ SME ไทยที่ไม่มีบริษัทในยุโรปต้องปฏิบัติตาม EAA 2025 จริงหรือไม่

จริงในกรณีที่เว็บเปิดให้ลูกค้าใน EU สั่งสินค้าหรือใช้บริการได้ เพราะ EAA ครอบคลุมบริการที่ให้แก่ผู้บริโภคในตลาด EU ไม่ได้จำกัดเฉพาะผู้ประกอบการที่ตั้งอยู่ในประเทศสมาชิก หน่วยงานกำกับดูแลของประเทศ EU อาจสุ่มตรวจร้านค้าออนไลน์หรือรับเรื่องร้องเรียนจากผู้ใช้ สินค้าหรือบริการที่ถือเป็นการค้าออนไลน์ เช่น การขายเสื้อผ้า กระเป๋า หรือสมัครสมาชิกซอฟต์แวร์ จึงควรวางแนวทางปฏิบัติตาม WCAG ตั้งแต่วันนี้ ส่วนร้านที่ไม่มีเป้าหมายลูกค้า EU เลยก็ยังได้ประโยชน์ด้าน SEO และภาพลักษณ์ในระยะยาว

AI scan แล้วผลออกมาผ่าน หมายความว่าเว็บเป็นไปตาม EAA แล้วหรือไม่

ไม่ใช่ เกณฑ์ WCAG หลายข้อต้องการดุลยพินิจจากมนุษย์ เช่น ลำดับการอ่านของ screen reader ต้องสื่อความหมายจริง หรือข้อความลิงก์ต้องเข้าใจได้โดยไม่ต้องอ่านบริบททั้งหมด AI อัตโนมัติเจอได้ดีในกลุ่มที่เป็น rule-based เช่น สี contrast, alt text ว่าง, ARIA ผิด syntax แต่พลาดปัญหาที่ต้องใช้ความเข้าใจเชิงบริบท แนวทางปลอดภัยที่สุดคือใช้ AI คัดกรองก่อน แล้วให้มนุษย์ทดสอบ keyboard, screen reader และ mobile บนเทมเพลตหลัก ๆ และบันทึกหลักฐานไว้

การใช้ generative AI เขียน alt text จำนวนมากจะลดงานทีมได้จริงไหม

ช่วยได้จริงหากตั้ง prompt ให้เน้นข้อมูลขายของ เช่น ชื่อสินค้า สี ลาย วัสดุ และคุณสมบัติที่มองเห็นในภาพ ไม่ใช่ใส่ความเห็นเลื่อนลอย ส่วนภาพตกแต่งหรือภาพไอคอนซ้ำควรเขียน alt='' เพื่อให้ screen reader ข้าม อีกทั้งต้องมีมนุษย์ตรวจอย่างน้อยหนึ่งรอบเพราะ AI ยังเกิดภาพหลอนได้ เช่น บรรยายสีผิดหรือปุกรุ่นสินค้า

ใช้ accessibility overlay หรือ plugin ที่เคลมว่าติดแล้วจบ จะผ่านกฎหมายไหม

ไม่แนะนำให้พึ่ง overlay เพียงอย่างเดียว เพราะ overlay ส่วนใหญ่โหลด JavaScript ไปแก้ DOM ขณะเรียกใช้งาน ซึ่งอาจรบกวนผู้ใช้ screen reader และไม่สามารถแก้ semantic HTML ต้นทางได้ การประกาศความสอดคล้องควรมาจากการออกแบบ การทดสอบ และการดูแลเว็บจริง ถ้า overlay ทำงานผิดพลาด หรือหน้าเว็บมีฟีเจอร์ใหม่เพิ่มเข้ามา ปัญหาการเข้าถึงก็กลับมา และหน่วยงานกำกับดูแลหลายแห่งมองว่าโฆษณาแบบติดแล้วจบไม่ตรงกับหลัก POUR

แหล่งอ้างอิงและข้อมูลเพิ่มเติม

ลิงก์ไปยังเว็บไซต์ทางการของหน่วยงานและผู้พัฒนา — กฎเกณฑ์และรายละเอียดอาจเปลี่ยนแปลง กรุณายึดข้อมูลจากต้นทางเป็นหลัก