הקביעה אם האתר או האפליקציה נגישים אדירה. אם אתם מתקרבים לנגישות בפעם הראשונה, היקף החשיפה המלא של הנושא עלול לגרום לכם לתהות מאיפה להתחיל. אחרי הכול, היכולת לתת מענה למגוון רחב של יכולות מגוון רחב של נושאים שכדאי לשקול.
הפוסט הזה מפרק את הבעיות האלה לתהליך הגיוני, שלב אחר שלב, בדיקת אתר קיים בנושא הנגישות.
מתחילים לעבוד עם המקלדת
עבור משתמשים שאינם יכולים או בוחרים שלא להשתמש בעכבר, הניווט באמצעות המקלדת האמצעי העיקרי להגיע לכל מה שמופיע במסך. הקהל הזה כולל משתמשים עם לקויות מוטוריות, כמו פגיעת מאמץ חוזרת (RSI) וגם משתמשים בקורא מסך.
כדי ליהנות מחוויית מקלדת טובה, סדר הכרטיסיות צריך להיות הגיוני וברור סגנונות התמקדות מובחנים.
כדי להתחיל, עוברים בין הכרטיסיות באתר. הסדר שבו מתמקדים באלמנטים צריך להופיע לפי סדר ה-DOM. אם אתם לא בטוחים אילו רכיבים צריכים לקבל לעיין במודול בקורס 'לימוד נגישות' בנושא התמקדות. הטוב ביותר הוא שכל אמצעי בקרה שמשתמש יכול לקיים איתו אינטראקציה או לספק קלט צריך להיות פוקוס ולהציג אינדיקטור של מיקוד (כמו טבעת מיקוד).
יש להתמקד בפקדים אינטראקטיביים בהתאמה אישית. אם אתם משתמשים ב-JavaScript כדי
<div>לתפריט נפתח מהודר, הוא לא יתווסף באופן אוטומטי סדר הכרטיסיות. כדי שניתן יהיה להתמקד בפקד בהתאמה אישית, צריך לתת לוtabindex="0". ערכים שלtabindexשגדולים מ-0 משנים את סדר הכרטיסיות ועלולים לבלבל עבור למשתמשים בקורא מסך.ניתן להתמקד רק בתוכן אינטראקטיבי. המערכת מוסיפה את
tabindexאל רכיבים אינטראקטיביים כמו כותרות מאטים את המשתמשים במקלדת שיכולים לראות במסך, ולא עוזר למשתמשים בקורא מסך כי קורא המסך כבר יודע להכריז עליהן.אם מוסיפים תוכן חדש לדף, צריך להפנות את המיקוד של המשתמש לתוכן הזה כדי שיוכלו לבצע פעולה בנושא. צפייה ניהול הריכוז ברמת הדף לקבלת דוגמאות.
יש לעצב את האתר כך שהמשתמשים תמיד יוכלו להתמקד באלמנט הבא כשהוא רוצה. היזהרו מווידג'טים של השלמה אוטומטית ומהקשרים אחרים שעלולים להיקלט מיקוד המקלדת. אפשר להעביר את המיקוד באופן זמני למשתמש שרוצים או לבצע אינטראקציה בחלון מודאלי ולא בשאר הדף, אבל תמיד צריך לספק דרך נגישה במקלדת כדי לסמן בתו בריחה (escape). צפייה מודים ומלכודות למקלדת כדוגמה.
כך אפשר להשתמש בפקדים לשליטה
אם יצרתם אמצעי בקרה מותאם אישית, המשתמשים יוכלו לגשת לכל התכונות שלו באמצעות המקלדת בלבד. נקראו ניהול ההתמקדות ברכיבים לשיטות לשיפור הגישה למקלדת.
ניהול התוכן שלא מופיע במסך
אתרים רבים כוללים תוכן מחוץ למסך שנמצא ב-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.
aria-hidden לא מונע את מיקוד המקלדת
חשוב להבין ש-ARIA יכול להשפיע רק על הסמנטיקה של
element; אין לה השפעה על ההתנהגות של האלמנט. אפשר ליצור
רכיב שהוסתר לקוראי מסך עם 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 מספק את אותן תכונות בתור תוסף Xe לדפדפן, אבל ניתן להריץ אותו מהטרמינל.
- כדי להימנע מרגרסיות, במיוחד בסביבת אינטגרציה רציפה (CI), לשלב ספרייה כמו axe-core בחבילת הבדיקות האוטומטית. axe-core הוא אותו המנוע שמפעיל תוסף ל-Chrome מסוג X, אבל בכלי שורת פקודה.
- אם אתם משתמשים במסגרת או בספרייה, האם היא מספקת נגישות משלה כלים? לדוגמה, protractor-accessibility-plugin עבור Angular. כדאי לנצל את הכלים שזמינים ככל האפשר.
שימוש ב-Lighthouse כדי לבדוק אפליקציות PWA
Lighthouse הוא כלי מודד את הביצועים של Progressive Web App (PWA). בנוסף, הוא משתמש בספריית ליבת הגרזן כדי להפעיל את בדיקות הנגישות.
אם כבר השתמשת ב-Lighthouse, כדאי לבדוק אם יש בעיות בנגישות בדיקות בדוח. כדאי לתקן את השגיאות כדי לשפר את חוויית המשתמש הכוללת של באתר שלך.