Smashing Podcast ตอนที่ 4 ด้วย Heydon Pickering: องค์ประกอบแบบรวมคืออะไร?

เผยแพร่แล้ว: 2022-03-10
สรุปอย่างย่อ ↬ ในตอนนี้ของ Smashing Podcast เรากำลังพูดถึงส่วนประกอบที่ครอบคลุม การรวมเข้าด้วยกันหรือไม่ต้องพูดถึงองค์ประกอบหมายความว่าอย่างไร แล้วมันเกี่ยวอะไรกับการช่วยการเข้าถึง? Drew McLellan คุยกับ Heydon Pickering ผู้เขียน Smashing เพื่อหาคำตอบ

วันนี้ฉันคุยกับ Heydon Pickering เกี่ยวกับหนังสือเล่มใหม่ของเขา Inclusive Components Heydon เป็นที่รู้จักจากผลงานและการเขียนเรื่องการเข้าถึงได้ ดังนั้น "Inclusive Design" หมายถึงอะไรจริง ๆ และองค์ประกอบต่างๆ เข้ามามีบทบาทอย่างไร Heydon อธิบายทั้งหมดนี้และอื่น ๆ ในตอนนี้ คุณสามารถฟังด้านล่างหรือสมัครรับข้อมูลได้ทุกที่ที่มีพอดแคสต์ของคุณ

แสดงหมายเหตุ

  • The book Inclusive Components จาก Smashing Magazine
  • โครงการของ Heydon ทุก เลย์เอาต์กับ Andy Bell
  • เว็บไซต์ของ Heydon Heydonworks
  • Heydon บน Twitter

การถอดเสียง

รูปภาพของ เฮย์ดอน พิกเคอริง Drew McLellan: เขาเป็นที่ปรึกษาด้านการเข้าถึงเว็บอิสระ นักออกแบบส่วนต่อประสานและนักเขียน งานของเขามุ่งเน้นไปที่การออกแบบประสบการณ์ผู้ใช้ที่เข้าถึงได้ตลอดจนการเขียนและการแก้ไขสำหรับ Smashing Magazine เขาเป็นผู้เขียนหนังสือที่มีชื่อเสียงเกี่ยวกับการออกแบบเว็บแอปพลิเคชันที่เข้าถึงได้ Apps For All และเพิ่งเปิดตัวหนังสือเล่มใหม่ Inclusive Components ทั้งหมดเกี่ยวกับวิธีสร้างเว็บอินเทอร์เฟซที่เข้าถึงได้อีกครั้งด้วย Smashing Magazine เห็นได้ชัดว่าเขาเป็นผู้เชี่ยวชาญในเรื่องของการออกแบบที่เข้าถึงได้ แต่คุณรู้ไหมว่าเขาเป็นมนุษย์คนแรกที่กระโดดสะพานซิดนีย์ฮาร์เบอร์ด้วยเรือเร็ว เพื่อนยอดเยี่ยมของฉัน ยินดีต้อนรับ Heydon Pickering สวัสดี Heydon คุณเป็นอย่างไรบ้าง?

Heydon Pickering: ฉันยอดเยี่ยมมาก ฉันอยู่ในแบรนด์

ดรูว์: วันนี้ฉันอยากคุยกับคุณเกี่ยวกับหัวข้อของหนังสือเล่มใหม่ของคุณ ส่วนประกอบรวม

เฮย์ดอน: ครับ

Drew: เห็นได้ชัดว่าเป็นเพียงชื่อคำสองคำ แต่ฉันรู้สึกว่าแต่ละคำเหล่านั้นช่วยยกน้ำหนักได้มาก เริ่มต้นในตอนท้าย อย่างที่เห็นได้ชัดว่าเป็นตรรกะที่ต้องทำ ส่วนประกอบ นี่เป็นการออกแบบตามส่วนประกอบหรือไม่ นั่นคืออะไร?

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

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

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

Heydon: ดังนั้น แนวคิดก็คือการนำความสามารถในการเข้าถึงมาสู่ระบบการออกแบบ แต่ในทำนองเดียวกัน ให้คิดอย่างเป็นระบบเมื่อต้องพยายามระบุถึงการช่วยสำหรับการเข้าถึง ลองนึกถึงการแก้ปัญหาประเภทหนึ่งในที่เดียวในแง่ของการช่วยสำหรับการเข้าถึง และทำให้แน่ใจว่าเพียงแค่เผยแพร่ไปรอบๆ รูปแบบ [ไม่ได้ยิน 00:03:16] ระบบการออกแบบโดยรวม

Drew: ในทางปฏิบัติ การทำงานแบบอิงองค์ประกอบเป็นอย่างไร? ตัวอย่างของส่วนประกอบคืออะไร?

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

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

