การนำทางที่ทุกคนเข้าถึงได้: ทำเมนู การใช้คีย์บอร์ด และโฟกัสที่มองเห็นชัด ให้ถูกวิธี

ลองเก็บเมาส์ไว้ในลิ้นชัก แล้วพยายามไปให้ถึงหน้าติดต่อของเว็บไซต์คุณเอง นี่คือบททดสอบง่าย ๆ ว่าการนำทางของเว็บไซต์เข้าถึงได้สำหรับทุกคนหรือไม่ และบนเว็บไซต์ธุรกิจจำนวนมาก กดปุ่มไปได้ไม่กี่ครั้งก็ติดแล้ว เช่น เมนูบริการเปิดได้เฉพาะตอนชี้เมาส์ กรอบไฮไลต์โฟกัสหายไปที่ไหนสักแห่งในส่วนหัว หรือปุ่มเมนูบนมือถือถูกอ่านออกมาแค่ว่า “ปุ่ม”

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

คำตอบสั้น ๆ

การนำทางที่เข้าถึงได้ ช่วยให้คนไปถึงทุกหน้าด้วยคีย์บอร์ด โปรแกรมอ่านหน้าจอ หรือเสียง ได้ง่ายพอ ๆ กับการใช้เมาส์ โดยต้องมี:

• ลิงก์ข้ามไปยังเนื้อหา (skip link) เป็นจุดแรกเมื่อกด Tab และ ลำดับโฟกัส ที่ตรงกับลำดับที่ตาเห็น
• ตัวบ่งชี้โฟกัสที่มองเห็นได้ และไม่ถูกแถบที่ติดขอบจอหรือแบนเนอร์บังเลย
• ดรอปดาวน์ ที่เปิดด้วยการคลิก ปุ่ม Enter หรือ Space ไม่ใช่แค่การชี้เมาส์ และปิดได้ด้วย Escape
• ปุ่มเมนูบนมือถือ ที่มีชื่อชัดเจน และบอกสถานะว่าเปิดหรือปิดอยู่
• แลนด์มาร์ก การระบุหน้าปัจจุบัน จุดแตะที่ใหญ่พอ และเมนูที่เหมือนกันทุกหน้าและทุกภาษา

ใครต้องใช้ และ WCAG กำหนดอะไร

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

เกณฑ์ WCAG 2.2 ที่สำคัญที่สุดสำหรับการนำทาง

เกณฑ์โฟกัสไม่ถูกบัง และขนาดเป้าหมาย เป็นเกณฑ์ใหม่ใน 2.2 ส่วนบทความ อธิบาย WCAG 2.2 จะพาไล่ดูทุกข้อที่เพิ่มเข้ามา

ลิงก์ข้ามและลำดับโฟกัสที่สมเหตุสมผล

ลิงก์ “ข้ามไปยังเนื้อหา”

ลิงก์ข้าม (skip link) คือองค์ประกอบแรกของหน้าที่รับโฟกัสได้ ลิงก์นี้ซ่อนอยู่จนกว่าจะมีคนกด Tab จากนั้นกด Enter อีกครั้งเดียวก็ไปถึงเนื้อหาหลัก ผู้ใช้โปรแกรมอ่านหน้าจอกระโดดตามแลนด์มาร์กได้ แต่เบราว์เซอร์ไม่มีวิธีในตัวให้ผู้ใช้คีย์บอร์ดที่มองเห็นหน้าจอทำแบบนั้น ถ้าไม่มีลิงก์ข้าม พวกเขาต้องกด Tab ผ่านเมนูทั้งหมดในทุกหน้า

• ตั้งชื่อให้ตรงไปตรงมา: “ข้ามไปยังเนื้อหา”
• ชี้ไปที่ id="main" บนองค์ประกอบ main ในทุกเทมเพลตหน้า
• ซ่อนไว้นอกจอจนกว่าจะได้รับโฟกัส ห้ามใช้ display: none เพราะจะทำให้ลิงก์หายไปจากเส้นทางของคีย์บอร์ด
• ให้ลิงก์แสดงซ้อนอยู่บนส่วนหัวแบบติดจอ ไม่ใช่จมอยู่ข้างใต้

ลำดับโฟกัสที่ไล่ตามหน้าเว็บ

ปุ่ม Tab ไล่ตามลำดับในโค้ด HTML ไม่ใช่ตามเลย์เอาต์ที่ตาเห็น และปัญหามักเกิดตรงที่สองอย่างนี้ไม่ตรงกัน:

