จาก Figma สู่ HTML ที่เข้าถึงได้: คู่มือปฏิบัติจริง

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

ทำไมการเข้าถึงได้ถึงหายไปในการแปลงจาก Figma สู่ HTML

ไฟล์ Figma อธิบายว่าดีไซน์หน้าตาเป็นอย่างไร แต่ไม่ได้อธิบายว่าโปรแกรมอ่านหน้าจอ (screen reader) ควรอ่านออกเสียงอะไร element ใดควรได้รับโฟกัสถัดไป หรือคู่สีนั้นอ่านง่ายพอสำหรับคนที่มีสายตาเลือนรางหรือไม่ ช่องว่างนี้เองคือสาเหตุที่แท้จริงที่การเข้าถึงได้พังระหว่างการแปลง ไม่ใช่เพราะความประมาท แต่เพราะสิ่งที่การเข้าถึงได้ต้องการบางส่วนไม่ใช่ข้อมูลที่ไฟล์ดีไซน์มีอยู่เลย การจับคู่ภาพที่ตรงเป๊ะระดับพิกเซลก็ยังอาจเป็นความล้มเหลวด้านการเข้าถึงได้ ถ้ามาร์กอัปที่อยู่ข้างใต้เป็น <div> ทั่วไปที่ไม่มีโครงสร้าง ไม่มีป้ายกำกับ และไม่รองรับคีย์บอร์ด

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

การตัดสินใจด้านดีไซน์ใน Figma ที่ส่งผลต่อการเข้าถึงได้

พฤติกรรมทั่วไปบางอย่างใน Figma ก่อให้เกิดปัญหาการเข้าถึงได้ในขั้นถัดไป ก่อนที่เครื่องมือแปลงใดๆ จะเข้ามาเกี่ยวข้องด้วยซ้ำ:

• สีเป็นสัญญาณเดียว ฟิลด์ฟอร์มที่จำเป็นต้องกรอกซึ่งทำเครื่องหมายด้วยสีแดง หรือปุ่มที่ถูกปิดใช้งานซึ่งเป็นเพียงสีเดียวกันแต่อ่อนกว่า — ทั้งสองอย่างมองไม่เห็นสำหรับคนที่แยกเฉดสีเหล่านั้นไม่ออก การแยกความแตกต่างต้องมีสัญญาณที่สอง (ไอคอน ป้ายกำกับ ลวดลาย) ไม่ใช่แค่การเปลี่ยนสี
• ข้อความที่ฝังอยู่ในรูปภาพ พาดหัวที่ส่งออกเป็น PNG แบบ flatten อาจดูเหมือนเลเยอร์ข้อความจริงทุกประการ แต่โปรแกรมอ่านหน้าจอไม่สามารถอ่านได้ เบราว์เซอร์ไม่สามารถปรับขนาดได้ และ crawler ไม่สามารถทำดัชนีได้
• ไม่มีการออกแบบสถานะโฟกัสที่มองเห็นได้ ชุดคอมโพเนนต์ส่วนใหญ่ใน Figma มีสถานะปกติ สถานะ hover และบางครั้งก็มีสถานะปิดใช้งาน — แต่สถานะโฟกัส (สำหรับผู้ใช้คีย์บอร์ดที่กด Tab ไล่ไปทั่วหน้า) มักไม่เคยถูกออกแบบไว้เลย จึงไม่มีอะไรให้การแปลงนำมาใช้ต่อ
• ปุ่มที่มีแต่ไอคอนโดยไม่มีชื่อที่เข้าถึงได้อยู่ในไฟล์เลย ไอคอนถังขยะที่หมายถึง "ลบ" นั้นชัดเจนในเชิงภาพ แต่ไม่มีอะไรในเลเยอร์ Figma ที่บอกตัวแปลง — หรือโปรแกรมอ่านหน้าจอ — ว่าไอคอนนั้นหมายถึงอะไร เว้นแต่ตัวเลเยอร์เองจะถูกตั้งชื่อไว้อย่างมีความหมาย
• ขนาดหัวข้อที่ไม่สอดคล้องกัน Figma ไม่มี element แบบ "Heading 2" เหมือนที่ CMS หรือโปรแกรมประมวลผลคำมี — เลเยอร์ข้อความก็เป็นแค่ข้อความที่ถูกจัดสไตล์ให้ดูมีขนาดหนึ่งๆ หัวข้อสองอันที่หน้าตาคล้ายกันในเฟรมต่างกันอาจแทนระดับที่แตกต่างกันโดยสิ้นเชิงในลำดับชั้นเนื้อหาที่แท้จริง

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

