พาเลตที่เข้าถึงได้: เลิกใช้ HSL ในระบบสี

 (wildbit.com)
2 คะแนน โดย GN⁺ 2023-08-30 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • พาเลตสีเดิมของ Postmark มีปัญหาที่ ความสว่างตามการรับรู้ ของแต่ละสีไม่สม่ำเสมอ และคาดเดาอัตราความเปรียบต่างระหว่างแต่ละระดับได้ยาก จึงต้องตรวจสอบตามคำแนะนำของ WCAG ด้วยตนเองทุกครั้ง
  • HSL/HSV เป็นโมเดลที่แปลงมาจาก RGB แบบตรงไปตรงมา จึงไม่สะท้อน การรับรู้ความสว่างและความอิ่มสีของมนุษย์ ได้ดี ใช้เลือกสีเดี่ยว ๆ ได้ แต่ไม่เหมาะกับการสร้างระบบสี
  • CIELAB และ LCh เป็น ปริภูมิสีที่สม่ำเสมอตามการรับรู้ ซึ่งออกแบบมาให้การเปลี่ยนค่าตัวเลขใกล้เคียงกับการเปลี่ยนแปลงที่มนุษย์รู้สึก จึงสร้างสเกลสีที่มีระดับความสว่างเท่ากันได้สม่ำเสมอกว่า
  • Accessible Palette เป็นแอปที่สร้าง พาเลตที่สม่ำเสมอ โดยอิง LCh และปรับความสว่าง อัตราความเปรียบต่าง การชดเชย Hue และการสะท้อนสีแบรนด์เดิม
  • ควรตรวจดูทั้งอัตราความเปรียบต่างตาม WCAG 2.1 และ APCA ใน Working Draft ของ WCAG 3 เพื่อให้รองรับทั้งแนวทางปัจจุบันและ การเปลี่ยนแปลงของอัลกอริทึมความเปรียบต่าง ในอนาคตได้ง่ายขึ้น

ปัญหาในระบบสีของ Postmark

  • พาเลตเดิมของ Postmark มีปัญหาสองอย่าง
    • ความสว่างตามการรับรู้ ไม่สม่ำเสมอ เช่น สีน้ำเงินและสีแดงดูมืดกว่าสีเหลืองและสีเขียวมาก
    • คาดเดา อัตราความเปรียบต่าง ระหว่างสีแต่ละเฉดได้ยาก จึงไม่รู้ได้ง่ายว่าสีคู่หนึ่ง ๆ ตรงตามคำแนะนำของ WCAG หรือไม่
  • ทุกครั้งที่เลือกคู่สี ต้องตรวจสอบอัตราความเปรียบต่างด้วยตนเอง และในทางปฏิบัติก็มีโอกาสสูงที่จะไม่ได้ตรวจ
  • สาเหตุมาจากข้อจำกัดของโมเดลสี HSL เอง และจากการที่เครื่องมือออกแบบยังรองรับทางเลือกที่ดีกว่าได้ไม่เพียงพอ

ทำไม HSL จึงไม่เหมาะกับระบบสี

  • RGB เป็นโมเดลที่สะท้อนวิธีการทำงานของหน้าจอ แต่ไม่ใช่โมเดลเชิงสัญชาตญาณที่ทำให้มนุษย์เลือกสีได้ง่าย
  • HSL และ HSV/HSB เป็นทางเลือกที่สร้างขึ้นในทศวรรษ 1970 เพื่อแสดง RGB ในรูปแบบที่ใกล้กับวิธีที่มนุษย์คิดเรื่องสีมากขึ้น
    • HSL ย่อมาจาก Hue, Saturation, Lightness
    • HSV/HSB ย่อมาจาก Hue, Saturation, Value หรือ Brightness
  • ในเวลานั้น โมเดลที่ซับซ้อนกว่ามีต้นทุนการคำนวณสูง จึงทำให้ HSL และ HSV ยอมลด ความแม่นยำด้านการรับรู้ เพื่อแลกกับ ความเร็วในการคำนวณ
  • ผลลัพธ์คือ HSL และ HSV เป็นเพียงการแปลงทางคณิตศาสตร์ที่ทำได้ง่ายจาก RGB และไม่สะท้อนความสว่างหรือความอิ่มสีที่มนุษย์รับรู้ได้อย่างถูกต้อง
  • ตัวอย่างเช่น ใน HSL หากตั้ง Saturation 100 และ Lightness 50 ให้เป็นสเกลสีเดียวกัน ตามโมเดลแล้วจะมีความสว่างเท่ากัน แต่ในความเป็นจริง สีน้ำเงิน #00F ดูมืดกว่าสีเหลือง #FF0 หรือสีฟ้าอมเขียว #0FF มาก
  • ใน HSL สีที่อิ่มเต็มที่จะถูกแมปไปยังค่าสูงสุดของ RGB และวางอยู่บนวง Hue ที่ Lightness 50 ส่วน Lightness 0 และ 100 จะตรงกับสีดำและสีขาวตามลำดับ
    • เฉดที่สว่างขึ้นหรือมืดลงจะถูกสร้างขึ้นด้วยวิธีการ “ผสม” กับสีขาวหรือสีดำ
    • แกนแนวตั้งตรงกลางคือช่วงของสีกลางหรือสีเทาที่มี Saturation 0

