Cách audit độ tương phản màu mà không cần cài đặt gì

Các đợt audit độ tương phản màu thường bị xem như một nhiệm vụ accessibility dành cho chuyên gia: mở tệp thiết kế, cài plugin, xuất ảnh chụp màn hình, chạy báo cáo, rồi tranh luận về màu thương hiệu. Những việc đó có thể hữu ích, nhưng không phải là nơi hầu hết đội ngũ nên bắt đầu.

Với một website production, cách audit nhanh và đáng tin cậy nhất thường được thực hiện ngay trong trình duyệt bạn đã mở sẵn. DevTools của các trình duyệt hiện đại có thể kiểm tra màu đã tính toán, hiển thị tỷ lệ tương phản, làm lộ các kiểu trạng thái và giúp bạn thử những trường hợp khó mà báo cáo tự động thường bỏ sót.

Hướng dẫn này giả định rằng bạn không cài đặt bất cứ thứ gì. Không browser extension. Không design plugin. Không bộ công cụ audit trả phí. Chỉ có trang, trình duyệt và một phương pháp đơn giản.

Những quy tắc tương phản bạn thực sự cần

Với phần lớn công việc web, độ tương phản WCAG quy về một vài ngưỡng:

• Văn bản thông thường: độ tương phản tối thiểu 4.5:1 so với nền.
• Văn bản lớn: tối thiểu 3:1. WCAG định nghĩa mức này xấp xỉ 24 pixel CSS, hoặc khoảng 18.66 pixel CSS nếu in đậm.
• Thành phần UI và đối tượng đồ họa: tối thiểu 3:1 cho các ranh giới, biểu tượng, trạng thái và các phần của biểu đồ có ý nghĩa cần thiết để hiểu giao diện.
• Tương phản nâng cao: 7:1 cho văn bản thông thường và 4.5:1 cho văn bản lớn nếu bạn muốn vượt trên mức cơ bản.

Có một số ngoại lệ, chẳng hạn như control không hoạt động, thành phần trang trí và logo. Hãy dùng các ngoại lệ đó một cách tiết chế. “Đó là một phần của thương hiệu” không phải là ngoại lệ; đó là một ràng buộc thiết kế.

Cũng cần nhớ rằng độ tương phản chỉ là một phần của việc dùng màu sao cho accessible. Nếu trạng thái lỗi màu đỏ có đủ tương phản nhưng không có văn bản, nhãn biểu tượng hoặc chỉ báo lập trình được, nó vẫn có thể gây thất bại cho người dùng không phân biệt được màu đỏ với các màu gần đó.

Bắt đầu với trang đã render, không phải tệp thiết kế

Tệp thiết kế rất hữu ích, nhưng chúng không bao gồm mọi biến số trong thực tế: CSS override, opacity, trạng thái hover, cách trình duyệt render font, zoom của người dùng, dark mode, kiểu kế thừa, nội dung CMS và các phần nhúng marketing.

Hãy audit trang như cách người dùng thực sự nhận được nó.

Mở trang trong một trình duyệt desktop hiện đại. Chrome, Edge, Firefox và Safari đều có các công cụ kiểm tra hữu ích. Nhãn chính xác có thể khác nhau, nhưng quy trình thì giống nhau:

1. Nhấp chuột phải vào văn bản hoặc thành phần UI.
2. Chọn Inspect.
3. Tìm color và background-color đã tính toán.
4. Dùng ô mẫu màu của trình duyệt hoặc bảng accessibility để đọc tỷ lệ tương phản.
5. Ghi lại pass, fail và những điểm chưa chắc chắn.

Trong các trình duyệt dựa trên Chromium, bộ chọn màu thường hiển thị tỷ lệ tương phản và hướng dẫn pass/fail theo WCAG cho văn bản. Firefox DevTools cũng cung cấp thông tin accessibility và công cụ màu. Safari’s Web Inspector có thể hiển thị computed styles và thông tin accessibility, dù quy trình hơi khác.

Điểm mấu chốt không phải là trình duyệt cụ thể nào. Điểm mấu chốt là đọc kết quả đã tính toán, không phải giá trị mà ai đó nghĩ là component đang dùng.

