נגישות למפתחי אתרים

שיפור הנגישות הופך את האתר לשימושי יותר לכולם.

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

יותר ממיליארד אנשים חיים עם מוגבלות מסוימת.

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

הנה כמה דוגמאות למוגבלויות שעשויות להיות למשתמשים:

בעיות חזותיות נעות בין חוסר יכולת להבחין בין צבעים לבין בעיות ראיה בכלל.

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

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

המשמעות של בעיות שמיעה היא שלמשתמש יכול להיות בעיה בשמיעה של צליל בדף.

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

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

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

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

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

  prefers-reduced-motion שאילתת המדיה של CSS מאפשרת להגביל אנימציות והפעלה אוטומטית של סרטונים עבור משתמשים שמעדיפים תזוזה נמוכה:

  /*
  If the user expresses a preference for reduced motion, don't use animations on buttons.
  */
  @media (prefers-reduced-motion: reduce) {
    button {
      animation: none;
    }
  }
  

• כדאי להימנע מאינטראקציות מבוססות-תזמון.

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

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

מדידת הנגישות של רכיבי ממשק משתמש

במהלך הבדיקה של רכיבי ממשק המשתמש של הדף לצורך נגישות, כדאי לשאול את עצמך:

• האם אפשר להשתמש ברכיב של ממשק המשתמש רק עם המקלדת?

  האם הרכיב מנהל את המיקוד ונמנע ממלכודות מיקוד? האם הוא יכול להגיב לאירועי המקלדת המתאימים?

• האם יש לך אפשרות להשתמש ברכיב בממשק המשתמש עם קורא מסך?

  האם סיפקת חלופות טקסט למידע שמוצג באופן ויזואלי? האם הוספת מידע סמנטי באמצעות ARIA?

• האם רכיב ממשק המשתמש שלך יכול לפעול ללא צליל?

  מומלץ לכבות את הרמקולים ולעיין בתרחישים לדוגמה.

• האם רכיב ממשק המשתמש יכול לפעול ללא צבע?

  צריך לוודא שאנשים שלא יכולים לראות צבעים יכולים להשתמש ברכיב של ממשק המשתמש שלך. כלי שימושי להדמיה של עיוורון צבעים הוא תוסף ל-Chrome שנקרא Colorblindly. (נסו את כל ארבע הצורות של סימולציה של עיוורון צבעים). אולי התוסף Daltonize מועיל באותה מידה.

• האם רכיב ממשק המשתמש יכול לפעול כשמצב ניגודיות גבוהה מופעל?

  כל מערכות ההפעלה המודרניות תומכות במצב ניגודיות גבוהה. ניגודיות גבוהה הוא תוסף ל-Chrome שיכול לעזור כאן.

לאמצעי בקרה סטנדרטיים (כמו <button> ו-<select>) יש נגישות מובנית בדפדפן. אפשר להתמקד בהם באמצעות המקש Tab; הם מגיבים לאירועי מקלדת (כמו Enter, Space ומקשי החיצים), ויש להם תפקידים, מצבים ומאפיינים סמנטיים שמשמשים את כלי הנגישות. סגנון ברירת המחדל של הגרסאות האלה גם צריך לעמוד בדרישות הנגישות המפורטות.

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

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

ב-Firefox יש גם חלונית נגישות.

Safari חושף את פרטי הנגישות בכרטיסייה צומת שבחלונית רכיבים.

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

שיפור המיקוד של המקלדת

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

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

שימוש באינדקס

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

רכיבים אינטראקטיביים מובנים (כמו <button>) ניתנים למיקוד באופן מפורש, ולכן הם לא צריכים את המאפיין tabindex, אלא אם צריך לשנות את המיקום שלהם בסדר הכרטיסיות.

יש שלושה סוגים של ערכים מסוג tabindex:

• השדה tabindex="0" הוא הנפוץ ביותר ומציב את הרכיב בסדר הכרטיסיות הטבעי (מוגדר לפי סדר ה-DOM).
• ערך tabindex גדול מ-0 מציב את הרכיב בסדר כרטיסיות ידני. הביקורים בכל הרכיבים בדף עם ערך tabindex חיובי, מופיעים בסדר מספרי, לפני הרכיבים לפי סדר הכרטיסיות הטבעי.
• ערך tabindex השווה ל-1- גורם לאלמנט להיות ניתן למיקוד באופן פרוגרמטי, אבל לא לפי סדר הכרטיסיות.

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

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

שימוש במיקוד אוטומטי

מאפיין המיקוד האוטומטי של HTML מאפשר למחבר לציין שרכיב מסוים צריך להתמקד באופן אוטומטי כשהדף נטען. autofocus כבר נתמך בכל הפקדים של טפסים באינטרנט, כולל לחצנים. כדי למקד אלמנטים של מיקוד אוטומטי ברכיבי ממשק משתמש מותאמים אישית, צריך לקרוא ל-method focus(), הנתמכת בכל רכיבי ה-HTML שאפשר להתמקד בהם (לדוגמה, document.querySelector('myButton').focus()).

הוספת אינטראקציה עם המקלדת

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

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

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

// Example for expanding and collapsing a category with the Space key
const category = await page.$(`.category`);

// verify tabIndex, role and focus
expect(await page.evaluate(elem => elem.getAttribute(`role`), category)).toEqual(`button`);
expect(await page.evaluate(elem => elem.getAttribute(`tabindex`), category)).toEqual(`0`);
expect(await page.evaluate(elem => window.document.activeElement === elem, category)).toEqual(true);

// verify aria-expanded = false
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`false`);

