Bảng màu dễ truy cập: Ngừng dùng HSL trong hệ thống màu
(wildbit.com)- Bảng màu hiện tại của Postmark có độ sáng cảm nhận không đồng đều giữa các màu và khó dự đoán tỷ lệ tương phản giữa các cấp, nên mỗi lần đều phải kiểm tra thủ công độ tương phản theo khuyến nghị WCAG
- HSL/HSV là các mô hình chỉ chuyển đổi đơn giản từ RGB, không phản ánh cảm nhận của con người về độ sáng và độ bão hòa; có thể dùng để chọn một màu đơn lẻ nhưng không phù hợp để xây dựng hệ thống màu
- CIELAB và LCh là không gian màu đồng đều theo cảm nhận, được thiết kế để thay đổi về số liệu gần hơn với thay đổi cảm nhận, nhờ đó có thể tạo các thang màu ở cùng mức độ sáng một cách nhất quán hơn
- Accessible Palette là ứng dụng dựa trên LCh, tạo ra bảng màu nhất quán bằng cách điều chỉnh độ sáng, tỷ lệ tương phản, hiệu chỉnh Hue và phản ánh màu thương hiệu hiện có
- Nên kiểm tra đồng thời tỷ lệ tương phản WCAG 2.1 và APCA trong WCAG 3 Working Draft để dễ đáp ứng cả hướng dẫn hiện tại lẫn những thay đổi về thuật toán tương phản trong tương lai
Vấn đề trong hệ thống màu của Postmark
- Bảng màu hiện tại của Postmark có hai vấn đề
- Độ sáng cảm nhận không nhất quán, chẳng hạn xanh dương và đỏ trông tối hơn nhiều so với vàng và xanh lá
- Khó dự đoán tỷ lệ tương phản giữa các biến thể màu, nên không dễ biết một cặp màu có đáp ứng khuyến nghị của WCAG hay không
- Mỗi khi chọn một cặp màu đều phải kiểm tra tỷ lệ tương phản thủ công, và trên thực tế khả năng cao là việc này sẽ không được kiểm tra
- Nguyên nhân nằm ở giới hạn của chính mô hình màu HSL, cũng như việc các công cụ thiết kế chưa hỗ trợ đầy đủ những lựa chọn thay thế tốt hơn
Vì sao HSL không phù hợp với hệ thống màu
- RGB là mô hình phản ánh cách màn hình hoạt động, chứ không phải mô hình trực quan giúp con người dễ chọn màu
- HSL và HSV/HSB là các lựa chọn thay thế được tạo ra vào thập niên 1970 nhằm biểu diễn RGB gần hơn với cách con người nghĩ về màu sắc
- HSL là viết tắt của Hue, Saturation, Lightness
- HSV/HSB là viết tắt của Hue, Saturation, Value hoặc Brightness
- Vào thời điểm đó, chi phí tính toán của các mô hình tinh vi hơn còn cao, nên HSL và HSV đã hy sinh độ chính xác theo cảm nhận để đổi lấy tốc độ tính toán
- Kết quả là HSL và HSV chỉ là các phép chuyển đổi toán học đơn giản của RGB, không phản ánh đúng độ sáng hay độ bão hòa mà con người cảm nhận
- Ví dụ, một thang màu đặt Saturation 100 và Lightness 50 trong HSL có cùng độ sáng theo mô hình, nhưng trên thực tế xanh dương
#00Ftrông tối hơn nhiều so với vàng#FF0hoặc cyan#0FF - Trong HSL, màu có độ bão hòa tối đa được ánh xạ tới giá trị tối đa của RGB và nằm trên vòng Hue ở Lightness 50; Lightness 0 và 100 lần lượt tương ứng với đen và trắng
- Các biến thể sáng hơn hoặc tối hơn được tạo theo cách “trộn” với trắng hoặc đen
- Trục dọc ở giữa là dải màu trung tính hoặc xám với Saturation 0
CIELAB và LCh
- Vào thời điểm HSL và HSV được chính thức hóa, đã tồn tại một lựa chọn thay thế tốt hơn là không gian màu CIELAB
- International Commission on Illumination, tức CIE, đã định nghĩa CIELAB hoặc không gian màu L*a* b* vào năm 1976
- CIELAB là không gian màu đồng đều theo cảm nhận, được thiết kế sao cho các thay đổi về số liệu tương ứng với những thay đổi màu sắc cảm nhận được ở mức tương tự
- Khác với RGB, nó được thiết kế để bao phủ toàn bộ dải màu có thể nhìn thấy
- Thành phần L*, tức Lightness, được điều chỉnh gần với cảm nhận của con người về độ sáng
- CIELAB gồm ba trục
- Giá trị L* định nghĩa màu đen ở 0 và màu trắng ở 100
- Trục a* là trục màu đối lập xanh lá-đỏ; giá trị âm nghiêng về xanh lá, giá trị dương nghiêng về đỏ
- Trục b* là trục màu đối lập xanh dương-vàng; giá trị âm nghiêng về xanh dương, giá trị dương nghiêng về vàng
- CIELCh, LCh, hoặc Lch(ab) là biểu diễn hình trụ của CIELAB
- Thay cho a* và b*, nó dùng Chroma và góc Hue
- Lightness được giữ nguyên
- Góc Hue của LCh giống Hue trong HSL nhưng không hoàn toàn giống
- HSL/HSV đặt ba màu cơ bản cộng đỏ, xanh lá, xanh dương tại H=0, 120, 240°
- LCh đặt đỏ, vàng, xanh lá, xanh dương tại h=0, 90, 180, 270°
- Cũng có một không gian màu tương tự gọi là HCL hoặc LCh(uv); khác với LCh(ab), Chroma của nó có thang đo đồng đều từ 0 đến 100
Cách tạo thang màu trong LCh
- Khác với HSL/HSV, LCh nằm trong một hình trụ nhưng không lấp đầy hình trụ đó
- Một số tổ hợp Lightness, Chroma và Hue tạo ra các màu không thể tồn tại
- Ví dụ, màu vàng tối và có độ bão hòa cao không tồn tại
- Trên thang Lightness, càng gần đen và trắng thì số lượng màu mà con người có thể phân biệt càng giảm
- Màn hình thực tế không thể hiển thị toàn bộ các màu có thể nhìn thấy
- Gam màu sRGB đại diện cho màn hình thông thường và chỉ bao gồm khoảng ⅓ không gian màu LCh
- Ngay cả trong CSS, ít nhất hiện tại cũng bị giới hạn trong phạm vi này
- Nếu nhìn thang màu có Saturation 100 và Lightness 50 trong HSL theo chuẩn LCh, vàng là màu sáng nhất còn xanh dương là màu tối nhất
- Xanh lá sáng hơn xanh dương gần ba lần và sáng hơn đỏ khoảng hai lần
- Khi tạo lại thang màu ở cùng mức Lightness trong LCh, độ sáng giữa các màu nhất quán về mặt thị giác
- Do Chroma khác nhau, một số màu có thể bão hòa hơn các màu khác
- Với màu thông báo và cảnh báo, có thể bạn muốn chúng bão hòa hơn màu chữ mặc định; trong hệ thống màu, khác biệt như vậy có thể hữu ích
- Nếu điều chỉnh cả Chroma cho nhất quán hơn, vẫn có thể tạo ra thang màu mượt mà trong không gian màu sRGB giới hạn
Giới hạn của công cụ thiết kế và Accessible Palette
- Hiện tại Figma, Sketch, Adobe XD không hỗ trợ CIELAB hoặc LCh
- Figma có các plugin LCH color picker và Chromatic, nhưng chúng chưa đủ để tạo một hệ thống màu linh hoạt
- Công cụ cần thiết phải đáp ứng ba điều kiện
- Duy trì tính nhất quán về độ sáng khi tạo các biến thể màu
- Có thể kiểm soát tỷ lệ tương phản giữa các cấp
- Đủ linh hoạt để chấp nhận các màu thương hiệu hiện có
- Sau khi tìm thấy thư viện Chroma.js có hỗ trợ LCh tốt, tác giả đã tạo một công cụ đơn giản bằng code để sinh bảng màu mới
- Sau khi dùng nội bộ và chia sẻ với một số người quen, công cụ này được công khai dưới dạng ứng dụng Accessible Palette
- Accessible Palette là ứng dụng để tạo hệ thống màu có độ sáng nhất quán và tỷ lệ tương phản dự đoán được trên toàn bộ các cấp màu
Cách Accessible Palette hoạt động
- Khi điều chỉnh màu khởi đầu hoặc dán màu từ thiết kế hiện có, công cụ sẽ dùng Chroma và Hue của màu đó để tính thang màu ở nhiều cấp Lightness
- Lightness có thể tùy chỉnh hoàn toàn và dùng được cho cả bảng màu sáng lẫn bảng màu tối
- Có thể tinh chỉnh để bao gồm các màu thương hiệu hiện có
- Ở Postmark, họ đã cố giữ lại các màu được dùng nhiều nhất trong bảng màu cũ: vàng
#FFDE00, xanh dương#007DCC, xanh lá#4FC47F - Các giá trị Lightness 88.6, 75.2, 50.6 của những màu này lần lượt được dùng làm độ sáng cho các cấp 200, 400, 600
- Tỷ lệ tương phản thay đổi theo Lightness, và với mỗi cấp được tính bằng cả phương pháp khuyến nghị của WCAG 2.1 lẫn thuật toán mới trong WCAG 3.0 Working Draft
- Mặc định, độ tương phản của mọi màu được đo trên nền trắng
- Có thể chọn mẫu màu mong muốn để đo tỷ lệ tương phản dựa trên màu đó
- Các cấp có thể được tạo bằng không gian màu RGB hoặc CIELAB
- Vì kết quả có thể khác trong một số trường hợp, đáng để thử nghiệm
- Trong hệ màu của Postmark, dùng CIELAB đã giảm sắc tím ở màu đỏ sáng, nhưng lại tăng sắc tím ở màu xanh dương
- Một số màu có thể cần hiệu chỉnh Hue trên toàn dải
- Vàng sáng có xu hướng ngả xanh lá khi tối dần
- Để làm nó gần với cam hơn một chút, họ dùng hiệu chỉnh Hue âm
- Ứng dụng cập nhật URL trong khi sử dụng để lưu lại các thay đổi
- Có thể chia sẻ với nhóm hoặc thêm vào thư viện Figma và file biến màu CSS để tham chiếu về sau
- Các bảng màu ví dụ gồm bảng màu dựa trên Postmark color palette, Google’s Material Design, TailwindCSS
- Các ví dụ này không sao chép chính xác bản gốc, mà là các phương án thay thế lấy cảm hứng từ màu gốc và các cấp độ sáng ban đầu
Tính tỷ lệ tương phản và WCAG
- Lý do Accessible Palette hiển thị hai loại tỷ lệ tương phản là vì phương pháp của WCAG 2.1 có giới hạn
- WCAG 2.1 tính tỷ lệ tương phản bằng cách chia độ chói của màu tiền cảnh cho độ chói của màu nền
- Công thức này cho phản hồi tuyến tính, nhưng con người cảm nhận tương phản giữa các màu sáng cao hơn tương phản giữa các màu tối
- Trong ví dụ thực tế, một mẫu đáp ứng khuyến nghị WCAG 2.1 có thể khó đọc hơn mẫu bị đánh dấu là có tỷ lệ tương phản “không đủ”
- W3C nhận thức được vấn đề này, và Andrew Somers đã khởi xướng thảo luận công khai vào năm 2019
- Thuật toán làm việc mới do Andrew Somers đề xuất đã trở thành một phần của WCAG 3 Working Draft, và ông cũng tạo APCA Contrast Calculator
- APCA là viết tắt của Advanced Perceptual Contrast Algorithm, chính xác hơn về mặt cảm nhận và cũng xét đến kích thước, độ đậm của phông chữ
- Accessible Palette dùng APCA và sử dụng điểm 60 làm mức khuyến nghị tối thiểu cho văn bản có thể đọc được
- Đây là tiêu chuẩn tương tự khuyến nghị tỷ lệ tương phản 4.5:1 hiện có của WCAG 2.1
- Tỷ lệ tương phản WCAG 2.1 không phải hoàn toàn vô dụng
- Ở các màu vùng trung gian, nó vẫn khá chính xác
- Tuy nhiên xét tổng thể, thuật toán mới là một cải tiến lớn
- Phương pháp WCAG 3 hiện vẫn là Working Draft nên có thể thay đổi theo thời gian
- Nếu muốn vừa tuân thủ hướng dẫn hiện tại vừa chuẩn bị cho thay đổi trong tương lai, tốt hơn nên xây dựng hệ thống màu với cả hai bộ hướng dẫn trong đầu
1 bình luận
Ý kiến trên Hacker News
Trong các hệ thống hiển thị và in ấn thông thường, nên xem đỏ và xanh lam bão hòa thực ra tối hơn xanh lục
Công thức chính xác thay đổi tùy theo không gian màu, nhưng
Grayscale = 0.299R + 0.587G + 0.114Bthường được trích dẫn; trong trường hợp này, đỏ thuần sáng nhất có độ sáng khoảng 30%, còn xanh lam thuần là 11%, nên trong đa số trường hợp đỏ sáng gần như là một mâu thuẫnVẫn có thể dùng những màu như vậy, nhưng chúng chắc chắn luôn trông tối; nếu chỉ áp dụng các quy tắc tương phản thì có thể đáp ứng khả năng tiếp cận, nhưng nếu muốn kết quả còn đẹp mắt thì kỹ thuật được bàn trong bài viết có lợi hơn nhiều
Ngay cả khi tạo ảnh nổi đỏ-xanh như https://en.wikipedia.org/wiki/Anaglyph_3D, cây cối và cỏ là màu xanh lục nhưng thực tế có nhiều thành phần đỏ, nên cân bằng kênh tốt và cho ra cả hiệu ứng nổi lẫn màu sắc tốt
Tham khảo: https://www.dynamsoft.com/blog/insights/image-processing/ima...
Việc giải thích rằng tác phẩm màu đỏ tuyệt đẹp sẽ trông chẳng đẹp chút nào trên TV luôn rất khó, đặc biệt là khi dùng cho phát sóng
Ngay cả khi không dùng cho phát sóng, màu đỏ ngoài chuẩn có thể còn lưu lại đến vài khung hình sau và trông như bị loang ra như cổ bị cắt
Nếu đã đọc các trả lời, hãy phản hồi thì tôi sẽ thử giải thích rõ hơn vài điểm
Từ lâu tôi đã thấy khó chịu vì các mẫu thực sự đáp ứng tiêu chí khuyến nghị WCAG 2.1 lại khó đọc hơn các mẫu có tỷ lệ tương phản “không đủ”
Tôi tự hỏi vì sao công thức “hướng dẫn khả năng tiếp cận” lại được chuẩn hóa trong khi nó tạo ra tác dụng ngược
WCAG 2.1 là vậy và tiêu chuẩn tiếp theo cũng thế; với một lĩnh vực có ảnh hưởng lớn như thế này, tôi mong ngành sẽ tài trợ cho các nghiên cứu nghiêm ngặt hơn
Có lẽ chỉ đơn giản là đã có yêu cầu như vậy, chứ chưa chắc đã được chính thức áp dụng
Bài hay nhất tôi từng đọc về chủ đề này là https://www.handprint.com/HP/WCL/color1.html
Bài rất dài, nên cần chuẩn bị tinh thần là sẽ mất cả ngày
Có thể bạn sẽ ngạc nhiên, nhưng khi tô màu log cho đẹp trong ClickHouse, chúng tôi cũng dùng một số ý tưởng từ bài này: https://github.com/ClickHouse/ClickHouse/blob/master/base/ba...
Tôi tò mò liệu bạn có thể chia sẻ các giá trị RGB mong đợi cho từng loại thông điệp được thiết lập trong mã không
Tôi đã gặp Eugene tại hội nghị Config của Figma; anh ấy chia sẻ rất nhiều mẹo thực chiến tương tự cho các nhà thiết kế, là người thật sự tử tế và rất tâm huyết với thiết kế cũng như khả năng tiếp cận
Điều tôi đặc biệt muốn khen trong bài này là APCA, vốn có khả năng kế thừa thuật toán tương phản màu của WCAG 2
Chúng tôi cũng dùng APCA trong lần cải tổ khả năng tiếp cận nội bộ của Figma, và nhờ vậy kết quả cuối cùng tốt hơn nhiều
Eugene chỉ ra rất rõ các trường hợp WCAG 2 thất bại, và trên thực tế chúng tôi cũng liên tục gặp những trường hợp như vậy
Lời khuyên cốt lõi là việc chỉnh màu cho đúng thật sự rất khó
Công cụ có ích, nhưng đến một lúc nào đó bạn phải tin vào mắt mình
Rốt cuộc các công cụ này chỉ là phép xấp xỉ toán học cho cách mắt nhìn màu, còn tiêu chuẩn cuối cùng không phải thuật toán mà là mắt người
Ở những điểm mà công cụ hay thuật toán cho ra kết quả không đúng, tốt hơn là nên điều chỉnh hoặc quay về những điều cơ bản
Tôi muốn biết có phải ý bạn là chỉ dùng APCA và bỏ qua những nội dung mà thuật toán tương phản màu WCAG 2 đánh dấu là thiếu tương phản không
Làm rất tốt
Cũng muốn giới thiệu HCT
Đây là không gian màu được tạo ra để hiện thực hóa Material You, kết hợp các phép đo độ sáng nói ở đây với không gian màu dựa trên khoa học màu sắc hiện đại
LAB/LCH là từ năm 1976
Nó giúp thiết kế trực quan hơn: chỉ cần biết rằng chênh lệch
Tlà 40 thì đạt tiêu chí WCAG cho nút, còn 50 thì đạt tiêu chí cho văn bảnTôi tò mò HCT so sánh thế nào với https://www.hsluv.org/comparison/
Tương tự HCT, ở đây việc chọn màu tương phản trở nên dễ hơn dựa trên chênh lệch
LCũng trong bối cảnh đó, tôi muốn biết suy nghĩ về https://www.myndex.com/APCA/ và cách tiếp cận khi nó trở thành tiêu chuẩn
Vì giá trị tương phản giữa hai màu thay đổi tùy màu nào là tiền cảnh và màu nào là nền, nên có vẻ giờ đây chỉ so sánh chênh lệch
Tlà chưa đủVí dụ giả sử một ứng dụng cần đỏ, vàng, xanh lam, cam, xanh lục, tím, tức 6 màu tương ứng với 3 màu cơ bản và 3 màu bổ sung
Chính xác chúng là màu nào thì không quá quan trọng, nhưng nếu muốn 6 màu đó phần nào dễ phân biệt và có độ sáng, có thể cả độ bão hòa, tương tự nhau thì nên làm thế nào
Vì vàng rất sáng còn xanh lam rất tối, có lẽ không có đáp án chính xác và phải tiến tới một giá trị xấp xỉ
Tôi tò mò có công cụ hay hướng dẫn nào để học những điều như vậy không
Thứ tôi tìm được chỉ là mã
material-color-utilitiestrên GitHubNhìn vào mã thì phép tính có vẻ phức tạp hơn OkLab nhiều, đặc biệt là chiều từ HCT sang RGB
Ngoài việc bài viết bỏ sót oklab/oklch, nhận định rằng web/CSS chỉ hỗ trợ sRGB cũng sai
Hàm CSS
color()hỗ trợ nhiều không gian màuBài này được xuất bản 2 năm trước, và khi tôi bắt đầu làm công cụ thì đặc tả OkLCH còn chưa có
Nếu là bây giờ tôi sẽ chọn OkLCH thay vì LCH, vì nó giải quyết một số vấn đề của LCH
Ở đây, “hỗ trợ” nói chính xác hơn là “được hỗ trợ ngoại trừ Microsoft Edge(chromium) và Pale Moon(goanna)”
https://test.csswg.org/harness/results/css-color-4_dev/group...
Tuy nhiên nó dùng tỷ lệ tương phản của APCA, tức WCAG 3, thay vì độ sáng: https://github.com/antiflasher/apcach
oklab có thể là một lựa chọn tốt hơn LCh
https://bottosson.github.io/posts/oklab/
Kênh độ sáng bị đảo ngược so với mọi không gian màu khác, và
Lkhông liên quan gì đếnLtrong LCH hay LABThành công của nó ở một khía cạnh nào đó lại mang đến thêm sự nghèo nàn về mặt trí tuệ
Bài blog đầu tiên có rất nhiều nội dung cần chỉnh sửa, và lập luận bắt đầu lệch hẳn từ chỗ dùng gradient dựa trên CAM16 UCS để khẳng định độ chính xác
Nếu các giá trị CIELAB dựa trên thay đổi cảm nhận, tôi tò mò chúng tương tác với khả năng tiếp cận như thế nào
Có cần lo rằng các công thức cảm nhận này có thể được xây dựng dựa trên thị lực tiêu chuẩn không
Tôi cũng tự hỏi liệu điều đó có thể khác nhau theo từng dạng rối loạn sắc giác, hay đây không phải là vấn đề thuộc loại đó
Tôi đang cố làm biểu đồ dễ tiếp cận nhất có thể, nhưng chưa từng học gì về màu sắc nên chỉ làm theo lời khuyên chứ không thể tự suy ra
Vì vậy rất có thể đây là một câu hỏi ngớ ngẩn
Độ tương phản thay đổi phi tuyến
Mô phỏng có thể áp dụng khá dễ, và mô phỏng của Machado cùng các tác giả khác chỉ là phép biến đổi ma trận
Bài viết đặt phần giải thích ở phía dưới, nhưng APCA Contrast, phép kiểm tra độ tương phản dễ đọc trong bản thảo tiêu chuẩn WCAG 3, công bằng hơn nhiều với một số màu so với tỷ lệ tương phản của WCAG 2.1
Bài viết dễ đọc về lý thuyết màu đằng sau tương phản cảm nhận: https://www.smashingmagazine.com/2022/09/realities-myths-con...
Bài giải thích ngắn gọn về APCA: https://typefully.com/u/DanHollick/t/sle13GMW2Brp
Trước khi dùng vào việc gì, tốt hơn nên xem kỹ phần đó và đánh giá xem có thật sự dùng được hay không
Mã nằm ở đâu?
Cần một thuật toán có thể dùng trong bất kỳ phần mềm nào, chứ không phải một biểu mẫu web
Tôi đã tự dùng thử và nó hoạt động tốt
https://github.com/gka/chroma.js
Oklab được giới thiệu trong [2], và mã trong bài đó thật sự rất dễ dùng
[1]: https://news.ycombinator.com/item?id=37310534
[2]: https://bottosson.github.io/posts/oklab/