נגישות לצוותים

איך לשלב את הנגישות בתהליך של הצוות.

Rob Dodson

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

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

מנהלי פרויקטים

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

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

הדרכה בנושא נגישות

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

אלה כמה מהמשאבים ש-Google מספקת:

Web Accessibility by Google – קורס הכשרה אינטראקטיבי שנמשך מספר שבועות.

יסודות הנגישות – מדריכים כתובים לנגישות ושיטות מומלצות.

הנחיות מהותיות: נגישות – קבוצה של שיטות מומלצות ליצירת חוויית משתמש שמעודדת את קבלת האחר.

זיהוי מסלולים קריטיים שעוברים המשתמשים

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

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

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

שילוב רשימת משימות לנגישות

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

יש מספר רשימות של משימות בנושא נגישות, לדוגמה:

רשימת משימות של WebAIM WCAG הנחיות לנגישות של Vox

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

הערכה באמצעות מחקרי משתמשים

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

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

מעצב UX

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

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

לתוכן יש ניגודיות טובה של צבעים

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

הניגודיות נמדדת על ידי השוואת רמת ההארה של צבע החזית וצבע הרקע. בטקסט קטן יותר (כל טקסט מודגש בגודל נמוך מ-18 נקודות או 14 נקודות), מומלץ להשתמש ביחס מינימלי של 4.5:1. לטקסט גדול יותר אפשר לשנות את היחס ל-3:1.

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

יש כמה כלים למדידת ניגודיות של צבעים, כמו Material Color Tool של Google, האפליקציה Contrast Ratio של Lea Verou ו-aXe של Deque.

סדר הכרטיסיות מוגדר

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

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

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

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

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

הנה כמה הצעות פשוטות שיעזרו לך לעצב תוויות נגישות:

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

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

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

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

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

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

המפַתח

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

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

סדר כרטיסיות לוגי

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

יש שתי אפשרויות:

• מזינים את הערך tabindex="0" בשדה הבקרה. כך לפחות יהיה אפשר להתמקד בו, אבל כנראה תצטרכו לבצע פעולות נוספות כדי להוסיף תמיכה בהקשה על מקש.
• כשאפשר, מומלץ להשתמש ב-button במקום ב-div או ב-span לכל אמצעי בקרה דמוי-לחצן. קל מאוד לעצב את רכיב button המקורי, והוא מקבל תמיכה במקלדת בחינם.

ניהול המיקוד

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

תמיכה במקלדת ברכיבים אינטראקטיביים

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

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

תפקידים ומאפיינים של ARIA מיושמים לפי הצורך

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

רכיבי תוויות

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

לצערנו, <label> לא תומך במתן שם נגיש לפקדים בהתאמה אישית (כמו אלה שנוצרו באמצעות Custom Elements או מתוך div ו-spans פשוטים). כדי להשתמש באמצעי בקרה כאלה, צריך להשתמש במאפיינים aria-label ו-aria-labelledby.

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

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

AXe שנוצר על ידי מערכות Deque זמין כתוסף ל-Chrome וגם כמודול צומת (מתאים לסביבות של אינטגרציה רציפה (CI). ה-A11ycast הקצר הזה מסביר כמה דרכים שונות לשילוב aXe בתהליך הפיתוח שלכם.

Lighthouse הוא פרויקט קוד פתוח של Google, שמטרתו לבדוק את הביצועים של האפליקציות שלכם מסוג Progressive Web App. בנוסף לבדיקה אם ב-PWA יש תמיכה בדברים כמו Service Worker ומניפסט של אפליקציית אינטרנט, ל-Lighthouse יתבצעו סדרה של בדיקות של שיטות מומלצות, כולל בדיקות של בעיות נגישות.

סיכום

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

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