Mở đầu — vì sao bài này quan trọng
Có một sự thật mà nhiều bạn UI Designer trẻ ở Việt Nam thường bỏ qua: bạn không thiết kế cho một "người dùng trung bình" tưởng tượng. Bạn thiết kế cho một dải rất rộng những con người thật — có người 22 tuổi mắt tinh như đại bàng, ngồi phòng máy lạnh với màn hình 4K; nhưng cũng có bác 58 tuổi bị viễn thị đang cầm điện thoại giơ ra xa để đọc; có người bị mù màu đỏ-xanh (chiếm khoảng 8% nam giới); có người đang đứng ngoài nắng chói chang ở vỉa hè Sài Gòn nhìn màn hình mờ tịt; có người chỉ dùng bàn phím vì tay phải đang bế con.
Accessibility (viết tắt là a11y — vì giữa chữ "a" và "y" có 11 ký tự) chính là bộ nguyên tắc để thiết kế của bạn dùng được cho tất cả những con người đó, chứ không chỉ cho phiên bản lý tưởng hóa của chính bạn.
Nhiều người nghĩ a11y là việc của developer, là mấy đoạn code aria-label bí hiểm. Sai. Phần lớn các lỗi accessibility bắt nguồn ngay từ file Figma — từ màu chữ quá nhạt, kích thước nút bấm quá nhỏ, thứ tự nội dung lộn xộn. Nếu bạn đưa cho dev một thiết kế đã "hỏng" về a11y, không code nào cứu được. Ngược lại, nếu bạn nắm được những nguyên tắc nền tảng trong bài này, bạn giải quyết được 60-70% vấn đề accessibility trước khi một dòng code nào được viết. Đó là lý do a11y là kỹ năng phân biệt một UI Designer chuyên nghiệp với một người chỉ biết vẽ đẹp.
Ở bài này, chúng ta tập trung vào nền tảng tư duy và những kiểm tra thực tế mà một UI Designer phải làm. Chúng ta sẽ không đi sâu vào công thức contrast HSL (đã có ở Bài 7) hay chi tiết inclusive design vượt ngoài khuyết tật (Bài 40 sẽ bàn) — bài này là điểm khởi đầu vững chắc để bạn "nhìn thấy" accessibility trong mọi màn hình mình chạm vào.
Khái niệm cốt lõi
WCAG và 4 trụ cột POUR
Tiêu chuẩn accessibility chính thức trên toàn cầu là WCAG (Web Content Accessibility Guidelines), do W3C ban hành. Phiên bản đang dùng phổ biến là WCAG 2.1 và 2.2. Bạn không cần học thuộc lòng cả trăm tiêu chí, nhưng bạn PHẢI thuộc bốn trụ cột nền tảng, gọi tắt là POUR:
1. Perceivable (Cảm nhận được). Người dùng phải "nhận" được nội dung bằng ít nhất một giác quan. Nghĩa là: chữ phải đủ tương phản để đọc, hình ảnh phải có văn bản thay thế (alt text) để người mù nghe được qua trình đọc màn hình, video phải có phụ đề. Nếu thông tin chỉ được truyền bằng màu sắc (ví dụ "ô đỏ là sai, ô xanh là đúng"), người mù màu sẽ không cảm nhận được — đây là vi phạm Perceivable.
2. Operable (Thao tác được). Người dùng phải điều khiển được giao diện. Trụ cột này bao gồm: điều hướng được hoàn toàn bằng bàn phím (không bắt buộc phải dùng chuột), không có "bẫy thời gian" (time trap) kiểu popup tự đóng sau 3 giây khiến người đọc chậm không kịp thao tác, vùng chạm (touch target) đủ lớn để bấm không bị trượt, không dùng hiệu ứng nhấp nháy nhanh có thể gây co giật động kinh.
3. Understandable (Hiểu được). Nội dung và cách vận hành phải dễ hiểu và có thể đoán trước. Ngôn ngữ rõ ràng, thông báo lỗi cụ thể ("Email chưa đúng định dạng" thay vì "Lỗi 402"), hành vi nhất quán (nút "Lưu" luôn ở cùng một chỗ, cùng một màu xuyên suốt sản phẩm).
4. Robust (Bền vững). Nội dung phải hoạt động tốt với nhiều công nghệ khác nhau, đặc biệt là trợ lý công nghệ (assistive technology) như trình đọc màn hình (screen reader). Trụ cột này nghiêng về code nhiều hơn, nhưng phần của designer là: đặt tên component rõ ràng, chỉ định đâu là heading/nút/link để dev gắn đúng ngữ nghĩa (semantic).
Hãy nhớ POUR như bốn câu hỏi bạn tự hỏi trước mỗi màn hình: Người ta có nhận ra được không? Có thao tác được không? Có hiểu được không? Có bền với công cụ hỗ trợ không?
Ba mức độ tuân thủ: A, AA, AAA
WCAG chia thành ba mức: A (tối thiểu), AA (tiêu chuẩn công nghiệp), và AAA (cao nhất, hiếm khi bắt buộc toàn bộ). Trong thực tế, AA là mục tiêu mặc định cho hầu hết sản phẩm thương mại. Khi ai đó nói "sản phẩm này phải accessible", 99% là họ muốn nói mức AA. Ở Việt Nam, các dự án làm cho khách hàng châu Âu, Mỹ, Úc hoặc chính phủ thường ràng buộc AA trong hợp đồng — vi phạm có thể bị kiện.
Những con số một UI Designer phải thuộc lòng
Đây là phần "cơm áo gạo tiền" của a11y trong Figma. Bạn nên thuộc như bảng cửu chương:
- Contrast chữ thường (nhỏ hơn 18px hoặc 14px in đậm): tối thiểu tỉ lệ 4.5:1 (mức AA).
- Contrast chữ lớn (từ 24px, hoặc 18.66px in đậm trở lên): tối thiểu 3:1.
- Contrast của thành phần giao diện (viền input, icon mang thông tin, đường ranh giới nút): tối thiểu 3:1.
- Vùng chạm (touch target): tối thiểu 44×44px (chuẩn Apple) hoặc 48×48px (chuẩn Google Material). Trên WCAG 2.2, tiêu chí mới yêu cầu tối thiểu 24×24px, nhưng bạn nên nhắm 44-48 cho an toàn.
- Không dùng màu làm phương tiện truyền tin duy nhất — luôn kèm icon, chữ, hoặc gạch chân.
Screen reader và tại sao thứ tự lớp (layer order) quan trọng
Người khiếm thị dùng screen reader (VoiceOver trên iOS, TalkBack trên Android, NVDA trên Windows) để "nghe" giao diện. Công cụ này đọc lần lượt từng phần tử theo thứ tự trong code. Là designer, bạn ảnh hưởng đến trải nghiệm này qua hai việc: (1) đặt thứ tự nội dung hợp lý trong Figma (dev thường dựng code theo thứ tự layer/frame bạn sắp xếp), và (2) đánh dấu rõ cấp bậc heading (H1, H2, H3) để người nghe có thể "nhảy" nhanh giữa các mục thay vì nghe tuần tự từ đầu.
Tình huống thực tế
Tình huống 1 — Nút "Đặt vé" chìm nghỉm ở một startup du lịch
Một startup đặt tour tại Đà Nẵng (gọi là "GoDaNang") ra mắt app với tông thương hiệu màu cam nhạt (#FFB74D) rất "trendy". Nút CTA quan trọng nhất — "Đặt vé ngay" — dùng chữ trắng trên nền cam nhạt đó. Nhìn trong Figma trên MacBook màn hình đẹp thì lung linh.
Nhưng khi user thật dùng app ngoài trời — mà khách du lịch thì luôn ở ngoài trời — tỉ lệ contrast chữ trắng trên #FFB74D chỉ đạt khoảng 1.9:1, thấp hơn rất nhiều so với ngưỡng 4.5:1. Dữ liệu analytics cho thấy tỉ lệ nhấn nút đặt vé thấp bất thường ở nhóm người dùng trên 45 tuổi. Team ban đầu tưởng do giá, giảm giá mãi không ăn thua.
Một bạn designer mới vào chạy thử Stark plugin trong Figma, phát hiện contrast quá thấp. Họ đổi chữ nút sang màu nâu đậm (#5D4037) trên nền cam — contrast lên 5.1:1, đạt AA — mà vẫn giữ được tông cam thương hiệu. Sau hai tuần, tỉ lệ nhấn nút ở nhóm 45+ tăng rõ rệt. Bài học: contrast không phải chuyện "làm cho đẹp người khuyết tật", nó trực tiếp ảnh hưởng doanh thu vì ai cũng có lúc đọc màn hình trong điều kiện tệ.
Tình huống 2 — Form báo lỗi chỉ bằng màu đỏ ở một ví điện tử
Một ví điện tử phổ biến ở Đông Nam Á thiết kế form nhập số tài khoản. Khi nhập sai, ô input chỉ đổi viền sang màu đỏ, không có chữ giải thích, không có icon. Với người dùng bình thường thì tạm ổn. Nhưng với anh Tuấn — một khách hàng bị mù màu đỏ-xanh (deuteranopia) — viền đỏ nhìn gần như xám giống hệt ô bình thường. Anh loay hoay bấm "Xác nhận" bốn năm lần, không hiểu vì sao không đi tiếp được, cuối cùng bỏ cuộc và chuyển sang app đối thủ.
Đội ngũ nhận phản hồi qua support, chạy audit và sửa theo nguyên tắc không dùng màu làm tín hiệu duy nhất: thêm icon cảnh báo (dấu chấm than) bên trong ô, thêm dòng chữ đỏ đậm bên dưới "Số tài khoản phải có 12 chữ số", và đảm bảo dòng chữ này đạt contrast 4.5:1. Giờ đây dù người dùng có nhìn thấy màu đỏ hay không, họ vẫn nhận được thông tin qua icon và chữ. Bài học: màu sắc chỉ nên là lớp thông tin bổ sung, không bao giờ là lớp duy nhất.
Tình huống 3 — Modal "bẫy" người dùng bàn phím ở một dashboard SaaS
Một công ty SaaS Việt Nam làm phần mềm quản lý kho, bán cho khách châu Âu nên phải đạt WCAG AA theo hợp đồng. Trong lần audit trước khi ship, chuyên gia a11y phát hiện: khi mở modal "Xác nhận xóa", người dùng chỉ điều hướng bằng bàn phím (một số nhân viên kho bị chấn thương tay, không dùng chuột được) bấm phím Tab thì tiêu điểm (focus) lại chạy ra sau modal, xuống các nút ở nền phía dưới — hoàn toàn lạc lối, không có đường thoát.
Đây là lỗi focus trap bị thiếu và thiếu trạng thái focus visible. Phần code do dev xử lý, nhưng designer là người đã bỏ sót: file Figma không hề thiết kế trạng thái focus (viền sáng bao quanh phần tử đang được chọn) cho bất kỳ nút hay input nào. Dev không có mẫu để dựng theo. Sau đó, designer bổ sung một focus ring thống nhất (viền xanh 2px, contrast 3:1 với nền) như một biến thể (variant) trong mọi component tương tác, và ghi chú rõ hành vi khi mở modal. Audit lần hai đạt. Bài học: trạng thái focus là một phần bắt buộc của thiết kế component, ngang hàng với hover và active — không phải "để dev tự lo".
Hướng dẫn từng bước
Đây là quy trình a11y bạn nên chạy trên MỌI màn hình trước khi handoff:
Bước 1 — Kiểm tra contrast toàn bộ văn bản và thành phần. Cài plugin Stark hoặc Contrast trong Figma. Quét từng khối chữ, từng icon mang thông tin, từng viền input. Đối chiếu: chữ thường ≥ 4.5:1, chữ lớn ≥ 3:1, thành phần UI ≥ 3:1. Ghi lại chỗ nào rớt và sửa ngay trong file.
Bước 2 — Kiểm tra "không phụ thuộc màu". Tự hỏi từng chỗ có màu mang nghĩa: nếu chuyển màn hình sang grayscale (đen trắng), người dùng còn hiểu được không? Bật chế độ giả lập mù màu trong Stark (deuteranopia, protanopia, tritanopia) để nhìn thấy. Mọi tín hiệu trạng thái (thành công/lỗi/cảnh báo) phải có kèm icon hoặc chữ.
Bước 3 — Đo vùng chạm. Với mọi phần tử tương tác trên mobile (nút, icon, checkbox, link), đảm bảo vùng chạm tối thiểu 44×44px. Nếu icon nhỏ về mặt thị giác, hãy mở rộng vùng chạm vô hình xung quanh nó (padding) — thị giác nhỏ nhưng vùng bấm phải lớn.
Bước 4 — Duyệt thứ tự nội dung và cấp bậc heading. Đọc màn hình từ trên xuống, trái sang phải, đúng như một screen reader sẽ đọc. Thứ tự có logic không? Có đúng một H1 mỗi màn hình không? Các mục có được phân cấp H2, H3 rõ ràng không? Sắp xếp lại layer trong Figma cho khớp thứ tự logic đó.
Bước 5 — Thiết kế đầy đủ các trạng thái tương tác. Mỗi component tương tác cần tối thiểu: default, hover, focus (viền sáng, đây là trạng thái hay bị quên nhất), active, và disabled. Lưu ý: nút disabled thường được miễn yêu cầu contrast, nhưng đừng lạm dụng khiến người dùng không biết nó là nút.
Bước 6 — Viết alt text và annotation cho dev. Với mỗi hình ảnh mang thông tin, ghi chú nội dung alt text nên là gì. Với các phần cần ngữ nghĩa đặc biệt (đây là landmark điều hướng, đây là nút không phải link), thêm annotation. Việc annotation chi tiết cho handoff sẽ được đào sâu ở Bài 43, ở đây bạn chỉ cần bắt đầu thói quen ghi chú.
Bước 7 — Kiểm tra reduce motion và text scaling. Nếu thiết kế có animation, hãy cân nhắc bản "giảm chuyển động" cho người nhạy cảm với hiệu ứng. Kiểm tra layout có "vỡ" không khi người dùng phóng to cỡ chữ lên 200% (nhiều người lớn tuổi bật tính năng này).
Lỗi thường gặp & mẹo
Lỗi 1 — Tin vào cảm giác "nhìn đủ rõ mà". Mắt bạn trẻ, màn hình bạn xịn, phòng bạn đủ sáng. Cảm giác chủ quan luôn đánh giá quá cao độ tương phản. Luôn dùng công cụ đo, đừng dùng mắt.
Lỗi 2 — Placeholder thay cho label. Nhiều designer bỏ label, chỉ để chữ mờ trong ô input ("Nhập email..."). Khi người dùng bắt đầu gõ, placeholder biến mất — người lớn tuổi hoặc người dùng screen reader quên mất ô này để làm gì. Mẹo: luôn có label thật, hiển thị rõ, đặt phía trên hoặc bên cạnh ô.
Lỗi 3 — Chữ trắng trên ảnh nền. Rất "nghệ" nhưng contrast thay đổi tùy vùng ảnh. Mẹo: thêm lớp phủ tối (dark overlay) hoặc gradient dưới chữ để đảm bảo contrast ổn định ở mọi vùng.
Lỗi 4 — Quên trạng thái focus. Như tình huống 3 đã kể. Mẹo: đưa focus ring vào design system như một biến bắt buộc, dùng chung một style xuyên suốt.
Lỗi 5 — Nghĩ a11y là công đoạn cuối. Nếu để cuối mới "làm accessibility", bạn sẽ phải đập đi làm lại nhiều thứ. Mẹo: kiểm tra contrast và touch target ngay khi đặt màu và kích thước đầu tiên. Biến POUR thành thói quen tự hỏi trong lúc thiết kế, không phải checklist cuối.
Mẹo vàng — Xây a11y vào nền tảng. Nếu color palette và type scale của bạn (thiết lập ở các bài trước) đã được kiểm tra contrast từ đầu, thì mọi màn hình dùng chúng sẽ tự động đạt chuẩn. Accessibility bền vững đến từ hệ thống, không phải từ việc vá lỗi từng màn.
Bài tập thực hành
- Audit một màn hình thật. Lấy một màn hình bất kỳ trong dự án của bạn (hoặc thiết kế lại màn hình đăng nhập của một app Việt Nam bạn hay dùng). Chạy Stark plugin, ghi lại mọi chỗ contrast rớt dưới 4.5:1 và sửa. Chụp ảnh trước/sau.
- Test mù màu. Bật chế độ giả lập deuteranopia, chụp lại màn hình. Tìm mọi chỗ mà thông tin bị mất khi không thấy màu. Thêm icon hoặc chữ để khắc phục.
- Thiết kế bộ trạng thái nút hoàn chỉnh. Tạo một component nút với đủ 5 trạng thái: default, hover, focus, active, disabled. Đảm bảo focus ring đạt contrast 3:1 với nền. Dùng variants trong Figma.
- Viết alt text. Chọn 5 hình ảnh trong một màn hình và viết alt text phù hợp cho từng cái — lưu ý ảnh trang trí thuần túy thì alt text nên để rỗng, còn ảnh mang thông tin phải mô tả nội dung.
Tóm tắt
Accessibility không phải là "tính năng thêm cho người khuyết tật" — nó là chất lượng nền tảng giúp sản phẩm dùng được cho tất cả mọi người, trong mọi hoàn cảnh. Bốn trụ cột POUR (Perceivable, Operable, Understandable, Robust) là khung tư duy bạn áp dụng cho mọi màn hình. Mục tiêu thực tế của hầu hết dự án là WCAG mức AA.
Là UI Designer, phần lớn trách nhiệm a11y nằm trong tay bạn ngay từ file Figma: đảm bảo contrast (4.5:1 cho chữ thường, 3:1 cho chữ lớn và thành phần), không dùng màu làm tín hiệu duy nhất, vùng chạm đủ lớn (44-48px), thiết kế đầy đủ trạng thái focus, và sắp xếp thứ tự nội dung cùng cấp bậc heading hợp lý. Ba tình huống — nút CTA chìm màu ở startup du lịch, form báo lỗi chỉ bằng màu ở ví điện tử, và modal bẫy người dùng bàn phím ở SaaS — cho thấy lỗi a11y luôn là lỗi kinh doanh, không chỉ là lỗi đạo đức.
Hãy biến việc kiểm tra POUR và chạy Stark thành phản xạ. Khi accessibility được xây vào color palette, type scale và component library ngay từ đầu, bạn không còn phải "vá" nó nữa — sản phẩm của bạn tự nhiên dùng được cho tất cả.