CIELAB และ LCh

  • ในช่วงที่มีการนิยาม HSL และ HSV นั้น มีทางเลือกที่ดีกว่าอย่าง CIELAB อยู่แล้ว
  • International Commission on Illumination หรือ CIE ได้กำหนดปริภูมิสี CIELAB หรือ L*a* b* ในปี 1976
  • CIELAB เป็น ปริภูมิสีที่สม่ำเสมอตามการรับรู้ ซึ่งออกแบบมาให้การเปลี่ยนค่าตัวเลขสอดคล้องกับการเปลี่ยนแปลงของสีที่มนุษย์รู้สึกใกล้เคียงกัน
    • ต่างจาก RGB ตรงที่ออกแบบมาให้ครอบคลุมขอบเขตของสีที่มองเห็นได้ทั้งหมด
    • องค์ประกอบ L* ซึ่งหมายถึง Lightness ถูกปรับให้ใกล้กับการรับรู้ความสว่างของมนุษย์
  • CIELAB ประกอบด้วยสามแกน
    • ค่า L* กำหนดให้ 0 คือสีดำ และ 100 คือสีขาว
    • แกน a* คือแกนสีตรงข้ามเขียว-แดง โดยค่าลบไปทางเขียว และค่าบวกไปทางแดง
    • แกน b* คือแกนสีตรงข้ามน้ำเงิน-เหลือง โดยค่าลบไปทางน้ำเงิน และค่าบวกไปทางเหลือง
  • CIELCh, LCh หรือ Lch(ab) เป็นการแสดง CIELAB ในรูปทรงกระบอก
    • ใช้ Chroma และมุม Hue แทน a* และ b*
    • ค่า Lightness ยังคงเดิม
  • มุม Hue ของ LCh คล้ายกับ Hue ของ HSL แต่ไม่เหมือนกัน
    • HSL/HSV วางแม่สีเชิงบวกสามสีคือแดง เขียว น้ำเงินไว้ที่ H=0, 120, 240°
    • LCh วางแดง เหลือง เขียว น้ำเงินไว้ที่ h=0, 90, 180, 270°
  • ยังมีปริภูมิสีคล้ายกันคือ HCL หรือ LCh(uv) ซึ่งต่างจาก LCh(ab) ตรงที่ Chroma มีสเกลสม่ำเสมอตั้งแต่ 0 ถึง 100

