יישום ניגודיות וגדלי גופנים לפי WCAG

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

פיתוח ותחזוקה של כל סוגי האתרים:

אתרי מידע או יישומי אינטרנט
אתרי תדמית, דפי נחיתה, אתרי חברה, קטלוגים מקוונים, חידונים, אתרי קידום, בלוגים, מקורות חדשות, פורטלי מידע, פורומים, אגרגטורים
אתרי מסחר אלקטרוני או יישומי אינטרנט
חנויות מקוונות, פורטלי B2B, שווקים, בורסות מקוונות, אתרי קאשבק, בורסות, פלטפורמות דרופשיפינג, מנתחי מוצרים
יישומי אינטרנט לניהול תהליכים עסקיים
מערכות CRM, מערכות ERP, פורטלים ארגוניים, מערכות ניהול ייצור, מנתחי מידע
אתרי שירות אלקטרוני או יישומי אינטרנט
פלטפורמות מודעות, בתי ספר מקוונים, בתי קולנוע מקוונים, בוני אתרים, פורטלים לשירותים אלקטרוניים, פלטפורמות אירוח וידאו, פורטלים נושאיים

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

השירותים שאנו מציעים
מציג 1 מתוך 1כל 2062 השירותים
יישום ניגודיות וגדלי גופנים לפי WCAG
פשוט
מ- 1 יום עד 3 ימים
שאלות נפוצות

ניגודיות WCAG: היכן הממשק מפסיק להיות קריא

ניגודיות נמוכה בממשק כמעט אף פעם לא נראית בפריסה — היא מתגלה על מסכים אמיתיים ובתאורה אמיתית.

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

פורמלית, ניגודיות WCAG נמדדת כיחס בין בהירות הטקסט לרקע: לטקסט רגיל נדרש 4.5:1, לטקסט גדול — 3:1, לגבולות שדות וסמלים ברכיבי בקרה — גם 3:1.

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

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

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

קריאות, שינוי קנה מידה של טקסט וכיסוי קהל

ניגודיות טקסט ראשי מתחת לסף 4.5:1 — זו לא שאלה של טעם. ביחס כזה, כתוביות שדות, רמזים והודעות שגיאה מתמזגים עם הרקע עבור אנשים עם ראייה ירודה ועבור אלה שקוראים מהטלפון בחדר מואר.

הבאת צמדי "טקסט — רקע" ל-4.5:1, וטקסט גדול ורכיבי בקרה ל-3:1 מסירה סוג שלם של כשלים, שבהם אדם פיזית לא יכול להשלים את התרחיש.

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

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

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

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

דרכים להביא ניגודיות וטיפוגרפיה לנורמה

ביקורת מתחילה במיפוי צמדי "טקסט — רקע" וגדלי גופן לפי מסכים. הסף לטקסט ראשי — 4.5:1, לגודל גופן גדול ולרכיבים גרפיים — 3:1, ובנוסף דרישה לשמור על קריאות בעת שינוי קנה מידה של הממשק עד 200%. לפי WCAG הפרות כמעט תמיד מקובצות לכמה תבניות — מכך תלוי איזו שיטת תיקון תעבוד.

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

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

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

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

איך עובר היישום: מביקורת ועד מסירה

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

  1. מיפוי הממשק. אוספים רשימת תבניות, רכיבים והמצבים שלהם — ריחוף, מיקוד, רכיב מושבת, שגיאה. לכל אחד מתעדים סגנונות טקסט ורקעים: בלי הרשימה הזו המדידות מאבדות שלמות.
  2. ביקורת ומדידה. מחשבים מקדם ניגודיות בפועל לכל צמדי "טקסט — רקע" בנפרד לטקסט קטן וגדול, לרכיבי בקרה ולגרפיקה. מסמנים כל מה שמתחת ל-4.5:1 ול-3:1 הנדרשים.
  3. ניתוח מקומות שנויים במחלוקת. טקסט מעל תמונות, גרדיאנטים, שכבות חצי-אטומות ומצבי מיקוד — אוטומציה מחשבת אותם לא נכון, ולכן בודקים אותם ידנית, על תוכן אמיתי.
  4. תוכנית תיקונים. לכל קבוצה מחליטים: לשנות גוון בפלטה, להוסיף רקע או מסגרת, להגביל את הרקע מתחת לטקסט. תיקונים מכניסים לטוקנים של מערכת העיצוב, ולא לרכיבים בודדים — שינוי אחד מתפשט לכל המסכים.
  5. התאמה ובדיקה. מתקנים פלטה, טיפוגרפיה וטוקנים, קובעים גדלי גופן מינימליים וריווח שורות, מסירים גבהים קבועים של בלוקים. אחר כך חוזרים על המדידות ומריצים רגרסיה בכל התבניות, ערכת נושא כהה ומצב ניגודיות גבוהה של המערכת.
  6. מסירת תיעוד. מוסרים כללי ניגודיות וטיפוגרפיה, רשימת בדיקה לרכיבים חדשים ותיאור בדיקות בבדיקות אוטומטיות, כדי שבמהדורה הבאה הנגישות לא תתבטל.

