איך בודקים את הנגישות

Rob Dodson

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

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

התחלה עם המקלדת

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

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

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

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

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

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

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

איך משתמשים בשליטה במיקוד

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

ניהול תוכן מחוץ למסך

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

טיפים לטיפול בתוכן שמופיע מחוץ למסך

בדיקה באמצעות קורא מסך

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

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

  • בודקים את כל התמונות כדי לוודא שהטקסט של alt תקין. היוצא מן הכלל הוא כשהתמונות נועדו בעיקר לצורכי הצגה ולא הן חלק חיוני מהתוכן. כדי לציין שקוראי המסך צריכים לדלג על תמונה, מגדירים את הערך למחרוזת ריקה: alt="".
  • בודקים את כל אמצעי הבקרה של התווית. אם מדובר באמצעי בקרה בהתאמה אישית, יכול להיות שתצטרכו להשתמש ב-aria-label או ב-aria-labelledby. דוגמאות מפורטות זמינות במאמר תוויות וקשרים ב-ARIA.
  • בודקים את כל אמצעי הבקרה המותאמים אישית כדי לוודא שהם כוללים את הערך המתאים של role ואת כל מאפייני ה-ARIA הנדרשים שמייצגים את המצב שלהם. לדוגמה, כדי להעביר את המצב של תיבת סימון בהתאמה אישית בצורה נכונה, צריך להשתמש ב-role="checkbox" וב-aria-checked="true|false". במאמר מבוא ל-ARIA מפורטת סקירה כללית על האופן שבו ARIA יכולה לספק סמנטיקה חסרה לאמצעי בקרה בהתאמה אישית.
  • חשוב שהמידע בדף יהיה הגיוני. מכיוון שקוראי המסך מנווטים בדף לפי סדר DOM, הם ידברו על כל רכיב ששיניתם את המיקום שלו באופן חזותי באמצעות CSS, בסדר לא הגיוני. אם אתם רוצים שרכיב מסוים יופיע מוקדם יותר בדף, צריך להעביר אותו פיזית מוקדם יותר ב-DOM.
  • כדאי לתמוך בניווט של קורא מסך בכל התוכן בדף. חשוב לוודא שאין חלקים באתר שמוסתרים או חסומים לצמיתות לגישה של קורא המסך.
    • אם התוכן צריך להיות מוסתר מקורא מסך, למשל אם הוא מחוץ למסך או שהוא רק חזותי, צריך להגדיר את התוכן הזה כ-aria-hidden="true". הסבר מפורט יותר זמין במאמר הסתרת תוכן.

היכרות עם קוראי מסך

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

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

aria-hidden לא מונע את מיקוד המקלדת

חשוב להבין ש-ARIA יכולה להשפיע רק על הסמנטיקה של רכיב, ואין לה השפעה על ההתנהגות שלו. אפשר להסתיר רכיב לקוראי מסך באמצעות aria-hidden="true", אבל הפעולה הזו לא משנה את התנהגות המיקוד ברכיב. תוכן אינטראקטיבי שמופיע מחוץ למסך: תוכלו להשתמש במאפיין inert כדי לוודא שהוא אכן יוסר מתהליך ההקלדה במקלדת. בדפדפנים ישנים יותר, צריך לשלב את aria-hidden="true" עם tabindex="-1".

אלמנטים אינטראקטיביים צריכים לציין את המטרה והמצב שלהם

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

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

שימוש בכותרות ובציוני דרך

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

באופן דומה, קוראי מסך גם מאפשרים לעבור למאפיינים חשובים כמו <main> ו-<nav>. לכן חשוב לחשוב איך אפשר להשתמש במבנה הדף כדי להנחות את חוויית המשתמש.

  • משתמשים בהיררכיה h1-h6. אפשר להתייחס לכותרות ככלים ליצירת תוכנית של הדף. אל תסתמכו על הסגנון המובנה של הכותרות. במקום זאת, צריך להתייחס אליהן כאילו כולן באותו גודל ולהשתמש ברמה הסמנטית המתאימה לתוכן ראשי, משני ושלישי. לאחר מכן, משתמשים ב-CSS כדי שהכותרות יתאימו לעיצוב.
  • כדאי להשתמש ברכיבים ובתפקידים של ציוני דרך כדי שמשתמשים יוכלו לעקוף תוכן חוזר. הרבה טכנולוגיות מסייעות מספקות קיצורי דרך לדילוג לחלקים ספציפיים בדף, כמו אלה שמוגדרים על ידי אלמנטים מסוג <main> או <nav>. לאלמנטים האלה יש תפקידים משניים מרומזים. אפשר גם להשתמש במאפיין ARIA role כדי להגדיר באופן מפורש אזורים בדף, כמו ב-<div role="search">. דוגמאות נוספות זמינות במאמר סמנטיקה וניווט בתוכן.
  • מומלץ להימנע משימוש ב-role="application", אלא אם יש לכם ניסיון בעבודה איתו. התפקיד application של ציון הדרך מורה לטכנולוגיה המסייעת להשבית את מקשי הקיצור שלה ולהעביר את כל הקשות המקלדת לדף. פירוש הדבר הוא שהמקשים שבהם משתמשים בקורא מסך בדרך כלל כדי לנוע בדף לא יפעלו יותר, ותצטרכו להטמיע בעצמכם את כל הטיפול במקלדת.

איך קוראים כותרות וציוני דרך באמצעות קורא מסך

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

מידע נוסף זמין בסרטוני ההדרכה הבאים על העקרונות הבסיסיים של VoiceOver ושל NVDA.

אוטומציה של התהליך

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

  • האם הדף עובר את כל הבדיקות של התוספים לדפדפן aXe או WAVE? יש אפשרויות אחרות, אבל התוספים האלה יכולים להוות תוספת שימושית לכל תהליך בדיקה ידני, כי הם יכולים לזהות בעיות עדינות כמו יחסי ניגודיות לא תקינים ומאפייני ARIA חסרים.
    • אם אתם מעדיפים לעבוד בשורת הפקודה, axe-cli מספק את אותן תכונות כמו התוסף לדפדפן aXe, אבל אפשר להריץ אותו מהמסוף.
  • כדי למנוע נסיגה לאחור, במיוחד בסביבת שילוב רצוף (CI), כדאי לשלב ספרייה כמו axe-core בחבילת הבדיקות האוטומטיות. axe-core הוא אותו מנוע שמפעיל את התוסף aXe ל-Chrome, אבל בתור כלי שורת פקודה.
  • אם אתם משתמשים בספרייה או ב-framework, האם יש להם כלים משלהם לנגישות? לדוגמה, התוסף protractor-accessibility-plugin ל-Angular. כדאי להשתמש בכלים הזמינים כשהדבר אפשרי.

שימוש ב-Lighthouse לבדיקת אפליקציות PWA

Lighthouse הוא כלי למדידת הביצועים של אפליקציות ה-PWA שלכם. בנוסף, הוא משתמש בספריית axe-core כדי להפעיל את בדיקות הנגישות שלו.

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

מקורות מידע נוספים