Lập một danh sách audit nhỏ trước

Đừng kiểm tra văn bản ngẫu nhiên cho đến khi bạn mệt. Hãy lập một inventory ngắn về các pattern:

• Body text trên nền chính của trang.
• Văn bản muted, chú thích, metadata và placeholder.
• Liên kết ở trạng thái normal, hover, visited và focus.
• Nút primary, secondary và destructive.
• Nhãn form, help text, thông báo lỗi và thông báo thành công.
• Mục điều hướng, breadcrumb và tab.
• Card, badge, pill và tag.
• Biểu tượng truyền đạt ý nghĩa.
• Biểu đồ, bản đồ, thanh tiến trình và màu trạng thái.
• Văn bản trên hình ảnh, video, gradient hoặc lớp phủ trong suốt.

Danh sách này đủ để tìm ra phần lớn lỗi trên một site điển hình. Nó cũng giữ cho audit gắn với component, thay vì các pixel đơn lẻ.

Nếu audit của bạn bao gồm nút, hãy kiểm tra độ tương phản song song với các điểm cơ bản trong checklist nút web accessible của chúng tôi. Vấn đề tương phản của nút thường nằm cạnh trạng thái focus bị thiếu, nhãn không rõ hoặc hành vi bàn phím bị hỏng.

Kiểm tra độ tương phản văn bản trong DevTools

Với văn bản đơn giản trên nền đặc, trình duyệt thường có thể tính độ tương phản cho bạn.

Kiểm tra phần tử và tìm thuộc tính color. Mở bộ chọn màu từ ô mẫu màu. Nếu trình duyệt xác định được nền, nó sẽ hiển thị tỷ lệ tương phản. Một số công cụ còn vẽ một đường trong bộ chọn màu để cho biết màu sẽ đạt 3:1, 4.5:1 hoặc 7:1 ở đâu.

Khi trình duyệt báo fail, hãy tin điều đó cho đến khi bạn chứng minh được ngược lại. Khi nó báo pass, vẫn cần dùng phán đoán. Chữ nhỏ và mảnh, màn hình chất lượng thấp, anti-aliasing mạnh và nền rối có thể khiến văn bản về mặt kỹ thuật là đạt nhưng vẫn trông yếu.

Một quy tắc thực tế: nếu body text chỉ vừa đủ đạt ở mức 4.55:1, đừng vội ăn mừng. Hãy chừa thêm khoảng an toàn. Yêu cầu tương phản là mức tối thiểu, không phải mục tiêu lý tưởng.

Typography cũng quan trọng. Một hệ thống chữ lớn hơn, rõ hơn sẽ giảm căng thẳng cho người đọc ngay cả trước khi bạn chỉnh màu. Nếu trang vẫn khó đọc dù đạt tương phản, hãy xem lại độ dài dòng, kích thước, độ đậm và khoảng cách bằng một góc nhìn rộng hơn về khả năng đọc, như hướng dẫn thực tế này về kiểu chữ dễ đọc.

Kiểm tra nền thực tế, bao gồm opacity

Nhiều lỗi tương phản xảy ra vì nền nhìn thấy được không phải là nền đã khai báo.

Các bẫy thường gặp gồm:

• Văn bản nằm trong một card bán trong suốt.
• Văn bản nằm trên phần tử cha có áp dụng opacity.
• Lớp phủ dùng rgba() hoặc color-mix().
• Gradient phía sau heading.
• Hình nền thay đổi trên vùng văn bản.
• Biến theme thay đổi trong dark mode.

Nếu DevTools không thể tính độ tương phản một cách chắc chắn, hãy xác định thủ công màu foreground và background đã render. Dùng bảng computed styles, tạm thời tắt các layer, hoặc lấy mẫu màu nhìn thấy bằng bộ chọn màu tích hợp nếu trình duyệt của bạn hỗ trợ.

Với văn bản trên hình ảnh, đừng lấy mẫu ở phần đẹp nhất của ảnh. Hãy lấy mẫu ở vùng xấu nhất có thể xảy ra phía sau văn bản. Nếu hình ảnh thay đổi qua upload CMS, carousel hoặc crop responsive, đây không phải là một hệ thống tương phản ổn định. Hãy thêm lớp phủ đáng tin cậy, bóng chữ, container nền đặc hoặc xử lý gradient để bảo vệ văn bản bất kể hình ảnh là gì.