วิธีสร้างสเกลสีใน LCh

  • LCh แม้จะพอดีกับทรงกระบอกแบบเดียวกับ HSL/HSV แต่ไม่ได้เติมเต็มทรงกระบอกนั้นทั้งหมด
  • การผสมบางค่าของ Lightness, Chroma และ Hue จะทำให้เกิดสีที่ไม่มีอยู่จริง
    • เช่น สีเหลืองที่มืดและอิ่มสีสูง เป็นสีที่ไม่มีอยู่จริง
  • เมื่อเข้าใกล้สีดำและสีขาวในสเกล Lightness จำนวนสีที่มนุษย์แยกแยะได้จะลดลง
  • หน้าจอจริงก็ไม่สามารถแสดงสีที่มองเห็นได้ทั้งหมด
    • ช่วงสี sRGB ใช้แทนหน้าจอทั่วไป และครอบคลุมเพียงประมาณ ⅓ ของปริภูมิสี LCh
    • ใน CSS อย่างน้อยในตอนนี้ก็ยังถูกจำกัดอยู่ในช่วงนี้
  • หากมองสเกลสีใน HSL ที่ตั้ง Saturation 100 และ Lightness 50 ด้วยมุมมองของ LCh จะพบว่าสีเหลืองสว่างที่สุด และสีน้ำเงินมืดที่สุด
    • สีเขียวสว่างกว่าสีน้ำเงินเกือบสามเท่า และสว่างกว่าสีแดงประมาณสองเท่า
  • หากสร้างสเกลใหม่ใน LCh โดยใช้ระดับ Lightness เดียวกัน ความสว่างของแต่ละสีจะสม่ำเสมอในเชิงการมองเห็นมากกว่า
    • เนื่องจาก Chroma ต่างกัน บางสีอาจอิ่มสีกว่าสีอื่น
    • สีสำหรับการแจ้งเตือนและคำเตือนอาจต้องการความอิ่มสีสูงกว่าสีข้อความหลัก ดังนั้นความต่างแบบนี้จึงมีประโยชน์ในระบบสี
  • หากปรับให้ Chroma สม่ำเสมอขึ้นด้วย ก็สามารถสร้างสเกลที่นุ่มนวลขึ้นได้แม้อยู่ภายในขอบเขต sRGB ที่จำกัด

ข้อจำกัดของเครื่องมือออกแบบและ Accessible Palette

  • ปัจจุบัน Figma, Sketch และ Adobe XD ยังไม่รองรับ CIELAB หรือ LCh
  • ใน Figma มีปลั๊กอิน LCH color picker และ Chromatic แต่ก็ยังไม่เพียงพอสำหรับการสร้างระบบสีที่ยืดหยุ่น
  • เครื่องมือที่ต้องการจำเป็นต้องตอบโจทย์สามข้อ
    • รักษา ความสว่างที่สม่ำเสมอ เมื่อสร้างเฉดสีต่าง ๆ
    • ควบคุมอัตราความเปรียบต่างระหว่างแต่ละระดับได้
    • ยืดหยุ่นพอที่จะรองรับสีแบรนด์เดิม
  • หลังจากพบไลบรารี Chroma.js ที่รองรับ LCh ได้ดี ก็ได้สร้างเครื่องมือง่าย ๆ สำหรับสร้างพาเลตใหม่ด้วยโค้ด
  • หลังจากใช้ภายในและแบ่งปันให้คนรู้จักบางส่วน เครื่องมือนี้ก็ถูกเปิดตัวเป็นแอป Accessible Palette
  • Accessible Palette เป็นแอปสำหรับสร้างระบบสีที่มีความสว่างสม่ำเสมอและมีอัตราความเปรียบต่างที่คาดเดาได้ในทุกระดับสี

วิธีทำงานของ Accessible Palette

  • เมื่อปรับสีตั้งต้นหรือวางสีจากดีไซน์เดิมลงไป เครื่องมือจะใช้ค่า Chroma และ Hue ของสีนั้นคำนวณสเกลหลายระดับของ Lightness
  • Lightness สามารถกำหนดเองได้ทั้งหมด และใช้ได้ทั้งกับพาเลตสว่างและพาเลตมืด
    • ปรับอย่างละเอียดเพื่อให้รวมสีแบรนด์เดิมเข้าไปได้
    • ในกรณีของ Postmark ต้องการคงสีที่ใช้มากที่สุดจากพาเลตเดิม ได้แก่ สีเหลือง #FFDE00, สีน้ำเงิน #007DCC, สีเขียว #4FC47F
    • จึงนำค่า Lightness ของสีเหล่านี้คือ 88.6, 75.2, 50.6 มาใช้เป็นความสว่างของระดับ 200, 400, 600 ตามลำดับ
  • อัตราความเปรียบต่าง จะเปลี่ยนตาม Lightness และคำนวณสำหรับแต่ละระดับโดยใช้ทั้งวิธีที่แนะนำใน WCAG 2.1 และอัลกอริทึมใหม่ใน Working Draft ของ WCAG 3.0
    • โดยค่าเริ่มต้น ความเปรียบต่างของทุกสีจะวัดเทียบกับพื้นหลังสีขาว
    • สามารถเลือกสวอตช์สีที่ต้องการเพื่อวัดอัตราความเปรียบต่างโดยใช้สีนั้นเป็นฐานได้
  • ระดับสีสามารถสร้างได้โดยใช้ปริภูมิสี RGB หรือ CIELAB
    • ในบางกรณีผลลัพธ์อาจต่างกัน จึงคุ้มค่าที่จะทดลอง
    • ในระบบสีของ Postmark การใช้ CIELAB ช่วยลดโทนม่วงในสีแดงอ่อน แต่กลับเพิ่มโทนม่วงในสีน้ำเงิน
  • บางสีอาจต้องมีการ ชดเชย Hue ตลอดทั้งช่วง
    • สีเหลืองอ่อนจะมีโทนเขียวมากขึ้นเมื่อทำให้มืดลง
    • เพื่อดันให้เข้าใกล้สีส้มมากขึ้นเล็กน้อย จึงใช้การชดเชย Hue แบบค่าลบ
  • แอปจะอัปเดต URL ระหว่างใช้งานเพื่อบันทึกการเปลี่ยนแปลง
    • สามารถแชร์กับทีม หรือเพิ่มเข้าไปในไลบรารี Figma และไฟล์ตัวแปรสี CSS เพื่อใช้อ้างอิงต่อได้
  • ตัวอย่างพาเลตมีทั้ง Postmark color palette, Google’s Material Design, และพาเลตที่อิงจาก TailwindCSS
    • ตัวอย่างเหล่านี้ไม่ใช่การคัดลอกต้นฉบับแบบตรงตัว แต่เป็นทางเลือกที่ได้แรงบันดาลใจจากสีดั้งเดิมและระดับความสว่างของต้นฉบับ