• การจัดลำดับใหม่ด้วย CSS Flexbox และ grid จัดเรียงส่วนหัวใหม่ให้ตาเห็นได้ ในขณะที่ลำดับ Tab ยังอยู่ที่เดิม
• ค่า tabindex ที่เป็นบวก จะแทนที่ลำดับตามธรรมชาติ และแทบทุกครั้งทำให้แย่ลง
• เมนูที่ปิดแล้วแต่ยังรับโฟกัสได้ เมนูที่เลื่อนซ่อนไว้นอกจอ อาจกินการกด Tab ไปเป็นสิบครั้ง โดยไม่มีอะไรเกิดขึ้นให้เห็นเลย ให้เอาออกจากลำดับ Tab ด้วยแอตทริบิวต์ hidden หรือ display: none หรือ inert

ตัวบ่งชี้โฟกัสที่มองเห็นได้จริง

สำหรับผู้ใช้คีย์บอร์ด ตัวบ่งชี้โฟกัส (focus indicator) ทำหน้าที่แทนตัวชี้เมาส์ ถ้าไม่มี การกด Tab ทุกครั้งก็เหมือนการเดา

ปรับสไตล์ได้ แต่อย่าลบทิ้ง

ความผิดพลาดคลาสสิกคือ outline: none ที่ใส่ไว้ เพราะมีคนไม่ชอบวงกรอบที่โผล่มาหลังคลิกเมาส์ ให้ใช้ selector :focus-visible แทน เบราว์เซอร์จะแสดงผลกับโฟกัสจากคีย์บอร์ด แต่มักไม่แสดงเมื่อคลิกลิงก์หรือปุ่ม วงกรอบจึงขึ้นให้คนที่ต้องใช้มันเห็น

ตัวบ่งชี้โฟกัสที่ดีต้อง:

• สังเกตได้ชัด: หนา 2 ถึง 3 พิกเซล และเว้นห่างจากองค์ประกอบเล็กน้อย
• คอนทราสต์สูง: อย่างน้อย 3:1 เทียบกับสีที่อยู่ติดกัน ซึ่งเป็นเกณฑ์คอนทราสต์ของสิ่งที่ไม่ใช่ข้อความ (Non-text Contrast) ของ WCAG สำหรับองค์ประกอบของอินเทอร์เฟซ (คู่มือคอนทราสต์สีและตัวอักษรที่ทุกคนอ่านได้ ของเราแสดงวิธีตรวจ)
• ใช้สองสี ในเว็บไซต์ที่มีทั้งส่วนพื้นสว่างและพื้นมืด
• ออกแบบไว้ก่อน ไม่ใช่ด้นเอาหน้างาน: เหมือนกันทุกลิงก์ ปุ่ม และช่องกรอก และวาดไว้ในไฟล์ออกแบบ คู่กับสถานะเมื่อชี้เมาส์

เกณฑ์ระดับ AAA ข้อ 2.4.13 ลักษณะของโฟกัส (Focus Appearance) กำหนดขนาดและคอนทราสต์ไว้ชัดเจน ซึ่งน่าหยิบมาใช้เป็นเป้าหมาย

อย่าให้ส่วนหัว แชต หรือแบนเนอร์คุกกี้ บังโฟกัส

เกณฑ์โฟกัสไม่ถูกบัง (ขั้นต่ำ) กำหนดว่าองค์ประกอบที่ได้รับโฟกัส ต้องไม่ถูกเนื้อหาที่เว็บไซต์ใส่เพิ่มเข้ามาบังจนมิด ส่วนเวอร์ชัน AAA ไม่ยอมให้บังเลยแม้แต่นิดเดียว ตัวการที่พบบ่อยคือ ส่วนหัวแบบติดจอ ที่ลิงก์เลื่อนไปอยู่ข้างใต้เมื่อมีคนกด Tab ย้อนขึ้นไปบนหน้า แบนเนอร์คุกกี้ที่เปิดค้างไว้ขณะผู้เข้าชมกด Tab ไปมาอยู่ข้างหลัง และปุ่มแชตหรือแถบ “โทร” ที่ติดอยู่ด้านล่างแล้วทับลิงก์ใกล้ท้ายหน้า

scroll-padding ของ CSS ทำให้เบราว์เซอร์เว้นที่ให้แถบที่ติดอยู่กับจอ เมื่อเลื่อนหน้าเพื่อพาองค์ประกอบที่ถูกโฟกัสเข้ามาให้เห็น:

