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