การคำนวณอัตราความเปรียบต่างและ WCAG

  • เหตุผลที่ Accessible Palette แสดงอัตราความเปรียบต่างสองแบบ เป็นเพราะวิธีของ WCAG 2.1 มีข้อจำกัด
  • WCAG 2.1 คำนวณ อัตราความเปรียบต่าง โดยนำค่าความส่องสว่างของสีตัวอักษรหารด้วยค่าความส่องสว่างของสีพื้นหลัง
  • สูตรนี้ให้การตอบสนองแบบเชิงเส้น แต่มนุษย์รับรู้ความเปรียบต่างระหว่างสีสว่างว่าเด่นกว่าความเปรียบต่างระหว่างสีมืด
  • ในตัวอย่างจริง สีตัวอย่างที่ผ่านคำแนะนำของ WCAG 2.1 อาจอ่านยากกว่าสีตัวอย่างที่ถูกระบุว่าเป็นความเปรียบต่าง “ไม่เพียงพอ” ก็ได้
  • W3C รับรู้ปัญหานี้อยู่แล้ว และ Andrew Somers ได้เริ่ม การอภิปรายสาธารณะ ในปี 2019
  • อัลกอริทึมใหม่ที่ Andrew Somers เสนอได้กลายเป็นส่วนหนึ่งของ WCAG 3 Working Draft และยังได้สร้าง APCA Contrast Calculator ขึ้นมาด้วย
  • APCA ย่อมาจาก Advanced Perceptual Contrast Algorithm และมีความแม่นยำด้านการรับรู้มากกว่า รวมถึงคำนึงถึงขนาดและความหนาของฟอนต์ด้วย
  • Accessible Palette ใช้ APCA และใช้คะแนน 60 เป็นระดับคำแนะนำขั้นต่ำสำหรับข้อความที่อ่านได้
    • ซึ่งเป็นเกณฑ์ที่ใกล้เคียงกับคำแนะนำอัตราความเปรียบต่าง 4.5:1 แบบเดิมของ WCAG 2.1
  • อัตราความเปรียบต่างของ WCAG 2.1 ไม่ได้ไร้ประโยชน์ไปเสียทีเดียว
    • ในช่วงสีกลาง ๆ ก็ยังค่อนข้างแม่นยำอยู่
    • แต่โดยรวมแล้วอัลกอริทึมใหม่ถือว่าปรับปรุงขึ้นมาก
  • แนวทางของ WCAG 3 ยังเป็นเพียง Working Draft จึงอาจเปลี่ยนแปลงได้เมื่อเวลาผ่านไป
  • หากต้องการคำนึงถึงทั้งการปฏิบัติตามแนวทางปัจจุบันและการรับมือกับการเปลี่ยนแปลงในอนาคต ก็ควรสร้างระบบสีโดยพิจารณาทั้งสองแนวทางควบคู่กันไป

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-08-30
ความคิดเห็นจาก Hacker News

  • ในระบบจอแสดงผลและการพิมพ์ทั่วไป ควรมองว่าสีแดงและสีน้ำเงินที่อิ่มตัวนั้นมืดกว่าสีเขียวจริง ๆ
    สูตรที่แน่นอนจะแตกต่างกันไปตาม color space แต่ Grayscale = 0.299R + 0.587G + 0.114B มักถูกอ้างถึงบ่อย และในกรณีนี้ สีแดงล้วนที่สว่างที่สุดมีความสว่างประมาณ 30% ส่วนสีน้ำเงินล้วนมีความสว่าง 11% ดังนั้นในกรณีส่วนใหญ่ สีแดงสว่าง จึงแทบจะเป็นความขัดแย้งในตัวเอง
    สีแบบนี้ใช้งานได้ แต่ย่อมดูมืดเสมอ และถ้าแค่ใช้กฎคอนทราสต์อย่างเดียว ก็อาจทำให้ผ่านเกณฑ์การเข้าถึงได้ แต่ถ้าต้องการผลลัพธ์ที่ดูดีด้วย เทคนิคที่บทความพูดถึงจะได้เปรียบกว่ามาก
    แม้ตอนทำภาพสามมิติแบบแดง-ฟ้า เช่น https://en.wikipedia.org/wiki/Anaglyph_3D ต้นไม้และหญ้าเป็นสีเขียว แต่จริง ๆ แล้วมีองค์ประกอบสีแดงอยู่มาก ทำให้สมดุลของช่องสัญญาณดี จึงได้ทั้งมิติและสีที่ออกมาดี
    อ้างอิง: https://www.dynamsoft.com/blog/insights/image-processing/ima...

    • นึกถึงยุค ช่วงปลอดภัยสำหรับการออกอากาศ NTSC และลูกค้าที่ชอบสีแดงมากเกินไป
      การอธิบายว่างานศิลป์สีแดงสวย ๆ จะดูไม่สวยเลยบนทีวีนั้นเป็นเรื่องยากเสมอ โดยเฉพาะถ้าเป็นงานสำหรับออกอากาศ
      แม้จะไม่ใช่งานออกอากาศ สีแดงที่อยู่นอกสเปกก็อาจค้างให้เห็นต่อไปอีกหลายเฟรม และดูเหมือนเลือดที่ไหลซึมจากคอที่ถูกตัดได้
    • มีหลายอย่างในนี้ที่ไม่ถูกต้อง
      ถ้าได้อ่านคำตอบต่าง ๆ แล้ว ลองตอบกลับมาได้ ผมจะอธิบายบางประเด็นให้ชัดขึ้น

  • ผมหงุดหงิดมานานแล้วที่ตัวอย่างซึ่งผ่าน เกณฑ์แนะนำของ WCAG 2.1 จริง ๆ แล้วอ่านยากกว่าตัวอย่างที่มีอัตราคอนทราสต์ “ไม่เพียงพอ”
    สงสัยเหมือนกันว่าทำไมสูตร “แนวทางการเข้าถึง” ที่ให้ผลตรงกันข้ามแบบนี้ถึงถูกทำให้เป็นมาตรฐาน

    • น่าเสียดายอยู่บ้างที่ อัลกอริทึมและแนวทาง ที่ใช้กันแพร่หลายที่สุดในเรื่องการเข้าถึงด้านคอนทราสต์ไม่มีหลักฐานที่ผ่านการทบทวนโดยผู้ทรงคุณวุฒิรองรับ
      ทั้ง 2.1 และมาตรฐานถัดไปก็เช่นกัน สำหรับพื้นที่ที่มีผลกระทบสูงขนาดนี้ อยากให้อุตสาหกรรมสนับสนุนงานวิจัยที่เข้มงวดกว่านี้
    • จำได้ว่าเคยมีความเคลื่อนไหวใน W3C/WCAG เพื่อเปลี่ยน สูตรตัดสินคอนทราสต์
      บางทีอาจเป็นแค่มีข้อเรียกร้องแบบนั้น แต่ยังไม่ได้รับการยอมรับอย่างเป็นทางการก็ได้

  • บทความที่ดีที่สุดที่ผมเคยเห็นในหัวข้อนี้คือ https://www.handprint.com/HP/WCL/color1.html
    เป็นบทความยาวมาก ควรเตรียมใจว่าจะต้องใช้เวลาอ่านทั้งวัน
    อาจจะแปลกใจได้ แต่แม้ตอนแต่งสี log ใน ClickHouse ให้สวย ก็ยังใช้ไอเดียบางอย่างจากบทความนี้: https://github.com/ClickHouse/ClickHouse/blob/master/base/ba...

    • วิธีเฉพาะในการแปลงสี ANSI เหล่านี้เป็น RGB นั้นหายาก และจริง ๆ แล้วดูเหมือนเป็นเพียงการร้องขอสี ซึ่งขึ้นอยู่กับ การตั้งค่าเทอร์มินัล
      อยากทราบว่าคุณแชร์ค่า RGB ที่คาดหวังสำหรับข้อความแต่ละประเภทที่ตั้งไว้ในโค้ดได้ไหม

  • ผมได้เจอ Eugene ที่งาน Config ของ Figma เขาให้ทิปเชิงปฏิบัติคล้าย ๆ กันกับเหล่านักออกแบบเยอะมาก และเป็นคนที่ใจดีจริง ๆ อีกทั้งจริงจังกับการออกแบบและการเข้าถึงมาก
    สิ่งที่อยากชมเป็นพิเศษในบทความนี้คือ APCA ซึ่งมีแนวโน้มจะสืบต่ออัลกอริทึมคอนทราสต์สีของ WCAG 2
    ในการปรับปรุงการเข้าถึงภายใน Figma ก็ใช้ APCA ด้วย และเพราะอย่างนั้นผลลัพธ์สุดท้ายจึงดีขึ้นมาก
    Eugene แสดงตัวอย่างกรณีที่ WCAG 2 ล้มเหลวได้ดี และในความเป็นจริง พวกเราก็เจอสถานการณ์แบบนั้นอยู่เรื่อย ๆ
    คำแนะนำสำคัญคือการปรับสีให้ถูกต้องนั้นยากจริง ๆ
    เครื่องมือช่วยได้ แต่เมื่อถึงจุดหนึ่งก็ต้อง เชื่อสายตาของตัวเอง
    ท้ายที่สุด เครื่องมือเหล่านี้เป็นเพียงการประมาณด้วยคณิตศาสตร์ว่าสายตามองเห็นสีอย่างไร และเกณฑ์ตัดสินสุดท้ายไม่ใช่อัลกอริทึม แต่คือสายตามนุษย์
    ในจุดที่เครื่องมือหรืออัลกอริทึมให้ผลลัพธ์ที่ไม่ถูกต้อง ควรปรับแก้หรือกลับไปยึดหลักพื้นฐานจะดีกว่า

    • อยากให้ช่วยอธิบายเพิ่มเติมได้ไหมว่าที่บอกว่าใช้ APCA ในการปรับปรุงการเข้าถึงภายใน Figma นั้นหมายถึงอะไร
      อยากรู้ว่าหมายถึงใช้ APCA อย่างเดียว แล้วเพิกเฉยต่อสิ่งที่อัลกอริทึมคอนทราสต์สีของ WCAG 2 ระบุว่าคอนทราสต์ไม่พอหรือไม่
    • ผมเป็นตาบอดสีแดง-เขียว แต่การเข้าถึงพื้นฐานของ Figma ดีพอจนไม่เคยคิดว่าจะต้อง ปรับแต่งการเข้าถึง แยกต่างหาก
      ทำได้ดีมาก

  • อยากแนะนำ HCT ด้วย
    เป็นปริภูมิสีที่สร้างขึ้นเพื่อทำให้ Material You เป็นไปได้ โดยผสานค่าการวัดความสว่างที่กล่าวถึงในที่นี้เข้ากับปริภูมิสีตามวิทยาศาสตร์สีสมัยใหม่
    LAB/LCH เป็นสิ่งที่ออกมาตั้งแต่ปี 1976
    ช่วยให้การออกแบบเป็นไปอย่างเป็นธรรมชาติมากขึ้น โดยแค่รู้ว่า ถ้าค่า T ต่างกัน 40 จะผ่านเกณฑ์ WCAG สำหรับปุ่ม และถ้าต่างกัน 50 จะผ่านเกณฑ์สำหรับข้อความ

    • น่าสนใจ
      อยากรู้ว่า HCT เทียบกับ https://www.hsluv.org/comparison/ แล้วเป็นอย่างไร
      คล้ายกับ HCT ตรงที่ที่นี่ทำให้เลือกสีคอนทราสต์ได้ง่ายขึ้นด้วยความต่างของ L
      ในบริบทเดียวกัน ก็อยากรู้ความเห็นเกี่ยวกับ https://www.myndex.com/APCA/ และแนวทางเมื่อสิ่งนี้กลายเป็นมาตรฐานด้วย
      เพราะค่าคอนทราสต์ระหว่างสองสีจะแตกต่างกันตามว่าสีใดเป็นพื้นหน้าและสีใดเป็นพื้นหลัง ดังนั้นตอนนี้การเทียบแค่ความต่างของ T อย่างเดียวน่าจะไม่เพียงพอแล้ว
    • อยากรู้ว่ามีแหล่งเรียนรู้ HCT ที่ดีไหม
      เช่น สมมติว่าแอปพลิเคชันต้องการ 6 สี ได้แก่ แดง เหลือง น้ำเงิน ส้ม เขียว ม่วง หรือก็คือแม่สี 3 สีและสีคู่เติมเต็ม 3 สี
      สีที่แน่นอนจะเป็นอะไรก็ไม่สำคัญนัก แต่ถ้าอยากให้ทั้ง 6 สีนั้นแยกแยะได้พอสมควร และมีความสว่าง หรืออาจรวมถึงความอิ่มสีที่ใกล้เคียงกันด้วย ควรทำอย่างไร
      สีเหลืองสว่างมากและสีน้ำเงินมืดมาก จึงน่าจะไม่มีคำตอบที่ถูกต้องเป๊ะ ๆ และต้องไปให้ถึงค่าประมาณ
      อยากรู้ว่ามีเครื่องมือหรือบทช่วยสอนสำหรับเรียนรู้เรื่องแบบนี้ไหม
    • อยากรู้ว่ามีสเปกสาธารณะอยู่ที่ไหนหรือไม่
      ที่เจอมีแค่โค้ด material-color-utilities บน GitHub
      เมื่อดูโค้ดแล้ว การคำนวณดูซับซ้อนกว่า OkLab มาก โดยเฉพาะ ทิศทางจาก HCT ไป RGB ที่ดูเป็นแบบนั้นยิ่งกว่า

  • ไม่ใช่แค่บทความนี้ละ oklab/oklch ไปเท่านั้น แต่ข้ออ้างที่ว่าเว็บ/CSS รองรับแค่ sRGB ก็ผิดด้วย
    ฟังก์ชัน CSS color() รองรับหลายปริภูมิสี

    • ผู้เขียนเอง
      บทความนี้เผยแพร่เมื่อ 2 ปีก่อน และตอนที่เริ่มทำเครื่องมือ สเปก OkLCH ก็ยังไม่ออกมาด้วยซ้ำ
      ถ้าเป็นตอนนี้คงเลือก OkLCH แทน LCH เพราะมันแก้ปัญหาบางอย่างของ LCH ได้
    • CSS Color Module Level 4 ยังอยู่ในขั้นร่างข้อเสนอแนะ
      คำว่า “รองรับ” ในที่นี้ หากพูดให้แม่นยำกว่าคือ “รองรับ ยกเว้น Microsoft Edge(chromium) และ Pale Moon(goanna)”
      https://test.csswg.org/harness/results/css-color-4_dev/group...
    • เคยลองใช้ oklab และปริภูมิสีตระกูล LAB หลายแบบโดยตรงแล้ว Oklab ยอดเยี่ยมสำหรับการตัดใช้ด้วยการคำนวณที่เรียบง่าย
    • มีโมเดลสีที่สร้างบน Oklch ด้วย
      เพียงแต่ใช้สัดส่วนคอนทราสต์ของ APCA หรือก็คือ WCAG 3 แทนความสว่าง: https://github.com/antiflasher/apcach

  • oklab อาจเป็นทางเลือกที่ดีกว่า LCh
    https://bottosson.github.io/posts/oklab/

    • มีส่วนที่หลุดไปจากสมมติฐานตั้งต้นค่อนข้างมาก
      ช่องความสว่างกลับด้านเมื่อเทียบกับปริภูมิสีอื่นทั้งหมด และ L ไม่เกี่ยวข้องอะไรกับ L ของ LCH หรือ LAB
      ความสำเร็จกลับนำมาซึ่งความแร้นแค้นทางปัญญามากขึ้นด้วย
      บล็อกโพสต์แรกมีเนื้อหาที่ควรแก้ไขอยู่มาก และตรรกะเริ่มผิดเพี้ยนอย่างมากตั้งแต่จุดที่เริ่มอ้างความถูกต้องด้วยเกรเดียนต์ที่ใช้ CAM16 UCS
    • เพลย์กราวด์นี้แสดงภาพ ปริภูมิสี 16 แบบ รวมถึง LCh และ OKLAB ได้ดีอย่างน่าทึ่ง: https://color-playground.ardov.me/spaces-3d
    • แม้จะไม่สมบูรณ์แบบ แต่ในบางสถานการณ์ก็ใช้ oklab และ oklch สำหรับการอินเตอร์โพเลตสีมาแล้ว และผลลัพธ์ดูน่าพอใจกว่าการอินเตอร์โพเลตใน RGB หรือ HSL มาก
    • ใช้ OkLab บนเว็บไซต์ของตัวเองอย่างพอใจ และสบายตากว่าพาเลตสีที่เคยใช้ CIELAB มาก

  • ถ้าค่าตัวเลข CIELAB อิงจาก การเปลี่ยนแปลงในการรับรู้ ก็อยากรู้ว่ามันโต้ตอบกับการเข้าถึงได้อย่างไร
    เราควรกังวลไหมว่าสูตรการรับรู้แบบนี้อาจสร้างขึ้นโดยอิงสายตามาตรฐาน
    อยากรู้ด้วยว่าอาจแตกต่างไปตามประเภทของภาวะบกพร่องในการมองเห็นสีหรือไม่ หรือจริง ๆ แล้วไม่ใช่ปัญหาแบบนั้น
    พยายามทำให้แผนภูมิเข้าถึงได้มากที่สุดเท่าที่ทำได้ แต่ไม่เคยเรียนเรื่องสีเลย จึงได้แต่ทำตามคำแนะนำ และไม่สามารถอนุมานเองได้
    ดังนั้นก็เป็นไปได้มากว่าอาจเป็นคำถามโง่ ๆ

    • เคยทำงานด้านนี้มา
      คอนทราสต์เปลี่ยนแปลงแบบ ไม่เชิงเส้น
      การจำลองนำไปใช้ได้ค่อนข้างง่าย และการจำลองของ Machado และคณะก็เป็นเพียงการแปลงเมทริกซ์เท่านั้น

  • บทความนี้วางคำอธิบายไว้ด้านล่าง แต่ APCA Contrast ซึ่งเป็นการทดสอบคอนทราสต์ให้อ่านง่ายในร่างมาตรฐาน WCAG 3 มีความเป็นธรรมกับสีบางสีมากกว่าสัดส่วนคอนทราสต์ของ WCAG 2.1 มาก
    บทความอ่านง่ายเกี่ยวกับทฤษฎีสีเบื้องหลังคอนทราสต์เชิงการรับรู้: https://www.smashingmagazine.com/2022/09/realities-myths-con...
    บทความที่อธิบาย APCA อย่างกระชับ: https://typefully.com/u/DanHollick/t/sle13GMW2Brp

    • APCA ทำงานได้ดี แต่ ไลเซนส์ แปลกและมีข้อจำกัดมาก
      ก่อนนำไปใช้กับอะไร ควรพิจารณาส่วนนั้นอย่างละเอียดและตัดสินใจว่าจริง ๆ แล้วใช้งานได้หรือไม่

  • โค้ดอยู่ที่ไหน
    สิ่งที่ต้องการไม่ใช่เว็บฟอร์ม แต่เป็น อัลกอริทึม ที่ใช้ได้กับซอฟต์แวร์ใด ๆ

    • ไลบรารีที่ผู้เขียนพูดถึงคืออันนี้
      ผมลองใช้เองแล้ว และทำงานได้ดี
      https://github.com/gka/chroma.js
    • ในเธรดนี้ ผู้เขียนบอกว่าถ้าจะเขียนบทความนี้ใหม่ตอนนี้ เขาจะใช้ Oklab[1]
      Oklab ถูกแนะนำไว้ใน [2] และโค้ดในบทความนั้นใช้งานง่ายมาก
      [1]: https://news.ycombinator.com/item?id=37310534
      [2]: https://bottosson.github.io/posts/oklab/