ฉันใช้เว็บแค่วันเดียวโดยใช้คีย์บอร์ด

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

ใครใช้แป้นพิมพ์เพื่อนำทาง?

ผู้ใช้แป้นพิมพ์โดยทั่วไปมีสามประเภท:

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

เรากำลังพูดถึงผู้ใช้กี่คน?

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

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

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

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

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

“คนตาบอดจำเป็นต้องเข้าถึงคีย์บอร์ดเต็มรูปแบบ ระยะเวลา."

— David Macdonald บรรณาธิการร่วมของการใช้ WAI ARIA ใน HTML5

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

2.3% ของคนอเมริกัน (ทุกวัย) มีความบกพร่องทางสายตา ซึ่งไม่จำเป็นต้องรับประกันการใช้โปรแกรมอ่านหน้าจอทั้งหมด ในปี 2559 Addy Osmani ประมาณการการใช้งานโปรแกรมอ่านหน้าจอจริงจะอยู่ที่ประมาณ 1 ถึง 2% หากเรานำผู้ใช้เหล่านี้มาพิจารณาร่วมกับผู้ใช้ที่มีความบกพร่องด้านการเคลื่อนไหวและผู้ใช้ระดับสูง การใช้แป้นพิมพ์จะเพิ่มขึ้นเป็นเปอร์เซ็นต์ของผู้ชมทั่วโลก ดังนั้น การดูแลเรื่องการช่วยสำหรับการเข้าถึงด้วยแป้นพิมพ์ไม่ได้เป็นเพียงการทำสิ่งที่ถูกต้องตามหลักศีลธรรม (และในทางกฎหมาย หลายๆ ประเทศต้องการให้เว็บไซต์เข้าถึงได้ตามกฎหมาย) แต่ยังสมเหตุสมผลในเชิงธุรกิจอีกด้วย

จากทั้งหมดที่กล่าวมา สถานะของเว็บในปัจจุบันเป็นอย่างไร? ถึงเวลาที่จะหา!

การทดลอง

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

คุณสมบัติ autofocus

ฉันคิดว่าสิ่งนี้จะเน้นที่ JavaScript ในการโหลดหน้าต่าง แต่เบราว์เซอร์นี้จัดการด้วยแอตทริบิวต์ autofocus ในองค์ประกอบอินพุต

ในฐานะผู้ใช้แป้นพิมพ์ที่มองเห็นได้ ฉันพบว่าสิ่งนี้มีประโยชน์อย่างยิ่ง ในฐานะผู้ใช้โปรแกรมอ่านหน้าจอตาบอด ฉันไม่แน่ใจว่าจะชอบหรือไม่ ความเห็นพ้องต้องกันคือการใช้ autofocus อย่างรอบคอบนั้นเป็นเรื่องปกติ ในกรณีที่หน้านั้นมีจุดประสงค์เพื่อโต้ตอบกับแบบฟอร์ม (เช่น หน้า Landing Page ของ Google หรือแบบฟอร์มการติดต่อไซต์)

สไตล์โฟกัสเริ่มต้น

ฉันค้นหา Whose Line Is It Anything? ดี และอดไม่ได้ที่จะสังเกตว่า YouTube ไม่ได้กำหนดรูปแบบ :focus ที่กำหนดเองใดๆ เลย แทนที่จะอาศัยสไตล์ดั้งเดิมของเบราว์เซอร์เพื่อระบุองค์ประกอบที่ฉันกำลังแท็บด้วยสายตา

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

ฉันย้อนเวลากลับไปค่อนข้างไกล:

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

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

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

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

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

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

ตัวเลือก CSS :focus-visible CSS

หากคุณต้องการสิ่งที่ดีที่สุดของทั้งสองโลก คุณอาจต้องการสำรวจ CSS4 :focus-visible pseudo-class ซึ่งจะช่วยให้คุณกำหนดสไตล์การโฟกัสที่แตกต่างกันขึ้นอยู่กับบริบท :focus-visible จะกำหนดเป้าหมายเฉพาะองค์ประกอบที่เน้นด้วยแป้นพิมพ์ ไม่ใช่ด้วยการคลิกเมาส์ สิ่งนี้ยอดเยี่ยมมาก แม้ว่าปัจจุบันรองรับเฉพาะใน Firefox เท่านั้น สามารถเปิดใช้งานใน Chrome ได้โดยเปิดแฟล็ก 'Experimental Web Platform Features'

วิดีโอ YouTube และการช่วยสำหรับการเข้าถึงแป้นพิมพ์

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

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

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

