“การเข้าถึงสำหรับทุกคนดีต่อ SEO” เป็นประโยคที่ถูกพูดซ้ำบ่อย เพราะมันจริงอยู่ครึ่งหนึ่ง โปรแกรมอ่านหน้าจอ (screen reader) และเครื่องมือค้นหา ต่างก็อาศัยโค้ดเบื้องหลังของหน้าเว็บ ไม่ใช่แค่หน้าตาที่มองเห็น งานด้านการเข้าถึงกับงาน SEO จึงเป็นงานเดียวกันอยู่มาก แต่การเข้าถึงไม่ได้เป็นสัญญาณจัดอันดับในตัวเอง และวิธีทำ SEO บางอย่างที่ใช้กันมานาน ยังทำให้ผู้เข้าชมที่มีความพิการ ใช้งานหน้าเว็บได้ยากขึ้นด้วย
บทความนี้จะพาดูว่า งานไหนได้ผลสองต่อ งานไหนไม่มีผลต่อการค้นหา และวิธีทำ SEO แบบไหนที่ควรเลิก
คำตอบสั้น ๆ
การเข้าถึงสำหรับทุกคนกับ SEO ทับซ้อนกันที่รากฐาน ไม่ใช่ที่อันดับการค้นหา
- การเข้าถึงไม่ได้เป็นปัจจัยจัดอันดับในตัวเอง และ Google Search ไม่ได้ใช้คะแนนด้านการเข้าถึงของ Lighthouse
- รากฐานหลายอย่างให้ประโยชน์ทั้งสองฝั่ง ได้แก่ ชื่อหน้าที่สื่อความหมาย ลำดับหัวข้อที่เป็นหัวข้อจริง semantic HTML ข้อความลิงก์ที่มีความหมาย alt text ที่เขียนเพื่อคน และบทถอดความ (transcript)
- วิธีทำ SEO บางอย่างส่งผลเสียต่อการเข้าถึง เช่น alt text ที่ยัดคีย์เวิร์ด ลิงก์ “คลิกที่นี่” และหัวข้อที่เลือกตามคีย์เวิร์ด
- งานบางอย่างให้ผลแค่ฝั่งเดียว การใช้งานด้วยคีย์บอร์ดไม่ได้ขยับอันดับ ส่วน hreflang ก็ไม่ได้ช่วยผู้ใช้โปรแกรมอ่านหน้าจอเลย
การเข้าถึงมีผลต่ออันดับไหม?
ไม่ใช่ อย่างน้อยก็ไม่ใช่โดยตรง เอกสารเรื่องประสบการณ์หน้าเว็บ (page experience) ของ Google ถามถึง Core Web Vitals, HTTPS, การแสดงผลบนมือถือ โฆษณาและป๊อปอัปที่รบกวน และความง่ายในการแยกเนื้อหาหลักออกจากส่วนอื่น การทำตาม WCAG (แนวทางการเข้าถึงเนื้อหาเว็บ) ไม่ได้อยู่ในรายการนั้น และเอกสารของ Google Search ก็ไม่ได้บอกว่าเป็นสัญญาณจัดอันดับ
คะแนน Lighthouse เต็ม ไม่ได้ดันอันดับ
Lighthouse เป็นเครื่องมือทดสอบแบบแล็บ (lab) โดยจะโหลดหน้าเว็บ รันการตรวจอัตโนมัติที่สร้างบนเอนจิน axe-core แล้วถ่วงน้ำหนักผลผ่านหรือไม่ผ่าน ออกมาเป็นคะแนนเต็ม 100 Google Search ไม่ได้จัดอันดับจากคะแนน Lighthouse แม้แต่ Core Web Vitals ที่ Google ใช้จริงก็มาจากผู้ใช้ Chrome จริง ผ่าน Chrome UX Report
คะแนนนี้ยังบอกเรื่องการเข้าถึงได้น้อยกว่าที่เห็น การตรวจยืนยันได้ว่ารูปมี alt text แต่ยืนยันไม่ได้ว่าข้อความนั้นถูกต้อง หรือผู้ใช้คีย์บอร์ดติดอยู่ในป๊อปอัปหรือไม่ นี่คือเหตุผลที่ เครื่องมือตรวจอัตโนมัติ เป็นแค่ส่วนหนึ่งของการตรวจสอบการเข้าถึง
จุดที่การเข้าถึงกับ SEO ทับซ้อนกัน
โปรแกรมอ่านหน้าจอไม่ได้เห็นดีไซน์ของคุณ มันอ่าน accessibility tree ซึ่งเป็นแผนที่ของหัวข้อ ลิงก์ ปุ่ม และช่องกรอกข้อมูล ที่เบราว์เซอร์สร้างขึ้นจาก HTML ของคุณ เครื่องมือค้นหาก็อ่านและเรนเดอร์ HTML ชุดเดียวกัน ข้อความตัวหนาขนาด 24 พิกเซลที่ไม่ได้มาร์กอัปเป็นหัวข้อ ก็เป็นแค่ข้อความธรรมดาสำหรับโปรแกรมอ่านหน้าจอ ส่วน <div> ที่ใส่ตัวจัดการคลิกไว้ ก็ไม่ใช่ลิงก์ ทั้งสำหรับโปรแกรมอ่านหน้าจอและครอว์เลอร์ของ Google
ตัวเลขในตารางคือเกณฑ์ความสำเร็จ (success criteria) ของ WCAG 2.2 ซึ่ง อธิบายไว้ในบทความ WCAG 2.2
ชื่อหน้าที่ชัดเจนและไม่ซ้ำกัน
<title> คือสิ่งแรกที่โปรแกรมอ่านหน้าจอประกาศ เมื่อเปิดหน้าใหม่ และเป็นชื่อบนแท็บเบราว์เซอร์ Google ระบุว่ามันเป็นแหล่งแรกสำหรับ title link แม้ Google อาจเขียนใหม่ได้ ให้ขึ้นต้นด้วยหัวเรื่อง ปิดท้ายด้วยชื่อแบรนด์ และอย่าใช้ชื่อซ้ำ “บริการ | Acme” ไม่ได้ช่วยใครเลย ส่วน “งานตกแต่งและปรับปรุงสำนักงาน | Acme” ทำหน้าที่ได้ทั้งสองอย่าง
ลำดับหัวข้อที่เป็นโครงของหน้า
แบบสำรวจผู้ใช้โปรแกรมอ่านหน้าจอของ WebAIM พบซ้ำหลายครั้งว่า การไล่ดูตามหัวข้อ เป็นวิธีที่นิยมที่สุดในการหาข้อมูลบนหน้ายาว ๆ คู่มือ SEO Starter Guide ของ Google บอกว่าลำดับหัวข้อสำคัญต่อโปรแกรมอ่านหน้าจอ มากกว่าต่อ Search ดังนั้นทำให้ถูกเพื่อคน คือมี H1 เดียวที่บอกว่าหน้านี้เกี่ยวกับอะไร ใช้ H2 สำหรับส่วนหลัก H3 สำหรับส่วนย่อยภายใน และไม่ข้ามระดับ
ลองตรวจเอง อ่านเฉพาะหัวข้อ ในรายการหัวข้อของโปรแกรมอ่านหน้าจอ หรือในส่วนขยายที่แสดงโครงหน้า หัวข้อเหล่านั้นควรอ่านได้เหมือนสารบัญ คู่มือ on-page SEO อธิบายว่าโครงนี้ช่วยส่วนอื่นของหน้าอย่างไร
semantic HTML และลิงก์ที่เป็นลิงก์จริง
อิลิเมนต์มาตรฐานของ HTML มีความหมายติดตัวมาเอง <button> ใช้งานด้วยคีย์บอร์ดได้และถูกประกาศว่าเป็นปุ่ม ส่วน <a href> ถูกประกาศว่าเป็นลิงก์ และบอกเบราว์เซอร์ว่าจะไปที่ไหน Google บอกว่าครอว์ลได้เฉพาะลิงก์ที่เป็นอิลิเมนต์ <a> ที่มีแอตทริบิวต์ href ดังนั้น “ลิงก์” ที่สร้างจาก <span> กับ JavaScript อาจซ่อนหน้าไว้จากทั้งเครื่องมือค้นหา และผู้ใช้คีย์บอร์ดพร้อมกัน
ใช้ลิงก์เมื่อพาไปที่อื่น ใช้ปุ่มเมื่อสั่งให้ทำอะไรสักอย่าง และใช้ ARIA เฉพาะเมื่อ HTML ไม่มีอิลิเมนต์ที่ตรงกัน อีกข้อคือ ให้ข้อความเป็นข้อความจริง พาดหัวที่ฝังอยู่ในรูปแบนเนอร์ปรับขนาดไม่ได้ แปลไม่ได้ และเครื่องมือค้นหาอ่านได้ไม่แน่นอน (1.4.5)
ข้อความลิงก์ที่เข้าใจได้ในตัวเอง
ผู้ใช้โปรแกรมอ่านหน้าจอ มักเปิดรายการลิงก์ทั้งหมดบนหน้า ซึ่งลิงก์สิบอันที่เขียนว่า “อ่านต่อ” ไม่ได้ช่วยให้เลือกอะไรได้เลย Google บอกว่า anchor text บอกอะไรบางอย่างเกี่ยวกับหน้าที่ถูกลิงก์ไป แก้ครั้งเดียวได้ผลทั้งสองฝั่ง คือเขียนว่า “ดูโปรเจกต์คลังสินค้าของเรา” แล้วให้คำเหล่านั้นเป็นลิงก์
ถ้าดีไซน์ต้องใช้ปุ่มสั้น ๆ บนการ์ด ให้ทั้งการ์ดเป็นลิงก์เดียว ที่ตั้งชื่อตามหัวข้อการ์ด หรือเพิ่มข้อความที่ซ่อนจากสายตา ให้อ่านได้ว่า “อ่านต่อเรื่องการออกแบบคลังสินค้า” บทความ internal link และโครงสร้างเว็บไซต์ อธิบาย anchor text ในระดับทั้งเว็บไซต์
alt text ที่เขียนเพื่อคนที่มองไม่เห็นรูป
Google บอกว่าใช้ alt text ร่วมกับ computer vision และเนื้อหาบนหน้า เพื่อทำความเข้าใจรูปภาพ ทั้งสองกลุ่มต้องการคำอธิบายสั้น ๆ ที่ถูกต้อง ว่ารูปนั้นสื่ออะไร ในตำแหน่งนั้นของหน้า
- ภาพถ่าย: “โครงเหล็กของคลังสินค้าสองชั้น ที่ติดตั้งโครงถักหลังคาแล้ว”
- รูปที่เป็นลิงก์: อธิบายปลายทาง เช่น ชื่อสินค้าบนภาพย่อ
- แผนภูมิ: บอกข้อสรุปหลัก แล้วใส่รายละเอียดไว้ในข้อความหรือตารางใกล้ ๆ
- รูปตกแต่ง: ใส่
alt="" ว่างไว้ เพื่อให้โปรแกรมอ่านหน้าจอข้ามไป
ไม่ต้องเขียน “รูปภาพของ” เพราะโปรแกรมอ่านหน้าจอบอกอยู่แล้วว่าเป็นรูปภาพ
คำบรรยายและบทถอดความของวิดีโอและเสียง
คำบรรยายใต้ภาพ (caption) ช่วยคนหูหนวกหรือมีปัญหาการได้ยิน และทุกคนที่ดูแบบปิดเสียง บทถอดความทำแบบเดียวกันให้พอดแคสต์ และเหมาะกับคนที่ชอบอ่านข้าม ๆ ในด้านการค้นหา บทถอดความสำคัญที่สุด อย่าคิดว่าคำบรรยายในเครื่องเล่นวิดีโอ จะนับเป็นเนื้อหาของหน้า แต่บทถอดความบนหน้าเป็นข้อความที่เครื่องมือค้นหา index และยกไปอ้างอิงได้
แก้คำบรรยายอัตโนมัติเสมอ โดยเฉพาะชื่อเฉพาะและศัพท์เทคนิค ถ้าภาพในวิดีโอมีข้อมูลสำคัญ ระดับ AA ยังกำหนดให้มีเสียงบรรยายภาพ (audio description) ด้วย (1.2.5) การพากย์ที่อธิบายสิ่งที่อยู่บนจอไปด้วย ช่วยลดงานส่วนนี้ได้เกือบทั้งหมด
โครงสร้างเดียวกันช่วย AI agent ด้วย
AI agent ที่ท่องเว็บ ซึ่งคลิกผ่านเว็บไซต์แทนใครสักคน บางตัวอ่าน accessibility tree ควบคู่กับภาพหน้าจอ ปุ่มไอคอนที่ไม่มีชื่อจึงทำให้มันงงได้ เหมือนที่ทำให้โปรแกรมอ่านหน้าจองง ณ เวลาที่เขียน (สิงหาคม 2026) agent แต่ละตัวอ่านหน้าเว็บต่างกัน semantic HTML จึงเป็นทางเลือกที่ปลอดภัยในทุกกรณี บทความ AI browsing agent กับเว็บไซต์ของคุณ ลงรายละเอียดไว้
วิธีทำ SEO ที่ส่งผลเสียต่อการเข้าถึง
วิธีส่วนใหญ่ในนี้ ไม่เคยเป็น SEO ที่ดีมาตั้งแต่แรก ที่ยังใช้กันอยู่ เพราะดูเหมือนเป็นการปรับแต่ง SEO
alt text ที่ยัดคีย์เวิร์ด
“รับเหมาก่อสร้าง คลังสินค้า ผู้รับเหมา อาคารอุตสาหกรรม” จะถูกอ่านออกเสียงทีละคำ และการยัดคีย์เวิร์ดในรูปตกแต่ง ทำให้รูปที่ควรถูกข้าม กลายเป็นเสียงขัดจังหวะ คำแนะนำเรื่องรูปภาพของ Google เตือนว่าแอตทริบิวต์ alt ที่อัดแน่นด้วยคีย์เวิร์ด อาจทำให้เว็บไซต์ถูกมองว่าเป็นสแปม
“คลิกที่นี่” และ anchor ตรงคีย์เวิร์ดทุกลิงก์
ข้อความลิงก์กว้าง ๆ แบบนี้ ไม่ได้ช่วยทั้งสองฝั่ง แบบตรงกันข้ามก็เช่นกัน การใช้วลีคีย์เวิร์ดเดิมเป็น anchor text ในทุกลิงก์ที่ชี้ไปหน้าเดียวกัน ฟังผ่านโปรแกรมอ่านหน้าจอแล้วเหมือนแผ่นเสียงตกร่อง
หัวข้อที่เลือกตามคีย์เวิร์ด ไม่ใช่ตามโครงสร้าง
ใส่แท็กหัวข้อให้สโลแกน และข้อความสั้น ๆ ในส่วนท้ายเว็บ เพื่อ “ให้คีย์เวิร์ดได้อยู่ใน H2” เลื่อนบูลเล็ตขึ้นเป็น H3 หรือซ่อน H1 ที่อัดคีย์เวิร์ดไว้นอกจอ ทุกอย่างนี้ทำให้โครงหน้า ที่ผู้ใช้โปรแกรมอ่านหน้าจอใช้นำทาง รกไปหมด จัดรูปแบบข้อความด้วย CSS และเลือกระดับหัวข้อตามโครงสร้าง
ข้อความซ่อนและ ARIA ที่ใช้เก็บคีย์เวิร์ด
นโยบายสแปมของ Google มุ่งจัดการข้อความที่ซ่อนไว้เพื่อปั่นอันดับ และยอมรับอย่างชัดเจนว่า ข้อความสำหรับผู้ใช้โปรแกรมอ่านหน้าจอเท่านั้น ไม่ใช่ปัญหา ปัญหาเริ่มเมื่อข้อความที่ซ่อนจากสายตา หรือ aria-label กลายเป็นที่เก็บคีย์เวิร์ด ผู้ใช้โปรแกรมอ่านหน้าจอได้ยินทุกคำ และเพราะ aria-label จะแทนที่ข้อความที่มองเห็นของลิงก์ สำหรับเทคโนโลยีสิ่งอำนวยความสะดวก ผู้ใช้ที่สั่งงานด้วยเสียงโดยพูดคำที่มองเห็น อาจกดลิงก์นั้นไม่ได้ WCAG กำหนดให้ชื่อที่เข้าถึงได้ (accessible name) ต้องมีข้อความป้ายกำกับที่มองเห็นอยู่ด้วย (2.5.3)
จุดที่การเข้าถึงกับ SEO ไม่ซ้อนกัน
แอตทริบิวต์ lang กับ hreflang
แอตทริบิวต์ lang บอกโปรแกรมอ่านหน้าจอว่าต้องใช้กฎการออกเสียงแบบไหน ทั้งกับทั้งหน้า (3.1.1) และกับข้อความช่วงที่เป็นภาษาอื่น (3.1.2) Google บอกว่าไม่ได้ใช้ข้อมูลภาษาระดับโค้ดอย่าง lang แต่ดูจากเนื้อหาที่มองเห็น hreflang เชื่อมหน้าที่เทียบเท่ากันในภาษาต่าง ๆ สำหรับการค้นหา ส่วนโปรแกรมอ่านหน้าจอไม่ได้ใช้มันเลย เว็บไซต์หลายภาษาต้องมีทั้งสองอย่าง ในทุกเวอร์ชันภาษา ตามที่ คู่มือ SEO หลายภาษา อธิบายไว้
งานการเข้าถึงที่ไม่มีผลต่ออันดับ
การใช้งานด้วยคีย์บอร์ด โฟกัสที่มองเห็นได้ คอนทราสต์ของสี ข้อความที่ใช้งานได้เมื่อซูม 200% ช่องกรอกที่มีป้ายกำกับ และข้อความแจ้งข้อผิดพลาดที่ชัดเจน งานเหล่านี้ไม่มีผลต่ออันดับโดยตรง แต่แต่ละอย่างอาจเป็นตัวตัดสินว่า ผู้เข้าชมที่มีความพิการ จะติดต่อสอบถามได้สำเร็จหรือไม่ ถ้าขายเรื่องการเข้าถึงในองค์กรว่าเป็นโปรเจกต์ SEO งานเหล่านี้คือสิ่งแรกที่จะถูกตัดทิ้ง บทความ เหตุผลทางธุรกิจของการเข้าถึง อธิบายเหตุผลของการเข้าถึง โดยไม่ต้องอิง SEO และ คู่มือ web accessibility บอกว่าควรเริ่มจากตรงไหน
งาน SEO ที่ไม่ถูกอ่านออกเสียง
meta description, structured data, แท็ก canonical และ sitemap กำหนดว่าเครื่องมือค้นหาจะครอว์ลและแสดงหน้าอย่างไร และไม่มีส่วนไหนถูกอ่านออกเสียงบนหน้าเลย คู่มือเว็บไซต์ที่เป็นมิตรกับ SEO ครอบคลุมรากฐานเหล่านั้น
ตรวจรอบเดียว ได้ทั้งสองฝั่ง
เริ่มจากเทมเพลตหลัก (หน้าแรก หน้าบริการ หน้าบทความ หน้าติดต่อ) แล้วต่อด้วยหน้าที่แก้ไขบ่อยที่สุด
ตรวจอย่างไร เครื่องมือครอว์ลเว็บไซต์จะรายงาน title, H1, alt text ที่หายไป และลิงก์ที่ครอว์ลไม่ได้ทั้งเว็บ ส่วนแผง Accessibility ใน Chrome DevTools แสดงชื่อและบทบาทที่คำนวณได้ของทุกอิลิเมนต์ จากนั้นลองกด Tab ไล่ทั้งหน้า และใช้โปรแกรมอ่านหน้าจอสักสิบนาที (VoiceOver บน Mac และ iPhone หรือ NVDA ที่ใช้ฟรีบน Windows) ถ้ารายการหัวข้อและรายการลิงก์ อ่านแยกออกมาแล้วไม่เข้าใจ แปลว่าโครงสร้างยังต้องปรับ
คำถามที่พบบ่อย
การเข้าถึงช่วย SEO ไหม?
ช่วยทางอ้อม มาร์กอัปที่ทำให้หน้าใช้งานกับโปรแกรมอ่านหน้าจอได้ ยังช่วยให้เครื่องมือค้นหาเข้าใจหน้านั้นด้วย แต่ตัวการเข้าถึงเองไม่ได้เป็นปัจจัยจัดอันดับ
accessibility overlay ช่วย SEO ได้ไหม?
ไม่มีข้อมูลใดที่ Google เผยแพร่ ที่บอกว่า overlay ช่วยเรื่องอันดับ และมันยังเพิ่มสคริปต์จากภายนอกเข้าไปในทุกหน้า นอกจากนี้ overlay ยังซ่อมมาร์กอัปเบื้องหลัง ที่โปรแกรมอ่านหน้าจอ คีย์บอร์ด และเครื่องมือค้นหาต้องพึ่งพา ให้ถูกต้องได้ไม่แน่นอน
alt text ควรมีคีย์เวิร์ดไหม?
เฉพาะเมื่อคีย์เวิร์ดเป็นส่วนหนึ่ง ของคำอธิบายที่ถูกต้องจริง ๆ ถ้ารูปแสดงงานตกแต่งภายในสำนักงาน คำว่า “ตกแต่งภายในสำนักงาน” อาจควรอยู่ใน alt text แต่รายการวลีค้นหาไม่ควรอยู่
ขั้นต่อไป
แก้รากฐานที่ใช้ร่วมกันก่อน เพราะเป็นงานชิ้นเดียวที่ได้ผลกับสองกลุ่ม และคุ้มที่สุดเมื่อทำครั้งเดียว ในเทมเพลตและแนวทางการเขียนเนื้อหา จากนั้นค่อยทำงานที่เป็นเรื่องการเข้าถึงล้วน ๆ เพราะมีคนที่ต้องใช้มันจริง ๆ
ถ้าอยากได้มุมมองจากภายนอกในฝั่งการค้นหา ตรวจสอบเว็บไซต์ฟรี ของเราจะตรวจการมองเห็นบน Google (ชื่อหน้า การ index และโครงสร้างหน้า) ควบคู่กับความเร็ว มือถือ ความปลอดภัย และเส้นทางการติดต่อ แต่ไม่ใช่การทดสอบการเข้าถึง การทำตาม WCAG การใช้งานด้วยคีย์บอร์ด และการใช้โปรแกรมอ่านหน้าจอ เป็นหน้าที่ของ การตรวจสอบการเข้าถึง และถ้ากำลังจะ รีดีไซน์เว็บไซต์ นั่นคือจังหวะที่จะสร้างทั้งสองอย่างเข้าไป ตั้งแต่โค้ดบรรทัดแรก