Cách chọn các tổ hợp màu dễ tiếp cận
Việc chọn màu trông như một quyết định thẩm mỹ và hành xử như một quyết định pháp lý. Khoảng 4.000 vụ kiện về khả năng tiếp cận web mỗi năm tấn công các bị đơn ở Mỹ kể từ năm 2021, và độ tương phản màu không đủ là một trong ba vấn đề được trích dẫn nhiều nhất trong các đơn kiện dựa trên WCAG (cùng với văn bản alt bị thiếu và các trường biểu mẫu không có nhãn). Tin tốt là độ tương phản là vấn đề dễ sửa nhất trong ba: một tỷ lệ tương phản là một con số, ngưỡng WCAG là một con số, và bạn có thể tính một bên so với bên kia trong vài giây. Tin xấu là "dễ tiếp cận" vượt ra ngoài tỷ lệ tiêu đề: mù màu, chỉ báo tiêu điểm, chế độ tối, và tokenization tất cả đều quan trọng, và một bảng màu đạt điểm 4,5:1 trên mọi kiểu văn bản vẫn có thể thất bại với người dùng thực.
Lịch sử ngắn của khả năng tiếp cận màu kỹ thuật số
Độ tương phản màu như một tiêu chuẩn được viết ra có từ công việc Web Accessibility Initiative đầu tiên của W3C vào năm 1997. Web Content Accessibility Guidelines 1.0 ban đầu (tháng 5 năm 1999) khuyến nghị độ tương phản đủ về mặt định tính mà không có con số cứng. WCAG 2.0 (tháng 12 năm 2008) đã giới thiệu công thức độ sáng tương đối hiện quen thuộc và tỷ lệ 4,5:1 ở Cấp AA, rút ra từ nghiên cứu của Lighthouse International về những gì người dùng lớn tuổi đeo kính đọc có thể đọc thoải mái trên màn hình.
Trọng lượng pháp lý đến sau. Section 508 của U.S. Rehabilitation Act đã tham chiếu WCAG 2.0 vào năm 2018; Americans with Disabilities Act, sau phán quyết của Tòa phúc thẩm Khu vực 9 trong vụ Robles v. Domino's ngày 15 tháng 1 năm 2019 (Tòa án Tối cao từ chối nghe đơn kháng cáo vào tháng 10 năm 2019), hiện được các tòa án Mỹ đọc là bao gồm khả năng tiếp cận kỹ thuật số theo Title III. European Accessibility Act có hiệu lực ngày 28 tháng 6 năm 2025, yêu cầu WCAG 2.1 AA trên các dịch vụ kỹ thuật số đối mặt với người tiêu dùng cho khu vực công và nhiều công ty tư nhân. Trong thực tế, 4,5:1 văn bản bình thường + 3:1 văn bản lớn + 3:1 thành phần UI là mức sàn thực tế cho bất kỳ trang web công cộng nào đang được xây dựng hôm nay.
Khoa học tiếp tục phát triển. WCAG 2.1 (2018) đã thêm quy tắc tương phản không-văn-bản 3:1. Thuật toán APCA, được phát triển bởi Andrew Somers cho WCAG 3, mô hình nhận thức độ sáng chính xác hơn và đưa ra các con số khác nhau cho các kết hợp rất tối và rất sáng; nó là Editor's Draft tính đến năm 2026, chưa phải là tiêu chuẩn, vì vậy hầu hết các quy định vẫn trích dẫn WCAG 2.x. OKLAB và OKLCH của Bjorn Ottosson (2020) đã cho các nhà thiết kế một không gian màu đồng nhất về mặt nhận thức làm cho việc tạo ra các thang màu dễ tiếp cận dễ dàng hơn nhiều so với làm việc trong HSL hoặc RGB.
"Màu dễ tiếp cận" thực sự có nghĩa là gì
Bốn điều quan trọng, không chỉ một tỷ lệ:
- Độ tương phản tiền cảnh so với nền. Con số tiêu đề. Văn bản thân cần 4,5:1, văn bản lớn 3:1, các điều khiển UI và chỉ báo tiêu điểm 3:1 so với màu liền kề. Tính tỷ lệ bằng công thức WCAG 2 trong bất kỳ trình kiểm tra tương phản nào.
- Mù màu. Khoảng 8% nam giới và 0,5% nữ giới nhìn thấy ít màu sắc hơn so với những gì thiết kế giả định. Ba loại chính là protanopia và deuteranopia (đỏ-xanh lá, phổ biến nhất), và tritanopia (xanh dương-vàng). Một nhãn lỗi đỏ trên nhãn thành công xanh lá có thể không nhìn thấy được đối với người mù màu protanopic.
- Màu sắc không bao giờ là tín hiệu duy nhất. WCAG 1.4.1 cấm dựa vào màu sắc một mình để truyền đạt ý nghĩa. Một đường viền "lỗi" đỏ cũng cần một biểu tượng hoặc nhãn. Một toast "thành công" xanh lá cần một dấu kiểm.
- Chỉ báo tiêu điểm. Người dùng bàn phím cần nhìn thấy tiêu điểm đang ở đâu. Quy tắc WCAG 2.4.7 yêu cầu một chỉ báo tiêu điểm hiển thị, và cập nhật 2.4.11 (WCAG 2.2) yêu cầu nó dày ít nhất 2 pixel CSS và tương phản 3:1 so với màu liền kề.
Một bảng màu lấy đúng tỷ lệ nhưng bỏ qua ba điều kia vẫn thất bại với người dùng thực.
Cách chọn màu dễ tiếp cận, từng bước
- Bắt đầu với token ngữ nghĩa, không phải màu thô. Định nghĩa
text-primary,text-secondary,surface-default,surface-elevated,border-default,accent-primary,accent-danger, v.v. Ánh xạ mỗi token vào một màu cụ thể, và để các token đó mang ý nghĩa ngữ nghĩa ở mọi nơi trong design system. - Chọn thang độ sáng. Sử dụng các giá trị độ sáng OKLCH để xây dựng một thang 5-9 bước (50, 100, 200, ..., 900) trong đó mỗi bước có một sự khác biệt nhận thức không đổi từ bước tiếp theo. Các con số sẽ trông bất thường trong OKLCH (khoảng L = 0,97, 0,93, 0,88...) nhưng các bước được cảm nhận sẽ đồng đều, điều không thể trong HSL.
- Chọn các tông màu tại mỗi bước độ sáng. Chọn tông màu thương hiệu, sau đó chọn các tông màu bổ sung hoặc tông nhấn duy trì chroma tương tự. Sử dụng OKLCH để "xanh dương độ bão hòa 100" và "cam độ bão hòa 100" trông cùng độ sáng.
- Tính các tỷ lệ tương phản. Mỗi cặp token chạm nhau cần đúng tỷ lệ. Văn bản thân trên bề mặt mặc định: 4,5:1. Văn bản bị vô hiệu trên bề mặt mặc định: vẫn 3:1 nếu cần đọc được. Chỉ báo tiêu điểm trên bề mặt liền kề: 3:1.
- Chạy trình mô phỏng mù màu. Lấy một màn hình chính và render lại qua các trình mô phỏng protanopia, deuteranopia, và tritanopia. Xác nhận rằng thông tin được truyền đạt bởi màu sắc vẫn có thể phân biệt được.
- Kiểm tra với công nghệ hỗ trợ thực. Mac VoiceOver, NVDA, JAWS, và TalkBack đều phải có thể điều hướng mà không phụ thuộc vào các gợi ý màu.
- Thêm tín hiệu không-màu ở mọi nơi màu mang ý nghĩa. Biểu tượng cho lỗi/thành công/cảnh báo, gạch chân cho các liên kết trong văn bản thân, các mẫu cho chuỗi biểu đồ.
- Tài liệu hóa các token. Một thư viện Figma, một trang Storybook, hoặc một trang design-system tĩnh. Auditor và các nhà thiết kế mới phải có thể chọn token phù hợp trong vài giây.
Tham chiếu tỷ lệ tương phản
| Cặp ghép | Tối thiểu WCAG 2.1 | Cấp AA | Cấp AAA |
|---|---|---|---|
| Văn bản thân (dưới 18 pt thường hoặc 14 pt đậm) | 4,5:1 | 4,5:1 | 7:1 |
| Văn bản lớn (18 pt thường hoặc 14 pt đậm) | 3:1 | 3:1 | 4,5:1 |
| Các thành phần UI (đường viền biểu mẫu, trạng thái toggle, tiêu điểm) | 3:1 | 3:1 | n/a |
| Các đối tượng đồ họa (biểu tượng mang ý nghĩa) | 3:1 | 3:1 | n/a |
| Văn bản bên trong logo | miễn trừ | miễn trừ | miễn trừ |
| Các điều khiển bị vô hiệu | miễn trừ | miễn trừ | n/a |
| Văn bản trang trí | miễn trừ | miễn trừ | miễn trừ |
Việc miễn trừ cho các điều khiển bị vô hiệu là một sơ hở pháp lý, không phải một lời chúc phúc về khả năng sử dụng; một điều khiển bị vô hiệu mà không ai có thể đọc được có thể về mặt kỹ thuật vượt qua WCAG nhưng vẫn sẽ làm người dùng bối rối.
Các loại mù màu và cách kiểm tra
| Loại | Tỷ lệ phổ biến | Thấy ít hơn | Thất bại phổ biến |
|---|---|---|---|
| Protanopia | ~1% nam giới | Đỏ | Lỗi đỏ và thành công xanh lá không thể phân biệt |
| Deuteranopia | ~5% nam giới | Xanh lá | Tương tự: nhầm lẫn đỏ-xanh lá |
| Tritanopia | ~0,005% | Xanh dương | Xanh dương và vàng không thể phân biệt |
| Achromatopsia | ~0,003% | Tất cả màu sắc | Chỉ thấy độ sáng grayscale |
| Trichromacy bất thường | ~5% | Giảm độ nhạy trong một kênh | Các khác biệt màu tinh tế hòa nhau |
Luôn chạy thiết kế qua ít nhất các trình mô phỏng protanopia và deuteranopia; chúng bắt được phần lớn người dùng mù màu.
Các cạm bẫy phổ biến
- Thiết kế trong HSL hoặc RGB. Các bước số bằng nhau trong HSL tạo ra các bước được cảm nhận không đồng đều. Một bước nhảy độ sáng 10% trong vàng nhạt trông lớn hơn nhiều so với cùng bước nhảy trong xanh dương đậm. OKLCH khắc phục điều này.
- Dựa vào màu sắc một mình để truyền đạt trạng thái. Đỏ và xanh lá cho lỗi và thành công: 8% người dùng không thể phân biệt chúng. Thêm biểu tượng hoặc nhãn.
- Đen tinh khiết trên trắng tinh khiết.
#000trên#FFFđạt tỷ lệ hoàn hảo 21:1 nhưng gay gắt với mắt khi đọc lâu. Giảm xuống gần-đen (#1a1a1a) và gần-trắng (#f8f8f8) cho văn bản thân. - Bạo chúa màu thương hiệu. Coi đỏ thương hiệu là thiêng liêng và sử dụng nó trên trắng thương hiệu ở tương phản 2,1:1 chỉ vì "đó là thương hiệu". Làm mới bảng màu thương hiệu thành một bảng đáp ứng WCAG.
- Chỉ báo tiêu điểm biến mất trên nền tối. Một vòng xanh 2 pixel trên một nút xanh đậm có thể không nhìn thấy. Kiểm tra vòng tiêu điểm trên mọi bề mặt nơi nó có thể xuất hiện.
- Văn bản placeholder thất bại tương phản. Văn bản
placeholder=bên trong input được trình duyệt render ở ~40% độ mờ đục. Trên input trắng, điều đó dễ dàng giảm xuống dưới 4,5:1. - Đường viền trường biểu mẫu quá mờ. Một đường viền 1px xám-trên-trắng ở tương phản 1,2:1 thất bại WCAG 1.4.11 (tương phản không-văn-bản). Nâng lên 3:1 hoặc dày hơn.
- Trạng thái hover chỉ thay đổi màu. Một số thiết bị nhập con trỏ (bút stylus Bluetooth, theo dõi mắt) không tạo ra hover; một thay đổi màu chỉ-hover là vô hình đối với chúng. Kết hợp với một bóng tinh tế hoặc biến đổi.
- Chế độ tối bằng cách đảo ngược đơn giản. Đảo ngược một bảng màu sáng tạo ra các màu tối bão hòa trông gay gắt. Các bảng màu chế độ tối cần lần thiết kế riêng với các tông nhấn giảm bão hòa.
- Văn bản tự động tạo ra từ hình ảnh. Văn bản được render lên trên một hình ảnh được người dùng tải lên không thể đảm bảo độ tương phản. Thêm một nền trong suốt hoặc text-shadow đưa độ tương phản cục bộ trở lại.
Các thuật toán và tiêu chuẩn thay thế
| Thuật toán | Năm | Trạng thái | Điểm mạnh |
|---|---|---|---|
| Tỷ lệ tương phản WCAG 2.x | 2008 | Yêu cầu bởi hầu hết quy định | Toán đơn giản, công cụ rộng rãi |
| APCA | 2020 | WCAG 3 Editor's Draft | Tốt hơn ở độ sáng nhận thức |
| ISO 9241-302 | 2008 | Tiêu chuẩn ergonomic workstation | Hướng phần cứng, rất nghiêm ngặt |
| Cảnh báo tương phản Lighthouse | 2018 | Chrome DevTools | Miễn phí, trong trình duyệt |
| axe-core | 2015 | Thư viện mã nguồn mở | Tiêu chuẩn ngành cho kiểm tra tự động |
Đối với công việc được quy định ngày nay, WCAG 2.1 AA là mức sàn. APCA đáng theo dõi khi WCAG 3 trưởng thành; nhiều đội design system đã báo cáo cả hai con số.
Công cụ để chọn màu dễ tiếp cận
| Công cụ | Mục đích | Điểm mạnh |
|---|---|---|
| Trình kiểm tra tương phản màu (trình duyệt) | Chấm điểm một cặp tiền cảnh/nền | Tức thời, không tải lên, có thể truy cập từ bất kỳ thiết bị nào |
| Trình tạo bảng màu dễ tiếp cận | Xây dựng một thang độ sáng đầy đủ ở chroma không đổi | Sử dụng OKLCH cho tính đồng nhất nhận thức |
| Trình mô phỏng mù màu | Render lại một màn hình như người mù màu nhìn thấy | Bắt các vấn đề đỏ-xanh lá trước khi ra mắt |
| Chrome DevTools Lens | Kiểm tra tương phản và mù màu tại chỗ | Được tích hợp trong trình duyệt |
| WebAIM Contrast Checker | Tham chiếu WCAG 2 cổ điển | Đáng tin cậy, được trích dẫn rộng rãi |
| Stark (plugin Figma) | Audit thiết kế Figma về tương phản và mù màu | Bắt các vấn đề tại thời điểm thiết kế |
| axe DevTools (trình duyệt) | Quét WCAG tự động | Tiêu chuẩn ngành |
| Các thang màu Tailwind, Radix, Open Props | Các bảng màu đã được kiểm tra dựa trên OKLCH | Khả năng tiếp cận được tuyển chọn bởi các đội thiết kế |
Đối với các dự án mới, hãy bắt đầu từ một bảng màu đã được kiểm tra (Radix Colors và Open Props là các mặc định tốt), chọn các token thương hiệu, và xác minh mọi cặp văn bản-trên-bề-mặt bằng trình kiểm tra tương phản. Đối với các dự án hiện có, hãy thực hiện một lần audit cho mọi cặp văn bản/nền trong stylesheet của bạn, sửa các thất bại, và thêm bước Stark hoặc axe vào CI của bạn để thất bại tiếp theo được bắt tại thời điểm PR.
Quyền riêng tư và các công cụ
Trình kiểm tra tương phản màu, trình tạo bảng màu dễ tiếp cận và trình mô phỏng mù màu đều chạy hoàn toàn trong trình duyệt của bạn. Các màu bạn chọn hoặc dán được xử lý bởi JavaScript trên thiết bị của bạn, kết quả được render lên trang, và không có gì được gửi đến máy chủ. Không có telemetry, không có phân tích trên đầu vào, không có script bên thứ ba. Đối với các màu thương hiệu chưa công khai, các bảng màu sản phẩm nội bộ, hoặc các thiết kế dưới lệnh cấm, luồng chỉ-cục-bộ đó là sự khác biệt giữa tin tưởng công cụ thiết kế của người lạ với các tài sản thương hiệu chưa phát hành của bạn và không. Các công cụ có thể chạy ngoại tuyến sau khi trang được tải, điều bạn có thể xác minh bằng cách tắt mạng và kiểm tra lại một cặp tương phản.
Câu hỏi thường gặp
What contrast ratio does WCAG require?
WCAG 2.1 Level AA requires at least 4.5:1 for normal body text and 3:1 for large text (18 pt regular or 14 pt bold). Level AAA raises that to 7:1 for normal text and 4.5:1 for large text. Non-text UI components and graphical objects need 3:1 against adjacent colors.
Are WCAG contrast ratios scientifically accurate?
They are based on the WCAG 2.0 algorithm from 2008, which compares the relative luminance of two colors using the sRGB color space. The formula is imperfect for very dark and very light combinations and for some color hues; the APCA (Accessible Perceptual Contrast Algorithm) being developed for WCAG 3 produces more perceptually accurate results. For 2026 work, WCAG 2.x is still the standard most regulations cite.
How do I check whether my colors work for color-blind users?
Run them through a color-blindness simulator that converts your palette to what someone with protanopia, deuteranopia, or tritanopia sees. About 8% of men and 0.5% of women have some form of color vision deficiency, so this matters.
Should I use the same color palette for light and dark mode?
Usually not. Dark mode needs slightly desaturated colors at the same hue, otherwise vivid colors that look fine on white become eye-strain on black. Define semantic tokens (text-primary, surface-secondary) and map them to different physical colors per mode.
What does OKLCH have to do with accessibility?
OKLCH is a perceptually uniform color space (Bjorn Ottosson, 2020) where equal numerical changes produce equal perceptual changes. That makes it much easier to generate accessible color scales because you can step the lightness in equal increments and the perceived brightness step is consistent, which is hard to do in HSL or RGB. CSS supports OKLCH directly since 2023 in all major browsers.