Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Practical Accessibility Implementation

Đã đọc 0/14 mục · còn khoảng 13 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Mở đầu — vì sao bài này quan trọng

Ở Bài 1, chúng ta đã đi qua nền tảng lý thuyết của accessibility: nó là gì, ai được hưởng lợi, và tại sao đây không phải là "tính năng thêm thắt" mà là một phần cốt lõi của thiết kế tốt. Nhưng lý thuyết mà không biến thành sản phẩm chạy được thì cũng chỉ là slide đẹp. Bài này là bài đầu tiên bạn thực sự "xắn tay áo" — chúng ta chuyển từ hiểu sang làm được.

Trong nghề, tôi thấy khoảng cách lớn nhất của các bạn designer và developer trẻ ở Việt Nam không phải là thiếu kiến thức, mà là thiếu một quy trình thực thi (implementation workflow) đủ cụ thể để áp dụng ngay khi mở Figma hay VS Code. Bạn biết "màu chữ phải đủ tương phản", nhưng khi sếp giao một trang landing page với deadline chiều nay thì bạn kiểm tra tương phản bằng cách nào? Bạn biết "đừng dùng màu để truyền tin", nhưng cái nút "Còn hàng / Hết hàng" trên trang thương mại điện tử đang chỉ khác nhau ở màu xanh với đỏ thì sửa ra sao?

Bài này tập trung vào ba trụ cột thực thi mà bạn dùng mỗi ngày, ở mọi dự án, bất kể công nghệ gì: màu sắc và độ tương phản (color & contrast), không truyền đạt thông tin chỉ bằng màu, và cách kiểm thử với người mù màu (color blindness). Đây là những thứ chiếm phần lớn lỗi accessibility trong các báo cáo audit thực tế, và may mắn là chúng cũng nằm trong nhóm dễ sửa nhất. Nắm chắc bài này, bạn đã xử lý được một tỷ lệ đáng kể các vấn đề trước cả khi chạm tới những chủ đề phức tạp hơn ở các bài sau.

Khái niệm cốt lõi

Độ tương phản là gì và đo bằng gì

Độ tương phản (contrast ratio) là tỷ số giữa độ sáng (luminance) của màu chữ (foreground) và màu nền (background). Nó được biểu diễn dưới dạng một tỷ lệ, ví dụ 4.5:1 hay 7:1. Giá trị càng cao, chữ càng nổi bật so với nền, càng dễ đọc. Thang đo chạy từ 1:1 (hai màu y hệt nhau, hoàn toàn không đọc được) tới 21:1 (đen tuyệt đối trên trắng tuyệt đối).

Điểm mấu chốt bạn cần khắc cốt ghi tâm: con người không cảm nhận độ sáng theo tuyến tính. Màu vàng nhạt trông rất sáng với mắt ta, nhưng về mặt tính toán luminance nó gần với trắng, nên đặt chữ vàng nhạt trên nền trắng gần như không đọc được dù "cảm giác" hai màu khác nhau. Đó là lý do bạn không thể phán đoán tương phản bằng mắt thường — bạn phải đo bằng công cụ. Rất nhiều designer giỏi về thẩm mỹ vẫn tạo ra giao diện fail accessibility chỉ vì tin vào cảm nhận cá nhân.

Ngưỡng WCAG bạn phải thuộc lòng

WCAG (Web Content Accessibility Guidelines) định ra các mức đạt chuẩn. Ở cấp độ AA — mức mà 90% dự án thương mại và gần như mọi yêu cầu pháp lý nhắm tới — con số cần nhớ là:

  • 4.5:1 cho văn bản thường (normal text): chữ có kích thước nhỏ hơn khoảng 18pt (24px) thông thường, hoặc nhỏ hơn 14pt (khoảng 18.66px) nếu in đậm.
  • 3:1 cho văn bản lớn (large text): chữ từ 18pt (24px) trở lên, hoặc từ 14pt (18.66px) trở lên nếu in đậm.
  • 3:1 cho thành phần giao diện phi văn bản (non-text): viền của ô input, biểu tượng (icon) mang nghĩa, đường ranh giới của nút bấm, biểu đồ — những thứ người dùng cần nhìn thấy để thao tác.