ฉันเผลอแตะปุ่ม "แสดงเพิ่มเติม" โดยไม่ได้ตั้งใจเพราะฉันไม่เห็นการใช้สไตล์ :focus เลย ไม่ว่าจะกำหนดเองหรือเนทีฟ ฉันพบว่าสไตล์ดั้งเดิมถูกแทนที่ด้วย outline-width :

การช่วยการเข้าถึงแป้นพิมพ์ GitHub

โอเค เวลาทำงาน ที่ไหนดีกว่าที่จะทำงานมากกว่าที่บ้านของรหัส github.com?

ฉันสังเกตเห็นสามสิ่งเกี่ยวกับ GitHub: หนึ่งที่ยอดเยี่ยม หนึ่งสมเหตุสมผล และหนึ่งแย่

ประการแรกความดี

'ข้ามไปยังเนื้อหา' ลิงค์

GitHub เสนอลิงก์ Skip to content ซึ่งข้ามผ่านเมนูหลัก

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

หรือบางไซต์เลือกที่จะวางเนื้อหาหลักก่อนในลำดับการอ่าน เหนือการนำทาง วิธีการนี้ล้าสมัยเนื่องจากเป็นการฝ่าฝืนแนวทางในการทำให้เนื้อหา DOM ของคุณตรงกับลำดับภาพ (เว้นแต่การนำทางของคุณจะปรากฏที่ด้านล่าง) และในขณะที่วิธีนี้หมายความว่าเราไม่ต้องการลิงก์ 'ข้ามการนำทาง' เลย เราอาจต้องการลิงก์ 'ข้าม ไปยัง การนำทาง' แทน

แท็บเพื่อดูเนื้อหา

คุณลักษณะหนึ่งที่ฉันสังเกตเห็นว่าทำงานแตกต่างไปจากเวอร์ชัน 'ที่ไม่ใช่แป้นพิมพ์' คือตัวบ่งชี้การแบ่งรหัส

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

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

ลิงค์ที่มองไม่เห็น

ปัญหาหนึ่งที่ฉันเจอคือมีลิงก์ "มองไม่เห็น" หลังจากแท็บผ่านรูปโปรไฟล์ของฉันที่ด้านบนขวา ลำดับแท็บของฉันจะแท็บไปที่รูปภาพ จากนั้นไปที่ลิงก์ที่มองไม่เห็น จากนั้นไปที่ปุ่ม 'ดู' บน repo (ดู gif ด้านล่าง) ฉันไม่รู้ว่าลิงก์ล่องหนทำอะไร ดังนั้นเมื่อฉันรู้ว่าฉันอยู่บนนั้น ฉันกด ENTER และออกจากระบบทันที!

ในการตรวจสอบอย่างใกล้ชิด ดูเหมือนว่าฉันได้ไปที่แบบฟอร์ม "โปรแกรมอ่านหน้าจอเท่านั้น" ( sr-only คือชื่อคลาสของโปรแกรมอ่านหน้าจอทั่วไป) ซึ่งมีคุณลักษณะ "ออกจากระบบ"

ลิงก์ออกจากระบบนี้ เพิ่มเติม จากลิงก์ออกจากระบบในเมนูแบบเลื่อนลงโปรไฟล์ของคุณ:

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

วิธีสร้างทางลัด 'ข้ามไปยังเนื้อหา'

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

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

ลิงก์ทางลัดควรปรากฏตามหลังแท็กเปิด <body> อาจ ปรากฏขึ้นภายหลังใน DOM แม้จะอยู่ด้านหลังส่วนท้าย โดยที่คุณมีแอตทริบิวต์ tabindex="1" เพื่อบังคับให้เป็นองค์ประกอบแบบโต้ตอบแรกในลำดับแท็บ อย่างไรก็ตาม การใช้ tabindex ที่มีตัวเลขมากกว่าศูนย์มักเป็นแนวทางที่ไม่ดี และมักจะส่งผลให้เกิดการเตือนเมื่อใช้เครื่องมือตรวจสอบความถูกต้อง เช่น Lighthouse

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

 <a class="screen-reader-shortcut" href="#main-content"> Skip to main content </a>

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

 .screen-reader-shortcut { position: absolute; top: -1000em; } .screen-reader-shortcut:focus { position: fixed; top: 0; left: 0; z-index: 999; /* ...and now any nice styling you want to apply... */ padding: 1em; background-color: rgb(114, 105, 105); color: white; text-decoration: none; }

