Chuyển Figma sang HTML dễ tiếp cận: Hướng dẫn thực tế

Trả lời nhanh: accessibility trong một quy trình Figma-to-HTML không phải là một công tắc bật lên là xong — đó là một loạt quyết định cụ thể: dùng phần tử ngữ nghĩa thật thay vì <div> được style, thứ bậc heading khớp với cấu trúc nội dung (Figma không có khái niệm cấp heading sẵn có), trường form và nút chỉ có icon được gắn nhãn, trạng thái focus hiển thị rõ, độ tương phản màu đủ, và ARIA được dùng tiết chế — chỉ ở những chỗ mà HTML ngữ nghĩa không thể tự diễn đạt được tương tác đó. Đầu ra tự động có thể lo được phần lớn; một lượt rà soát thủ công ngắn vẫn bắt được những gì một file thiết kế không thể mang theo.

Vì sao accessibility bị thất lạc khi chuyển đổi Figma sang HTML

Một file Figma mô tả thiết kế trông như thế nào. Nó không mô tả trình đọc màn hình nên đọc ra cái gì, phần tử nào sẽ nhận focus tiếp theo, hay một cặp màu có đủ rõ để đọc với người có thị lực kém hay không. Khoảng trống đó chính là lý do thực sự khiến accessibility bị vỡ trong quá trình chuyển đổi — không phải do bất cẩn, mà vì một phần những gì accessibility cần vốn dĩ không phải là thông tin mà một file thiết kế mang theo. Một kết quả khớp thị giác hoàn hảo từng pixel vẫn có thể là một thất bại về accessibility nếu markup bên dưới chỉ là những <div> chung chung, không có cấu trúc, không có nhãn và không hỗ trợ bàn phím.

Cách khắc phục không phải là một lượt xử lý tự động duy nhất. Đó là việc hiểu phần nào của accessibility một công cụ chuyển đổi tốt đã tự làm đúng sẵn nhờ sinh ra cấu trúc thật thay vì markup chỉ mang tính thị giác, và phần nào luôn cần một quyết định có chủ đích — từ designer, developer, hoặc cả hai — vì file thiết kế thực sự không mang theo thông tin đó.

Những quyết định thiết kế trong Figma ảnh hưởng đến accessibility

Một vài thói quen phổ biến khi thiết kế trong Figma tạo ra vấn đề accessibility ở khâu sau, trước cả khi bất kỳ công cụ chuyển đổi nào vào cuộc:

• Màu sắc là tín hiệu duy nhất. Một trường form bắt buộc được đánh dấu đỏ, hay một nút disabled chỉ là một sắc độ nhạt hơn của cùng một màu — cả hai đều vô hình với người không phân biệt được những sắc màu đó. Sự khác biệt cần một tín hiệu thứ hai (một icon, một nhãn, một pattern), chứ không chỉ đổi màu.
• Chữ bị nướng chết vào hình ảnh. Một headline được xuất thành PNG phẳng có thể trông giống hệt một layer text thật, nhưng nó không thể được trình đọc màn hình đọc, không thể resize bởi trình duyệt, và không thể được crawler index.
• Không có trạng thái focus được thiết kế. Phần lớn bộ component trong Figma có state mặc định, hover và đôi khi cả disabled — nhưng trạng thái focus (dành cho người dùng bàn phím tab qua trang) thường đơn giản là chưa bao giờ được thiết kế, nên không có gì để bản chuyển đổi mang theo.
• Nút chỉ có icon mà không có tên accessible ở bất kỳ đâu trong file. Một icon thùng rác nghĩa là "xóa" thì rõ ràng về mặt thị giác. Nhưng không có gì trong layer Figma nói cho công cụ chuyển đổi — hay trình đọc màn hình — biết icon đó nghĩa là gì, trừ khi bản thân layer được đặt tên có ý nghĩa.
• Cỡ heading không nhất quán. Figma không có phần tử "Heading 2" như một CMS hay trình soạn thảo văn bản — layer text chỉ là text, được style để trông có một cỡ nhất định. Hai heading trông giống nhau về mặt thị giác ở các frame khác nhau có thể đại diện cho những cấp hoàn toàn khác nhau trong thứ bậc nội dung thực tế.

