5 ขั้นตอนในการออกแบบแอพโดยคำนึงถึงความสามารถในการเข้าถึงคีย์บอร์ด

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

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

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

การเข้าถึงแป้นพิมพ์ทำงานอย่างไร

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

พื้นฐานการนำทางด้วยแป้นพิมพ์

ต่อไปนี้คือคีย์พื้นฐานบางส่วนที่ใช้สำหรับการนำทางด้วยแป้นพิมพ์:

• การนำทางไปยังองค์ประกอบการควบคุมถัดไป: แท็บ (หรือปุ่มลูกศรขวาหรือลูกศรลงสำหรับปุ่มตัวเลือกที่เกี่ยวข้องและตัวเลือกที่เลือก)
• การนำทางไปยังองค์ประกอบการควบคุมก่อนหน้า: Shift + Tab (หรือปุ่มลูกศรซ้ายหรือลูกศรขึ้นสำหรับปุ่มตัวเลือกที่เกี่ยวข้องและตัวเลือกที่เลือก)
• การคลิกองค์ประกอบควบคุม: Enter และ/หรือ spacebar
• การนำทางระหว่างปุ่มตัวเลือกที่เกี่ยวข้องหรือเลือกตัวเลือก: ปุ่มลูกศร

เน้นสั่ง

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

คุณอาจชอบ: การออกแบบสากล: 11 เคล็ดลับการปฏิบัติเพื่อทำให้ไซต์และแอปของคุณสามารถเข้าถึงได้มากขึ้น

การเข้าถึงแป้นพิมพ์และแนวทางการเข้าถึงเนื้อหาเว็บ (WCAG)

หลักเกณฑ์การช่วยสำหรับการเข้าถึงเนื้อหาเว็บ (WCAG) ระบุระดับความสอดคล้องสามระดับ ได้แก่ ระดับ A ระดับ AA และระดับ AAA ซึ่งถูกนำมาใช้เป็นมาตรฐานสำหรับกฎหมายการเข้าถึงเว็บระดับภูมิภาคหรือระดับประเทศทั่วโลก

ความสามารถในการเข้าถึงคีย์บอร์ดเป็นหนึ่งในเกณฑ์ความสำเร็จสำหรับการปฏิบัติตามระดับ A เกณฑ์ระดับ A อธิบายคุณสมบัติที่ต้องมีสำหรับเนื้อหาเว็บทั้งหมด นอกจากนี้ยังถือว่าง่ายที่สุดในการติดตั้ง

“การเข้าถึงแป้นพิมพ์ยังผิดพลาดได้ง่ายหากเราไม่ระวัง”

การเข้าถึงคีย์บอร์ดยังผิดพลาดได้ง่ายหากเราไม่ระวัง ต่อไปนี้คือตัวอย่างปัญหาการเข้าถึงแป้นพิมพ์ทั่วไปที่พบในเว็บ:

• สถานะโฟกัสที่มองไม่เห็น
• ลำดับโฟกัสไม่ถูกต้อง
• องค์ประกอบแบบโต้ตอบที่ไม่สามารถรับโฟกัสได้
• คอมโพเนนต์ที่ซับซ้อนที่ไม่รับการโต้ตอบของแป้นพิมพ์

โชคดีที่มีเทคนิคมากมายที่เราสามารถใช้เพื่อระลึกถึงผู้ใช้แป้นพิมพ์และหลีกเลี่ยงข้อผิดพลาดเหล่านี้ในแอปของเรา

5 ขั้นตอนในการสร้างแอปที่เข้าถึงได้ด้วยแป้นพิมพ์

1. ออกแบบการโต้ตอบที่ใช้งานง่าย

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

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

ตัวอย่างเช่น บางครั้งนักพัฒนาซอฟต์แวร์ใช้ CSS เพื่อซ่อนปุ่มตัวเลือก HTML ดั้งเดิมเพื่อให้เห็นภาพที่มีสไตล์มากขึ้น ไม่ชัดเจนว่าอินพุตเป็นปุ่มตัวเลือกเบื้องหลัง ดังนั้นผู้ใช้แป้นพิมพ์อาจไม่ทราบว่าควรใช้ปุ่มลูกศร ไม่ใช่ปุ่ม Tab เพื่อเปลี่ยนโฟกัสระหว่างตัวเลือกที่เกี่ยวข้อง

เพื่อหลีกเลี่ยงปัญหานี้ เราควรแสดงบางสิ่งที่อย่างน้อยคล้ายกับองค์ประกอบ HTML ดั้งเดิมเพื่อให้สัญญาณภาพสำหรับทุกคนที่ต้องการหรือจำเป็นต้องโต้ตอบกับมันโดยใช้แป้นพิมพ์

2. สร้างแอปของคุณเพื่อให้แป้นพิมพ์สามารถทำทุกอย่างที่เมาส์ทำได้

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

JavaScript ช่วยให้เราสามารถเพิ่มตัวรับฟังเหตุการณ์ที่ทำให้องค์ประกอบที่ไม่ใช่การควบคุมตอบสนองต่อการคลิกเมาส์หรือท่าทาง ตัวอย่างเช่น ใน React เราสามารถใช้ onClick prop เพื่อเพิ่มการโต้ตอบให้กับองค์ประกอบรายการ

เมื่อใดก็ตามที่เราเพิ่มการโต้ตอบให้กับองค์ประกอบที่ไม่ใช่การควบคุม เราต้องตั้งค่าแอตทริบิวต์ tabIndex เป็น 0 สิ่งนี้จะช่วยให้องค์ประกอบได้รับโฟกัสในลำดับโฟกัสที่ถูกต้องเมื่อกดแป้น Tab เรายังต้องใช้ตัวจัดการเหตุการณ์การกดแป้นหรือคีย์ดาวน์เพื่อลงทะเบียน "การคลิก" ผ่านแป้น Enter และ/หรือ Spacebar (สามารถคลิกลิงก์ได้โดยใช้ทั้งสองอย่าง ในขณะที่ปุ่มรองรับเฉพาะแป้น Enter)

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

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

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

3. ทำงานพิเศษเมื่อแทนที่คำสั่งโฟกัสเริ่มต้น

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

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

คุณอาจชอบ: สร้างการนำทาง Breadcrumb ที่สามารถเข้าถึงได้ด้วย Liquid และ Shopify

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

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

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

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

4. เมื่อปรับแต่งสถานะโฟกัส ให้ออกแบบสำหรับผู้ใช้ที่ต้องการมากที่สุด

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

เป็นเรื่องปกติมากที่นักออกแบบและนักพัฒนาจะแทนที่สถานะโฟกัสเริ่มต้นที่แสดงผลโดยเบราว์เซอร์ ซึ่งอาจเกี่ยวข้องกับการอัปเดต outline เริ่มต้น หรือลบออกทั้งหมดและแทนที่ด้วยคุณสมบัติ CSS อื่น เช่น background border box-shadow color หรือ transform

คุณอาจชอบ: การสร้างเลขหน้าสำหรับผู้พิการด้วยของเหลว

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

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

แม้ว่าการแทนที่คุณสมบัติ outline เริ่มต้นจะยอมรับได้ แต่อย่าลบสถานะโฟกัสเริ่มต้นโดยไม่เปลี่ยน

5. ให้ทางลัดสำหรับผู้ใช้แป้นพิมพ์

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

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

เมื่อคลิกลิงก์ โฟกัสจะเลื่อนไปที่คอนเทนเนอร์เนื้อหาหลัก และผู้ใช้แป้นพิมพ์สามารถเริ่มแท็บผ่านองค์ประกอบการควบคุมหลักในหน้าได้ทันที

การข้ามลิงก์เป็นมากกว่าทางลัดที่สะดวกสบาย เป็นตัวอย่างของบล็อกบายพาส ซึ่งจำเป็นต้องเป็นไปตามมาตรฐานระดับ A WCAG

ทดสอบแอปของคุณบ่อยๆ ด้วยการเป็นผู้ใช้คีย์บอร์ดด้วยตัวเอง

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

ต่อไปนี้คือคำถามบางข้อที่ควรคำนึงถึงในขณะที่เราทดสอบแอพของเราสำหรับการเข้าถึงแป้นพิมพ์:

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

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

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