จริง ๆ แล้วเราข้ามไปที่อะไร? #main-content อะไร ? มันสามารถเป็นอะไรก็ได้:

1. เนื้อหาแบบอินไลน์
   เช่น id ของแท็ก h1 ของคุณ: <h1 id="main-content">
2. คอนเทนเนอร์
   เช่น id ของคอนเทนเนอร์รอบๆ เนื้อหาหลักของคุณ เช่น <main id="main-content">
3. พี่น้องผู้ประกาศข่าว
   คุณสามารถเชื่อมโยงไปยังแท็กที่มีชื่ออยู่เหนือเนื้อหาหลักของคุณ เช่น <a name="main-content"></a> แนวทางนี้มักจะอธิบายไว้ในบทช่วยสอนที่เก่ากว่า — ฉันจะไม่แนะนำในทุกวันนี้

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

#main-content ของคุณควรมี tabindex เป็น -1 เพื่อให้แน่ใจว่าสามารถโฟกัสแบบเป็นโปรแกรมได้ โปรแกรมอ่านหน้าจอบางตัวอาจไม่เชื่อฟังลิงก์ข้าม

 <h1 tabindex="-1">This is the title of the page</h1>

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

ทำไมเราถึงคิดค้นล้อใหม่?

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

ตั้งแต่ HTML5 เรามีองค์ประกอบเชิงความหมายเช่น <main> , <nav> และ <header> ก่อนหน้านั้น เรามีจุดสังเกตของ ARIA เช่น role="main" , role="navigation" และ role="banner" ตามลำดับ ในภูมิทัศน์ปัจจุบันของเว็บ แนวปฏิบัติที่ดีที่สุดกำหนดว่าคุณต้องการทั้งสองอย่าง กล่าวคือ <main role="main"> ซึ่งเป็นการละเมิดหลักการ DRY อย่างร้ายแรง แต่เราไปต่อแล้ว

ด้วยความสมบูรณ์ของความหมายนี้ คุณจึงหวังว่าเบราว์เซอร์จะเริ่มสนับสนุนการนำทางผ่านจุดสังเกตเหล่านี้โดยกำเนิด เช่น โดยการเปิดเผยแป้นพิมพ์ลัดให้ผู้ใช้แท็บตรงไปยังส่วน <main> ของหน้าเว็บ ไม่มีโชคเช่นนี้ - ไม่มีการสนับสนุนในขณะนี้ ทางออกที่ดีที่สุดของคุณคือการใช้ส่วนขยาย Landmark Navigation ผ่านแป้นพิมพ์สำหรับ Chrome, Opera หรือ Firefox

อย่างไรก็ตาม ผู้ใช้โปรแกรมอ่านหน้าจอ สามารถ เริ่มนำทางไปยังบริเวณจุดสังเกตเหล่านี้ได้โดยตรง ตัวอย่างเช่น บน VoiceOver บน Mac คุณสามารถกด CTRL + ALT + U เพื่อเปิดเมนู Landmarks และไปที่จุดสังเกต 'หลัก' ซึ่งเป็นทางลัดที่รวดเร็วและสม่ำเสมอเพื่อไปยังเนื้อหาหลัก แน่นอนว่าต้องอาศัยไซต์ที่ทำเครื่องหมายเอกสารอย่างถูกต้อง

นี่เป็นจุดเริ่มต้นที่ดีสำหรับไซต์ของคุณ หากคุณต้องการให้ไซต์นำทางผ่านภูมิภาคที่เป็นสถานที่สำคัญได้:

 <body> <header role="banner"> <!-- Logo and things can go here --> <nav role="navigation"> <!-- Site navigation links go here --> </nav> </header> <main role="main"> <!-- Main content lives here - including our h1 --> </main> <footer role="contentinfo"> <!-- Copyright statement, etc --> </footer> </body>

มาร์กอัปทั้งหมดนี้เป็นงานที่กระหายน้ำ เวลาสำหรับกาแฟ

Pact Coffee

ฉันจำได้ว่าเห็นใบปลิวสำหรับ pactcoffee.com... ไปดูกันเลย!

แบนเนอร์คุกกี้

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

ฉันใช้ส่วนขยายการเข้าถึง ChromeLens เพื่อติดตามลำดับแท็บของหน้า:

