כשנגישות צבע היא איכות מוצר

לפעמים תיקון נגישות נראה כמו שינוי קטן בצבע. מחליפים `primary-600` ל-`primary-700`, מחזקים hover, משנים label אפור אחד, והאתר נראה כמעט אותו דבר.

אבל בפועל זה לא תיקון קוסמטי. זה תיקון איכות מוצר.

בפורטפוליו שלי היה מצב שבו חלק מהפעולות והטקסטים עבדו טכנית, אבל לא היו מספיק קריאים בכל הקשרים: כפתורי פעולה בהירים מדי, labels עדינים מדי, וטקסטים במצב כהה שנראו טוב עיצובית אבל לא החזיקו מספיק contrast.

זו דוגמה טובה לפער בין "המסך נראה יפה" לבין "המסך עובד עבור המשתמש".

הבעיה

בממשק אישי כמו פורטפוליו קל להתייחס לצבע כאל עניין של אסתטיקה. בפועל, צבע הוא חלק מהפונקציונליות.

אם כפתור לא מספיק בולט, המשתמש עלול לא להבין מה הפעולה המרכזית. אם label דק מדי, הוא הופך לרעש במקום מידע. אם מצב dark נראה אלגנטי אבל קשה לקריאה, זו לא חוויה מלוטשת. זו חוויה שמכריחה את המשתמש להתאמץ.

באתר שלי זה הופיע בעיקר באזורי פעולה וקשר:

• כפתור WhatsApp הראשי ב-Hero.
• כפתור שליחת טופס.
• CTA ב-Closing Dock.
• labels קטנים בערוצי קשר.
• טקסטים משניים במצב כהה.

אלה לא מקומות שוליים. אלה נקודות שבהן משתמש אמור להבין, לבחור ולפעול.

האבחון

הבעיה לא הייתה שאין מערכת צבעים. להפך, כבר הייתה מערכת tokens מסודרת.

הבעיה הייתה שחלק מהרכיבים השתמשו בטון צבע נכון מבחינה מותגית, אבל גבולי מבחינת contrast בפועל. צבע יכול להיות "על הפלטה" ועדיין לא להיות הבחירה הנכונה עבור טקסט או פעולה.

במילים אחרות: עצם זה שהצבע מגיע מ-token לא מוכיח שהוא מתאים להקשר.

ההבחנה החשובה היא בין שלושה שימושים שונים:

• צבע דקורטיבי.
• צבע שמייצר היררכיה.
• צבע שנושא פעולה או מידע קריא.

רק השלישי חייב לעמוד ברף גבוה יותר. CTA, label, status text וקישור צריכים להיבדק כמשטחי קריאה ופעולה, לא כקישוט.

התיקון

ב-commit `6a77c7f`, `fix portfolio contrast accessibility`, התיקון היה ממוקד:

• כפתורי פעולה עברו מ-`primary-600` ל-`primary-700`.
• hover עבר לצבע כהה יותר במקום בהיר יותר.
• labels קטנים קיבלו token קריא יותר.
• טקסטים משניים במצב כהה עברו ל-`neutral-400`.
• אנימציית opacity באזור About הוסרה משלבי תוכן כדי שהתוכן לא יהיה דהוי בזמן גלילה.

הנקודה האחרונה חשובה. נגישות היא לא רק צבע סטטי. גם motion יכול לפגוע בקריאות אם הוא משאיר תוכן במצב שקוף מדי בזמן שהמשתמש כבר אמור לקרוא אותו.

התיקון לא שינה את המבנה ולא ניסה לעצב מחדש את האתר. הוא שמר על שפת המותג, אבל העביר רכיבי פעולה ומידע ל-tokens שמתאימים יותר למשימה שלהם.

למה הוספתי בדיקה

תיקון כזה קל מאוד לשבור בעתיד.

מישהו יכול להחזיר צבע בהיר יותר כי הוא "נראה טוב יותר", או לשנות CTA בלי לשים לב שהוא הוריד contrast. לכן הוספתי בדיקת רגרסיה ב-`src/color-system.test.ts`.

הבדיקה לא מנסה למדוד את כל WCAG בתוך הדפדפן. היא עושה משהו פשוט יותר: היא מוודאת שהרכיבים הקריטיים ממשיכים להשתמש ב-tokens הנכונים.

זה לא מחליף ביקורת נגישות מלאה, אבל זה סוגר דלת על רגרסיה ספציפית שכבר זוהתה.

זו גישה פרגמטית:

• מזהים כשל אמיתי.
• מתקנים אותו במקום שבו הוא נוצר.
• מוסיפים guardrail שמגן על אותה משפחה של טעויות.

הלקח

נגישות לא צריכה להיכנס לפרויקט רק כשלב ביקורת בסוף. היא צריכה להיכנס לתוך מערכת העיצוב, לתוך רכיבים חוזרים ולתוך בדיקות.

כאשר צבע הוא רק החלטה ויזואלית, הוא נשאר שברירי. כאשר צבע הוא חוזה בין עיצוב, תוכן ופעולה, אפשר לבדוק אותו.

הלקח שלי מהתיקון הזה פשוט:

אם אלמנט אמור לגרום למשתמש להבין או לפעול, הקריאות שלו היא חלק מה-feature.

לא nice-to-have. לא polishing. חלק מה-feature.