Không cái nào trong số này là lỗi của việc chuyển đổi. Đó là những quyết định phải được đưa ra ở đâu đó trong pipeline, và đáng để biết điều này từ đầu thay vì mặc định rằng một công cụ sẽ tự suy luận ra được.

HTML ngữ nghĩa và landmark

Đây là phần accessibility mà một công cụ chuyển Figma sang code tốt nên tự làm đúng theo mặc định: các phần tử <header>, <nav>, <main>, <article>, <section>, <aside> và <footer> thật, thay vì một trang dựng hoàn toàn từ <div> không nhãn. Landmark quan trọng vì đó là cách người dùng trình đọc màn hình nhảy thẳng đến "nội dung chính" hay "navigation" thay vì phải tab tuần tự qua toàn bộ trang. Xem Figma to Semantic HTML để biết đầu ra của MarkupGen trông như thế nào về mặt cấu trúc, và Is Figma-to-HTML Output SEO-Ready? để hiểu phần giao nhau giữa markup ngữ nghĩa và khả năng crawl — hai vấn đề này có chung một nguyên nhân gốc và phần lớn cũng chung một cách khắc phục.

Thứ bậc heading

Mỗi trang chỉ một <h1>, và các heading giảm cấp theo đúng thứ tự — một <h3> nên nằm trong một section đã có <h2>, chứ không nhảy thẳng vào đó chỉ vì một layer text trong thiết kế tình cờ trông có cỡ đó. Như đã nói ở trên, Figma không có khái niệm cấp heading sẵn có, nên một layer text được style to không tự động trở thành <h1> — đây là điều đáng để kiểm tra thủ công bất kể công cụ nào sinh ra markup, vì nó phụ thuộc vào việc hiểu cấu trúc nội dung thực tế, chứ không chỉ cỡ chữ nhìn thấy.

Button và link

Đây là một trong những lỗi accessibility phổ biến nhất trong markup được chuyển đổi, và cấu trúc component của Figma không tự giải quyết chuyện này giúp bạn: <button> dùng cho một hành động trên trang hiện tại (submit, mở modal, xóa một mục); <a href> dùng để điều hướng sang một trang hoặc view khác. Một file thiết kế đầy những hình pill được style giống nhau không cho biết cái nào là cái nào — đó là một quyết định ngữ nghĩa, không phải thị giác, và nó ảnh hưởng trực tiếp đến cả hành vi bàn phím (button và link mặc định phản hồi phím khác nhau) lẫn những gì trình đọc màn hình đọc lên.

Form và nhãn

Mỗi input cần một <label> thật, được gắn kết một cách có thể lập trình được — không phải một placeholder đóng thế cho nó. Text placeholder biến mất ngay khi người dùng bắt đầu gõ, vốn nổi tiếng có độ tương phản kém theo mặc định, và không được mọi trình đọc màn hình đọc lên một cách đáng tin cậy để thay thế cho một nhãn. Nếu một form cần trông như không có nhãn vì lý do thiết kế, hãy dùng một nhãn ẩn về mặt thị giác (visually-hidden) thay vì bỏ hẳn nó ra khỏi markup. Thông báo lỗi cần được gắn kết với trường tương ứng (thường qua aria-describedby), chứ không chỉ đặt gần đó và chỉ dùng màu sắc để báo hiệu vấn đề.

Hình ảnh và alt text

Hình ảnh được xuất ra cần thuộc tính alt có ý nghĩa, không phải chuỗi rỗng hay tên file. Đây là một trong những chỗ mà bước rà soát thủ công thực sự không thể tránh khỏi: một hình nền trang trí dùng để làm gì, so với một ảnh sản phẩm cần được mô tả điều gì, không phải lúc nào cũng rõ ràng chỉ từ frame Figma — file thiết kế không mang theo chủ đích, chỉ mang theo pixel. Hình ảnh thuần trang trí nên có alt="" rỗng (để trình đọc màn hình bỏ qua), trong khi hình ảnh có ý nghĩa cần một mô tả thật về những gì nó truyền tải, chứ không chỉ những gì nó cho thấy.

Điều hướng bàn phím

Mọi phần tử tương tác — link, button, trường form — cần có thể tiếp cận và thao tác được chỉ bằng bàn phím, theo đúng thứ tự khớp với thứ tự đọc thị giác. Đây là chỗ Auto Layout thực sự giúp ích: vì cấu trúc Auto Layout được chuyển tiếp thành một thứ tự DOM hợp lý thay vì các mảnh định vị tuyệt đối, thứ tự tab có xu hướng tự động theo đúng thứ tự đọc thay vì nhảy lung tung khó đoán như có thể xảy ra với layout tự do, định vị tuyệt đối.

Trạng thái focus

Vì bộ component trong Figma hiếm khi có sẵn trạng thái focus được thiết kế, đây thường là khoảng trống accessibility phổ biến nhất trong một trang đã chuyển đổi: người dùng bàn phím tab qua giao diện mà không thể nhận biết bằng mắt mình đang ở đâu. Ít nhất, đừng gỡ outline focus mặc định của trình duyệt (outline: none) mà không thay nó bằng thứ gì đó rõ ràng tương đương — một lỗi phổ biến, rất dễ vô tình đưa vào production nhân danh việc khớp với một thiết kế chưa từng tính đến chuyện này.

Độ tương phản màu

Figma cho phép bạn chọn bất kỳ hai màu nào bất kể chúng có đủ rõ khi đặt cạnh nhau hay không, nên đây là điều cần kiểm tra tường minh chứ không thể mặc định là ổn. WCAG AA yêu cầu tối thiểu tỷ lệ tương phản 4.5:1 cho body text thông thường và 3:1 cho text lớn (18px+ đậm, hoặc 24px+ thường) cũng như cho các component UI có ý nghĩa như icon và viền input. Hãy chạy các cặp màu thật của thiết kế qua một công cụ kiểm tra tương phản trước khi chuyển đổi — sửa một token trong Figma rẻ hơn rất nhiều so với việc phải truy tìm nó khắp markup đã sinh ra sau đó.

ARIA — khi nào hữu ích, khi nào gây hại

Nguyên tắc đầu tiên của ARIA vẫn luôn đúng: không có ARIA còn tốt hơn ARIA sai. Một <button> gốc đã có role đúng, có thể nhận focus, và mặc định phản hồi phím Enter và Space — thêm role="button" vào nó không có tác dụng gì hữu ích và có nguy cơ xung đột với ngữ nghĩa thật của phần tử. ARIA chỉ thực sự có chỗ đứng ở những nơi HTML ngữ nghĩa không thể tự diễn đạt được tương tác đó:

• Nên dùng: aria-label trên một nút chỉ có icon, không có text hiển thị (icon thùng rác nghĩa là "xóa"), aria-expanded trên một toggle điều khiển một section có thể thu gọn, aria-live="polite" trên một vùng cập nhật mà không reload trang (thông báo validate form, số lượng trong giỏ hàng).
• Không nên dùng: thêm role ARIA vào những phần tử vốn đã có ngữ nghĩa gốc đúng, ARIA mang tính trang trí lặp lại những gì đã hiển thị và đã được đọc lên rồi, hay aria-live="assertive" trên bất cứ thứ gì không thực sự khẩn cấp — nó ngắt lời đầu ra của trình đọc màn hình và rất dễ bị lạm dụng.

Accessibility trên responsive

Vấn đề accessibility không tự động được khắc phục ở mọi breakpoint chỉ vì nó đã được xử lý ở một kích thước nào đó. Vùng chạm (touch target) cần giữ tối thiểu khoảng 44×44px trên mobile ngay cả khi layout bị nén lại — một nút bấm thoải mái trên desktop có thể trở nên quá nhỏ để chạm chính xác một khi các ràng buộc resizing của Auto Layout thu nhỏ nó lại. Text cần reflow thay vì bị cắt hoặc chồng lên nhau ở chiều rộng hẹp, và thứ tự nội dung không nên thay đổi một cách khó hiểu giữa các breakpoint theo cách phá vỡ thứ tự đọc hợp lý mà trình đọc màn hình dựa vào.