HTML เชิงความหมายและ landmarks

นี่คือส่วนของการเข้าถึงได้ที่ตัวแปลง Figma เป็นโค้ดที่ดีควรทำได้ถูกต้องโดยดีฟอลต์ นั่นคือ element <header>, <nav>, <main>, <article>, <section>, <aside> และ <footer> ที่แท้จริง แทนที่จะเป็นหน้าเว็บที่สร้างขึ้นทั้งหมดจาก <div> ที่ไม่มีป้ายกำกับ Landmarks สำคัญเพราะเป็นวิธีที่ผู้ใช้โปรแกรมอ่านหน้าจอกระโดดตรงไปยัง "เนื้อหาหลัก" หรือ "การนำทาง" แทนที่จะต้องกด Tab ไล่ไปทั่วทั้งหน้าเว็บทีละขั้น ดู Figma to Semantic HTML เพื่อดูว่าผลลัพธ์ของ MarkupGen มีโครงสร้างหน้าตาเป็นอย่างไร และ ผลลัพธ์จาก Figma สู่ HTML พร้อมสำหรับ SEO หรือไม่? สำหรับความเกี่ยวเนื่องระหว่างมาร์กอัปเชิงความหมายกับความสามารถในการถูก crawl — ทั้งสองปัญหามีสาเหตุรากเดียวกันและส่วนใหญ่แก้ไขด้วยวิธีเดียวกัน

ลำดับชั้นหัวข้อ

หนึ่ง <h1> ต่อหนึ่งหน้า และหัวข้อที่ลดระดับลงตามลำดับ — <h3> ควรอยู่ในเซกชันที่มี <h2> อยู่แล้ว ไม่ใช่กระโดดไปอยู่ตรงนั้นเพียงเพราะเลเยอร์ข้อความบังเอิญดูมีขนาดเท่านั้นในดีไซน์ ตามที่กล่าวไว้ข้างต้น Figma ไม่มีแนวคิดเรื่องระดับหัวข้อในตัว ดังนั้นเลเยอร์ข้อความที่จัดสไตล์ให้ดูใหญ่จึงไม่ได้กลายเป็น <h1> โดยอัตโนมัติ — เรื่องนี้ควรตรวจสอบด้วยมือไม่ว่าเครื่องมือใดจะเป็นผู้สร้างมาร์กอัปก็ตาม เพราะขึ้นอยู่กับความเข้าใจโครงสร้างเนื้อหาที่แท้จริง ไม่ใช่แค่ขนาดที่มองเห็น

ปุ่มกับลิงก์

นี่คือหนึ่งในความผิดพลาดด้านการเข้าถึงได้ที่พบบ่อยที่สุดในมาร์กอัปที่แปลงแล้ว และโครงสร้างคอมโพเนนต์ของ Figma ก็ไม่ได้ช่วยแก้ปัญหานี้ให้: <button> มีไว้สำหรับการกระทำในหน้าปัจจุบัน (ส่งฟอร์ม เปิดโมดัล ลบรายการ) ส่วน <a href> มีไว้สำหรับการนำทางไปยังหน้าหรือมุมมองอื่น ไฟล์ดีไซน์ที่เต็มไปด้วยรูปทรงแคปซูลที่มีสไตล์คล้ายกันไม่ได้บอกเลยว่าอันไหนเป็นอันไหน — นั่นคือการตัดสินใจเชิงความหมาย ไม่ใช่เชิงภาพ และส่งผลโดยตรงทั้งต่อพฤติกรรมคีย์บอร์ด (ปุ่มและลิงก์ตอบสนองต่อปุ่มกดที่ต่างกันโดยดีฟอลต์) และสิ่งที่โปรแกรมอ่านหน้าจอประกาศออกมา

