כלי הפיתוח של Chrome משיקים עץ נגישות מלא, שיעזור למפתחים לקבל סקירה כללית של העץ כולו. בפוסט הזה תוכלו לקרוא איך נוצר העץ הזה ואיך להשתמש בו בעבודה.
מהו עץ הנגישות?
טכנולוגיה מסייעת כמו קוראי מסך משתמשת בממשק ה-API לנגישות של Chromium כדי לבצע אינטראקציה עם תוכן באינטרנט. המודל הבסיסי של ה-API הזה הוא עץ הנגישות: עץ של אובייקטים של נגישות שטכנולוגיה מסייעת יכולה להריץ בו שאילתות לגבי מאפיינים ומאפיינים משניים ולבצע בו פעולות. מפתחי אתרים מעצבים את עץ הנגישות ומשנים אותו בעיקר באמצעות מאפייני DOM, כמו מאפייני ARIA ל-HTML.
בכלי הפיתוח של Chrome, אנחנו מספקים את חלונית הנגישות כדי לעזור למפתחים להבין איך התוכן שלהם חשוף לטכנולוגיה מסייעת. באופן ספציפי, כשבוחרים צומת בתצוגת עץ ה-DOM, הנכסים של צומת הנגישות התואם מוצגים בחלונית יחד עם תצוגה של הצמתים האב של הצומת והצאצאים המיידיים שלו.
איך נוצר העץ?
לפני שנראה איך נראית תצוגת העץ המלאה החדשה ב-DevTools, ננסה להסביר בקצרה מהו עץ הנגישות במונחים מוחשי יותר. עץ הנגישות הוא נגזרת של עץ ה-DOM. המבנה שלו די דומה, אבל פשוט יותר להסיר צמתים ללא תוכן סמנטי, כמו רכיב <div> שמשמש אך ורק לעיצוב. לכל צומת בעץ יש תפקיד, כמו Button או Heading, ולרוב גם שם שיכול להיות מאפייני ARIA או נגזר מהתוכן של הצומת. אם אנחנו מסתכלים על מסמך HTML:
<html>
<head>
<title>How old are you?</title>
</head>
<body>
<label for="age">Age</label>
<input id="age" type="number" name="age" value="42">
<div>
<button>Back</button>
<button>Next</button>
</div>
</body>
</html>
המנגנון להצגת תוכן ב-Chromium, שנקרא Blink, יוצר עץ פנימי של נגישות באופן הבא, בערך.
role='rootWebArea' focusable name='How old are you?'
role='genericContainer' ignored
role='genericContainer' ignored
role='labelText'
role='staticText' name='Age'
role='spinButton' editable focusable name='Age' value='42'
role='genericContainer' editable
role='staticText' editable name='42'
role='genericContainer'
role='button' focusable name='Back'
role='staticText' name='Back'
role='button' focusable name='Next'
role='staticText' name='Next'
שימו לב שהייצוג הזה מכיל כמה צמתים מיותרים עם התפקיד genericContainer, שנראה שהוא סותר את ההצהרה שלמעלה על כך שעץ הנגישות הוא נגזרת פשוטה של עץ ה-DOM. עם זאת, רוב הצמתים האלה מופיעים רק בעץ הפנימי ולא יהיו חשופים לטכנולוגיה מסייעת. מאחר שכלי הפיתוח אוספים את פרטי הנגישות ישירות מתהליך היצירה, זוהי ייצוג העץ שכלי הפיתוח מטפל בו.
עץ נגישות מלא בכלי הפיתוח
עץ הנגישות החדש והמלא מסתנכרן עם עץ ה-DOM, כך שהמפתחים יכולים לעבור בין שני העצים. אנחנו מקווים שהעץ החדש יהיה קל יותר לגילוי, שימושי וקל יותר לשימוש.
עכשיו, אחרי שהסברנו איך פועל עץ הנגישות, אפשר להשתמש בכלי הפיתוח כדי לראות איך נראית תצוגת העץ החדשה. מסמך ה-HTML הבא עם כותרת, כותרת משנית ושני לחצנים משמש להצגת העץ.
<!DOCTYPE html>
<title>Test</title>
<h1>Heading for example page</h1>
<div>
<button>Back</button>
<button>Next</button>
</div>
בתצוגת העץ הקודמת אפשר לחקור רק צומת אחד ואת ישות האב שלו.
עכשיו, כשמחליפים את ��מצב של העץ החדש, הוא מחליף את תצוגת עץ ה-DOM ומאפשר לראות את עץ הנגישות המלא של הדף:
יצירת עץ ביעילות
כדי שהעצים ישיגו ביצועים טובים גם באתרים גדולים יותר, העץ נבנה באופן מדורג בקצה הקדמי בזמן שחוקרים אותו. אחרי שמרחיבים צומת בעץ, הילדים של הצמתים מאוחזרים דרך פרוטוקול Chrome DevTools (CDP) והעץ נבנה מחדש.
בשידור חי
תצוגת העץ החדשה פעילה ומתעדכנת באופן דינמי אם עץ הנגישות משתנה במעבד הגרפיקה. הוא מתחבר לאותה מכניקה שמעדכנת את הטכנולוגיה המסייעת לגבי שינויים בעץ, ומשתמש בה כדי לשלוח אירועים לקצה הקדמי של DevTools עם צמתים מעודכנים. בפועל, הקצה העורפי של ה-CDP מאזין לעדכונים בעץ, עוקב אחרי הצמתים שנשלחו בעבר ושולח אירועים לממשק הקדמי של כלי הפיתוח אם אחד מהצמתים האלה משתנה.
הסיפור של הרבה עצים
בתיאור של מהו עץ הנגישות, למדתם איך Blink יוצרת עץ נגישות ל-DOM שהיא מבצעת רינדור שלו, וכיצד DevTools מאחזרת את העץ הזה דרך CDP. זה נכון, אבל השמטנו כמה סיבוכים בתיאור הזה. למעשה, יש הרבה דרכים שונות להשתמש בעץ הנגישות ב-Chromium. בתהליך העיצוב של תצוגת העץ החדשה ב-DevTools, עשינו כמה בחירות לגבי החלק של הרכיבים הפנימיים של Chromium שרצינו להציג.
פלטפורמות
לכל פלטפורמה יש ממשק API שונה לנגישות. צורת העץ זהה בכל הפלטפורמות, אבל ממשק ה-API לאינטראקציה עם העץ שונה, ושמות המאפיינים יכולים להיות שונים. ב-DevTools מוצג העץ הפנימי של Chromium, שבו התפקידים והמאפיינים בדרך כלל תואמים לאלה שמוגדרים במפרט ARIA.
מסגרות מרובות ובידוד של אתר
ב-Chromium, התוכן של כל כרטיסייה לא רק מועבר לתהליכי עיבוד גרפי שונים, אלא גם מופרד ממסמכים באתרים אחרים בתהליכי עיבוד גרפי שונים. לכן אנחנו צריכים להתחבר בנפרד לכל מסמך צאצא מחוץ לתהליך דרך CDP ולאחזר את עץ הנגישות שלו. לאחר מכן אנחנו מחברים את עצי המשנה האלה יחד בחזית כדי ליצור את האשליה של עץ אחד עקבי, למרות שהם נמצאים בתהליכי עיבוד גרפי שונים ב-Chromium.
צמתים שלא נלקחו בחשבון וצמתים לא מעניינים
אנחנו מסתירים חלק מהצומתים כברירת מחדל: צמתים שנדחו וצמתים עם התפקיד 'גנרי' ללא שם. הצמתים האלה לא מכילים משמעות סמנטית, ובמקרה של צמתים שנדחו, הם לא חשופים לטכנולוגיה מסייעת. אנחנו מסתירים את הצמתים האלה כדי למנוע עומס בתצוגת העץ. אם לא, עץ הנגישות עבור רוב דפי האינטרנט ייראה כך:
האזהרה הזאת היא שלמעשה, המשמעות היא שאנחנו צריכים לבנות עץ נוסף מזה שזמין בקצה העורפי. לדוגמה, נניח שיש לנו את הצמתים A, B, C ו-X שבהם A הוא צאצא X ו-B, ול-X יש את צאצא ג'. אם X הוא צומת שנדחה, אנחנו מסירים את X מהעץ ובמקום זאת יוצר��ם ��ץ ��בו C ��וא צ��צא של A.
בחזית, אנחנו יוצרים את העץ המלא, כולל צמתים שנדחו, ורק מסירים אותם ממש לפני שאנחנו מייצגים את הצמתים. אנחנו עושים זאת משתי סיבות:
- קל יותר לטפל בעדכוני צמתים מהקצה העורפי, כי יש לנו את אותו מבנה עץ בשתי נקודות הקצה. לדוגמה, אם הצומת B יוסר מהדוגמה, נקבל עדכון לצומת X (כי הצאצאים שלו השתנו), אבל אם נחסם את הצומת הזה, יהיה לנו קשה להבין מה צריך לעדכן.
- הוא מבטיח שלכל צומתי ה-DOM יהיה צומת נגישות תואם. כשמפעילים את העץ, אנחנו בוחרים את הצומת התואם לצומת שנבחר כרגע בעץ ה-DOM. לדוגמה הקודמת, אם המשתמש מפעיל או משבית את העץ בזמן שצוין צומת ה-DOM התואם ל-X, אנחנו מזריקים את X בין הצמתים A ו-B ובוחרים את X בעץ. כך המשתמש יכול לבדוק את צומת הנגישות עבור כל צומתי ה-DOM ולהבין למה המערכת מתעלמת מהצומת.
רעיונות לעתיד
הפעלת עץ הנגישות החדש היא רק ההתחלה. יש לנו כמה רעיונות לפרויקטים עתידיים שאפשר להוסיף לתצוגה החדשה, אבל נשמח גם לשמוע את המשוב שלך.
מסננים חלופיים
כפי שהוסבר למעלה, אנחנו מסננים כרגע צמתים שנחשבים לא מעניינים. אנחנו יכולים לספק דרך להשבית את ההתנהגות הזו ולהציג את כל הצמתים, או לספק סינונים חלופיים כמו הצגת צמתים של ציוני דרך או הצגת כותרות.
הדגשת בעיות נגישות
אפשר לשלב בעץ ניתוח של 'שיטות מומלצות לנגישות' ולהדגיש בעיות נגישות ישירות בצמתים הבעייתיים.
הצגת פעולות נגישות ב-DevTools
העץ שאנחנו מציגים כרגע הוא חד-כיווני בלבד: הוא מאפשר לנו לקבל מושג לגבי המידע שיוזן בטכנולוגיה המסייעת בזמן גלישה בדף אינטרנט ספציפי. פעולות הנגישות מייצגות את התקשורת בכיוון ההפוך: הן מאפשרות לטכנולוגיה מסייעת לפעול בממשק המשתמש המוצג. אנחנו יכולים להציג פעולות כאלה בכלי הפי��וח כדי לאפשר פעולות כמו 'לחיצה', גלילה או שינוי ערכים בדף באמצעות ה-API שזמין לטכנולוגיה מסייעת.