Những lỗi accessibility thường gặp khi chuyển Figma sang HTML

• Mọi phần tử có thể click được chuyển thành <div onclick> thay vì một <button> hay <a> thật.
• Nút chỉ có icon nhưng không có aria-label, vì layer Figma chỉ đơn giản được đặt tên "Icon 4".
• Màu sắc là cách duy nhất để truyền đạt một state (lỗi, disabled, đã chọn).
• outline: none trên trạng thái focus mà không có gì hiển thị thay thế vào chỗ đó.
• Text placeholder được dùng làm nhãn duy nhất cho một trường form.
• Hình ảnh trang trí được gán tên file làm alt text thay vì một alt="" rỗng.
• Cấp heading được chọn theo cỡ chữ trong thiết kế thay vì cấu trúc nội dung thực tế.

Trước / sau: một nút chỉ có icon

Trước — đúng về thị giác, không accessible:

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

Sau — cùng kết quả thị giác, thực sự dùng được:

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

Sự khác biệt hoàn toàn không nằm ở thị giác — đó là một phần tử <button> thật (có thể nhận focus, thao tác được bằng bàn phím, được trình đọc màn hình đọc đúng), một aria-label cho icon một tên accessible, và aria-hidden="true" trên SVG trang trí để nó không bị đọc lên hai lần.

Checklist accessibility thực tế

• Mỗi trang chỉ một <h1>; heading giảm cấp theo đúng thứ tự, không theo cỡ chữ
• Có đầy đủ các phần tử landmark thật (header, nav, main, footer)
• Mọi hành động có thể click là một <button>; mọi link điều hướng là một <a href>
• Mọi input trong form có một <label> thật, được gắn kết đầy đủ — không chỉ là placeholder
• Hình ảnh có ý nghĩa có alt text mô tả; hình ảnh trang trí có alt=""
• Trạng thái focus hiển thị rõ trên mọi phần tử tương tác
• Thứ tự tab khớp với thứ tự đọc thị giác
• Độ tương phản của text và component UI đạt chuẩn WCAG AA (4.5:1 / 3:1)
• Màu sắc không bao giờ là tín hiệu duy nhất cho state hay ý nghĩa
• ARIA chỉ được dùng ở những chỗ HTML ngữ nghĩa không thể tự diễn đạt được tương tác
• Vùng chạm vẫn dùng được ở các breakpoint mobile
• Layout reflow mà không cắt hay chồng chữ ở chiều rộng hẹp

Cách rà soát code sinh ra trước khi đưa vào production

Đầu ra của MarkupGen mặc định ưu tiên phần tử ngữ nghĩa và một cấu trúc heading thật, thay vì là một tùy chọn phải bật thêm, và việc cấu trúc Auto Layout được chuyển tiếp thành một thứ tự DOM hợp lý chính là phần lớn lý do khiến thứ tự tab đúng trở nên khả thi ngay từ đầu. Điểm chất lượng AI tự động mà mỗi bản xuất nhận được là một tín hiệu ban đầu thực sự hữu ích — nhưng đó rõ ràng là một điểm khớp thị giác, so sánh bản preview đã render với thiết kế gốc. Nó không kiểm tra tính đúng đắn của ARIA, tỷ lệ tương phản hay hành vi bàn phím, vì không cái nào trong số đó nhìn thấy được qua một phép so sánh ảnh chụp màn hình. Hãy coi checklist ở trên là lượt rà soát thủ công đến sau một điểm thị giác cao, chứ không phải thay thế cho nó — xem How to Evaluate AI-Generated HTML Before You Ship It để thấy cùng nguyên tắc đó được áp dụng rộng hơn cho việc review code.

Thử ngay trên thiết kế của bạn

Cách nhanh nhất để biết thiết kế của bạn cần rà soát accessibility ở đâu là chuyển đổi nó và mở markup thật ra xem. Dùng thử MarkupGen miễn phí, hoặc bắt đầu với hướng dẫn chuyển đổi Figma sang HTML đầy đủ cho quy trình từ đầu đến cuối mà bài viết này dựa trên.