/* Leave room for fixed bars when focus scrolls the page */
html {
  scroll-padding-top: 80px;    /* sticky header height */
  scroll-padding-bottom: 96px; /* bottom bar or chat button */
}

/* A two-tone ring that shows on light and dark backgrounds */
:focus-visible {
  outline: 3px solid #111;
  outline-offset: 2px;
  box-shadow: 0 0 0 2px #fff;
}

สำหรับแบนเนอร์คุกกี้ แนวทางของ W3C สำหรับเกณฑ์ข้อนี้ แนะนำให้ทำแบนเนอร์เป็นแบบโมดัล คือต้องตอบก่อนจึงใช้หน้าต่อได้ หรือเว้นที่ให้แบนเนอร์ด้วย scroll padding หรือปิดแบนเนอร์เมื่อโฟกัสย้ายไปที่อื่น

ดรอปดาวน์ที่ไม่ต้องพึ่งการชี้เมาส์

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

รูปแบบ disclosure

ดรอปดาวน์ที่เข้าถึงได้ ใช้รูปแบบ disclosure คือปุ่มที่กดแล้วแสดงหรือซ่อนรายการลิงก์

1. รายการแม่เป็นปุ่ม ที่มี aria-expanded="false" และเปลี่ยนเป็น true ขณะเปิด
2. กด Enter หรือ Space คลิก หรือแตะ เพื่อเปิด
3. Tab ไล่ผ่านลิงก์ข้างในตามลำดับ แล้วไปยังรายการระดับบนสุดถัดไป
4. Escape ปิดเมนู และส่งโฟกัสกลับไปที่ปุ่ม
5. เมนูปิดเมื่อโฟกัสหรือการคลิกย้ายไปที่อื่น

การชี้เมาส์ก็เปิดเมนูได้เช่นกัน ตราบใดที่การคลิกยังใช้ได้ แผงเมนูยังเปิดค้างเมื่อตัวชี้เลื่อนเข้าไป และกด Escape เพื่อปิดได้

รายการแม่ควรทำหน้าที่อะไร

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

ไม่ต้องใช้ role เมนูของ ARIA

ธีมและปลั๊กอินเมนูบางตัว ใส่ role menu และ menubar ให้กับการนำทางของเว็บไซต์ role เหล่านี้มีไว้สำหรับเมนูแบบแอปพลิเคชัน เหมือนเมนูของโปรแกรมบนคอมพิวเตอร์ และสัญญาว่าจะรองรับการใช้ปุ่มลูกศร ซึ่งงานที่ทำไว้ครึ่ง ๆ กลาง ๆ แทบไม่เคยทำได้จริง คู่มือ ARIA Authoring Practices ของ W3C อธิบายว่าทำไมตัวอย่างการนำทางแบบ disclosure จึงไม่ใช้ menu role เพราะการนำทางทั่วไปของเว็บไซต์ ไม่ต้องใช้การโต้ตอบด้วยคีย์บอร์ดตามที่รูปแบบเมนูกำหนด แค่ปุ่มธรรมดาและรายการลิงก์ภายใน nav ก็เพียงพอ

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

เมนูมือถือ: ปุ่มที่มีชื่อและสถานะที่ถูกต้อง

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

• ใช้ <button> จริง div หรือไอคอนที่แค่คลิกได้ ต้องทำใหม่ก่อน คีย์บอร์ดและโปรแกรมอ่านหน้าจอจึงจะใช้งานได้
• แสดงคำว่า “เมนู” ข้างไอคอน เพื่อให้ผู้ใช้ที่สั่งงานด้วยเสียงพูดว่า “คลิก เมนู” ได้ ปุ่มที่มีแค่ไอคอนต้องมี aria-label="Menu"
• บอกสถานะ ด้วย aria-expanded เพื่อให้โปรแกรมอ่านหน้าจอประกาศว่าเมนูยุบหรือขยายอยู่ และให้ชื่อปุ่มคงเดิม
• จัดการโฟกัส เมนูที่ดันเนื้อหาลงมา ตามหลังปุ่มในลำดับ Tab ได้เลย ส่วนเมนูที่ซ้อนเต็มจอทำงานเหมือนกล่องโต้ตอบ (dialog) คือย้ายโฟกัสเข้าไป เก็บโฟกัสไว้ข้างใน (ใส่ inert ให้ส่วนอื่นของหน้าช่วยได้) ปิดด้วย Escape หรือปุ่มปิดที่มีชื่อกำกับ แล้วส่งโฟกัสกลับไปที่ปุ่มเมนู
• ใช้ส่วนที่กดขยายได้สำหรับเมนูย่อย ไม่ใช่เมนูที่เด้งออกด้านข้าง

