แบบฟอร์มติดต่อที่เข้าถึงได้กับ European Accessibility Act
ตั้งแต่วันที่ 28 มิถุนายน 2025 European Accessibility Act กำหนดกฎสำหรับบริการดิจิทัลจำนวนมากที่ให้แก่ผู้บริโภค เรื่องนี้หมายถึงอะไรต่อแบบฟอร์มติดต่อ พร้อมรายการตรวจ WCAG 2.2 ที่ใช้ได้จริง
แบบฟอร์มติดต่อมักเป็นประตูเดียวระหว่างผู้เยี่ยมชมกับธุรกิจ หากเปิดประตูนั้นได้เฉพาะผู้ใช้เมาส์ สายตาดี และอดทนแก้ปริศนารูปภาพพร่ามัว บางคนก็ต้องอยู่ข้างนอก ตั้งแต่กลางปี 2025 เรื่องนี้ไม่ใช่เพียงคำถามด้านความสะดวกใช้งานอีกต่อไป สำหรับหลายธุรกิจที่ขายแก่ผู้บริโภคในสหภาพยุโรป เรื่องนี้กลายเป็นคำถามทางกฎหมาย
European Accessibility Act ครอบคลุมอะไร
European Accessibility Act (Directive (EU) 2019/882) ใช้บังคับตั้งแต่วันที่ 28 มิถุนายน 2025 โดยกำหนดข้อกำหนดการเข้าถึงสำหรับผลิตภัณฑ์และบริการบางประเภทที่เสนอแก่ผู้บริโภค รวมถึงอีคอมเมิร์ซ บริการธนาคารสำหรับผู้บริโภค อีบุ๊ก การสื่อสารอิเล็กทรอนิกส์ และบางส่วนของการขนส่งผู้โดยสาร สำหรับเว็บไซต์ หมายถึงร้านค้าออนไลน์หรือบริการธนาคารทั้งบริการ รวมถึงแบบฟอร์มที่ลูกค้าใช้ติดต่อ ถามคำถาม หรือร้องเรียน วิสาหกิจขนาดย่อยที่ให้บริการได้รับยกเว้น ได้แก่ ธุรกิจที่มีพนักงานน้อยกว่าสิบคนและมีรายได้ต่อปีหรือยอดรวมงบดุลไม่เกิน EUR 2 ล้าน โดยทั่วไปข้อเสนอที่มุ่งเฉพาะธุรกิจอื่นอยู่นอกขอบเขต
รัฐสมาชิกแต่ละประเทศได้นำข้อกำหนดนี้ไปตราเป็นกฎหมายภายในประเทศ ในเยอรมนีคือ Barrierefreiheitsstärkungsgesetz (BFSG) ส่วนโปแลนด์คือกฎหมายปี 2024 ว่าด้วยการทำให้ผลิตภัณฑ์และบริการบางประเภทเป็นไปตามข้อกำหนดการเข้าถึง หน่วยงานกำกับดูแลและบทลงโทษต่างกันในแต่ละประเทศ แต่เกณฑ์ทางเทคนิคโดยรวมใกล้เคียงกัน: ในทางปฏิบัติคือมาตรฐานยุโรป EN 301 549 ซึ่งอาศัย Web Content Accessibility Guidelines (WCAG)
ทำไมจึงคุ้มค่าแม้ไม่มีหน้าที่ตามกฎหมาย
ธุรกิจอาจได้รับยกเว้นหรือให้บริการเฉพาะบริษัทอื่น แบบฟอร์มที่เข้าถึงได้ก็ยังคุ้มค่า ด้วยเหตุผลง่าย ๆ ว่าทุกคนที่ยอมแพ้กลางทางคือข้อความสอบถามที่ไม่มีวันได้รับ การแก้ไขที่ช่วยผู้ใช้โปรแกรมอ่านหน้าจอยังช่วยคนที่กรอกแบบฟอร์มบนโทรศัพท์ขณะอยู่บนรถไฟ กลางแสงแดดจ้า ข้อมือหัก หรือใช้ภาษาที่สอง ป้ายกำกับชัดเจนและข้อความผิดพลาดที่ช่วยแก้ไขทำให้ทุกคนละทิ้งแบบฟอร์มน้อยลง และไม่มีข้อใดทำให้การป้องกันสแปมอ่อนแอลง
รายการตรวจที่ใช้ได้จริงพร้อมการอ้างอิง WCAG 2.2
- ป้ายกำกับที่มองเห็นและผูกกับช่องกรอก (1.3.1, 3.3.2): ทุกช่องมีป้ายกำกับที่มองเห็นและเชื่อมผ่าน for/id ข้อความตัวอย่างในช่องอย่างเดียวไม่ใช่ป้ายกำกับ เพราะหายไปทันทีที่เริ่มพิมพ์
- ข้อความผิดพลาดที่อธิบายวิธีแก้ (3.3.1, 3.3.3): ระบุช่อง บอกว่าผิดอะไรและแก้อย่างไรเป็นข้อความ ไม่ใช่แค่ขอบสีแดง “กรุณากรอกที่อยู่อีเมล เช่น name@example.com” ดีกว่า “ข้อมูลไม่ถูกต้อง”
- ใช้งานด้วยแป้นพิมพ์ได้ครบ (2.1.1, 2.1.2): เข้าถึงและใช้งานทุกช่อง ช่องทำเครื่องหมาย CAPTCHA และปุ่มส่งด้วย Tab, Space และ Enter ได้โดยไม่ติดกับดักแป้นพิมพ์
- มองเห็นโฟกัส (2.4.7): เห็นเสมอว่าช่องใดกำลังใช้งาน การลบเส้นโฟกัสของเบราว์เซอร์โดยไม่มีสิ่งทดแทนไม่ผ่านเกณฑ์นี้
- ความเปรียบต่างเพียงพอ (1.4.3): ข้อความ ป้ายกำกับ และข้อความผิดพลาดมีอัตราส่วนความเปรียบต่างกับพื้นหลังอย่างน้อย 4.5:1 (3:1 สำหรับข้อความขนาดใหญ่)
- ขนาดเป้าหมาย (2.5.8): ปุ่ม ช่องทำเครื่องหมาย และลิงก์มีขนาดอย่างน้อย 24 × 24 พิกเซล CSS หรือมีระยะห่างรอบข้างเพียงพอ
- ทางเลือก CAPTCHA (1.1.1) และการยืนยันตัวตนที่เข้าถึงได้ (3.3.8): 1.1.1 กำหนดให้มีข้อความทางเลือกและ CAPTCHA มากกว่าหนึ่งรูปแบบการรับรู้ ส่วน 3.3.8 ครอบคลุมขั้นตอนเข้าสู่ระบบโดยเคร่งครัด แต่แนวคิดนำมาใช้ได้ คือปริศนา เช่น พิมพ์ตัวอักษรบิดเบี้ยวซ้ำหรือคำนวณผลบวก ไม่ควรเป็นทางผ่านเพียงทางเดียว ควรมีทางเลือกหรือใช้วิธีที่ไม่ต้องมีปริศนาเลย
- ซ่อนช่องดักบอตจากเทคโนโลยีช่วยเหลือ: ใส่ aria-hidden="true" ที่องค์ประกอบครอบช่องดักบอตและ tabindex="-1" เพื่อไม่ให้ผู้ใช้โปรแกรมอ่านหน้าจอและแป้นพิมพ์เข้าถึงช่องนี้
CAPTCHA และช่องดักบอต: จุดที่การป้องกันสแปมพบกับการเข้าถึง
กล่าวอย่างเคร่งครัด เกณฑ์ 3.3.8 เป็นเรื่องขั้นตอนเข้าสู่ระบบและการยืนยันตัวตน ไม่ใช่แบบฟอร์มติดต่อ แต่แนวคิดเบื้องหลังนำมาใช้ได้ดี การพิมพ์ตัวอักษรบิดเบี้ยว แก้ผลบวก หรือเลือกรูปสัญญาณไฟจราจรจากตารางรูปภาพกีดกันคนบางกลุ่มโดยสิ้นเชิง ทางเลือกที่มักทำงานโดยไม่มีปริศนา เช่น Cloudflare Turnstile, Friendly Captcha, ช่องดักบอตร่วมกับการตรวจสอบเวลา หรือการกรองฝั่งเซิร์ฟเวอร์อย่าง Akismet กันสแปมโดยไม่ขอให้ผู้เยี่ยมชมพิสูจน์อะไร ช่องดักบอตจะเป็นมิตรก็ต่อเมื่อมองไม่เห็นจริง รวมถึงสำหรับผู้ใช้โปรแกรมอ่านหน้าจอและแป้นพิมพ์ด้วย:
<div class="hp" aria-hidden="true">
<label for="hp-website">เว้นช่องนี้ว่างไว้</label>
<input type="text" id="hp-website" name="website"
tabindex="-1" autocomplete="off">
</div>
<!-- CSS: .hp { position: absolute; left: -10000px; } -->ทดสอบแบบฟอร์มของตนเองในสิบห้านาที
- 1วางเมาส์ไว้ข้าง ๆ แล้วกรอกแบบฟอร์มทั้งหมดด้วยแป้นพิมพ์อย่างเดียว เข้าถึงทุกช่องและปุ่มส่งได้หรือไม่ และเห็นตลอดหรือไม่ว่าอยู่ตรงไหน
- 2ส่งแบบฟอร์มว่าง แล้วลองส่งด้วยที่อยู่อีเมลผิด ข้อผิดพลาดปรากฏเป็นข้อความข้างช่องที่ถูกต้องหรือไม่ และเข้าใจชัดเจนหรือไม่ว่าต้องทำอะไร
- 3เปิดหน้าบนโทรศัพท์หรือซูมเบราว์เซอร์เป็น 200% ทุกอย่างอ่านได้หรือไม่ ปุ่มแตะง่ายหรือไม่ และมีแบนเนอร์คุกกี้หรือวิดเจ็ตแชตบังปุ่มส่งหรือไม่
- 4เปิดโปรแกรมอ่านหน้าจอ (VoiceOver, NVDA หรือ TalkBack) แล้วฟัง: ทุกช่องถูกอ่านพร้อมป้ายกำกับหรือไม่ และช่องดักบอตเงียบอยู่หรือไม่
- 5รันการตรวจอัตโนมัติ เช่น axe-core ซึ่งพบป้ายกำกับที่ขาดและปัญหาความเปรียบต่างได้รวดเร็ว แต่ไม่ครอบคลุมทุกอย่าง ยังต้องทำขั้นตอนด้วยตนเองข้างต้น
หากต้องการเริ่มจากภาพรวม formexposed ตรวจแบบฟอร์มสาธารณะจากภายนอกโดยไม่ส่งข้อมูลใด ๆ การตรวจการเข้าถึงรัน axe-core กับแต่ละแบบฟอร์ม ระบุ CAPTCHA ที่ไม่มีทางเลือกที่เข้าถึงได้และช่องดักบอตที่โปรแกรมอ่านหน้าจออ่าน และดูแบบฟอร์มบนโทรศัพท์ ทั้งเป้าหมายการแตะ องค์ประกอบทับปุ่มส่ง และการเลื่อนแนวนอน การตรวจฟรีแสดงระดับโดยรวม ส่วนรายละเอียดเหล่านี้อยู่ในรายงานฉบับเต็ม เป็นจุดเริ่มต้นที่ดีสำหรับรายการข้างต้น ไม่ใช่สิ่งทดแทนการทดสอบกับคนจริง