// toggle category by pressing Space
await page.keyboard.press('Space');

// verify aria-expanded = true
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`true`);

הבטחת שימוש מוצלח בקורא מסך

כ-1% עד 2% מהאנשים משתמשים בקורא מסך. האם אפשר להבין את כל המידע החשוב ולבצע אינטראקציה עם הרכיב באמצעות קורא המסך והמקלדת בלבד?

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

האם לכל הרכיבים והתמונות יש חלופות בעלות משמעות?

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

לדוגמה, אם ברכיב ממשק המשתמש <fancy-menu> מוצג רק סמל גלגל שיניים כדי לציין שמדובר בתפריט הגדרות, נדרשת לו חלופה נגישה לטקסט, כמו 'הגדרות', שתעביר את אותו מידע. בהתאם להקשר, תוכלו לספק חלופה לטקסט באמצעות מאפיין alt, מאפיין aria-label, מאפיין aria-labelledby או טקסט פשוט ב-DOM של הצל. ניתן למצוא טיפים טכניים כלליים בעיון המהיר של WebAIM.

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

האם הרכיבים מספקים מידע סמנטי?

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

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

לדוגמה, רכיב מותאם אישית של ממשק המשתמש <fancy-slider> עשוי לקבל תפקיד ARIA של פס הזזה, שיש לו כמה מאפייני ARIA קשורים: aria-valuenow, aria-valuemin ו-aria-valuemax. קישור המאפיינים האלה למאפיינים הרלוונטיים ברכיב המותאם אישית יאפשר למשתמשים בטכנולוגיה מסייעת לבצע אינטראקציה עם האלמנט, לשנות את הערך שלו ואפילו לגרום לשינויים בהצגה החזותית של הרכיב.

<fancy-slider role="slider" aria-valuemin="1" aria-valuemax="5" aria-valuenow="2.5">
</fancy-slider>

האם המשתמשים יכולים להבין הכול בלי להסתמך על צבע?

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

האם יש מספיק ניגודיות?

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

האם ניתן לעצור באופן בטוח או ניתן למנוע עצירה של תוכן זז או מהבהב?

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

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

בדיקות וכלי נגישות

יש יותר מ-100 כלים שאפשר להיעזר בהם כדי לבדוק את הנגישות של האתר ושל הרכיבים שלו. חלק מהכלים הם אוטומטיים ואחרים דורשים בדיקה ידנית.

כמה נקודות שכדאי להביא בחשבון:

• Axe מספק בדיקות נגישות אוטומטיות ל-framework או לדפדפן לבחירתכם. אפשר להשתמש ב-Axe Puppeteer כדי לכתוב בדיקות נגישות אוטומטיות.

• ביקורת נגישות Lighthouse מספקת תובנות מועילות כדי לזהות בעיות נגישות נפוצות. ציון הנגישות הוא ממוצע משוקלל של כל ביקורות הנגישות, שמבוסס על הערכות ההשפעה על משתמשי Axe. תוכלו להיעזר ב-Lighthouse CI כדי לעקוב אחרי הנגישות באמצעות אינטגרציה רציפה (CI).

  

• Tenon.io הוא כלי שימושי לבדיקת בעיות נגישות נפוצות. ב-Tenon יש תמיכה גבוהה בשילוב בכלי build, בדפדפנים (דרך תוספים) ואפילו בעורכי טקסט.

• יש כלים רבים שספציפיים לספרייה ול-framework כדי להדגיש בעיות נגישות ברכיבים. לדוגמה, אפשר להשתמש ב-eslint-plugin-jsx-a11y כדי להדגיש בעיות נגישות ברכיבי React בעורך.

  

  אם אתם משתמשים ב-Angular, מקודד מספק גם ביקורות נגישות של עורכים:

  

עבודה עם טכנולוגיות מסייעות

• אפשר להשתמש ב-Accessibility Inspector (ב-Mac) או ב-Windows Automation API Testing Tools כדי לראות את האופן שבו טכנולוגיות מסייעות יכולות לראות תוכן באינטרנט. ניתן גם להשתמש ב-AccProbe (Windows). על ידי מעבר אל about://accessibility תוכלו גם לראות את עץ הנגישות המלא ש-Chrome יוצר.
• הדרך הטובה ביותר לבדוק אם יש תמיכה בקורא מסך ב-Mac היא להשתמש בכלי VoiceOver. כדי להפעיל או להשבית אותה, משתמשים ב-⌘F5, ב-Ctrl+Option ←→ כדי לנווט בדף וב-Ctrl+Shift+Option + ↑↓ כדי לזוז למעלה ולמטה בעץ הנגישות. לקבלת הוראות מפורטות יותר, תוכלו לעיין ברשימת הפקודות המלאה ב-VoiceOver וברשימת הפקודות של VoiceOver באינטרנט.

• ב-Windows, NVDA הוא קורא מסך בקוד פתוח בחינם. עם זאת, עקומת הלמידה תלולה גם בקרב משתמשים בעלי יכולת ראייה.

  

• ב-ChromeOS יש קורא מסך מובנה.

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

• ב-4 מתוך כל 5 אתרים יש טקסט שמשתלב ברקע, כך שהם בלתי קריאים.
• ב-49.91% מהדפים עדיין לא מספקים מאפייני alt בחלק מהתמונות.
• רק 24% מהדפים שנעשה בהם שימוש בלחצנים או בקישורים כוללים תוויות.
• רק 22.33% מהדפים מספקים תוויות לכל הקלט שהוזן.

יש הרבה מה שאנחנו יכולים לעשות כדי ליצור חוויות שיהיו נגישות יותר לכולם.