ทำไมคุณควรเลือกบทความ HTML5 เหนือส่วน

เมื่อไม่กี่วันก่อน ฉันกำลังสนทนากับเพื่อนบางคน ซึ่งหนึ่งในนั้นถามฉันถึงความแตกต่างระหว่าง <article> และ <section> ใน HTML นี่เป็นหนึ่งในความลึกลับชั่วนิรันดร์ของการพัฒนาเว็บ บนนั้นด้วย "ทำไมมันถึงเป็น white-space: nowrap ไม่ใช่ white-space: no-wrap?" และ "ทำไม CSS 'สีเทา' ถึงมีสีเข้มกว่า 'darkgray'?

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

ข้อมูลจำเพาะพูดว่า:

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

ดังนั้นหน้าแรกที่มีรายการโพสต์ในบล็อกจะเป็นองค์ประกอบ <main> ที่รวมชุดองค์ประกอบ <article> ไว้หนึ่งรายการสำหรับแต่ละโพสต์ในบล็อก คุณจะใช้โครงสร้างเดียวกันสำหรับรายการวิดีโอ (คิดว่า YouTube) โดยแต่ละวิดีโอจะรวมไว้ใน <article> รายการผลิตภัณฑ์ (นึกถึง Amazon) เป็นต้น <article> ใดๆ เหล่านี้สามารถเผยแพร่ตามแนวคิดได้ — แต่ละรายการสามารถยืนอยู่คนเดียวในหน้าเฉพาะของตนเอง ในโฆษณาในหน้าอื่น เป็นรายการในฟีด RSS และอื่นๆ

WatchOS ของ Apple มี Reader ซึ่งใช้องค์ประกอบ <article> เพื่อทราบเนื้อหาหลักของหน้าเว็บของคุณ แอปเปิ้ล พูดว่า:

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

การรวม <article> เข้ากับไมโครดาต้า HTML5 ช่วยให้ Reader สร้างการแสดงผลที่เหมาะสมที่สุดสำหรับหน้าจอนาฬิกาขนาดเล็ก:

“โดยเฉพาะอย่างยิ่ง การปิดองค์ประกอบส่วนหัวเหล่านี้ภายในบทความทำให้แน่ใจได้ว่าองค์ประกอบทั้งหมดจะปรากฏใน Reader Reader ยังจัดรูปแบบองค์ประกอบส่วนหัวแต่ละองค์ประกอบแตกต่างกันไปตามค่าของแอตทริบิวต์ itemprop เมื่อใช้ itemprop เราสามารถมั่นใจได้ว่าผู้แต่ง วันที่ตีพิมพ์ ชื่อเรื่อง และหัวข้อย่อยมีความโดดเด่น”

แล้ว <section> ล่ะ?

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

อะไร? อัลกอริธึมโครงร่างเอกสารเป็นวิธีการใช้แท็กหัวเรื่องเพียงแท็กเดียว — <h1> — และทำให้มัน "กลายเป็น" ระดับหัวเรื่องที่ถูกต้องอย่างน่าอัศจรรย์ (เช่น เปลี่ยนเป็น <h2> , <h3> เป็นต้น) ขึ้นอยู่กับว่า มันซ้อนอยู่ในองค์ประกอบการแบ่งส่วน HTML5: <article> , <section> และอื่น ๆ

ตัวอย่างเช่น นี่คือสิ่งที่คุณพิมพ์ลงใน CMS ของคุณ:

 <h1>My Fabulous article</h1> <p>Lorem Ipsum Trondant Fnord</p>

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

 <h1>My latest posts</h1> <article> <h1>My fabulous article</h1> <p>Lorem Ipsum Trondant Fnord</p> </article> <article> <h1>Another magnum opus</h1> <p>Magnum solero paddle pop</p> </article>

ในตัวอย่างนี้ ตามข้อกำหนด <h1> s ภายในองค์ประกอบ <article> "กลายเป็น" ตรรกะ <h2> s เนื่องจาก <article> เช่น <section> เป็น องค์ประกอบการแบ่งส่วน

หมายเหตุ : นี่ไม่ใช่แนวคิดใหม่ ย้อนกลับไปในปี 1991 เซอร์ลุงทิมโบเขียนว่า:

“ที่จริงแล้วฉันต้องการแทน <h1> , <h2> ฯลฯ สำหรับส่วนหัว [ที่มาจาก AAP DTD] เพื่อให้มีองค์ประกอบ <SECTION> ... </SECTION> ที่ซ้อนกันได้ และ <H> ทั่วไป <H> ... </H> ซึ่งระดับใด ๆ ภายในส่วนจะสร้างระดับของหัวเรื่องที่ต้องการ”

