בדיקת טכנולוגיה מסייעת

מודול זה מתמקד בשימוש בטכנולוגיה מסייעת (AT) לבדיקת נגישות. אנשים עם מוגבלויות יכולים להיעזר ב-AT כדי להגדיל את היכולות, לשמור עליהן או לשפר אותן.

במרחב הדיגיטלי, ATs יכולים להיות:

• לא/פחות בסיסי: מקלות ראש/פה, זכוכית מגדלת שמוחזקת ביד, מכשירים עם לחצנים גדולים
• היי-טק: מכשירים שמופעלים באמצעות קול, מכשירי מעקב אחר העין, מקלדות/עכברים שניתנים להתאמה
• חומרה: לחצני מתג, מקלדות ארגונומיות, מכשיר ברייל שמתרענן אוטומטית
• תוכנה: תוכניות המרת טקסט לדיבור, כתוביות מיידיות, קוראי מסך

אנחנו ממליצים להשתמש בכמה סוגים של AT בתהליך העבודה הכולל של הבדיקה.

מידע בסיסי על בדיקת קוראי מסך

במודול הזה נתמקד באחד מהקוראים הדיגיטליים הפופולריים ביותר, קוראי מסך. קורא מסך הוא תוכנה שקוראת את הקוד הבסיסי של אתר או אפליקציה. לאחר מכן, קורא המסך ממיר את המידע הזה לדיבור או לפלט ברייל עבור המשתמש.

קוראי מסך חיוניים לאנשים עיוורים ולעיוורים, אבל הם יכולים להועיל גם לאנשים עם ליקויי ראייה, הפרעות קריאה או לקויות קוגניטיביות.

תאימות דפדפן

יש כמה אפשרויות לקורא מסך. קוראי המסך הפופולריים ביותר כיום הם JAWS, NVDA ו-VoiceOver למחשבים שולחניים, ו-VoiceOver ו-Talkback למכשירים ניידים.

בהתאם למערכת ההפעלה (OS), לדפדפן המועדף ולמכשיר שבו אתם משתמשים, קורא מסך אחד עשוי לבלוט כאופציה הטובה ביותר. רוב קוראי המסך בנויים מתוך מחשבה על חומרה ודפדפני אינטרנט ספציפיים. כשמשתמשים בקורא מסך עם דפדפן שלא כוויל, יכול להיות שיופיעו עוד "באגים" או התנהגות לא צפויה. קוראי מסך פועלים בצורה הטובה ביותר כשמשתמשים בהם בשילובים הבאים.

פקודות לקורא מסך

לאחר ההגדרה של תוכנת קורא המסך למחשב השולחני או למכשיר הנייד, עליך לעיין בתיעוד של קורא המסך (הקישור מופיע בטבלה הקודמת) ולעבור על כמה פקודות חיוניות לקורא מסך כדי להכיר את הטכנולוגיה הרלוונטית. אם השתמשת בעבר בקורא מסך, כדאי לנסות קורא מסך חדש!

כשמשתמשים בקורא מסך לבדיקת נגישות, המטרה היא לזהות בעיות בקוד שמפריעות לשימוש באתר או באפליקציה, ולא ליצור אמולציה של חוויית המשתמש בקורא מסך. לכן, אפשר לעשות הרבה דברים עם ידע בסיסי, כמה פקודות של קוראי מסך וקצת תרגול.

אם אתם צריכים להבין יותר לעומק את חוויית המשתמש של אנשים שמשתמשים בקוראי מסך ובנתוני AT אחרים, אתם יכולים לפנות לארגונים ולאנשים פרטיים כדי לקבל את התובנה החשובה הזו. חשוב לזכור שבמקרים רבים, שימוש ב-AT לבדיקת קוד מול קבוצה של כללים ובירור על החוויה שלהם מניב תוצאות שונות. שני המאפיינים הם היבטים חשובים ביצירת מוצרים שכוללים את כל המוצרים שלנו.

פקודות המקשים לקוראי מסך במחשב

פקודות מרכזיות לקוראי מסך בנייד

הדגמה לבדיקה של קורא המסך

כדי לבדוק את ההדגמה שלנו, השתמשנו ב-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 בקטעים של המחלות הנדירות. למרות שזו לא התמונה מקובלת שהסברנו במודול של Google Photos, בכל זאת צריך לשנות אותה כי היא משבשת את זרימת התוכן ועלולה להסיח את דעתו של המשתמש בקורא מסך או לבלבל אותו.

<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 המעודכן להדגמה הזו.

עכשיו תוכלו להיעזר במה שלמדתם כדי לבדוק את הנגישות של האתרים והאפליקציות שלכם.

המטרה של כל בדיקות הנגישות האלה היא לטפל בכמה שיותר בעיות שמשתמשים עשויים להיתקל בהן. עם זאת, זה לא אומר שהאתר או האפליקציה שלכם יהיו נגישים באופן מושלם בסיום. כדי להשיג את התוצאות הטובות ביותר, תכננו את האתר או האפליקציה שלכם בהתאם לנגישות לאורך התהליך, ותשלבו את הבדיקות האלה בבדיקות אחרות טרום-השקה.

בדיקת ההבנה

בחינת הידע שלכם לגבי בדיקות נגישות אוטומטיות