ซึ่งสามารถแก้ไขได้โดยการย้ายประกาศไปที่ด้านบนของเอกสาร (ยังคงสามารถตรึงไว้ที่ด้านล่างด้วยสายตาด้วย CSS) หรือโดยการเพิ่ม tabindex="1" ไปที่ปุ่ม OK ฉันขอแนะนำให้ใช้การแก้ไขนี้กับเนื้อหาใดๆ ที่ผู้ใช้ต้องการยกเลิกการแก้ไขนี้

ลิงค์ที่มองไม่เห็นเพิ่มเติม

เช่นเดียวกับ GitHub ฉันพบว่าตัวเองกำลังแท็บไปยังองค์ประกอบนอกหน้าจอซึ่งมีวัตถุประสงค์ไม่ชัดเจน ปรากฏว่าเป็นการสลับ 'ดูน้อยลง…' ซึ่งอยู่ ด้านหลัง การ์ด 'ดูเพิ่มเติม…'

นี่เป็นเพราะว่าพื้นที่ 'ซ่อน' ไม่ได้ถูกซ่อนจริงๆ มันแค่หมุนไป 180 องศา โดยใช้:

 transform: rotateY(180deg);

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

สั่งกาแฟ. ถึงเวลาดำเนินการวิจัยต่อแล้ว

ไอทีเวิลด์

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

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

ฉันขุดซอร์สโค้ดเพื่อค้นหาว่าเกิดอะไรขึ้น สักครู่ ฉันคิดว่ามันอาจจะเป็นตัวซวยของเรา ซึ่งเป็นคุณสมบัติ CSS ของ outline

การตรวจสอบลิงก์ "อัปเดตการตั้งค่าความเป็นส่วนตัว" ฉันสามารถเห็น outline: 0 ตามที่ฉันสงสัย ดังนั้นบางที ฉัน อาจเพ่งความสนใจไปที่ปุ่มต่างๆ แต่ไม่มีการตอบสนองด้วยภาพเมื่อสิ่งนั้นเกิดขึ้น

ฉันพยายามตั้งค่าสถานะเป็น :hover เพื่อดูว่าฉันพลาดรูปแบบใด ๆ ในฐานะผู้ใช้แป้นพิมพ์หรือไม่:

แน่นอนว่าลิงก์เปลี่ยนเป็นสีส้มที่สวยงามอย่างเห็นได้ชัดเมื่อวางเมาส์เหนือ ซึ่งเป็นสิ่งที่ฉันไม่เคยเห็นในโฟกัส:

ฮูรา! แตกมัน! ฉันไม่เคยเห็นสถานะ :focus เพราะการใช้สไตล์แบบกำหนดเองถูกนำไปใช้กับ :hover เท่านั้น ฉันต้องข้ามปุ่มโดยไม่ได้สังเกตใช่ไหม

ผิด. แม้ว่าฉันจะแฮ็ค CSS ในเครื่อง ฉันก็ไม่เห็นการจัดสไตล์โฟกัสเลย หมายความว่าฉันไม่ค่อยได้เข้าไปที่คุกกี้โมดอลด้วยซ้ำ จากนั้นฉันก็รู้ว่า… ลิงก์ไม่มีแอตทริบิวต์ href :

นั่น คือผู้กระทำความผิดที่แท้จริง outline: 0 ไม่ใช่ปัญหา — เบราว์เซอร์ไม่เคยไปที่แท็บไปที่ลิงก์เพราะไม่ใช่ลิงก์ที่ถูกต้อง!

จากข้อกำหนด HTML 5.2:

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

การระบุแอตทริบิวต์ href ให้กับลิงก์แม้ว่าจะเป็นเพียง # จะทำให้ลิงก์ถูกต้องและเพิ่มลงในลำดับแท็บของหน้า

ที่น่าตลกคือ ต่อมาในวันนั้น ฉันถูกส่งบทความเกี่ยวกับ PC World เพื่ออ่าน และฉันพบปัญหา เดียวกัน ทุกประการ

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

Kinetico

ก๊อกน้ำในครัวของฉันรั่ว และฉันตั้งใจจะเปลี่ยนมัน ฉันเห็นโฆษณาในหนังสือพิมพ์ท้องถิ่นของ kinetico.co.uk เลยคิดว่าจะลองดู

ฉันไม่สามารถนำทางไปยังส่วน 'Kitchen Taps' ได้ เนื่องจากลิงก์ซ่อนอยู่หลังลิงก์หลัก 'Salt & Cartridges' ซึ่งจะแสดงเฉพาะลิงก์ย่อยเมื่อวางเมาส์เหนือ เป็นเรื่องที่น่าสนใจที่ไซต์มีความคิดก้าวหน้ามากพอที่จะให้ลิงก์ 'ข้ามไปยังเนื้อหา' (ดูสั้น ๆ ใน gif ด้านบน) แต่ไม่สามารถสร้างเมนูที่สามารถเข้าถึงได้!

