מבוא לעץ הנגישות
נניח שאתם יוצרים ממשק משתמש למשתמשים בקורא מסך בלבד. כאן לא צריך ליצור ממשק משתמש ויזואלי, אלא רק לספק מספיק מידע כדי שקורא המסך יוכל להשתמש בו.
מה שתיצרו הוא סוג של ממשק API שמתאר את מבנה הדף, בדומה ל-DOM API, אבל אפשר להמשיך עם פחות מידע ופחות צמתים, כי הרבה מהמידע הזה שימושי רק להצגה חזותית. הוא עשוי להיראות כך.
![הדמיה של קורא מסך DOM API](https://web.developers.google.cn/static/articles/the-accessibility-tree/image/screen-reader-dom-api-moc-86f15b848dd25.jpg?authuser=9&hl=he)
בעיקרון, זה מה שהדפדפן מציג בפועל לקורא המסך. הדפדפן לוקח את עץ ה-DOM ומשנה אותו לצורה שימושית לטכנולוגיה מסייעת. העץ שהשתנה הזה נקרא עץ הנגישות.
אפשר לדמות את עץ הנגישות כאל דף אינטרנט ישן משנות ה-90 של המאה ה-20: מספר תמונות, הרבה קישורים, אולי שדה ולחצן.
![דף אינטרנט בסגנון שנות ה-90](https://web.developers.google.cn/static/articles/the-accessibility-tree/image/a-1990s-style-web-page-71a74592e602e.png?authuser=9&hl=he)
סריקה חזותית של דף כמו בדוגמה הזו מספקת חוויה שדומה לזו שמשתמש קורא מסך יקבל. יש ממשק כזה, אבל הוא פשוט וישיר, בדומה לממשק עץ נגישות.
עץ הנגישות הוא המקום שבו רוב הטכנולוגיות המסייעות פועלות איתן. הזרימה מתחילה בערך כך.
- אפליקציה (הדפדפן או אפליקציה אחרת) חושפת גרסה סמנטית של ממשק המשתמש שלה לטכנולוגיה מסייעת באמצעות API.
- הטכנולוגיה המסייעת עשויה להשתמש במידע שהיא קוראת דרך ה-API כדי ליצור מצגת חלופית של ממשק המשתמש למשתמש. לדוגמה, קורא מסך יוצר ממשק שבו המשתמש שומע ייצוג קולי של האפליקציה.
- הטכנולוגיה המסייעת עשויה גם לאפשר למשתמש לבצע אינטראקציה עם האפליקציה בדרך אחרת. לדוגמה, רוב קוראי המסך כוללים קטעי הוק כדי לאפשר למשתמש לדמות בקלות לחיצה על העכבר או הקשה באצבע.
- הטכנולוגיה המסייעת מעבירה את כוונת המשתמש (למשל "קליק") בחזרה לאפליקציה דרך ממשק ה-API לנגישות. לאחר מכן, האפליקציה צריכה לפרש את הפעולה כראוי בהקשר של ממשק המשתמש המקורי.
יש שלב נוסף בכל כיוון עבור דפדפני אינטרנט, כי הדפדפן הוא למעשה פלטפורמה של אפליקציות אינטרנט שפועלות בתוכו. לכן, הדפדפן צריך לתרגם את אפליקציית האינטרנט לעץ נגישות, ולוודא שהאירועים המתאימים מופעלים ב-JavaScript על סמך פעולות המשתמש שמגיעות מהטכנולוגיה המסייעת.
אבל זה כל האחריות של הדפדפן. התפקיד שלנו כמפתחי אתרים הוא להיות מודעים לכך שזה קורה, ולפתח דפי אינטרנט שמנצלים את היתרונות של התהליך הזה כדי ליצור חוויה נגישה למשתמשים שלנו.
לשם כך, אנחנו מוודאים שאנחנו מביעים נכון את הסמנטיקה של הדפים שלנו: מוודאים שלרכיבים החשובים בדף יש את התפקידים, המצבים והמאפיינים הנגישים הנכונים, ושאנחנו מציינים שמות ותיאורים נגישים. לאחר מכן הדפדפן יכול לאפשר לטכנולוגיה המסייעת לגשת למידע הזה כדי ליצור חוויה מותאמת אישית.
סמנטיקה ב-HTML מקורי
דפדפן יכול להפוך את עץ ה-DOM לעץ נגישות כי לרוב ה-DOM יש משמעות סמנטית משתמעת. כלומר, ה-DOM משתמש ברכיבי HTML מקוריים שמזוהים על ידי דפדפנים ופועלים באופן צפוי במגוון פלטפורמות. הנגישות לרכיבי HTML מקוריים, כמו קישורים או לחצנים, מנוהלת באופן אוטומטי. אנחנו יכולים לנצל את הנגישות המובנית הזו על ידי כתיבת HTML שמבטא את הסמנטיקה של רכיבי הדף שלנו.
עם זאת, לפעמים אנחנו משתמשים ברכיבים שנראים כמו רכיבים מקוריים, אבל בפועל הם אינם. לדוגמה, ה'לחצן' הזה הוא לא לחצן בכלל.
ניתן ליצור אותם ב-HTML בכמה דרכים שונות. אחת הדרכים מוצגת בהמשך.
<div class="button-ish">Give me tacos</div>
כשאנחנו לא משתמשים ברכיב לחצן, קורא המסך לא יכול לדעת למה הוא נחת. בנוסף, נצטרך לעשות את העבודה הנוספת בהוספת Tabindex כדי שיהיה אפשר להשתמש בו גם למשתמשים עם מקלדת בלבד, כי כמו שהוא מקודד עכשיו, אפשר להשתמש בו רק עם עכבר.
אפשר לתקן את הבעיה בקלות באמצעות רכיב button
רגיל במקום div
.
לשימוש באלמנט נייטיב יש גם יתרון בכך שאנחנו מטפלים באינטראקציות עם המקלדת. חשוב לזכור שאתם לא צריכים לאבד את האפקטים החזותיים המהודרים שלכם רק בגלל שאתם משתמשים באלמנט מקורי. אפשר לסגנן רכיבים מקוריים כך
שהם ייראו כמו שאתם רוצים, ועדיין לשמור על הסמנטיקה וההתנהגות המרומזת.
מוקדם יותר ציינו שקוראי מסך מכריזים על התפקיד, השם, המצב והערך של הרכיב. על ידי שימוש ברכיב הסמנטי, התפקיד, המצב והערך הנכונים, אנחנו גם צריכים לוודא ששם הרכיב יהיה גלוי.
באופן כללי, יש שני סוגים של שמות:
- תוויות גלויות, שבהן כל המשתמשים משתמשים כדי לשייך משמעות לרכיב
- חלופות טקסט, שבהן משתמשים רק כשאין צורך בתווית ויזואלית.
לגבי אלמנטים ברמת הטקסט, אין צורך לעשות דבר, כי מעצם הגדרתו הוא יכיל תוכן טקסטואלי. עם זאת, עבור רכיבי קלט או בקרה, ותוכן חזותי כמו תמונות, אנחנו צריכים לוודא שאנחנו מציינים שם. למעשה, אספקת חלופות טקסט לכל תוכן שאינו טקסט היא הפריט הראשון ברשימת המשימות של WebAIM.
אחת הדרכים לעשות זאת היא לפעול בהתאם להמלצה שלהם: "לקלט של טופס יש תוויות טקסט משויכות". יש שתי דרכים לשייך תווית לרכיב טופס, למשל תיבת סימון. כל אחת מהשיטות גורמת לטקסט של התווית להפוך גם ליעד לחיצה של תיבת הסימון, וזה שימושי גם למשתמשים בעכבר או במסך מגע. כדי לשייך תווית לרכיב,
- הצבת רכיב הקלט בתוך רכיב תווית
<label> <input type="checkbox">Receive promotional offers? </label>
או
- צריך להשתמש במאפיין
for
של התווית ולהתייחס ל-id
של האלמנט
<input id="promo" type="checkbox">
<label for="promo">Receive promotional offers?</label>
אם התיבה מסומנת בצורה נכונה, קורא המסך יכול לדווח שלרכיב יש תפקיד 'תיבת סימון', שהוא במצב מסומן ונקרא 'לקבל הצעות לקידום מכירות?'.
![פלט טקסט מ-VoiceOver שמוצג במסך ומופיעה בו התווית שמסומנת בתיבת סימון](https://web.developers.google.cn/static/articles/the-accessibility-tree/image/on-screen-text-output-vo-2bf0c33d65f23.png?authuser=9&hl=he)