מה הלקוח מקבל לידיים: כללים, סגנונות, נוהל

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

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

ניתוח פרויקט: איך הסרנו כשלים בנגישות

הלקוח — שירות להגשת בקשות עם אזור אישי: כ-240 מסכים, חלקם על תבניות ישנות. ריצת בדיקת ניגודיות לפי הנחיות לנגישות תכנים באינטרנט (WCAG) הראתה ש-68 מסכים לא עוברים בדיקה, ו-31 מוגדרים בגודל גופן מתחת לבסיסי. הסורק הציג 210 הערות קריטיות — וזה רק בתרחישי המפתח שנכנסו למדגם.

מה שינו במימוש

ניגודיות הועברה לטוקנים של ערכת נושא: במקום קודי צבע בתוך רכיבים — צמדי "טקסט/רקע" שנבדקו ליחס 4.5:1 לטקסט ראשי ו-3:1 לגדול, עם ערכים נפרדים לריחוף ולמצב לא פעיל.

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

מה הראו המדידות

שיעור המסכים שעוברים בדיקה אוטומטית עלה מ-72% ל-100%: אפס הערות קריטיות, נשארו אזהרות בודדות בתרגומים. שיעור הטפסים שהושלמו עלה מ-61% ל-84% — אנשים הפסיקו לנטוש מילוי בשלב שבו כתוביות השדות היו אפורות על אפור. פניות לתמיכה בניסוח "אני לא רואה טקסט" פחתו פי שלושה באותה תקופה.

במה נבדלות רמות AA ו-AAA ב-WCAG ואיזו לבחור?

רמות WCAG — זה לא "איכות יקרה יותר", אלא ספים פורמליים: A — מינימום בסיסי, AA — תקן ענפי שאליו מפנים בדרישות ובמכרזים, AAA — מורחב. ההבדל ביניהם ניתן למדידה ונוגע בראש ובראשונה לדרישות לניגודיות טקסט ורכיבי ממשק.

רמה דרישות לניגודיות למי נחוץ היקף תיקונים
A טקסט גדול ורכיבי בקרה 3:1 תאימות מינימלית בדרך כלל כבר מושגת
AA טקסט רגיל 4.5:1, גדול 3:1, ניגודיות גבולות ומצבים רוב האתרים והשירותים טוקנים של פלטה ומצבי רכיבים
AAA טקסט רגיל 7:1, גדול 4.5:1 שירותים ממשלתיים, בנקים, רפואה, חינוך עיבוד מחדש של מערכת העיצוב

רמה A נסגרת כמעט אוטומטית. AA דורשת להרכיב מחדש מצבי ממשק: מצייני מקום, כפתורים מושבתים, קישורים בתוך טקסט, גבולות שדות קלט — לרוב מגדירים אותם אפורים "בעין", ובבדיקה הם לא עוברים את הסף.

AAA מעלה את הרף ל-7:1: הדגש המותג כמעט אף פעם לא עובר כצבע טקסט, ומשאירים אותו לרקעים ולכותרות גדולות. ברמת האתר כולו לוקחים רמה כזו לעיתים רחוקות, כי היא מצמצמת את הפלטה לכמה צמדים בדוקים; באופן סלקטיבי — לטקסטים ארוכים, טפסים ומדורים שבהם הקהל קורא לאורך זמן.

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

ספקות טכניים בנוגע לנגישות ולגדלי גופן

שאלות על נגישות כמעט תמיד נתקעות באותו דבר: איך לעמוד בדרישות הניגודיות של WCAG בלי לסטות מהמותג, ולא לכתוב מחדש את מה שכבר עובד. להלן תשובות למה שהכי נפוץ לעלות בשלב בדיקת הממשק.

צבעי מותג לא עוברים בניגודיות — להחליף פלטה?

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

כבר יש לנו ערכת רכיבים מיושמת — הכול לעבד מחדש?

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

הגופן של המותג דק ובגדלים קטנים "מתפורר". מה לעשות?

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

איך אתם בודקים את התוצאה?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

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

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

הכישורים שלנו:

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1393
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1368
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1139
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1152
  • פיתוח אתר עבור SBH Partners
    פיתוח אתר עבור SBH Partners
    1231
  • פיתוח אתר עבור Red Pear
    פיתוח אתר עבור Red Pear
    641