יחידת הלימוד הזו מתמקדת בשימוש בטכנולוגיה מסייעת (AT) לבדיקת הנגישות. אנשים עם מוגבלויות יכולים להיעזר ב-AT כדי לשפר, לתחזק או לשפר את היכולות לביצוע משימות.
במרחב הדיגיטלי, סוכנויות פרסום יכולות להיות:
- ללא טכנולוגיה או טכנולוגיה בסיסית: מוטות לראש ולפה, מגדילים ידניים, מכשירים עם לחצנים גדולים
- טכנולוגיה מתקדמת: מכשירים המופעלים באמצעות קול, מכשירים למעקב אחר תנועות עיניים, מקלדות ועכברים מותאמים אישית
- חומרה: לחצני מתג, מקלדות ארגונומיות, מכשיר ברייל ברענון אוטומטי
- תוכנה: תוכנות המרת טקסט לדיבור, כתוביות מיידיות, קוראי מסך
מומלץ להשתמש בכמה סוגים של בדיקות AT בתהליך הבדיקה הכולל.
יסודות של בדיקות קורא מסך
במודול הזה נעסוק באחד מהכלים הדיגיטליים הפופולריים ביותר לתמיכה בטכנולוגיה, קוראי מסך. קורא מסך הוא תוכנה שקוראת את הקוד הבסיסי של אתר או אפליקציה. לאחר מכן, הוא ממיר את המידע הזה לפלט דיבור או ברייל בשביל המשתמש.
קוראי מסך חיוניים לאנשים עיוורים ולאנשים עם עיוורון ודיסלקציה, אבל הם יכולים להועיל גם לאנשים עם לקות ראייה, הפרעות קריאה וליקויים קוגניטיביים.
תאימות דפדפן
יש כמה אפשרויות של קוראי מסך. קוראי המסך הפופולריים ביותר הם JAWS, NVDA ו-VoiceOver למחשבים, ו-VoiceOver ו-Talkback למכשירים ניידים.
בהתאם למערכת ההפעלה (OS), לדפדפן המועדף ולמכשיר שבו אתם משתמשים, קורא מסך אחד עשוי להתבלט בתור האפשרות הטובה ביותר. רוב קוראי המסך תוכננו תוך התמקדות בחומרה ובדפדפני אינטרנט ספציפיים. כשמשתמשים בקורא מסך עם דפדפן שלא בוצעה לו כיול, יכול להיות שתבחינו ביותר 'באגים' או בהתנהגות בלתי צפויה. קוראי המסך פועלים בצורה הטובה ביותר בשילובים הבאים.
| קורא מסך | מערכת ההפעלה | תאימות דפדפן |
|---|---|---|
| Job Access With Speech (JAWS) | Windows | Chrome, Firefox, Edge |
| גישה לא-ויזואלית למחשב (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 |
| ציוני דרך | י | Control+Option+U |
| כותרות | מחצית | Control+Option+Command+H |
| קישורים | K | Control+Option+Command+L |
| פקדי טופס | Control+Option+Command+J | |
| טבלאות | T | Control+OptionCommand+T |
| בטבלאות | InsertAlt + ↓ ↑ ← → | 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 המעודכן של הדגמה הזו.
עכשיו תוכלו להשתמש במה שלמדתם כדי לבדוק את הנגישות של האתרים והאפליקציות שלכם.
מטרת כל בדיקות הנגישות האלה היא לטפל בכמה שיותר בעיות שעלולות להיתקל בהן משתמשים. עם זאת, זה לא אומר שהאתר או האפליקציה יהיו נגישים לחלוטין בסיום התהליך. כדי להשיג את התוצאות הטובות ביותר, מעצבים את האתר או האפליקציה עם נגישות לאורך התהליך, ומשלבים את הבדיקות האלה עם בדיקות אחרות לפני ההשקה.
בדיקת ההבנה
בחינת הידע שלכם לגבי בדיקות נגישות אוטומטיות
מהו קורא המסך הטוב ביותר לבדיקת הנגישות?
מהי מטרת הבדיקה באמצעות טכנולוגיה מסייעת?