Drew: ฉันหมายถึงในทางปฏิบัติจริง ๆ แล้วเรากำลังพูดถึงองค์ประกอบที่อาจเหมือนกับฟิลด์แบบฟอร์ม?

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

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

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

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

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

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

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

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

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

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

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

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

Drew: เป็นไปได้ไหมที่จะใช้แนวทางแบบอัลกอริธึมหรือแบบอัตโนมัติทั้งหมดในการออกแบบเพื่อการเข้าถึง?

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

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

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

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

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

Drew: บางครั้งอันตรายจากเครื่องมืออัตโนมัติคือพวกเขาดูรายการแยกกันหรือดูอินเทอร์เฟซเดียวแยกและไม่เห็นบริบทที่กว้างขึ้น

เฮย์ดอน: ครับ

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

Heydon: ใช่อย่างแน่นอน คุณกำลังคิดไปข้างหน้าและกำลังตัดสินใจ และจนกว่าเราจะไปถึง AI ขั้นสูงเพื่อคาดการณ์ได้ ใช่แล้ว คุณต้องการมนุษย์จริงๆ ที่จะมองมันและผ่านมันไป และไปต่อ … ฉันหมายความว่าการทดสอบอัตโนมัติควร อย่างที่ฉันพูด เป็นระบบเตือนภัยล่วงหน้า ระบบวินิจฉัย แต่ควรมีด้วย หากคุณสนใจในองค์กรของคุณที่ดูแลเอาใจใส่ และทำให้สิ่งต่าง ๆ ครอบคลุมและเข้าถึงได้มากขึ้น ก็จำเป็นต้องมีการฝึกอบรมเช่นกัน . ต้องมี Q&A

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

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

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

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

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

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

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

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

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

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

Heydon: ดังนั้น จะมีคนที่ คนดีบางคนที่ฉันเคยทำงานด้วยเช่นที่ Paciello Group ที่จะพูดว่า "จริงๆ แล้ว ฉันอยากเป็นที่รู้จักในฐานะบุคคล UX ที่เข้าถึงได้" ดังนั้น มันไม่เพียงแค่เกี่ยวกับแบบฝึกหัดการเลือกกล่องนี้เท่านั้น แต่ยังเกี่ยวกับการพยายามทำให้ประสบการณ์ดีขึ้น และมีค่ามากขึ้นสำหรับผู้คนจำนวนมากขึ้น และมุ่งไปสู่หลักการที่กว้างขึ้นและสิ่งต่าง ๆ ที่เป็นเลขฐานสองน้อยกว่า แต่สุดท้ายแล้ว มันคือทั้งหมดนั้น และ WCAC และเกณฑ์อื่นๆ ก็สามารถระบุสิ่งที่ยากและรวดเร็วอย่างแท้จริงเท่านั้นว่า "สิ่งนี้ไม่ถูกต้อง" ฉันคิดว่า

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

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

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

ดริว : ถูกต้อง

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

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

Drew: ตัวหนังสือเอง คุณตัดสินใจจัดโครงสร้างอย่างไร ดูเหมือนว่าจะใช้งานได้จริงมากซึ่งฉันชอบในหนังสือ แต่คุณจัดโครงสร้างอย่างไร?

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

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

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

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

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

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

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

เฮย์ดอน: โอ้เยี่ยมมาก นั่นคือสิ่งที่ฉันกำลังจะไป นั่นเป็นสิ่งที่ดี แต่ใช่ ดูเหมือนว่าจะเป็นเรื่องของฉัน I mean, I've been working with the BBC for some months and we've kind of made a thing a bit like Inclusive Components but for the BBC, so we've done this sort of technical implementation with a through the lens of accessibility version of their design language called GEL. And yeah, it explains the why as well as the how and it's not a pattern, really. The idea is that the individual departments at the BBC, because there's so many of them, because it's such a large organization, so there'll be BBC Sport, BBC Weather, BBC News, they're the ones who would be taking care of the kind of technical stack and making their pattern library. And what we've really provided is just, we've just tried to exemplify the best practices. So it was really much more of a learning resource than a simple plug and play pattern library. ใช่.

Drew: Was it difficult deciding what patterns to include in the book? Was there anything that you left out?

Heydon: The only ones I really had problems with or second thoughts about were the ones where, the tab interface, for instance, I wasn't going to include, because I really hate tab interfaces, but then I had folks saying, “Could you please do a tab interface? Could you include a chapter of that?” Because I get asked to put them in my interface all the time by clients or whoever. So, I ended up doing one. But it's full of caveats. And the main caveat is, probably don't use a tab interface. Use maybe an accordion, it's a simpler interaction paradigm. It's easier to make responsive, it's easier to make compatible with screen readers, et cetera, et cetera.

Heydon: So I put all those caveats in. But yeah, and some of them were ones where I just thought, “Oh, I haven't written about this before and I could do with having sort of thought about it so that I could actually use it in my design work.” And others were people requesting, saying, “I know this is a gnarly one, I just don't know how to go about it. Could you give it a go?” And so I gave it a go as best as I could. That is going to be the last time I write a book about accessibility because I've done three now.

Heydon: So if anyone wants to know any more and if they think of any other components that they might want doing, just DM me on Twitter or something and I'll try and deal with it in that way rather than writing a whole article, because those articles are quite long and they take up quite a lot of time and I'm kind of doing other things at the moment. But I'm always happy to chat with anyone who has any questions about this stuff. They might be working on something similar to what I've covered and there was just something that they were unsure about or which I, for whatever reason, I hadn't made as clear as they'd liked it. Yeah, then just contact me because I'm always happy to talk about the stuff because it helps me to sort of ruminate over things and try to, it might challenge my assumptions and help me to do a better job as well.

Drew: So, the book, Inclusive Components, is available right now from Smashing Magazine, smashingmagazine.com/books, and I'd recommend everybody check it out.

Heydon: Thank you.

Drew: So I always like to ask people, I mean, Smashing is all about learning, right, with the books, the conferences, the magazine, we're all about learning. What is it that you've been learning lately?

Heydon: So, recently, well, a couple of years ago I made something, I made a drum machine using the web audio API called Beads and it's still available as a PWA, it's a progressive web app. If you Google search Beads GitHub or something like that, you should get the GitHub page which has it on there. But that was a alpha version and I'm now working on doing a much more advanced version of this. And it's a different kind of drum machine because it's polymetric, it has different, you can have different tracks of different lengths. So you can have a track which has seven beats and a track which has nine beats, a track which has four beats. And then, the rhythm evolves over time because of the changing syncopation. You've got these, it's multi-threaded.

Heydon: That was the main reason that I wanted to build it, because, as someone who's interested in kind of experimental music, that's something I wanted to play with. Obviously, I'm trying to make this drum machine as accessible as possible. And that's been interesting from the point of view now that I'm working with, I'm turning it into an Electron app. So, for those of you that know Electron allows you to kind of wrap a sandbox version of Chromium browser and create a desktop application but using web technology, which was really great because it makes things, for this projects anyways, because it gets around a lot of performance problems.

Heydon: But also, although I've been doing cross browser testing for 12 years now, it's really nice to have a break and just to design stuff for one browser. And it's got some, so there's a flag in Chromium. It's a, what's it called, an experimental web platform feature for focus visible. So I've been able to make this drum machine completely keyboard accessible with these really nice, big focus outlines without those appearing for mouse users, because focus visible uses this heuristic where it detects whether or not you're using a keyboard. So that's been nice, to be able to incorporate that.

Heydon: But the thing recently that I've been learning about, just I've, I guess, been learning about some of the more advanced things you can do with the web audio API itself. So I had this problem where I have, you can put multiple sounds on one track so you can load in an array of audio files and it places them one after the other, and by default they overlap, so they'll always play out out, the audio buffer will play until it finishes. So if the next sounds comes before the end of that, it just overlaps, which is fine. It's kind of like a reverb or something. But sometimes if you're doing an arpeggio, like a baseline or something, you don't want them to open up. That's not how a bass guitar works, right? If you're on the same string, you press the next note, the first one has to finish.

Heydon: So, I was stopping a note as the next one started and there was always an audible popping sound and it's not the web audio API having a problem or anything like that. It's just the human ear will hear a kind of a nasty popping sound where you kind of sever away from. You just cut it, stop it dead, it's going to sound nasty. And then, so I found that there's a function as part of the web audio API, which allows you to choose a point where you can taper off the sound. And so I was able to detect where the sounds should end because the other sound is beginning, then taper it off very quickly, but it is a taper, like a fade out, rather than a hard cut off thing.

Heydon: So I solved that problem after it annoying me for ages. So it's basically been web audio API stuff and messing around with sounds because I've always been into, as I say, into experimental music and messing about with that sort of stuff. And I'm trying to write a talk about this. And in the talk, I'm using Billy Jean by Michael Jackson because it's a very straight, fall to the floor rhythm and I'm going to kind of warp it in various different ways. So I've actually had to learn the parts for Billy Jean to kind of sequence that and stuff. So, weirdly enough, that was what I was doing before doing this podcast.

Drew: That sounds like a lot of fun. So if you, dear listener, would like to learn more about Heydon or hire him to consult on your projects, you can follow him on Twitter, where he's @heydonworks, or visit his website at heydonworks.com. Thanks for joining us, Heydon. Do you have any parting words?

Heydon: Goodbye.