המודול הזה מתמקד בשימוש בטכנולוגיה מסייעת (AT) לבדיקת נגישות. אדם עם מוגבלות יכול להשתמש בטכנולוגיה מסייעת כדי להגדיל, לשמור או לשפר את היכולות שלו לבצע משימה.
במרחב הדיגיטלי, טכנולוגיות מסייעות יכולות להיות:
- טכנולוגיה נמוכה או ללא טכנולוגיה: מקלות לראש ולפה, זכוכית מגדלת ידנית, מכשירים עם לחצנים גדולים
- טכנולוגיה מתקדמת: מכשירים בהפעלה קולית, מכשירים למעקב אחר תנועות העיניים, מקלדות ועכברים אדפטיביים
- חומרה: לחצני מתג, מקלדות ארגונומיות, מכשיר ברייל עם רענון אוטומטי
- תוכנה: תוכניות להמרת טקסט לדיבור, כתוביות מיידיות, קוראי מסך
מומלץ להשתמש בכמה סוגים של כלים אוטומטיים בתהליך הבדיקה הכולל.
הבסיס לבדיקות של קורא מסך
במודול הזה נתמקד באחד מהטכנולוגיות המסייעות הדיגיטליות הפופולריות ביותר – קוראי מסך. קורא מסך הוא תוכנה שקוראת את קוד הבסיס של אתר או אפליקציה. לאחר מכן היא ממירה את המידע הזה לדיבור או לפלט ברייל עבור המשתמש.
קוראי מסך חיוניים לעיוורים ולעיוורים חירשים, אבל הם יכולים לעזור גם לאנשים עם לקויות ראייה, הפרעות קריאה ומוגבלויות קוגניטיביות.
תאימות דפדפן
יש כמה אפשרויות לקוראי מסך. קוראי המסך הפופולריים ביותר הם JAWS, NVDA ו-VoiceOver למחשבים, ו-VoiceOver ו-Talkback למכשירים ניידים.
קורא מסך אחד עשוי להיות האפשרות הטובה ביותר, בהתאם למערכת ההפעלה, לדפדפן המועדף ולמכשיר שבו אתם משתמשים. רוב קוראי המסך מיועדים לחומרה ולדפדפני אינטרנט ספציפיים. כשמשתמשים בקורא מסך עם דפדפן שלא בוצעה בו כיול, יכול להיות שתיתקלו ביותר "באגים" או בהתנהגות לא צפויה. קוראי המסך פועלים בצורה הטובה ביותר כשמשתמשים בהם בשילובים הבאים.
| קורא מסך | מערכת ההפעלה | תאימות דפדפן |
|---|---|---|
| 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) |
|---|---|---|
| מקשי קיצור כלליים | הוספה | 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 המוטבע שמשמש כתמונת הפתיחה הראשית בדף ההדגמה שלנו. עם זאת, קורא המסך מוצא את התמונה ומכריז עליה כ'תמונה' בלי מידע נוסף.
זה נכון גם אם לא מוסיפים במפורש את המאפיין 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 עם המחלקה bullet כדי להסתיר אותה מקורא המסך. באופן דומה, אפשר להשתמש ב-role="none". חשוב לא להשתמש בתווית aria-hidden: true, אחרת תסתירו את כל המידע בפסקה ממשתמשים בקורא מסך.
<p class="bullet" role="none">...</p>
בעיה 5: שדה בטופס
במודול טפסים למדנו שכל שדות הטופס צריכים לכלול גם תווית חזותית וגם תווית פרוגרמטית. התווית הזו צריכה להיות גלויה תמיד.
בהדגמה שלנו, חסרה לנו תווית חזותית ותווית פרוגרמטית בשדה של כתובת האימייל להרשמה לניוזלטר. יש רכיב של placeholder לטקסט, אבל הוא לא מחליף את התווית כי הוא לא מוצג באופן קבוע ולא תואם באופן מלא לכל קוראי המסך.
<form>
<div class="form-group">
<input type="email" placeholder="Enter your e-mail address" required>
<button type="submit">Subscribe</button>
</div>
</form>
כדי לפתור את הבעיה, צריך להחליף את הפלייסהולדר של הטקסט ברכיב תווית שנראה דומה. רכיב התווית הזה מחובר באופן פרוגרמטי לשדה הטופס, והוספנו תנועה באמצעות 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 המעודכן של ההדגמה הזו.
עכשיו אפשר להשתמש במה שלמדתם כדי לבדוק את הנגישות של האתרים והאפליקציות שלכם.
המטרה של כל בדיקות הנגישות האלה היא לטפל בכמה שיותר בעיות שמשתמשים עלולים להיתקל בהן. עם זאת, זה לא אומר שהאתר או האפליקציה שלכם יהיו נגישים באופן מושלם אחרי שתסיימו את התהליך. כדי להשיג את התוצאות הטובות ביותר, מומלץ לתכנן את האתר או האפליקציה עם נגישות לאורך כל התהליך, ולשלב את הבדיקות האלה עם בדיקות אחרות לפני ההשקה.