המודול הזה מתמקד בשימוש בטכנולוגיה מסייעת (AT) לבדיקת נגישות. אנשים עם מוגבלויות יכולים להשתמש ב-AT כדי לשפר, לשמר או לשפר את היכולות שלהם לבצע משימה.
במרחב הדיגיטלי, כלי AT יכולים להיות:
- ללא טכנולוגיה או טכנולוגיה בסיסית: מוטות לראש ולפה, מגדילים ידניים, מכשירים עם לחצנים גדולים
- טכנולוגיה מתקדמת: מכשירים המופעלים באמצעות קול, מכשירים למעקב אחר תנועות עיניים, מקלדות ועכברים מותאמים אישית
- חומרה: לחצני מתג, מקלדות ארגונומיות, מכשיר ברייל עם רענון אוטומטי
- תוכנה: תוכנות להמרת טקסט לדיבור, כתוביות מיידיות, קוראי מסך
מומלץ להשתמש בכמה סוגים של בדיקות AT בתהליך הבדיקה הכולל.
יסודות של בדיקות קורא מסך
במודול הזה נעסוק באחד מהכלים הדיגיטליים הפופולריים ביותר לתמיכה בטכנולוגיה, קוראי מסך. קורא מסך הוא תוכנה שקוראת את הקוד הבסיסי של אתר או אפליקציה, ולאחר מכן ממירה את המידע הזה לקלט דיבור או ברייל עבור המשתמש.
קוראי מסך חיוניים לאנשים עיוורים ולאנשים עם עיוורון ודיסלקציה, אבל הם יכולים להועיל גם לאנשים עם לקות ראייה, הפרעות קריאה והפרעות קוגניטיביות.
תאימות דפדפן
יש כמה אפשרויות של קוראי מסך. קוראי המסך הפופולריים ביותר הם JAWS, NVDA ו-VoiceOver למחשבים, ו-VoiceOver ו-Talkback למכשירים ניידים.
בהתאם למערכת ההפעלה (OS), לדפדפן המועדף ולמכשיר שבו אתם משתמשים, יכול להיות שקורא מסך אחד יהיה האפשרות הטובה ביותר. רוב קוראי המסך תוכננו תוך התמקדות בחומרה ובדפדפני אינטרנט ספציפיים. כשמשתמשים בקורא מסך עם דפדפן שלא בוצעה לו כיול, יכול להיות שתבחינו ביותר 'באגים' או בהתנהגות בלתי צפויה. קוראי המסך פועלים בצורה הטובה ביותר בשילובים הבאים.
| קורא מסך | מערכת ההפעלה | תאימות דפדפן |
|---|---|---|
| Job Access With Speech (JAWS) | Windows | Chrome, Firefox, Edge |
| Non-Visual Desktop Access (NVDA) | Windows | Chrome ו-Firefox |
| קריינות | Windows | Edge |
| VoiceOver | macOS | Safari |
| Orca | Linux | Firefox |
| TalkBack | Android | Chrome ו-Firefox |
| VoiceOver (לנייד) | iOS | Safari |
| ChromeVox | ChromeOS | Chrome |
פקודות של קורא מסך
אחרי שתסיימו להגדיר את תוכנת קורא המסך במחשב או בנייד, כדאי לעיין במסמכי העזרה של קורא המסך (הקישורים מוצגים בטבלה שלמעלה) ולתרגל כמה פקודות חיוניות של קורא המסך כדי להתמצא בטכנולוגיה. אם כבר השתמשתם בקורא מסך, כדאי לנסות קורא מסך חדש.
כשמשתמשים בקורא מסך לצורך בדיקת נגישות, המטרה היא לזהות בעיות בקוד שמפריעות לשימוש באתר או באפליקציה, ולא לחקות את החוויה של משתמש בקורא מסך. לכן, אפשר לעשות הרבה דברים עם ידע בסיסי, כמה פקודות של קורא מסך וקצת (או הרבה) תרגול.
אם אתם רוצים להבין טוב יותר את חוויית המשתמש של אנשים שמשתמשים בקוראי מסך ובאמצעות טכנולוגיות תמיכה אחרות, אתם יכולים ליצור קשר עם ארגונים ואנשים פרטיים רבים כדי לקבל תובנות חשובות. חשוב לזכור שבדרך כלל, שימוש ב-AT כדי לבדוק את הקוד בהתאם לקבוצה של כללים ושאילתה של משתמשים לגבי החוויה שלהם מניבות תוצאות שונות. שני הדברים האלה חשובים כדי ליצור מוצרים שמתאימים לכולם.
פקודות מקשים לקוראי מסך במחשב
| רכיב | NVDA (ב-Windows) | VoiceOver (macOS) |
|---|---|---|
| מפתחות פקודות כלליים | Insert | Control+Option |
| הפסקת האודיו | שליטה | שליטה |
| קריאת ההודעה הבאה/הקודמת | ↓ או ↑ | Control+Option+→ או ← |
| מתחילים לקרוא | Insert↓ | Control+Option+A |
| רשימת רכיבים/רוטור | NVDA + F7 | Control+Option+U |
| ציוני דרך | D | Control+Option+U |
| כותרות | H | Control+Option+Command+H |
| קישורים | K | Control+Option+Command+L |
| פקדי טופס | Control+Option+Command+J | |
| טבלאות | T | Control+OptionCommand+T |
| בטבלאות | Insert Alt + ↓ ↑ ← → | Control+Option+↓ ↑ ← → |
פקודות מקשים לקוראי מסך בניידים
| רכיב | TalkBack (Android) | VoiceOver (iOS) |
|---|---|---|
| אפשרויות נוספות | גוררים אצבע אחת ברחבי המסך | גוררים אצבע אחת ברחבי המסך |
| בחירה או הפעלה | לחיצה פעמיים | לחיצה פעמיים |
| העברה למעלה או למטה | החלקה כלפי מעלה או כלפי מטה בעזרת שתי אצבעות | מחליקים למעלה או למטה עם שלוש אצבעות |
| שינוי דפים | מחליקים ימינה או שמאלה עם שתי אצבעות | מחליקים ימינה או שמאלה עם שלוש אצבעות |
| הבא/הקודם | מחליקים ימינה או שמאלה עם אצבע אחת | מחליקים ימינה או שמאלה עם אצבע אחת |
הדגמה של בדיקת קורא מסך
כדי לבדוק את הדמו שלנו, השתמשנו ב-Safari במחשב נייד עם macOS והקלטנו אודיו. אפשר לבצע את השלבים האלה באמצעות כל קורא מסך, אבל יכול להיות שהאופן שבו תיתקלו בשגיאות מסוימות יהיה שונה מהאופן שמתואר במודול הזה.
שלב 1
אתם יכולים להיכנס ל-CodePen המעודכן, שבו הוחלו כל העדכונים האוטומטיים והידניים לשיפור הנגישות.
פותחים אותו במצב ניפוי באגים כדי להמשיך לבדיקות הבאות. חשוב לעשות זאת כי כך מסירים את <iframe> שמקיף את דף האינטרנט לדוגמה, שעלול להפריע לכלים מסוימים לבדיקות. מידע נוסף על מצב ניפוי הבאגים ב-CodePen
שלב 2
מפעילים את קורא המסך שבחרתם ונכנסים לדף הדגמה. מומלץ לעבור על כל הדף מלמעלה למטה לפני שמתמקדים בבעיות ספציפיות.
צילמנו את קורא המסך שלנו בכל בעיה, לפני ואחרי החלת התיקונים בדמו. מומלץ להריץ את הדמו עם קורא המסך שלכם.
בעיה 1: מבנה התוכן
כותרות וציוני דרך הם אחת מהדרכים העיקריות שבהן אנשים מנווטים באמצעות קוראי מסך. אם הם לא מופיעים, משתמש בקורא מסך יצטרך לקרוא את כל הדף כדי להבין את ההקשר. התהליך הזה עשוי להימשך זמן רב ולגרום לתסכול.
אם תנסו לנווט באמצעות אחד מהרכיבים האלה בדמו, תגלו במהירות שהם לא קיימים.
- דוגמה לציון דרך:
<div class="main">...</div> - דוגמה לכותרת:
<p class="h1">Join the Club</p>
אם עדכנתם את כל הרכיבים בצורה נכונה, לא אמורים להיות שינויים חזותיים, אבל חוויית השימוש בקורא המסך תשתפר באופן משמעותי.
נפתור את זה.
יש רכיבים שאינם נגישים שאי אפשר לראות רק על ידי צפייה באתר. ייתכן שזכרתם את החשיבות של רמות הכותרות ושל HTML סמנטי מהמודול מבנה התוכן. יכול להיות שחלק מהתוכן נראה כמו כותרת, אבל התוכן בעצם עטוף ב-<div> מעוצב.
כדי לפתור את הבעיה עם כותרות וציוני דרך, קודם צריך לזהות כל רכיב שצריך לסמן כזה ולעדכן את ה-HTML הרלוונטי. חשוב לעדכן גם את קובץ ה-CSS הרלוונטי.
- דוגמה לציון דרך:
<main>...</main> - דוגמה לכותרת:
<h1>Join the Club</h1>
אם עדכנתם את כל הרכיבים בצורה נכונה, לא אמורים להיות שינויים חזותיים, אבל חוויית השימוש בקורא המסך תשתפר באופן משמעותי.
בעיה 2: הקשר הקישור
חשוב לספק למשתמשים בקורא מסך תוכן לגבי מטרת הקישור, ואם הקישור מפנה אותם למיקום חדש מחוץ לאתר או לאפליקציה.
בדמו שלנו, תיקנו את רוב הקישורים כשעדכנו את הטקסט החלופי של התמונה הפעילה, אבל יש כמה קישורים נוספים לגבי מחלות נדירות שיכולים להפיק תועלת מהוספת הקשר – במיוחד מכיוון שהם מפנים לכתובת חדשה.
<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease">
Maple syrup urine disease (MSUD)
</a>
כדי לפתור את הבעיה עבור משתמשי קורא המסך, אנחנו מעדכנים את הקוד כדי להוסיף מידע נוסף, בלי להשפיע על הרכיב החזותי. לחלופין, כדי לעזור ליותר אנשים, כמו אנשים עם הפרעות קריאה והפרעות קוגניטיביות, יכול להיות שנוסיף טקסט חזותי נוסף.
יש הרבה דפוסים שונים שאנחנו עשויים לשקול כדי להוסיף מידע נוסף על הקישורים. מכיוון שהסביבה שלנו תומכת רק בשפה אחת, תווית ARIA היא אפשרות פשוטה במצב כזה. יכול להיות שתבחינו שהתווית ARIA מבטלת את הטקסט המקורי של הקישור, לכן חשוב לכלול את המידע הזה בעדכון.
<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease"
aria-label="Learn more about Maple syrup urine disease on the Rare Diseases website.">
Maple syrup urine disease (MSUD)
</a>
בעיה 3: תמונה דקורטיבית
במודול הבדיקה האוטומטי שלנו, מערכת Lighthouse לא הצליחה לזהות את קובץ ה-SVG שמוטמע בדף ומהווה את תמונת ה-splash הראשית בדף הדגמה שלנו. עם זאת, קורא המסך מוצא אותו ומקריא אותו כ'תמונה' ללא מידע נוסף.
זה נכון גם בלי להוסיף את המאפיין role="img" ל-SVG באופן מפורש.
<div class="section-right">
<svg>...</svg>
</div>
כדי לפתור את הבעיה, קודם עלינו להחליט אם התמונה היא מידעית או דקורטיבית. על סמך ההחלטה הזו, אנחנו צריכים להוסיף את הטקסט החלופי המתאים לתמונה (תמונה מידעית) או להסתיר את התמונה ממשתמשים בקורא מסך (תמונה דקורטיבית).
שקללנו את היתרונות והחסרונות של הדרכים השונות לסיווג התמונה, והחלטנו שהיא תמונה דקורטיבית. כלומר, אנחנו רוצים להוסיף או לשנות את הקוד כדי להסתיר את התמונה. שיטה מהירה היא להוסיף role="presentation" ישירות לתמונה בפורמט SVG. כך נשלח אות לקורא המסך כדי לדלג על התמונה הזו ולא לכלול אותה בקבוצת התמונות.
<div class="section-right">
<svg role="presentation">...</svg>
</div>
בעיה 4: קישוט של תווי נקודה
יכול להיות ששמתם לב שקורא המסך קורא את התמונה של פסיק ה-CSS בקטע של המחלות הנדירות. זהו לא סוג התמונה המסורתי שדיברנו עליו במודול תמונות, אבל עדיין צריך לשנות את התמונה כי היא משבשת את זרימת התוכן ויכולה להסיח את דעתו של משתמש קורא מסך או לבלבל אותו.
<p class="bullet">...</p>
בדומה לדוגמה של התמונה הגרפית שצוינה קודם, אפשר להוסיף את הקוד role="presentation" ל-HTML עם הכיתוב של פסיק התו, כדי להסתיר אותו מקורא המסך. באופן דומה, אפשר להשתמש ב-role="none". רק חשוב לא להשתמש ב-aria-hidden: true, אחרת כל פרטי הפסקה יוסתרו ממשתמשים בקורא מסך.
<p class="bullet" role="none">...</p>
בעיה 5: שדה בטופס
במודול Forms למדנו שכל השדות בטפסים חייבים לכלול גם תווית חזותית וגם תווית פרוגרמטית. התווית הזו צריכה להישאר גלויה תמיד.
בדמו שלנו, חסרה תווית חזותית וגם פרוגרמטית בשדה האימייל להרשמה לניוזלטר. יש רכיב של placeholder לטקסט, אבל הוא לא מחליף את התווית כי הוא לא נשאר גלוי באופן קבוע ולא תואם באופן מלא לכל קוראי המסך.
<form>
<div class="form-group">
<input type="email" placeholder="Enter your e-mail address" required>
<button type="submit">Subscribe</button>
</div>
</form>
כדי לפתור את הבעיה, צריך להחליף את placeholder הטקסט ברכיב תווית דומה. רכיב התווית מחובר באופן פרוגרמטי לשדה הטופס, והתנועה נוספה באמצעות JavaScript כדי שהתווית תישאר גלויה גם כשמוסיפים תוכן לשדה.
<form>
<div class="form-group">
<input type="email" required id="youremail" name="youremail" type="text">
<label for="youremail">Enter your e-mail address</label>
<button type="submit" aria-label="Subscribe to our newsletter">Subscribe</button>
</div>
</form>
סיכום
מעולה! השלמת את כל הבדיקות של ההדגמה הזו. אפשר לראות את כל השינויים האלה בCodepen המעודכן של הדגמה הזו.
עכשיו תוכלו להשתמש במה שלמדתם כדי לבדוק את הנגישות של האתרים והאפליקציות שלכם.
מטרת כל בדיקות הנגישות האלה היא לטפל בכמה שיותר בעיות שעלולות להיתקל בהן משתמשים. עם זאת, זה לא אומר שהאתר או האפליקציה יהיו נגישים בצורה מושלמת בסיום התהליך. כדי להפיק את התוצאות הטובות ביותר, כדאי לתכנן את האתר או האפליקציה עם דגש על נגישות לאורך כל התהליך, ולשלב את הבדיקות האלה בבדיקות האחרות שלכם לפני ההשקה.
בדיקת ההבנה
בדיקת הידע שלכם בנושא בדיקות נגישות אוטומטיות.
איזה קורא מסך הכי מתאים לבדיקה של נגישות?
מהי מטרת הבדיקה באמצעות טכנולוגיה מסייעת?