โครงร่างสำหรับใช้บรีฟนักพัฒนา:

<a class="skip-link" href="#main">Skip to content</a>
<header>
  <nav aria-label="Main">
    <button type="button" aria-expanded="false" aria-controls="site-menu">
      <svg aria-hidden="true"><!-- icon --></svg>
      Menu
    </button>
    <!-- a small script toggles aria-expanded and shows or hides the list -->
    <ul id="site-menu">
      <li><a href="/services/" aria-current="page">Services</a></li>
      <li><a href="/work/">Work</a></li>
      <li><a href="/contact/">Contact</a></li>
    </ul>
  </nav>
</header>
<main id="main">…</main>

แลนด์มาร์ก หน้าปัจจุบัน ขนาดจุดกด และชื่อ

แลนด์มาร์ก

องค์ประกอบ header nav main และ footer สร้างแลนด์มาร์ก (landmark) ที่ผู้ใช้โปรแกรมอ่านหน้าจอกระโดดไปมาได้ ใช้ main หนึ่งตัวต่อหน้า และตั้งชื่อ nav แต่ละตัว (เช่น “หลัก” “เบรดครัมบ์” “ส่วนท้าย”) โดยไม่ต้องใส่คำว่า “การนำทาง” เพราะโปรแกรมอ่านหน้าจอประกาศคำนี้อยู่แล้ว

ระบุหน้าปัจจุบัน

ใส่ aria-current="page" ให้ลิงก์ของหน้าปัจจุบันในเมนู และให้รายการสุดท้ายของเบรดครัมบ์ (breadcrumb) แล้วแสดงให้เห็นด้วยเส้นใต้หรือแถบ ไม่ใช่ใช้สีอย่างเดียว

ปุ่มและลิงก์ที่ใหญ่พอให้แตะ

เกณฑ์ขนาดเป้าหมาย (ขั้นต่ำ) ขอให้จุดที่คลิกหรือแตะได้มีขนาดอย่างน้อย 24 × 24 CSS พิกเซล หรือมีพื้นที่ว่างรอบจุดที่เล็กกว่านั้นมากพอ โดยลิงก์ที่อยู่ในประโยคได้รับการยกเว้น ให้ตั้งเป้าไว้ที่ 44 × 44 ซึ่งเหมาะกับนิ้วมากกว่า เพราะเป็นระดับ AAA ของ WCAG (หน่วย CSS พิกเซล) และเป็นขนาดตัวควบคุมเริ่มต้นใน Human Interface Guidelines ของ Apple สำหรับ iPhone (หน่วยพอยต์) ตรวจปุ่มปิด ลิงก์เปลี่ยนภาษา ไอคอนโซเชียล และลิงก์ในส่วนท้ายที่เรียงซ้อนกัน และทำให้คลิกได้ทั้งแถวของเมนู

ชื่อที่ตรงกับข้อความที่มองเห็น

การสั่งงานด้วยเสียงอาศัยเกณฑ์ป้ายกำกับอยู่ในชื่อ (Label in Name) คือชื่อในโค้ดควรมีข้อความที่มองเห็นอยู่ด้วย ปุ่มที่เขียนว่า “Contact” แต่มี aria-label="Get in touch with our friendly team" อาจไม่ตอบสนองเมื่อพูดว่า “click Contact” ถ้าต้องการบริบทเพิ่ม ให้ขึ้นต้นชื่อที่ซ่อนอยู่ด้วยคำที่มองเห็น

การนำทางที่สม่ำเสมอทุกหน้าและทุกภาษา

เกณฑ์การนำทางที่สม่ำเสมอ (Consistent Navigation) ขอให้เมนูที่ซ้ำอยู่หลายหน้า คงลำดับที่สัมพันธ์กันแบบเดิม ส่วนเกณฑ์ความช่วยเหลือที่สม่ำเสมอ (Consistent Help) ซึ่งเป็นเกณฑ์ใหม่ระดับ A ใน 2.2 ใช้กฎลำดับเดียวกันกับความช่วยเหลือที่ซ้ำอยู่หลายหน้า เช่น ข้อมูลติดต่อหรือลิงก์ขอความช่วยเหลือ

สำหรับ เว็บไซต์หลายภาษา ให้ทุกภาษาทำตามกฎเดียวกัน:

• โครงสร้างเดียวกัน ลำดับเดียวกัน ในทุกภาษา เพื่อให้การเปลี่ยนภาษาไม่ต้องเรียนรู้เมนูใหม่
• ปุ่มเปลี่ยนภาษาอยู่ที่เดิม ในทุกหน้า และเข้าถึงได้บนมือถือโดยไม่ต้องเลื่อน
• เรียกชื่อแต่ละภาษาด้วยภาษานั้นเอง พร้อมแอตทริบิวต์ lang ที่ตรงกัน เพื่อให้โปรแกรมอ่านหน้าจอออกเสียงถูก
• ลิงก์จริงไปยังหน้าที่ตรงกัน ไม่ใช่ดรอปดาวน์ที่เปลี่ยนภาษาทันที เมื่อผู้ใช้คีย์บอร์ดกดลูกศรผ่านตัวเลือก

ทดสอบ 5 นาทีแบบ “ถอดเมาส์”

เปิดหน้าแรกของคุณใน Chrome Edge หรือ Firefox (ใน Safari ให้ไปที่ การตั้งค่า → ขั้นสูง แล้วเปิดตัวเลือกให้กด Tab เพื่อไฮไลต์แต่ละรายการบนหน้าเว็บก่อน) แล้วดันเมาส์ให้พ้นมือ จากนั้น:

1. กด Tab หนึ่งครั้ง ลิงก์ข้ามต้องปรากฏขึ้น กด Enter แล้วกด Tab โฟกัสต้องไปอยู่ในเนื้อหาหลัก
2. กด Tab ไล่ผ่านส่วนหัว ทุกจุดที่หยุดต้องแสดงวงโฟกัสชัดเจน เรียงตามลำดับการอ่าน และไม่มีจุดหยุดที่มองไม่เห็น
3. เปิดดรอปดาวน์แต่ละอันด้วย Enter หรือ Space กด Tab ไล่ผ่าน แล้วกด Escape เมนูต้องปิด และโฟกัสกลับไปที่ปุ่มของมัน
4. กด Tab ไปจนถึงส่วนท้าย แล้วกด Shift+Tab ย้อนขึ้นไป ไม่มีองค์ประกอบที่ถูกโฟกัสไปซ่อนใต้ส่วนหัว แบนเนอร์คุกกี้ หรือปุ่มแชต และโฟกัสไม่ติดค้าง
5. ซูมเข้าจนเมนูมือถือปรากฏ เปิดเมนู ไล่ผ่าน แล้วปิดด้วย Escape โฟกัสต้องกลับไปที่ปุ่มเมนู
6. ลองส่งแบบฟอร์มติดต่อสอบถามถึงตัวเอง ถ้าคุณทำไม่ได้โดยไม่ใช้เมาส์ ผู้เข้าชมบางคนของคุณก็ทำไม่ได้เช่นกัน

ถ้ามีเวลาอีกสองนาที ลองใช้โปรแกรมอ่านหน้าจอ (VoiceOver ด้วย Cmd+F5 บน Mac หรือ NVDA ที่ใช้ฟรีบน Windows) ปุ่มเมนูควรประกาศชื่อของมัน บอกว่าเป็นปุ่ม และบอกว่าขยายอยู่หรือไม่

ทำอะไรต่อ

สไตล์โฟกัสต้องมีคนออกแบบ และพฤติกรรมของดรอปดาวน์ต้องมีคนเขียนโค้ด การนำทางที่เข้าถึงได้จึงจะใช้ได้จริง ก็ต่อเมื่อวางแผนงานออกแบบและงานพัฒนาไปพร้อมกัน ตั้งแต่ก่อนเขียนโค้ดบรรทัดแรก

ถ้าการทดสอบไม่ผ่านหลายขั้น ปัญหามักอยู่ที่ส่วนหัวเอง คือเมนูสำเร็จรูปที่ไม่เคยถูกสร้างมาให้ใช้กับคีย์บอร์ด ซึ่งการแก้ตามอาการมักอยู่ได้ไม่นาน การสร้างส่วนหัวใหม่ให้ถูกวิธี ไปพร้อมกับปรับโครงสร้าง ความเร็ว และเนื้อหา คือหน้าที่ของ การรีดีไซน์เว็บไซต์ ไม่แน่ใจว่าเว็บไซต์ของคุณแก้ของเดิมได้ไหม? เล่าให้เราฟังว่าการทดสอบเจออะไร หรืออ่าน บทความด้านการเข้าถึง อื่น ๆ ของเรา