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

כמפתחים, האחריות שלנו לוודא שהקוד שלנו זמין ונגיש לכלל המשתמשים, כולל אנשים עם מוגבלויות, היא לא רק חובה מוסרית אלא גם עסקית. כיום, כאשר נגישות דיגיטלית היא דרישה חוקית במספר רב של מדינות, המשמעות של נגישות בקוד היא עצומה. במאמר זה, אסקור כיצד לוודא שהקומפוננטות שאתם מפתחים עומדות בסטנדרטים הגבוהים ביותר של נגישות דיגיטלית, תוך שימוש בכלים ושיטות שפותחו בדיוק למטרה זו.
למה שנגישות דיגיטלית תעניין אתכם?
אחד מכל שישה אנשים בעולם חי עם מגבלה משמעותית כלשהי. מגבלות אלה יכולות לכלול קשיים, קבועים או זמניים, בראייה, שמיעה, מגבלות מוטוריות, לקויות למידה ועוד. המשמעות היא שקהל יעד רחב עלול להיתקל בקשיים בגישה למוצרים, אתרים ואפליקציות, שאתם מפתחים, ולא יוכל לצרוך את המוצר שלכם כמו שהייתם רוצים. אם תתייחסו לנגישות דיגיטלית באופן יסודי, לא רק חוויית המשתמש תהיה שוויונית יותר, אלא גם תשמור על תאימות לדרישות רגולטריות, ותגדיל את קהל המשתמשים שלכם.
בעיות נגישות דיגיטליות הן רחבות יותר ונפוצות יותר משחשבתם. סריקה שביצענו על 1,000 עמודי אינטרנט של חברות Fortune 500 העלתה אלפי בעיות, כגון: רכיבים שלא ניתן לגשת אליהם באמצעות מקלדת – דבר שמונע גישה מאנשים שלא יכולים להשתמש בעכבר; רכיבים ללא שמות נגישים – שגורמים לכך שקוראי מסך אינם יכולים לתאר למשתמש עיוור את התוכן באתר; חוסר בסמנטיקה מתאימה – מה שמקשה על אינטראקציה תקינה של קוראי מסך ומקלדות ברייל עם האלמנטים בעמוד, ועוד.
"בעידן שבו כולם גולשים, קונים ועובדים באינטרנט, נגישות דיגיטלית היא לא רק חובה מוסרית, אלא גם כלי עסקי קריטי. שימוש בבדיקות מבוססות TDD ובכלים מתקדמים יכול לחסוך לכם זמן, כסף ואי נעימויות משפטיות"
תיקון בעיות נגישות דיגיטלית בשלב הייצור נעשה קשה הרבה יותר, שכן חזרה לקוד שלא נגענו בו זמן רב, תוך שינוי הקונטקסט מהספרינט, תמיד נחשב למסובך יותר, בטח אם לא אנחנו כתבנו את הקוד. שלא לדבר על הפגיעה במוניטין ובשביעות הרצון של המשתמשים. לכן, נגישות צריכה להיות חלק אינטגרלי מתהליך הפיתוח – החל מהשלב הראשון.
פיתוח נגיש באמצעות בדיקות TDD
Test-Driven Development -TDD היא גישה שיכולה לעזור למפתחים לזהות ולמנוע בעיות נגישות דיגיטלית עוד בשלב מוקדם של מחזור הפיתוח. בשיטה זו כותבים את הבדיקות עוד לפני הפיתוח, דבר שמעודד קוד פשוט יותר, משפר את האיכות שלו, ומבטיח שניתן יהיה לתחזק אותו בקלות בעתיד. לדוגמה, כתיבת Unit Tests גם עבור קריטריונים של נגישות דיגיטלית יכולים להבטיח שהקוד שלכם יישאר נגיש גם לאחר שינויים ותיקונים, בדיוק כמו שהוא נשאר פונקציונלי בזכות טסטים.
כדי להקל על הפיתוח של בדיקות אלו, נוכל להשתמש בכלים ציבוריים כמו Testing Library – ספרייה המעודדת כתיבת קוד בדיקות פשוט, עם מחשבה על נגישות בחשיבות ראשונה.
איך נדע מה בכלל לבדוק?
כמפתחים, אנחנו אחראים לוודא שהקוד שלנו נגיש ונמצא בתאימות עם כל דרישות הנגישות הדיגיטלית. כדי לעשות זאת, יש להשתמש במדריכים וכלים מקובלים בתעשייה, כמו APG ו-MagentaA11y, שמספקים הנחיות מדויקות עבור הפיתוח של קומפוננטות נגישות.
במקרים רבים חשוב לוודא שגם המפתחים וגם צוות המוצר (Product) מבינים את הצרכים והדרישות של הקומפוננטות שאנחנו מפתחים ומדברים באותה השפה. כאשר אנחנו מבטיחים תקשורת ברורה עם הצוות, נוכל להיות בטוחים שאנחנו מפתחים את הקומפוננטות בצורה הנכונה.
כמובן, בגישת TDD חשוב גם לבדוק את הרכיבים השונים בשלב מוקדם של מחזור הפיתוח, כך שנוכל לזהות בעיות ולהתמודד איתן עוד לפני שהשתחררו ל-QA.
מקרה מבחן: פיתוח קומפוננטת כפתור Toggle נגיש
נבחן פיתוח כפתור Toggle נגיש באמצעות Unit Tests. קודם כל נאסוף את הדרישות לנגישות עבור כפתורי Toggle מתוך APG. כעת, אנחנו מוכנים לכתוב את הבדיקות:
1. זיהוי semantic role של הכפתור: ודאו שלכפתור יש role מוגדר, כגון "button", באמצעות פונקציות עזר של Testing Library כמו getByRole. פעולה זו תוודא שטכנולוגיות כמו קורא מסך יוכלו לתפעל את הכפתור בהצלחה.
2. מתן שם נגיש לכפתור: ודאו שיש טקסט שקורא המסך יוכל להקריא עבור הכפתור, באמצעות פונקצית עזר כמו toHaveAccessibleName. כך נוודא שמשתמשים עם לקויות ראייה ידעו מהי מטרת הכפתור.
3. גישה באמצעות מקלדת: בדקו שהכפתור ניתן למיקוד באמצעות כפתור הטאב במקלדת, על מנת להבטיח נגישות למשתמשים שאינם יכולים להשתמש בעכבר. את סימולציית המשתמש שמנווט על הכפתור באמצעות המקלדת אפשר לממש בעזרת ספריית UserEvent.
יתרונות הבדיקות בשלבי פיתוח מוקדמים:
זיהוי מוקדם של בעיות: כאשר רואים שהבדיקות נכשלות בשלב הכתיבה, ניתן לבצע התאמות מידיות.
שיפור תחזוקת הקוד: הקוד הופך להיות ברור יותר, וכל מי שקורא אותו ידע להבין את השימוש שלו בקלות, ויוכל לבצע בו שינויים בהמשך.
ביטחון בעת שינויים: כל רכיב שנבדק עם מלווה בסט בדיקות המוודאות שהשינויים העתידיים שנבצע לא יפגעו בנגישות שלו.
בעידן שבו כולם גולשים, קונים ועובדים באינטרנט, נגישות דיגיטלית היא לא רק חובה מוסרית, אלא גם כלי עסקי קריטי. שימוש בבדיקות מבוססות TDD ובכלים מתקדמים יכול לחסוך לכם זמן, כסף ואי נעימויות משפטיות. כמתכנתים, יש לנו הזדמנות להפוך את האינטרנט לנגיש יותר – כזו שכולנו חייבים לנצל. אז בפעם הבאה שאתם מפתחים קומפוננטה, זכרו: נגישות היא חלק בלתי נפרד מכתיבת קוד איכותי.
הכותב הוא חוקר מוביל בחברת הסטארטאפ Evinced, המפתחת כלים למפתחים להטמעת נגישות בסקייל גבוה באפליקציות ווב ומובייל.
תגובות
(0)