นี่คือจุดที่เมนูผิดพลาด โดยจะแสดงเฉพาะเมนูย่อยเมื่อวางรายการเมนูหลักไว้เหนือ:

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

 li:hover .nav_sub_menu, li:focus .nav_sub_menu { }

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

 li:hover .nav_sub_menu, a:focus + .nav_sub_menu { }

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

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

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

 li:hover .nav_sub_menu, /* hover over parent menu item, show child menu */ a:focus + .nav_sub_menu, /* focus onto parent menu item, show child menu */ .nav_sub_menu:focus-within { /* focus onto child menu item, keep showing child menu */ }

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

อันที่จริง เมนูที่ขับเคลื่อนด้วย JS อาจเป็นทางเลือกที่ดีกว่าในกรณีนี้ เนื่องจากเบราว์เซอร์รองรับโซลูชันนี้ค่อนข้างแย่ :focus-within ใช้ได้เฉพาะใน Chrome, Firefox และ Safari เท่านั้น แม้แต่ใน Chrome ฉันพบว่ามันเข้ากันไม่ได้กับ display: none ตรรกะใดที่ใช้แสดง/ซ่อนเมนูย่อย ฉันต้องซ่อนรายการเมนูโดยการตั้งค่า opacity: 0 แทน

ตกลง ฉันทำเสร็จแล้วสำหรับวันนี้ ถึงเวลาปิดท้ายด้วยโซเชียลมีเดียแล้ว

เฟสบุ๊ค

Facebook ทำงานได้อย่างยอดเยี่ยมที่นี่ โดยมอบมาสเตอร์คลาสในการเข้าถึงคีย์บอร์ด

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

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

คุณลักษณะที่มีประโยชน์มากที่สุดคือ Facebook มีทางลัด OPT + / (หรือ ALT + / ) เพื่อกลับไปที่เมนูเมื่อใดก็ได้ โดยใช้แอตทริบิวต์ aria-keyshortcuts

 <div class="a11y-help"> Press opt + / to open this menu </div> <div aria-label="Navigation Assistant" aria-keyshortcuts="Alt+/" role="menubar"> <a class="screen-reader-shortcut" tabindex="1" href="#main-content"> Skip to main content </a> </div>

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

นี่คือ JS บางส่วนที่ซ่อนและแสดงพื้นที่ menubar ซึ่งเป็นจุดเริ่มต้นที่มีประโยชน์:

 const a11yArea = document.querySelector('*[role="menubar"]'); document.addEventListener('keydown', (e) => { if (e.altKey && e.code === 'Slash') { a11yArea.style.display = a11yArea.style.display === 'block' ? 'none' : 'block'; } });

สรุป

การทดลองนี้เป็นประสบการณ์การใช้คีย์บอร์ดที่ยอดเยี่ยมและไม่ดี ฉันมีสามประเด็นหลัก

ให้มันมีสไตล์

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

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

ความหมายคือกุญแจสำคัญ

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

ลองดูรหัสนี้ที่นี่:

 <span>Click here</span>

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

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

ใช้คุณสมบัติดั้งเดิมของแพลตฟอร์ม เขียน HTML ที่ดีและสะอาด และใช้ตัวตรวจสอบความถูกต้อง เช่น https://validator.w3.org เพื่อตรวจจับสิ่งต่างๆ เช่น แอตทริบิวต์ href ที่ขาดหายไปบนจุดยึดของคุณ

เนื้อหาสำคัญ

คุณอาจจำเป็นต้องแสดงประกาศเกี่ยวกับคุกกี้ แบบฟอร์มสมัครสมาชิก โฆษณาหรือประกาศการบล็อกโฆษณา

ทำทุกอย่างที่ทำได้เพื่อทำให้ประสบการณ์เหล่านี้ไม่สร้างความรำคาญ หากคุณไม่สามารถทำให้พวกเขาไม่สร้างความรำคาญได้ อย่างน้อยก็ทำให้พวกเขาถูกมองข้าม

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

สุดท้าย สนับสนุนผู้ใช้ของคุณในการเข้าถึงเนื้อหาของคุณโดยเร็วที่สุดโดยใช้ลิงก์ 'ข้ามไปยังเนื้อหาหลัก' Holy Grail

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