היכולת לקבוע אם האתר או האפליקציה נגישים עשויה להיראות כמו משימה גדולה מדי. אם זו הפעם הראשונה שאתם ניגשים לנושא הנגישות, ההיקף העצום של הנושא יכול לגרום לכם לחשוב מאיפה להתחיל. אחרי הכול, המשמעות של עבודה לתת מענה למגוון רחב של יכולות מאפשרת להציג מגוון רחב של בעיות בהתאם.
בפוסט הזה אנחנו מפרטים את הבעיות האלה בתהליך הגיוני ומפורט לבדיקת נגישות של אתר קיים.
מתחילים עם המקלדת
למשתמשים שאינם יכולים או בוחרים לא להשתמש בעכבר, ניווט באמצעות המקלדת הוא הדרך העיקרית להגיע לכל מה שמופיע במסך. הקהל הזה כולל משתמשים בעלי לקויות מוטוריות, כמו פציעה או שיתוק לחץ חוזר ונשנה, וכן משתמשים בקורא מסך.
כדי ליהנות מחוויית שימוש טובה במקלדת, מומלץ להקפיד על סדר כרטיסיות הגיוני ולהשתמש בסגנונות מיקוד שניתן להבחין בהם בבירור.
בתור התחלה, עוברים בין הכרטיסיות באתר. הסדר שבו הרכיבים מתמקדים צריך להיות תואם לסדר ה-DOM. לא בטוחים אילו אלמנטים צריכים להתמקד? תוכלו לקרוא את המאמר יסודות המיקוד לרענון. השיטה המומלצת היא שכל אמצעי הבקרה שתהיה למשתמש יכול לבצע איתו פעולות או לתת לו מידע צריך להיות ניתן למיקוד ולהציג אינדיקטור למיקוד (כמו טבעת מיקוד).
הפקדים האינטראקטיביים בהתאמה אישית צריכים להיות ניתנים למיקוד. אם משתמשים ב-JavaScript כדי להפוך
<div>לתפריט נפתח מיוחד, הוא לא יתווסף באופן אוטומטי לסדר הכרטיסיות. כדי שניתן יהיה להתמקד בפקד בהתאמה אישית, צריך להקצות לוtabindex="0". ערכים גדולים מ-0 ב-tabindexמשנים את סדר הכרטיסיות ועלולים לבלבל משתמשים בקורא מסך.אפשר להתמקד רק בתוכן אינטראקטיבי. הוספת
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. אם אתם משתמשים במחשב PC, כדאי לצפות בסרטון הזה על NVDA, קורא מסך בקוד פתוח שנתמך על ידי Windows עבור Windows.
ההגדרה aria-hidden לא מונעת את מיקוד המקלדת
חשוב להבין ש-ARIA יכולה להשפיע רק על הסמנטיקה של אלמנט, ולא על ההתנהגות של הרכיב. אפשר להסתיר רכיב מפני קוראי מסך באמצעות aria-hidden="true", אבל פעולה זו לא תשנה את התנהגות המיקוד של אותו רכיב. אם מדובר בתוכן אינטראקטיבי מחוץ למסך,
אם מדובר בתוכן אינטראקטיבי מחוץ למסך, השתמשו במאפיין inert
כדי לוודא שהוא באמת הוסר מתהליך העבודה במקלדת. בדפדפנים ישנים יותר, משלבים את aria-hidden="true" עם tabindex="-1".
רכיבים אינטראקטיביים צריכים לציין את המטרה והמצב שלהם
כשמציגים רמזים ויזואליים, או סכומים מקובלים, לגבי מה שאמצעי הבקרה לעשות, עוזרים למגוון רחב של אנשים במגוון רחב של מכשירים להפעיל את האתר ולנווט בו.
- צריך להבחין בין רכיבים אינטראקטיביים, כמו קישורים ולחצנים, לבין רכיבים לא אינטראקטיביים. למשתמשים קשה לנווט באתר או באפליקציה כשהם לא יכולים לדעת אם אלמנט קליקבילי ניתן ללחיצה. יש דרכים חוקיות רבות לציין רכיבים אינטראקטיביים. אחת השיטות הנפוצות היא לסמן קישורים בקו תחתון, כדי להבדיל ביניהם לבין הטקסט שמסביב.
- בדומה לדרישה למיקוד, לרכיבים אינטראקטיביים כמו קישורים ולחצנים נדרש מצב
hoverכדי ליידע את משתמשי העכבר כשהסמן שלהם עובר מעל פריט שניתן ללחוץ עליו. עם זאת, כדי שהרכיבים האלה יהיו נגישים לשיטות קלט אחרות, צריך שתהיה אפשרות להבחין ביניהם ללא מצבhover.
נצל את היתרונות של כותרות וציוני דרך
כותרות ורכיבים של ציוני דרך מעניקים לדף מבנה סמנטי, ומשפרים משמעותית את יעילות הניווט של משתמשי טכנולוגיה מסייעת. הרבה משתמשים בקוראי מסך מדווחים שכאשר הם מגיעים בפעם הראשונה לדף לא מוכר, הם בדרך כלל מנסים לנווט לפי כותרות.
באופן דומה, קוראי מסך מאפשרים גם לדלג לציוני דרך חשובים כמו <main> ו-<nav>. לכן חשוב לקחת בחשבון את האופן שבו מבנה הדף יכול להשפיע על חוויית המשתמש.
- שימוש בהיררכיה
h1-h6. אפשר לחשוב על כותרות בתור כלים שיוצרים מתווה לדף. אין להסתמך על הסגנון המובנה של כותרות. במקום זאת, כדאי להתייחס אליהם כאילו כולם באותו גודל ולהשתמש ברמה המתאימה מבחינה סמנטית לתוכן ראשוני, משני ושלישוני. לאחר מכן השתמשו ב-CSS כדי להתאים את הכותרות לעיצוב. - כדאי להשתמש ברכיבים ובתפקידים חשובים כדי שהמשתמשים יוכלו לעקוף תוכן שחוזר על עצמו. טכנולוגיות מסייעות רבות מספקות קיצורי דרך למעבר לחלקים מסוימים בדף, כמו אלה שהוגדרו על ידי רכיבי
<main>או<nav>. לרכיבים האלה יש תפקידים משתמעים של ציון דרך. אפשר גם להשתמש במאפייןroleשל ARIA כדי להגדיר אזורים מפורשים בדף, כמו ב-<div role="search">. דוגמאות נוספות זמינות במאמר סמנטיקה וניווט בתוכן. - מומלץ לא להשתמש ב-
role="application"אלא אם יש לכם ניסיון בעבודה איתו. התפקיד 'ציון דרך'applicationמורה לטכנולוגיה המסייעת להשבית את קיצורי הדרך שלה ולהעביר את כל לחיצות המקשים לדף. המשמעות היא שהמקשים שמשתמשים בקורא המסך בדרך כלל לא פועלים יותר, ותצטרכו ליישם את כל הטיפול במקלדת בעצמכם.
בודקים כותרות וציוני דרך באמצעות קורא מסך
קוראי מסך, כמו VoiceOver ו-NVDA מספקים תפריט הקשר שמאפשר לדלג לאזורים חשובים בדף. כשבודקים נגישות, אפשר להשתמש בתפריטים האלה כדי לקבל סקירה כללית של הדף ולקבוע אם רמות הכותרת מתאימות ובאילו ציוני דרך נעשה שימוש.
כדי לקבל מידע נוסף, אפשר לצפות בסרטוני ההדרכה בנושאים הבסיסיים של VoiceOver ושל NVDA.
אוטומציה של התהליך
בדיקה ידנית של נגישות של אתר יכולה להיות משימה מייגעת וצפויה לשגיאות. כדאי לבצע בדיקה אוטומטית כמה שיותר. תוכלו להשתמש בתוספי דפדפן ובחבילות בדיקה לנגישות של שורת הפקודה.
- האם הדף עובר את כל הבדיקות מתוספי הדפדפן aXe או WAVE? יש עוד אפשרויות זמינות, אבל התוספים האלה יכולים להיות תוספת מועילה לכל תהליך בדיקה ידני, כי הם יכולים לזהות בעיות עדינות כמו יחסי ניגודיות כשלים ומאפייני ARIA חסרים.
- אם אתם מעדיפים לעבוד בשורת הפקודה, axe-cli מספק את אותן התכונות כמו התוסף של דפדפן aXe, אבל אפשר להריץ אותו מהטרמינל.
- כדי למנוע רגרסיות, במיוחד בסביבת אינטגרציה רציפה (CI), כדאי לשלב ספרייה כמו axe-core בחבילת הבדיקות האוטומטית. axe-core הוא אותו מנוע שמפעיל את תוסף Chrome מסוג AXe, אבל בכלי שורת פקודה.
- אם אתם משתמשים ב-framework או בספרייה, האם היא מספקת כלי נגישות משלה? לדוגמה, הפלאגין-protractor-accessibility- של Angular. נצלו את הכלים הזמינים במידת האפשר.
איך משתמשים ב-Lighthouse כדי לבדוק אפליקציות PWA
Lighthouse הוא כלי שמודד את הביצועים של Progressive Web App (PWA). בנוסף, הוא עושה שימוש בספריית גרזן כדי להפעיל את בדיקות הנגישות שלו.
אם אתם כבר משתמשים ב-Lighthouse, תוכלו לחפש בעיות בבדיקות הנגישות בדוח. תקנו את השגיאות כדי לשפר את חוויית המשתמש הכוללת באתר.