Một hệ thống lớp phủ hình ảnh tốt thường rất “nhàm chán”: cùng cường độ lớp phủ, vùng crop dự đoán được, đủ tương phản ngay cả với ảnh sáng. Nhàm chán cũng ổn. Người dùng đang cố đọc.

Đừng quên các trạng thái

Ảnh chụp màn hình tĩnh bỏ sót nhiều lỗi tương phản. Hãy audit trực tiếp các trạng thái tương tác trong trình duyệt.

Trong DevTools, ép các pseudo-class như:

• :hover
• :focus
• :focus-visible
• :active
• :visited
• :disabled
• :checked
• :invalid

Sau đó kiểm tra lại các màu đã tính toán.

Chỉ báo focus cần được chú ý đặc biệt. WCAG 2.2 đã tăng kỳ vọng về hình thức focus, và đường viền xanh nhạt trên card xám nhạt vẫn là một lỗi phổ biến. Chỉ báo focus cần đủ tương phản với các màu liền kề và đủ diện tích để người dùng nhận thấy.

Với control bị disabled, quy tắc tương phản WCAG có ngoại lệ cho component không hoạt động. Điều đó không có nghĩa là trạng thái disabled mặc định nên khó đọc. Nếu trạng thái disabled truyền đạt thông tin hữu ích, hãy làm cho nó đọc được. Nếu không, hãy cân nhắc liệu nó có nên xuất hiện hay không.

Dùng Lighthouse, nhưng đừng giao phán đoán cho nó

Các đợt audit trong trình duyệt như Lighthouse có thể nhanh chóng bắt một số lỗi tương phản. Hãy chạy audit tích hợp nếu trình duyệt của bạn có, rồi xem kết quả như điểm khởi đầu.

Kiểm tra tự động rất giỏi trong việc tìm các node văn bản có lỗi tương phản tính toán rõ ràng. Chúng yếu hơn ở:

• Văn bản nhúng trong hình ảnh.
• Nhãn được render bằng canvas.
• Các trường hợp biên của SVG.
• Lỗi chỉ xuất hiện khi hover.
• Chất lượng chỉ báo focus.
• Biểu đồ nơi quan hệ màu sắc mang ý nghĩa.
• Component ẩn sau xác thực, menu hoặc các bước form.

Nếu báo cáo trả về màu xanh, bạn vẫn cần kiểm tra các component đại diện. Nếu báo cáo trả về màu đỏ, hãy tránh hoảng loạn và phân loại lỗi theo tác động đến người dùng. Nguyên tắc tương tự cũng áp dụng chung cho các báo cáo performance và accessibility: đọc đầu ra của công cụ như bằng chứng, không phải phán quyết. Chúng tôi dùng tư duy đó trong hướng dẫn đọc báo cáo Lighthouse mà không hoảng loạn, và nó áp dụng rất gọn ở đây.

Audit cả độ tương phản không phải văn bản

Văn bản nhận được nhiều chú ý nhất, nhưng WCAG cũng bao phủ nội dung không phải văn bản cần thiết để hiểu hoặc vận hành giao diện.

Hãy kiểm tra ít nhất các trường hợp sau:

• Viền input so với nền trang.
• Đường viền checkbox và radio.
• Trạng thái toggle.
• Nút chỉ có biểu tượng.
• Biểu tượng lỗi và ký hiệu cảnh báo.
• Đường, cột và nhãn biểu đồ.
• Chỉ báo tiến trình.
• Chỉ báo tab được chọn hoặc điều hướng đang active.

Mục tiêu thường là 3:1 so với các màu liền kề. Ví dụ, viền input xám nhạt trên nền trắng có thể gần như vô hình. Một biểu đồ với năm đường pastel có thể trông thanh lịch nhưng vẫn không dùng được.