อย่างไรก็ตาม น่าเสียดายที่ไม่มีเบราว์เซอร์ใดที่ใช้การสรุป HTML5 ดังนั้นจึงไม่มีประเด็นในการใช้ <section> จนถึงจุดหนึ่ง โปรแกรมอ่านหน้าจอ JAWS พยายามใช้อัลกอริธึมการสรุปเอกสาร (ใน IE แต่ไม่ใช่ใน Firefox) แต่ใช้งานอย่างผิดพลาด ดูเหมือนว่านักพัฒนาเบราว์เซอร์จะไม่สนใจ (รายละเอียดที่แย่กว่านั้นในส่วนอ่านเพิ่มเติมสำหรับ anoraks ที่แท้จริง)

“แต่” แทรกเพื่อนอีกคนในการสนทนา “ตอนนี้เบราว์เซอร์แสดงขนาดตัวอักษรที่แตกต่างกันขึ้นอยู่กับว่า <h1> ซ้อนอยู่ใน <section> ลึกเพียงใด” และดำเนินการเพื่อพิสูจน์ ใจสลาย!

นี่คือตัวอย่างที่คล้ายกัน คอลัมน์ด้านซ้ายแสดงสี่ <h1> s ซ้อนอยู่ในส่วนต่างๆ คอลัมน์ทางขวาแสดง a, <h1> , <h2> , <h3> , <h4> โดยไม่มีการซ้อน ภาพหน้าจอของ Firefox แสดงให้เห็นว่า <h1> ที่ซ้อนกันนั้นใช้แบบอักษรเดียวกับแท็ก <h1> … <h4> แบบดั้งเดิม:

ผลลัพธ์จะเหมือนกันใน Chrome, อนุพันธ์ของ Chromium เช่น Edge beta สำหรับ Mac และ Safari บน Mac

นี่หมายความว่าเราทุกคนควรเริ่มต้นอย่างมีความสุขโดยใช้ <h1> เป็นองค์ประกอบหัวเรื่องเดียวของเราโดยซ้อนใน <section> หรือไม่?

ไม่ เพราะนี่เป็นเพียงการเปลี่ยนแปลงในการจัดรูปแบบภาพของ h1s หากเราเปิดโปรแกรมตรวจสอบการช่วยสำหรับการเข้าถึง Firefox ใน devtools เราจะเห็นว่าข้อความ "ระดับ 2" ถูกจัดรูปแบบให้ดูเหมือน H2 แต่ยังคงตั้งค่าไว้ที่ "ระดับ 1" — แผนผังการช่วยสำหรับการเข้าถึงไม่ได้ถูกเปลี่ยนเป็นระดับ 2.

เปรียบเทียบกับ Real H2 ในคอลัมน์ด้านขวา:

นี่แสดงว่าแผนผังการช่วยสำหรับการเข้าถึงได้รับแจ้งอย่างถูกต้องว่าเป็นส่วนหัวระดับ 2 อันที่จริง Mozilla ได้พยายามสื่อสารระดับที่คำนวณไปยังแผนผังการช่วยสำหรับการเข้าถึง:

“เราทดลองกับสิ่งนั้นเล็กน้อย… แต่ต้องย้อนกลับเพราะคนในทีม a11y ของเราบ่นเกี่ยวกับการถดถอยมากเกินไป (ลดระดับ <h1> และอื่น ๆ โดยไม่ได้ตั้งใจ)”

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

“ประโยชน์ของโครงสร้างหัวเรื่องที่เหมาะสมนั้นสูงมาก โดย 86.1% ของผู้ตอบแบบสอบถามพบว่าระดับหัวเรื่องมีประโยชน์มากหรือค่อนข้างดี”

ดังนั้น คุณควรใช้ <h1> จนถึง <h6> และละเว้น section

ไม่เคยพูดไม่เคย

“แต่..” ตอนนี้คุณอาจจะพูดออกมาอย่างขุ่นเคือง “มีองค์ประกอบ <section> อยู่ที่หน้านี้!” และคุณจะพูดถูกผู้อ่านที่รัก “สรุปด่วน” ถูกรวมไว้ใน <section> ด้วยเหตุผลด้านการเข้าถึง เมื่อผู้ใช้โปรแกรมอ่านหน้าจอ Leonie Watson ให้การสัมมนาผ่านเว็บของเธอว่า "ผู้ใช้โปรแกรมอ่านหน้าจอเข้าถึงเว็บได้อย่างไร" เธอชี้ให้เห็นพื้นที่ที่มาร์กอัปของ Smashing Magazine สามารถปรับเปลี่ยนเพื่อให้ประสบการณ์ของเธอดีขึ้น

ดังที่คุณเห็นจากภาพหน้าจอ บทความเกี่ยวกับ Smashing นำหน้าด้วยบทสรุปอย่างรวดเร็ว ตามด้วยเส้นแนวนอนที่แยกบทสรุปออกจากบทความที่เหมาะสม

แต่ตัวคั่นมีการตกแต่งอย่างหมดจด ดังนั้น Leonie จึงไม่สามารถบอกได้ว่าบทสรุปสิ้นสุดที่ใดและบทความเริ่มต้นขึ้น เธอแนะนำการแก้ไข: เรารวมการสรุปในองค์ประกอบ <section> :

 <section aria-label="quick summary"> Summary text </section>

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

เราสามารถใช้ <div> ง่ายๆ ได้ แต่ตามที่ Marco Zehe เขียนไว้

“ตามกฎทั่วไป หากคุณติดป้ายกำกับบางสิ่งผ่าน aria-label หรือ aria-labelledby ให้ตรวจสอบว่ามีวิดเจ็ตหรือบทบาทหลักที่เหมาะสม”

ดังนั้นแทนที่จะใช้ <div role=”region” aria-label=”quick summary”> เราเลือก <section> เนื่องจากมีบทบาทในตัวของภูมิภาคและกฎของ ARIA ที่ไม่ผิดเพี้ยนของ Bruce มีผลบังคับใช้: built-in beats bolt- บน. ใหญ่โต

บทสรุป

หวังว่าคุณจะกลับบ้านด้วยการซื้อกลับบ้านเหล่านี้:

• อย่าใช้ <h1> จำนวนมาก ทำให้ <h1> เป็นหัวข้อหลักของหน้า จากนั้นใช้ <h2> , <h3> , <h4> ฯลฯ ในลำดับชั้นที่เหมาะสมโดยไม่ข้ามระดับ
• <section> สามารถใช้กับ aria-label เพื่อส่งสัญญาณไปยังผู้ใช้โปรแกรมอ่านหน้าจอที่ส่วนย่อยเฉพาะของบทความเริ่มต้นและสิ้นสุด มิฉะนั้น ให้ลืมมันไป หรือใช้องค์ประกอบอื่น เช่น <aside aria-label=”quick summary”> หรือ <div role=”region” aria-label=”quick summary”>
• <main> , <header> , <footer> และ <nav> มีประโยชน์มากสำหรับผู้ใช้โปรแกรมอ่านหน้าจอ และโปร่งใสโดยสิ้นเชิงสำหรับผู้ที่ไม่ใช้เทคโนโลยีอำนวยความสะดวก ดังนั้นใช้พวกเขา
• <article> ไม่ได้มีไว้สำหรับโพสต์ในบล็อกเท่านั้น แต่ยังมีไว้สำหรับสิ่งที่อยู่ในตัวเอง นอกจากนี้ยังช่วยให้ WatchOS แสดงเนื้อหาของคุณได้อย่างถูกต้อง

ฉันขอขอบคุณสำหรับความช่วยเหลือจาก Leonie Watson ในการเขียนบทความนี้ ข้อผิดพลาดใด ๆ เป็นความผิดของเธอโดยสิ้นเชิง

อ่านเพิ่มเติม

• “หัวเรื่องและส่วน” คำแนะนำ HTML 5.2 W3C (14 ธ.ค. 60) โปรดสังเกตคำเตือน: “ขณะนี้ยังไม่มีการใช้งานอัลกอริธึมโครงร่างแบบเนทีฟที่รู้จัก … ดังนั้น อัลกอริธึมโครงร่างจึงไม่สามารถเชื่อถือได้ในการถ่ายทอดโครงสร้างเอกสารให้กับผู้ใช้ ผู้เขียนควรใช้หัวเรื่อง (h1-h6) เพื่อถ่ายทอดโครงสร้างเอกสาร”
• “ไม่มีอัลกอริธึมเค้าร่างเอกสาร” Adrian Roselli รายละเอียดที่เต็มไปด้วยเลือดว่าข้อกำหนดสำหรับอัลกอริธึมการแบ่งส่วนมีการเปลี่ยนแปลงอย่างไร
• “ARIA in HTML,” W3C Editor's Draft (19 ธ.ค. 62) กฎที่ควรใช้ หากคุณพบว่าตัวเองเพิ่มบทบาท ARIA และแอตทริบิวต์ให้กับ HTML
• คุณค่าเชิงปฏิบัติของ HTML เชิงความหมาย” บรูซ ลอว์สัน บทความของฉันซึ่งเชื่อมโยงไปยังรายละเอียดว่า WatchOS ใช้ HTML5 และ microdata อย่างไร