Nếu dự án yêu cầu mức AAA (thường là các website chính phủ, y tế, giáo dục), ngưỡng nâng lên 7:1 cho văn bản thường và 4.5:1 cho văn bản lớn. Trong thực tế, hãy mặc định làm AA, và cân nhắc AAA cho phần nội dung đọc dài như bài viết, hợp đồng, điều khoản.

Một lưu ý mà nhiều bạn bỏ sót: quy tắc "large text được nới lỏng xuống 3:1" khiến nhiều người lạm dụng, đặt tiêu đề màu nhạt cho "đẹp". Large text dễ đọc hơn về mặt hình dạng chữ, nhưng người thị lực kém vẫn cần độ tương phản. Đừng coi 3:1 là cái cớ để làm giao diện mờ nhạt.

Không truyền đạt thông tin chỉ bằng màu

Đây là nguyên tắc "don't convey information by color alone" — một trong những tiêu chí WCAG bị vi phạm nhiều nhất ở các sản phẩm Việt Nam. Ý tưởng đơn giản: bất kỳ thông tin nào bạn mã hóa bằng màu, phải có thêm ít nhất một tín hiệu thứ hai không phụ thuộc màu — chữ, biểu tượng, hoa văn, gạch chân, hình dạng.

Vì sao? Người mù màu (khoảng 8% nam giới và 0.5% nữ giới) không phân biệt được cặp màu bạn đang dùng. Người dùng screen reader không "thấy" màu chút nào. Người in trang ra giấy đen trắng cũng mất luôn thông tin màu. Nếu trạng thái "hợp lệ / lỗi" của một ô form chỉ khác nhau ở viền xanh và viền đỏ, thì với một tỷ lệ đáng kể người dùng, hai trạng thái đó là giống hệt nhau.

Ba dạng mù màu chính

Để kiểm thử có ý nghĩa, bạn nên biết mình đang mô phỏng cái gì:

  • Deuteranopia và Protanopia (mù màu đỏ–lục): phổ biến nhất, khiến đỏ và xanh lá dễ lẫn vào nhau — đúng cặp màu ta hay dùng cho "đúng/sai", "tăng/giảm".
  • Tritanopia (mù màu lam–vàng): hiếm hơn, lẫn xanh dương với xanh lá, vàng với hồng.
  • Achromatopsia (mù màu hoàn toàn): chỉ thấy sắc độ xám, cực hiếm nhưng là phép thử khắc nghiệt nhất — nếu giao diện của bạn dùng được ở chế độ xám thì gần như dùng được với mọi dạng mù màu.

Tình huống thực tế

Ví dụ 1 — Trang sản phẩm của một sàn thương mại điện tử Việt

Hãy tưởng tượng một sàn TMĐT nội địa (gọi là "ChợViệt") có trang danh sách sản phẩm. Mỗi sản phẩm hiển thị trạng thái kho: chữ "Còn hàng" màu xanh lá #4CAF50 và "Hết hàng" màu đỏ #F44336, cùng đặt trên nền trắng.

Đội QA nội bộ chạy audit và phát hiện hai lỗi cùng lúc. Thứ nhất, chữ xanh #4CAF50 trên nền trắng chỉ đạt tương phản khoảng 2.5:1 — fail chuẩn AA (cần 4.5:1). Chữ đỏ #F44336 đạt khoảng 3.9:1, cũng fail. Thứ hai, thông tin còn/hết hàng chỉ được phân biệt bằng màu. Một khách hàng nam bị mù màu đỏ–lục nhắn phản hồi rằng anh không phân biệt được sản phẩm nào còn hàng, phải bấm vào từng cái mới biết — trải nghiệm bực bội dẫn tới bỏ giỏ hàng.