Với biểu đồ, chỉ độ tương phản thôi là chưa đủ. Hãy dùng nhãn, pattern, kiểu đường, chú thích trực tiếp hoặc khoảng cách để thông tin không chỉ phụ thuộc vào màu. Điều này giúp người dùng mù màu, người dùng thị lực kém, người xem trong môi trường chói sáng và bất kỳ ai đọc ảnh chụp màn hình trong tài liệu.

Ghi lại phát hiện theo định dạng developer có thể dùng

Một audit độ tương phản hữu ích không nói “một số màu xám bị fail.” Nó xác định component, trạng thái, giá trị hiện tại, ngưỡng kỳ vọng và đề xuất sửa.

Một định dạng gọn thường hiệu quả:

| Component | State | Foreground | Background | Ratio | Target | Result | Suggested fix | |---|---:|---:|---:|---:|---:|---|---| | Metadata của card | Default | #8A8F98 | #FFFFFF | 3.2:1 | 4.5:1 | Fail | Dùng --color-text-muted-strong | | Nút primary | Hover | #FFFFFF | #2F6FEA | 4.8:1 | 4.5:1 | Pass | Giữ nguyên | | Viền input | Default | #D7DCE2 | #FFFFFF | 1.4:1 | 3:1 | Fail | Làm tối border token |

Gắn các bản sửa với design token nếu site có dùng. Đừng vá hai mươi component riêng lẻ nếu một token yếu mới là vấn đề thật sự.

Sửa mạnh hơn mức tối thiểu một chút

Lỗi tương phản thường dễ bị sửa theo cách kém. Các đội chỉ nhích màu cho đến khi checker báo 4.51:1, rồi chuyển tiếp. Cách đó không chừa biên cho việc render font, độ trong suốt, khác biệt trình duyệt, theming, biến thiên hình ảnh hoặc chỉnh sửa thương hiệu trong tương lai.

Hãy ưu tiên các mục tiêu thoải mái:

• Body text: gần 7:1 hơn khi thực tế cho phép.
• Văn bản muted: vẫn trên 4.5:1 nếu đó là nội dung thật.
• Viền và biểu tượng UI: thoải mái trên 3:1.
• Văn bản trên hình ảnh: dùng lớp phủ có kiểm soát thay vì đoán theo từng ảnh.

Web được xem trên laptop giá rẻ, điện thoại mờ, vỉa hè nắng gắt, màn hình ám màu và display đã cũ. Đạt chuẩn tối thiểu không giống với đọc thoải mái.

<!-- tool-cta:start -->

💡 Thử cách này: Khi kiểm tra các cặp độ tương phản bạn lấy từ DevTools, Color Converter giúp chuyển đổi giữa hex, RGB và HSL để các giá trị khớp với ghi chú kiểm tra của bạn.

<!-- tool-cta:end -->

Checklist audit độ tương phản không cần cài đặt

Dùng trình tự này khi bạn cần một audit nhanh nhưng đáng tin cậy:

1. Mở trang production trong một trình duyệt hiện đại.
2. Liệt kê các pattern chính về văn bản, UI và trạng thái.
3. Kiểm tra màu foreground và background đã tính toán trong DevTools.
4. Dùng bộ chọn màu tích hợp hoặc bảng accessibility để đọc độ tương phản.
5. Ép các trạng thái hover, focus, active, visited và invalid.
6. Kiểm tra văn bản trên hình ảnh và gradient so với nền xấu nhất có thể xảy ra.
7. Kiểm tra các phần UI không phải văn bản theo yêu cầu 3:1.
8. Chạy audit tự động tích hợp như một lưới an toàn, không phải toàn bộ audit.
9. Ghi lại lỗi theo component và token.
10. Sửa với biên an toàn, không chỉ vừa vượt ngưỡng.

Như vậy là đủ để bắt phần lớn vấn đề tương phản mà không cần thêm một công cụ nữa vào stack của bạn. Các audit nâng cao hơn vẫn có chỗ đứng, đặc biệt với design system lớn, sản phẩm chịu quy định hoặc trực quan hóa dữ liệu phức tạp. Nhưng với nhiều website, trình duyệt đã cung cấp bằng chứng bạn cần. Phần khó là đủ có hệ thống để sử dụng nó.