ฟอร์มและป้ายกำกับ

ทุก input ต้องมี <label> จริงที่เชื่อมโยงกันในเชิงโปรแกรม ไม่ใช่ placeholder ที่ทำหน้าที่แทน ข้อความ placeholder จะหายไปทันทีที่ผู้ใช้เริ่มพิมพ์ มีคอนทราสต์ที่แย่มากตามค่าเริ่มต้น และไม่ได้ถูกโปรแกรมอ่านหน้าจอทุกตัวอ่านออกมาอย่างน่าเชื่อถือในฐานะตัวแทนของป้ายกำกับ หากฟอร์มจำเป็นต้องดูเหมือนไม่มีป้ายกำกับด้วยเหตุผลด้านดีไซน์ ให้ใช้ป้ายกำกับที่ซ่อนไว้ในเชิงภาพ (visually-hidden) แทนที่จะเอาออกจากมาร์กอัปไปเลย ข้อความแจ้งข้อผิดพลาดต้องเชื่อมโยงกับฟิลด์ของมัน (โดยทั่วไปผ่าน aria-describedby) ไม่ใช่แค่วางไว้ใกล้ๆ โดยใช้สีเพียงอย่างเดียวเป็นสัญญาณของปัญหา

รูปภาพและข้อความ alt

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

การนำทางด้วยคีย์บอร์ด

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

สถานะโฟกัส

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

คอนทราสต์สี

Figma ให้คุณเลือกสีคู่ไหนก็ได้ ไม่ว่าจะอ่านง่ายด้วยกันหรือไม่ก็ตาม ดังนั้นเรื่องนี้ต้องมีการตรวจสอบอย่างชัดเจน ไม่ใช่แค่สันนิษฐานเอา WCAG AA กำหนดคอนทราสต์อย่างน้อย 4.5:1 สำหรับข้อความเนื้อหาปกติ และ 3:1 สำหรับข้อความขนาดใหญ่ (18px+ แบบตัวหนา หรือ 24px+ แบบปกติ) รวมถึงคอมโพเนนต์ UI ที่มีความหมาย เช่น ไอคอนและขอบของ input ให้นำคู่สีจริงของดีไซน์ไปตรวจผ่านเครื่องมือตรวจคอนทราสต์ก่อนการแปลง — การแก้ token ใน Figma นั้นถูกกว่ามากเมื่อเทียบกับการต้องไล่ตามแก้ทีหลังทั่วทั้งมาร์กอัปที่สร้างขึ้นแล้ว

ARIA: เมื่อไหร่ที่ช่วย และเมื่อไหร่ที่เป็นโทษ

กฎข้อแรกของ ARIA ยังคงถูกต้องเสมอ: ไม่ใช้ ARIA เลยยังดีกว่าใช้ ARIA ผิดๆ <button> แบบเนทีฟมี role ที่ถูกต้องอยู่แล้ว โฟกัสได้ และตอบสนองต่อ Enter กับ Space โดยดีฟอลต์ — การเพิ่ม role="button" เข้าไปไม่ได้ช่วยอะไรและยังเสี่ยงขัดแย้งกับความหมายที่แท้จริงของ element นั้น ARIA จะมีที่ทางของมันเฉพาะจุดที่ HTML เชิงความหมายเพียงอย่างเดียวไม่สามารถสื่อการโต้ตอบนั้นได้:

• ใช้เมื่อ: aria-label บนปุ่มที่มีแต่ไอคอนโดยไม่มีข้อความที่มองเห็น (ไอคอนถังขยะที่หมายถึง "ลบ"), aria-expanded บนตัวควบคุมที่เปิด/ปิดเซกชันแบบยุบขยายได้, aria-live="polite" บนพื้นที่ที่อัปเดตโดยไม่ต้องโหลดหน้าใหม่ (ข้อความตรวจสอบฟอร์ม จำนวนสินค้าในตะกร้า)
• อย่าใช้เมื่อ: เพิ่ม role ARIA ให้กับ element ที่มีความหมายเชิงเนทีฟที่ถูกต้องอยู่แล้ว, ARIA ที่เป็นการตกแต่งซึ่งซ้ำกับสิ่งที่มองเห็นและถูกอ่านออกเสียงอยู่แล้ว หรือ aria-live="assertive" กับสิ่งใดก็ตามที่ไม่ได้เร่งด่วนจริงๆ — มันขัดจังหวะเสียงของโปรแกรมอ่านหน้าจอ และใช้เกินความจำเป็นได้ง่าย

การเข้าถึงได้แบบ responsive

ปัญหาการเข้าถึงได้ไม่ได้ถูกแก้ไปตลอดในทุกจุด breakpoint เพียงเพราะได้รับการแก้ไขแล้วที่ขนาดหนึ่ง เป้าหมายการสัมผัส (touch target) ต้องคงขนาดอย่างน้อยประมาณ 44×44px บนมือถือ แม้ในขณะที่เลย์เอาต์ถูกบีบอัด — ปุ่มที่คลิกได้สบายบนเดสก์ท็อปอาจเล็กเกินไปจนแตะได้ไม่แม่นยำ เมื่อข้อจำกัดการปรับขนาดของ Auto Layout ทำให้มันหดลง ข้อความต้องไหลปรับ (reflow) แทนที่จะถูกตัดหรือซ้อนทับกันที่ความกว้างแคบ และลำดับเนื้อหาไม่ควรเปลี่ยนไปอย่างสับสนระหว่าง breakpoint ในแบบที่ทำลายลำดับการอ่านเชิงตรรกะที่โปรแกรมอ่านหน้าจอต้องพึ่งพา

ความผิดพลาดด้านการเข้าถึงได้ที่พบบ่อยเมื่อแปลงจาก Figma เป็น HTML

• element ที่คลิกได้ทุกตัวถูกแปลงเป็น <div onclick> แทนที่จะเป็น <button> หรือ <a> จริง
• ปุ่มที่มีแต่ไอคอนโดยไม่มี aria-label เพราะเลเยอร์ Figma ถูกตั้งชื่อไว้แค่ว่า "Icon 4"
• สีเป็นวิธีเดียวที่ใช้สื่อสถานะ (error, disabled, selected)
• outline: none บนสถานะโฟกัสโดยไม่มีอะไรที่มองเห็นมาแทนที่
• ข้อความ placeholder ถูกใช้เป็นป้ายกำกับเดียวของฟิลด์ฟอร์ม
• รูปภาพตกแต่งที่ใส่ชื่อไฟล์เป็นข้อความ alt แทนที่จะเป็น alt="" ที่ว่างเปล่า
• ระดับหัวข้อถูกเลือกตามขนาดฟอนต์ในดีไซน์ แทนที่จะเป็นโครงสร้างเนื้อหาที่แท้จริง

ก่อน / หลัง: ปุ่มที่มีแต่ไอคอน

ก่อน — ถูกต้องในเชิงภาพ แต่เข้าถึงไม่ได้:

<div class="icon-btn" onclick="deleteItem()">
  <svg><!-- trash icon --></svg>
</div>

หลัง — ผลลัพธ์ภาพเหมือนเดิม แต่ใช้งานได้จริง:

<button type="button" class="icon-btn" aria-label="Delete item" onclick="deleteItem()">
  <svg aria-hidden="true"><!-- trash icon --></svg>
</button>

ความแตกต่างไม่ได้อยู่ที่ภาพเลย — แต่คือ element <button> จริง (โฟกัสได้ ใช้งานด้วยคีย์บอร์ดได้ ถูกโปรแกรมอ่านหน้าจอประกาศออกมาอย่างถูกต้อง), aria-label ที่ให้ชื่อที่เข้าถึงได้แก่ไอคอน และ aria-hidden="true" บน SVG ที่เป็นการตกแต่งเพื่อไม่ให้ถูกประกาศซ้ำสองครั้ง

เช็กลิสต์การเข้าถึงได้ภาคปฏิบัติ

• หนึ่ง <h1> ต่อหนึ่งหน้า; หัวข้อลดระดับลงตามลำดับ ไม่ใช่ตามขนาดฟอนต์
• มี element landmark จริง (header, nav, main, footer) อยู่
• ทุกการกระทำที่คลิกได้เป็น <button>; ทุกลิงก์นำทางเป็น <a href>
• ทุก input ของฟอร์มมี <label> จริงที่เชื่อมโยงกัน — ไม่ใช่แค่ placeholder
• รูปภาพที่มีความหมายมีข้อความ alt ที่บรรยาย; รูปภาพตกแต่งมี alt=""
• สถานะโฟกัสมองเห็นได้บน element ที่โต้ตอบได้ทุกตัว
• ลำดับการกด Tab ตรงกับลำดับการอ่านที่มองเห็น
• คอนทราสต์ของข้อความและคอมโพเนนต์ UI เป็นไปตาม WCAG AA (4.5:1 / 3:1)
• สีไม่ใช่สัญญาณเดียวสำหรับสถานะหรือความหมายเลย
• ARIA ถูกใช้เฉพาะจุดที่ HTML เชิงความหมายไม่สามารถสื่อการโต้ตอบได้
• เป้าหมายการสัมผัสยังใช้งานได้ที่จุด breakpoint บนมือถือ
• เลย์เอาต์ไหลปรับได้โดยไม่ตัดหรือซ้อนทับข้อความที่ความกว้างแคบ

โค้ดที่สร้างขึ้นควรถูกตรวจสอบอย่างไรก่อนใช้งานจริง

ผลลัพธ์ของ MarkupGen เน้น element เชิงความหมายและโครงสร้างหัวข้อที่แท้จริงโดยดีฟอลต์ ไม่ใช่เป็นแค่ตัวเลือกที่ต้องเปิดเอง และการที่โครงสร้างของ Auto Layout ถูกส่งต่อไปเป็นลำดับ DOM ที่มีเหตุผลก็เป็นส่วนใหญ่ของสิ่งที่ทำให้ลำดับการกด Tab ที่ถูกต้องเป็นไปได้ตั้งแต่แรก คะแนนคุณภาพอัตโนมัติจาก AI ที่ทุกการเอ็กซ์พอร์ตได้รับเป็นสัญญาณแรกที่มีประโยชน์จริงๆ — แต่มันเป็นคะแนนการจับคู่เชิง ภาพ อย่างชัดเจน ที่เปรียบเทียบพรีวิวที่เรนเดอร์กับดีไซน์ต้นฉบับ มันไม่ได้ตรวจสอบความถูกต้องของ ARIA อัตราส่วนคอนทราสต์ หรือพฤติกรรมคีย์บอร์ด เพราะสิ่งเหล่านั้นไม่ปรากฏในการเปรียบเทียบภาพหน้าจอ ให้ถือว่าเช็กลิสต์ข้างต้นเป็นการตรวจสอบด้วยมือที่มาหลังจากคะแนนภาพที่สูง ไม่ใช่มาแทนที่มัน — ดู How to Evaluate AI-Generated HTML Before You Ship It สำหรับหลักการเดียวกันที่นำไปใช้กับการรีวิวโค้ดในภาพกว้างขึ้น

ลองใช้กับดีไซน์ของคุณเอง

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