Cách sửa của đội: đổi màu chữ sang tông đậm hơn để đạt tương phản (#2E7D32 cho xanh đạt ~5.1:1, #C62828 cho đỏ đạt ~5.9:1), và quan trọng hơn — thêm biểu tượng dấu tích cho "Còn hàng" và dấu gạch chéo cho "Hết hàng", đồng thời giữ nguyên nhãn chữ. Giờ đây thông tin được truyền qua ba kênh: chữ, biểu tượng, và màu.

Bài học: một lỗi thị giác thường kéo theo một lỗi "màu đơn kênh" đi kèm. Sửa cả hai cùng lúc, và luôn hỏi: "Nếu tắt màn hình màu, người dùng còn hiểu được không?"

Ví dụ 2 — Form đăng ký của một ứng dụng fintech

Một startup ví điện tử (gọi là "PayNhanh") thiết kế form đăng ký. Khi người dùng nhập sai định dạng số điện thoại, ô input chuyển viền sang màu đỏ #E53935. Không có thông báo lỗi bằng chữ, không có biểu tượng.

Vấn đề nằm ở hai tầng. Viền đỏ #E53935 trên nền trắng đạt khoảng 3.9:1 — với thành phần non-text ngưỡng là 3:1 nên viền vừa đủ đạt về mặt tương phản. Nhưng trạng thái lỗi chỉ được báo bằng màu viền, vi phạm nguyên tắc không-chỉ-dùng-màu. Người mù màu và người dùng screen reader hoàn toàn không nhận ra mình vừa nhập sai; họ bấm "Đăng ký" và không hiểu vì sao form không submit.

Đội sản phẩm sửa lại: giữ viền đỏ, thêm một dòng chữ lỗi bên dưới ("Số điện thoại phải có 10 chữ số") màu #C62828 đạt tương phản 4.5:1 với nền, kèm một biểu tượng cảnh báo. (Việc gắn thông báo lỗi này vào ô input cho screen reader đọc được là chủ đề của Bài 15 — Form Accessibility; ở đây ta chỉ tập trung khía cạnh màu và tín hiệu thị giác.)

Bài học: đối với trạng thái lỗi, màu là phụ trợ, không bao giờ là kênh duy nhất. Một dòng chữ mô tả lỗi vừa giải quyết vấn đề màu vừa giúp người dùng hiểu sai chỗ nào.

Ví dụ 3 — Dashboard biểu đồ của một agency

Một agency ở TP.HCM làm dashboard analytics cho khách hàng. Biểu đồ đường có năm dòng số liệu, phân biệt hoàn toàn bằng năm màu khác nhau, chú thích (legend) đặt riêng ở góc. Khi khách hàng in báo cáo ra giấy đen trắng để họp, năm đường trở thành năm sắc xám gần như không phân biệt nổi. Một thành viên ban lãnh đạo bị mù màu cũng phàn nàn tương tự ngay trên màn hình.

Giải pháp: mỗi đường ngoài màu còn có kiểu nét khác nhau (liền, đứt, chấm) và gắn nhãn trực tiếp ở cuối đường thay vì để legend tách rời. Với dữ liệu dạng cột, họ thêm hoa văn (pattern) cho từng nhóm.

Bài học: dữ liệu trực quan (data visualization) là nơi vi phạm "màu đơn kênh" nghiêm trọng nhất và cũng dễ bị bỏ quên nhất, vì bản thân nó "trông đã đẹp". Luôn thêm kênh thứ hai: kiểu nét, hoa văn, hoặc nhãn trực tiếp.

Hướng dẫn từng bước

Đây là quy trình bạn có thể áp dụng ngay khi nhận một màn hình cần triển khai:

  • Liệt kê mọi cặp chữ–nền. Đi qua thiết kế, gom lại từng loại: chữ thân bài trên nền chính, chữ phụ (caption) trên nền, chữ trên nút, chữ trên ảnh, placeholder trong input. Mỗi cặp là một phép đo.
  • Đo tương phản từng cặp. Dùng một trong các công cụ: WebAIM Contrast Checker (web), plugin "Stark" hoặc "A11y - Color Contrast Checker" trong Figma, hoặc tab Inspect của Chrome DevTools (chọn phần tử chữ, phần Accessibility sẽ hiện contrast ratio). Ghi lại con số.
  • Đối chiếu với ngưỡng. Phân loại cặp đó là normal text hay large text, rồi so với 4.5:1 / 3:1. Với viền input, icon chức năng, dùng ngưỡng 3:1.
  • Sửa những cặp fail. Ưu tiên chỉnh độ sáng của màu chứ không nhất thiết đổi tông màu — làm đậm màu chữ hoặc làm nhạt màu nền cho tới khi đạt. Giữ nhận diện thương hiệu bằng cách chỉ dịch chuyển sắc độ (lightness) trong không gian HSL.
  • Rà soát mọi thông tin đang mã hóa bằng màu. Tìm mọi chỗ dùng màu để biểu đạt trạng thái, phân loại, cảnh báo: link, tag, biểu đồ, badge trạng thái, form validation, dòng bắt buộc (*). Với mỗi chỗ, tự hỏi: có tín hiệu thứ hai không?
  • Thêm kênh thứ hai ở nơi còn thiếu. Chữ, biểu tượng, gạch chân (đặc biệt cho link trong đoạn văn), kiểu nét, hoa văn.
  • Kiểm thử với mô phỏng mù màu. Bật bộ lọc mù màu và soi lại toàn màn hình (xem phần công cụ ở dưới).
  • Ghi lại quyết định. Lưu bảng màu đã đạt chuẩn kèm giá trị tương phản vào design system hoặc file token, để lần sau cả team không phải đo lại từ đầu.

Lỗi thường gặp & mẹo

Lỗi: tin vào mắt mình. Như đã nói, cảm nhận màu của con người không tuyến tính. Luôn đo, đừng đoán. Đây là lỗi số một.

Lỗi: quên chữ đặt trên ảnh hoặc gradient. Nền thay đổi theo vị trí nên tương phản cũng thay đổi. Mẹo: thêm một lớp phủ tối bán trong suốt (scrim) dưới chữ, hoặc dùng khối nền đặc sau chữ, để đảm bảo tương phản ổn định ở mọi điểm.

Lỗi: placeholder làm nhiệm vụ của label. Placeholder thường màu xám nhạt (fail tương phản) và biến mất khi gõ. Đừng dùng nó thay label. (Chi tiết về label thuộc Bài 15.)

Lỗi: link chỉ khác đoạn văn ở màu. Trong một đoạn văn, nếu link chỉ đổi màu (thường là xanh dương) mà không gạch chân, người mù màu không nhận ra đâu là link. Mẹo: gạch chân link nằm trong nội dung; ngoài ra WCAG còn yêu cầu bản thân link phải khác chữ thường ít nhất 3:1 về màu và có tín hiệu phụ.

Lỗi: dùng màu thương hiệu cứng nhắc. Nhiều bạn nói "brand guideline quy định màu này rồi, không sửa được". Mẹo: bạn thường có thể tạo một biến thể đậm hơn của màu thương hiệu chỉ để dùng cho chữ nhỏ, giữ nguyên màu gốc cho mảng lớn và trang trí. Đề xuất điều này với bộ phận thương hiệu kèm số liệu tương phản — con số thuyết phục hơn tranh luận cảm tính.

Mẹo: đưa tương phản vào design token ngay từ đầu. Nếu bạn định nghĩa text-on-surface, text-error, border-input như các token đã kiểm chứng đạt chuẩn, thì mọi thành viên dùng lại sẽ tự động đúng. Đây là cách các design system trưởng thành phòng lỗi từ gốc.

Mẹo: chế độ tối (dark mode) phải đo lại riêng. Đảo màu không tự động giữ tương phản. Một bảng màu đạt AA ở light mode có thể fail ở dark mode và ngược lại.

Bài tập thực hành

Chọn một trang web tiếng Việt bạn hay dùng (một sàn TMĐT, một trang tin, hoặc chính sản phẩm bạn đang làm) và thực hiện:

  • Audit tương phản. Dùng WebAIM Contrast Checker hoặc Chrome DevTools đo ít nhất 5 cặp chữ–nền khác nhau trên trang (chữ thân bài, chữ nút chính, chữ phụ, placeholder, chữ trên banner). Lập bảng gồm: mô tả cặp, mã màu chữ, mã màu nền, tỷ lệ đo được, loại text (normal/large), kết luận Pass/Fail theo AA.
  • Sửa cặp fail. Với mỗi cặp fail, đề xuất mã màu mới đạt chuẩn, chỉ điều chỉnh độ sáng để giữ tông màu gần nhất. Ghi lại tỷ lệ mới.
  • Săn lỗi màu đơn kênh. Tìm ít nhất 2 chỗ trên trang truyền thông tin chỉ bằng màu (trạng thái, link, biểu đồ, tag...). Mô tả tín hiệu thứ hai bạn sẽ thêm vào.
  • Kiểm thử mù màu. Bật một bộ lọc mù màu (hướng dẫn ở dưới), chụp màn hình trước/sau, và chỉ ra thành phần nào trở nên khó phân biệt.
Gợi ý bật mô phỏng mù màu trong Chrome: mở DevTools (F12) → nhấn Ctrl/Cmd + Shift + P → gõ "Rendering" → chọn "Show Rendering" → tìm mục "Emulate vision deficiencies" → chọn lần lượt Protanopia, Deuteranopia, Tritanopia, Achromatopsia. Ngoài ra có thể dùng phần mềm Color Oracle (miễn phí, chạy toàn màn hình) để soi cả ứng dụng desktop lẫn Figma.

Hãy trình bày kết quả thành một mini-report ngắn — đây chính là dạng tài liệu bạn sẽ nộp trong công việc thật khi làm accessibility audit.

Tóm tắt

Bài này biến ba nguyên tắc thành thao tác cụ thể bạn dùng hằng ngày. Thứ nhất, độ tương phản đo được, không đoán được: nhớ ngưỡng AA là 4.5:1 cho chữ thường, 3:1 cho chữ lớn và thành phần giao diện, luôn dùng công cụ để kiểm chứng. Thứ hai, không bao giờ truyền thông tin chỉ bằng màu: mọi trạng thái, phân loại, cảnh báo phải có ít nhất một kênh thứ hai — chữ, biểu tượng, kiểu nét hay hoa văn. Thứ ba, kiểm thử với mô phỏng mù màu để tận mắt thấy sản phẩm của mình qua con mắt của khoảng 8% người dùng.

Ba ví dụ — sàn TMĐT, form fintech, dashboard agency — cho thấy các lỗi này không phải chuyện lý thuyết mà trực tiếp gây bỏ giỏ hàng, đăng ký thất bại, và báo cáo không đọc được. Điều đáng mừng: đây là nhóm lỗi accessibility dễ phát hiện và dễ sửa nhất, thường chỉ cần chỉnh vài mã màu và thêm một biểu tượng. Hãy đưa quy trình 8 bước ở trên thành thói quen, và tốt nhất là đóng gói kết quả vào design token để cả team đứng trên nền tảng đã đạt chuẩn. Ở các bài tiếp theo, chúng ta sẽ mở rộng sang cấu trúc HTML ngữ nghĩa và ARIA — nhưng nền màu sắc vững chắc bạn xây hôm nay sẽ theo bạn suốt cả khóa.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi