การตรวจสอบว่าเว็บไซต์หรือแอปพลิเคชันของคุณสามารถเข้าถึงได้หรือไม่อาจฟังดูยุ่งยาก หากคุณเพิ่งจะพูดถึงเรื่องการช่วยเหลือพิเศษเป็นครั้งแรก หัวข้อที่กว้างเกินไปอาจทำให้คุณสงสัยว่าต้องเริ่มต้นอย่างไร แน่นอนว่าการพยายามอำนวยความสะดวกให้แก่ผู้พิการด้านต่างๆ ก็หมายความว่าจะต้องพิจารณาปัญหาที่หลากหลายตามไปด้วย
โพสต์นี้แบ่งปัญหาเหล่านี้ออกเป็นกระบวนการแบบทีละขั้นตอนและเป็นเหตุเป็นผลสำหรับการตรวจสอบเว็บไซต์ที่มีอยู่สำหรับการเข้าถึง
เริ่มด้วยแป้นพิมพ์
สำหรับผู้ใช้ที่ไม่สามารถหรือเลือกที่จะไม่ใช้เมาส์ การนำทางด้วยแป้นพิมพ์เป็นวิธีการหลักในการเข้าถึงทุกอย่างบนหน้าจอ กลุ่มเป้าหมายนี้รวมถึงผู้ใช้ที่มีความบกพร่องทางการเคลื่อนไหว เช่น การบาดเจ็บจากความเครียดซ้ำๆ (RSI) หรือเป็นอัมพาต รวมถึงผู้ใช้โปรแกรมอ่านหน้าจอ
เพื่อประสบการณ์การใช้งานแป้นพิมพ์ที่ดี ให้มุ่งจัดลำดับแท็บที่สมเหตุสมผลและรูปแบบการโฟกัสที่ชัดเจน
เริ่มจากไปที่แท็บต่างๆ ในเว็บไซต์ ลำดับการโฟกัสองค์ประกอบ ควรเป็นไปตามลำดับ DOM หากไม่แน่ใจว่าองค์ประกอบใดควรได้รับโฟกัส โปรดดูพื้นฐานการโฟกัสเพื่อทบทวนความรู้ แนวทางปฏิบัติแนะนำคือการควบคุมที่ผู้ใช้โต้ตอบด้วยหรือให้อินพุตได้ควรโฟกัสได้และแสดงสัญญาณบอกสถานะโฟกัส (เช่น วงแหวนโฟกัส)
ส่วนควบคุมแบบอินเทอร์แอกทีฟที่กำหนดเองควรโฟกัสได้ หากคุณใช้ JavaScript ในการเปลี่ยน
<div>ให้เป็นเมนูแบบเลื่อนลงที่สวยงาม ระบบจะไม่แทรก URL ดังกล่าวในลำดับแท็บโดยอัตโนมัติ หากต้องการทำให้การควบคุมที่กำหนดเองโฟกัสได้ ให้กำหนดtabindex="0"ค่าtabindexที่มากกว่า 0 จะเปลี่ยนลำดับแท็บและอาจสร้างความสับสนให้กับผู้ใช้โปรแกรมอ่านหน้าจอทำให้โฟกัสได้เฉพาะเนื้อหาแบบอินเทอร์แอกทีฟ การเพิ่ม
tabindexลงในองค์ประกอบที่ไม่ใช่แบบอินเทอร์แอกทีฟ เช่น ส่วนหัว ทำให้ผู้ใช้แป้นพิมพ์ที่เห็นหน้าจอช้าลง และไม่ช่วยผู้ใช้โปรแกรมอ่านหน้าจอเนื่องจากโปรแกรมอ่านหน้าจอรู้ว่าจะอ่านออกเสียงข้อความเหล่านั้นอยู่แล้วหากคุณเพิ่มเนื้อหาใหม่ในหน้าเว็บ ให้มุ่งเน้นความสนใจของผู้ใช้ไปที่เนื้อหานั้นก่อนเพื่อให้ผู้ใช้ดำเนินการกับเนื้อหานั้นได้ โปรดดูตัวอย่างในการจัดการโฟกัสที่ระดับหน้าเว็บ
ออกแบบเว็บไซต์เพื่อให้ผู้ใช้โฟกัสองค์ประกอบถัดไปได้เสมอเมื่อต้องการ ระวังวิดเจ็ตเติมข้อความอัตโนมัติและบริบทอื่นๆ ที่อาจดักจับโฟกัสของแป้นพิมพ์ได้ คุณจะดักจับโฟกัสได้ชั่วคราวเมื่อต้องการให้ผู้ใช้โต้ตอบกับโมดัล ไม่ใช่กับส่วนที่เหลือของหน้า แต่ควรให้วิธีที่ใช้แป้นพิมพ์เพื่อออกจากโมดัลได้เสมอ โปรดดูตัวอย่างโมดัลและกับดักแป้นพิมพ์
ทำให้การควบคุมโฟกัสใช้งานได้
หากคุณสร้างการควบคุมที่กำหนดเอง อนุญาตให้ผู้ใช้เข้าถึงฟีเจอร์ทั้งหมดโดยใช้แป้นพิมพ์เท่านั้น โปรดอ่านการจัดการโฟกัสในคอมโพเนนต์เพื่อดูเทคนิคในการปรับปรุงการเข้าถึงแป้นพิมพ์
จัดการเนื้อหานอกหน้าจอ
เว็บไซต์จำนวนมากมีเนื้อหานอกหน้าจอที่อยู่ใน DOM แต่มองไม่เห็น เช่น ลิงก์ภายในเมนูลิ้นชักที่ปรับเปลี่ยนตามอุปกรณ์หรือปุ่มภายในหน้าต่างโมดัลที่ยังไม่ได้แสดง การวางองค์ประกอบเหล่านี้ไว้ใน DOM จะสร้างประสบการณ์การใช้แป้นพิมพ์ที่สับสน โดยเฉพาะสำหรับโปรแกรมอ่านหน้าจอซึ่งจะประกาศเนื้อหานอกหน้าจอราวกับว่าเนื้อหานั้นเป็นส่วนหนึ่งของหน้า
ดูการจัดการเนื้อหานอกหน้าจอสำหรับเคล็ดลับในการจัดการกับองค์ประกอบเหล่านี้
ทดสอบด้วยโปรแกรมอ่านหน้าจอ
การปรับปรุงการรองรับแป้นพิมพ์ทั่วไปจะเป็นการวางรากฐานสำหรับขั้นตอนถัดไป นั่นคือการตรวจสอบหน้าเว็บเพื่อดูการติดป้ายกำกับและความหมายที่เหมาะสม รวมถึงสิ่งกีดขวางการนำทางด้วยโปรแกรมอ่านหน้าจอ
หากไม่คุ้นเคยกับวิธีที่เทคโนโลยีความช่วยเหลือพิเศษตีความมาร์กอัปเชิงความหมาย โปรดอ่านโครงสร้างเนื้อหา
- ตรวจหาข้อความ
altที่เหมาะสมในรูปภาพทั้งหมด มีข้อยกเว้นสำหรับวิธีนี้เมื่อรูปภาพมีจุดประสงค์เพื่อการนำเสนอเป็นหลักและไม่ใช่เนื้อหาสำคัญ หากต้องการบ่งบอกว่าโปรแกรมอ่านหน้าจอควรข้ามรูปภาพ ให้ตั้งค่าค่าเป็นสตริงว่างเปล่า:alt="" - เลือกตัวควบคุมทั้งหมดสำหรับป้ายกำกับ สำหรับการควบคุมที่กำหนดเอง อาจต้องใช้
aria-labelหรือaria-labelledbyดู ป้ายกำกับและความสัมพันธ์ ARIA เพื่อดูตัวอย่าง - ตรวจสอบการควบคุมที่กำหนดเองทั้งหมดสำหรับ
roleที่เหมาะสมและแอตทริบิวต์ ARIA ที่จำเป็นซึ่งสื่อสารสถานะของตัวเอง เช่น ช่องทำเครื่องหมายที่กำหนดเองต้องมีrole="checkbox"และaria-checked="true|false"จึงจะสื่อถึงสถานะได้อย่างเหมาะสม ดูข้อมูลเบื้องต้นเกี่ยวกับ ARIA เพื่อดูภาพรวมทั่วไปว่า ARIA อธิบายความหมายที่ขาดหายไปสำหรับการควบคุมที่กำหนดเองได้อย่างไร - ทำให้การรับส่งข้อมูลผ่านหน้าเว็บของคุณเหมาะสม เนื่องจากโปรแกรมอ่านหน้าจอจะไปยังส่วนต่างๆ ของหน้าเว็บตามลำดับ DOM โปรแกรมจะประกาศองค์ประกอบที่คุณเปลี่ยนตำแหน่งภาพโดยใช้ CSS ตามลำดับที่ไม่สื่อความหมาย หากต้องการให้แสดงอะไรก่อนหน้าในหน้าเว็บ ให้ย้ายตำแหน่งนั้นมาไว้ที่ช่วงต้นของ DOM
- มุ่งมั่นที่จะรองรับการไปยังส่วนต่างๆ ด้วยโปรแกรมอ่านหน้าจอสำหรับเนื้อหาทั้งหมดในหน้า ตรวจสอบว่าไม่มีส่วนใดของเว็บไซต์ที่ซ่อนหรือถูกบล็อกอย่างถาวรจากการเข้าถึงโปรแกรมอ่านหน้าจอ
- หากควรซ่อนเนื้อหาจากโปรแกรมอ่านหน้าจอ เช่น หากเป็นเนื้อหาที่ไม่ได้อยู่ในหน้าจอหรือแค่การนำเสนอ ให้ตั้งค่าเนื้อหานั้นเป็น
aria-hidden="true"หากต้องการคำอธิบายที่ละเอียดยิ่งขึ้น โปรดดูที่ การซ่อนเนื้อหา
- หากควรซ่อนเนื้อหาจากโปรแกรมอ่านหน้าจอ เช่น หากเป็นเนื้อหาที่ไม่ได้อยู่ในหน้าจอหรือแค่การนำเสนอ ให้ตั้งค่าเนื้อหานั้นเป็น
ทำความคุ้นเคยกับโปรแกรมอ่านหน้าจอ
แม้ว่าการเรียนรู้โปรแกรมอ่านหน้าจออาจดูเป็นเรื่องยุ่งยาก แต่ที่จริงแล้วโปรแกรมอ่านหน้าจอนั้นใช้งานง่าย โดยทั่วไป นักพัฒนาซอฟต์แวร์ส่วนใหญ่รับด้วยคำสั่งคีย์ง่ายๆ เพียงไม่กี่คำสั่ง
ถ้าคุณใช้ Mac ให้ดูวิดีโอนี้เกี่ยวกับ VoiceOver โปรแกรมอ่านหน้าจอที่มากับ Mac OS หากใช้ PC โปรดดูวิดีโอนี้เกี่ยวกับ NVDA ซึ่งเป็นโปรแกรมอ่านหน้าจอแบบโอเพนซอร์สที่รองรับการบริจาคสำหรับ Windows
aria-hidden ไม่ป้องกันการโฟกัสแป้นพิมพ์
สิ่งสำคัญคือต้องเข้าใจว่า ARIA จะส่งผลต่อความหมายขององค์ประกอบเท่านั้น โดยไม่มีผลกระทบต่อลักษณะการทำงานขององค์ประกอบ คุณซ่อนองค์ประกอบไม่ให้โปรแกรมอ่านหน้าจอซ่อนด้วย aria-hidden="true" ได้ แต่การดำเนินการดังกล่าวจะไม่เปลี่ยนแปลงพฤติกรรมการโฟกัสขององค์ประกอบนั้น สำหรับเนื้อหาอินเทอร์แอกทีฟนอกหน้าจอ
สำหรับเนื้อหาแบบอินเทอร์แอกทีฟนอกหน้าจอ ให้ใช้แอตทริบิวต์ inert
เพื่อตรวจสอบว่าได้นำออกจากการไหลของแป้นพิมพ์จริงๆ สำหรับเบราว์เซอร์รุ่นเก่า ให้รวม aria-hidden="true" กับ tabindex="-1"
องค์ประกอบแบบอินเทอร์แอกทีฟควรระบุวัตถุประสงค์และสถานะ
การบอกใบ้ด้วยภาพหรือราคาว่าตัวควบคุมสามารถทำอะไรได้บ้างเพื่อให้ผู้คนหลากหลายอุปกรณ์หลากหลายประเภทใช้งานและไปยังส่วนต่างๆ ในเว็บไซต์ของคุณได้
- องค์ประกอบแบบอินเทอร์แอกทีฟ เช่น ลิงก์และปุ่ม ควรแตกต่างจากองค์ประกอบที่ไม่มีการโต้ตอบ ผู้ใช้จะไปยังส่วนต่างๆ ของเว็บไซต์หรือแอปได้ยากเมื่อไม่สามารถบอกได้ว่าองค์ประกอบสามารถคลิกได้หรือไม่ การระบุองค์ประกอบแบบอินเทอร์แอกทีฟ มีอยู่หลายวิธี แนวทางปฏิบัติทั่วไปอย่างหนึ่งคือขีดเส้นใต้ลิงก์ เพื่อแยกความแตกต่างจากข้อความที่อยู่โดยรอบ
- เช่นเดียวกับข้อกำหนดในการโฟกัส องค์ประกอบแบบอินเทอร์แอกทีฟ เช่น ลิงก์และปุ่ม จะต้องมีสถานะ
hoverเพื่อบอกผู้ใช้เมาส์เมื่อตัวชี้อยู่เหนือสิ่งที่คลิกได้ อย่างไรก็ตาม หากต้องการทำให้วิธีการป้อนข้อมูลอื่นๆ เข้าถึงองค์ประกอบเหล่านี้ได้ จะต้องแยกแยะองค์ประกอบเหล่านี้โดยไม่มีสถานะhover
ใช้ประโยชน์จากส่วนหัวและจุดสังเกต
ส่วนหัวและองค์ประกอบจุดสังเกตช่วยสร้างโครงสร้างตามความหมายของหน้าเว็บ และเพิ่มประสิทธิภาพการนำทางของผู้ใช้เทคโนโลยีความช่วยเหลือพิเศษได้อย่างมาก ผู้ใช้โปรแกรมอ่านหน้าจอหลายคนรายงานว่าเมื่อมาที่หน้าที่ไม่คุ้นเคยเป็นครั้งแรก ผู้ใช้มักจะพยายามไปยังส่วนต่างๆ โดยใช้ส่วนหัว
ในทำนองเดียวกัน โปรแกรมอ่านหน้าจอให้คุณข้ามไปยังจุดสังเกตที่สำคัญ เช่น <main> และ <nav> ได้ด้วย ด้วยเหตุนี้ คุณจึงควรคำนึงถึงวิธีใช้โครงสร้างของหน้าเว็บเพื่อเป็นแนวทางให้ผู้ใช้ได้รับประสบการณ์การใช้งาน
- ใช้ลำดับชั้น
h1-h6ให้คิดว่าส่วนหัวเป็นเครื่องมือในการสร้างเค้าโครงของหน้าเว็บ อย่าใช้การจัดรูปแบบส่วนหัวในตัว แต่ให้ปฏิบัติเสมือนว่ามีขนาดเท่ากันทั้งหมดและใช้ระดับที่เหมาะสมเชิงความหมายสำหรับเนื้อหาระดับประถมศึกษา มัธยมศึกษา และอุดมศึกษา แล้วใช้ CSS เพื่อให้ส่วนหัว เข้ากับการออกแบบ - ใช้องค์ประกอบและบทบาทจุดสังเกตเพื่อให้ผู้ใช้ข้ามผ่านเนื้อหาที่ซ้ำกันได้ เทคโนโลยีความช่วยเหลือมากมายมีทางลัดเพื่อข้ามไปยังส่วนที่เฉพาะเจาะจงของหน้าเว็บ เช่น เทคโนโลยีที่กำหนดโดยองค์ประกอบ
<main>หรือ<nav>องค์ประกอบเหล่านี้มีบทบาท จุดสังเกตโดยนัย คุณยังใช้แอตทริบิวต์roleของ ARIA เพื่อกำหนดภูมิภาคในหน้าอย่างชัดแจ้ง เช่น<div role="search">ได้อีกด้วย ดูตัวอย่างเพิ่มเติมที่ Semantics และการไปยังเนื้อหา - หลีกเลี่ยงการใช้
role="application"เว้นแต่คุณจะเคยใช้งานมาก่อน บทบาทจุดสังเกตapplicationจะบอกให้เทคโนโลยีความช่วยเหลือพิเศษปิดใช้ทางลัด และส่งผ่านการกดแป้นทั้งหมดไปยังหน้าเว็บ ซึ่งหมายความว่าแป้นต่างๆ ที่ผู้ใช้โปรแกรมอ่านหน้าจอมักจะใช้เพื่อไปยังส่วนต่างๆ ของหน้าเว็บจะใช้งานไม่ได้อีกต่อไป และคุณจะต้องใช้การจัดการแป้นพิมพ์ทั้งหมดด้วยตนเอง
ตรวจสอบส่วนหัวและจุดสังเกตด้วยโปรแกรมอ่านหน้าจอ
โปรแกรมอ่านหน้าจอ เช่น VoiceOver และ NVDA จะมีเมนูตามบริบทสำหรับข้ามไปยังภูมิภาคที่สำคัญในหน้าเว็บ เมื่อทดสอบการเข้าถึง คุณสามารถใช้เมนูเหล่านี้เพื่อดูภาพรวมของหน้าเว็บและพิจารณาว่าระดับส่วนหัวเหมาะสมหรือไม่และใช้จุดสังเกตใด
หากต้องการดูข้อมูลเพิ่มเติม โปรดดูวิดีโอให้คำแนะนำเหล่านี้เกี่ยวกับพื้นฐานของ VoiceOver และ NVDA
ทำให้กระบวนการเป็นแบบอัตโนมัติ
การทดสอบเว็บไซต์เพื่อการเข้าถึงด้วยตนเองอาจเป็นเรื่องน่าเบื่อหน่ายและเกิดข้อผิดพลาดได้ง่าย ข้อดีคือการทดสอบอัตโนมัติให้มากที่สุดเท่าที่จะเป็นไปได้ คุณสามารถใช้ส่วนขยายของเบราว์เซอร์และชุดทดสอบ การช่วยเหลือพิเศษของบรรทัดคำสั่งได้
- หน้าเว็บผ่านการทดสอบทั้งหมดจากเบราว์เซอร์ aXe หรือ WAVE หรือไม่ คุณยังมีตัวเลือกอื่นๆ อีกด้วย แต่ส่วนขยายดังกล่าวอาจเป็นส่วนเสริมที่เป็นประโยชน์สำหรับขั้นตอนการทดสอบด้วยตนเองเนื่องจากจะเจอปัญหาเล็กๆ น้อยๆ เช่น อัตราส่วนคอนทราสต์ที่ไม่สำเร็จและแอตทริบิวต์ ARIA ที่ขาดหายไป
- หากต้องการใช้งานบรรทัดคำสั่ง axe-cli จะมีฟีเจอร์เดียวกันกับส่วนขยายเบราว์เซอร์ aXe แต่เรียกใช้จากเทอร์มินัลได้
- เพื่อหลีกเลี่ยงการถดถอย โดยเฉพาะอย่างยิ่งในสภาพแวดล้อมการผสานรวมอย่างต่อเนื่อง ให้ใส่ไลบรารี เช่น axe-core ในชุดทดสอบอัตโนมัติ ซึ่ง axe-core เป็นเครื่องมือเดียวกับที่ขับเคลื่อนส่วนขยาย aXe Chrome แต่ใช้ในยูทิลิตีบรรทัดคำสั่ง
- หากคุณใช้เฟรมเวิร์กหรือไลบรารี มีเครื่องมือช่วยเหลือพิเศษของตนเองหรือไม่ เช่น protractor-accessibility-plugin สำหรับ Angular ใช้ประโยชน์จากเครื่องมือที่เรามีให้เป็นประโยชน์
ใช้ Lighthouse เพื่อทดสอบ PWA
Lighthouse คือเครื่องมือที่ใช้วัดประสิทธิภาพของ Progressive Web App (PWA) และใช้ไลบรารี Axe-core เพื่อขับเคลื่อนการทดสอบการช่วยเหลือพิเศษ
หากคุณใช้ Lighthouse อยู่แล้ว ให้มองหาการทดสอบการช่วยเหลือพิเศษที่ไม่สำเร็จในรายงาน แก้ไขข้อผิดพลาดเพื่อปรับปรุงประสบการณ์โดยรวมของผู้ใช้ในเว็บไซต์