ARIA: רעל או נוגדנים?

Aaron Leventhal

מה זה ARIA?

ARIA מאפשרת לכותבי אתרים ליצור מציאות חלופית שרק קוראי המסך יכולים לראות.

לפעמים צריך להרחיב את האמת או אפילו "לשקר" כדי לסנן את הקוראים לגבי מה שקורה בתוכן באינטרנט. לדוגמה, "focus is really over here!" או "this is really a slider!". זה כמו להוסיף פתקים דביקים קסומים מעל הכלים והווידג'טים במשטח העבודה. עם התווית המגנטית הזו, כולם יאמינו למה שכתוב עליה.

כשיש פתק דביק קסום, הוא משנה את התפיסה שלנו לגבי מה שכל כלי עושה. לדוגמה, אם מוסיפים ARIA עם הכיתוב "this thing over here is a glue gun!". למרות שמדובר בקופסה כחולה ריקה, פתק ההערה הקסום מראה שזוהי אקדח דבק. אפשר גם להוסיף "והיא מלאה ב-30%". קורא המסך מדווח עכשיו שיש אקדח דבק מלא ב-30%.

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

ARIA לא משפיעה על המראה של דף אינטרנט או על ההתנהגות של משתמש בעכבר או במקלדת. רק משתמשים בטכנולוגיות מסייעות יכולים להבחין בהשפעה של ARIA. מפתחי אתרים יכולים להוסיף כל רכיב ARIA שרירותי בלי להשפיע על משתמשים שלא משתמשים בטכנולוגיה מסייעת.

כן, קראתם נכון: ARIA לא עושה שום דבר בפועל להעברת המיקוד במקלדת או לסדר המעבר באמצעות Tab. כל זה נעשה ב-HTML, ולפעמים עם קצת JavaScript.

איך פועלת ARIA?

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

ריכזנו כאן כמה שימושים נפוצים ב-ARIA.

• להוסיף רכיבים מיוחדים שלא קיימים ב-HTML, כמו השלמה אוטומטית, עץ או גיליון אלקטרוני.
• הוספת רכיבים שקיימים ב-HTML, אבל המחבר החליט לחדש אותם, אולי כי הוא רצה לשנות את ההתנהגות או את המראה של הרכיב הרגיל. לדוגמה, רכיב HTML‏ <input type="range"> הוא בעצם פס הזזה, אבל המחברים רוצים לשנות את המראה שלו.
  • ברוב המקרים, אפשר לטפל בבעיה הזו באמצעות CSS. עם זאת, עבור range, ה-CSS הוא awkwARD. המחברים יכולים ליצור פס מחליק משלהם ולהשתמש ב-role="slider" יחד עם aria-valuenow כדי להודיע למקלדת מה הערך הנוכחי.
• כדאי לכלול אזורים פעילים כדי להודיע לקוראי המסך על שינויים רלוונטיים באזור מסוים בדף.
• ליצור ציוני דרך, כמו כותרות. מאפייני ARIA עוזרים למשתמשים בקורא מסך למצוא מה שהם מחפשים מהר יותר. אתרים מפורסמים יכולים לכלול אזור קשור שלם. לדוגמה, "הקונטיינר הזה הוא האזור הראשי של הדף" ו "הקונטיינר הזה הוא חלונית ניווט".

למה כדאי להשתמש ב-ARIA?

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

דוגמה לסרגל תפריטים

נניח שבחנות האינטרנט המקומית לא נמכרים כל הווידג'טים שאנחנו צריכים. אבל אנחנו MacGyver. אנחנו יכולים פשוט ליצור ווידג'טים משלכם מווידג'טים אחרים! זה דומה למצב שבו מחבר אינטרנט צריך ליצור שורת תפריט.

אמנם רכיב <nav> קיים, אבל לרוב סרחי התפריטים מורכבים באמצעות div, תמונות, לחצנים, טיפול באירועי לחיצה, טיפול באירועי הקשה על מקש ו-ARIA.

תמיכה במשתמשים בעכבר

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

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

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

כל זה לא נגיש במיוחד, כמו בדרך כלל באינטרנט.

הפיכת המקלדת של סרגל התפריטים לנגישה

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

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

• אם המשתמש ילחץ על מקש כיוון, נבדוק את התוכניות הפנימיות שלנו לסרגל התפריטים ונחליט איזה פריט תפריט פעיל חדש יוצג. נמחק את ההדגשות הנוכחיות ונדגיש את פריט התפריט החדש, כדי שהמשתמשים שרואים יוכלו לדעת איפה הם נמצאים. לאחר מכן, דף האינטרנט צריך לבצע קריאה ל-event.preventDefault() כדי למנוע מהדפדפן לבצע את הפעולה הרגילה (גלילה של הדף, במקרה הזה).
• אם המשתמש ילחץ על המקש Enter, נוכל להתייחס לכך כמו לקליק, ולבצע את הפעולה המתאימה (או אפילו לפתוח תפריט אחר).
• אם המשתמש לוחץ על מקש שצריך לבצע פעולה אחרת, שולחים אותו חזרה לדף. לדוגמה, אין צורך במקש Tab בסרגל התפריטים שלנו, אז אפשר להחזיר אותו למקומו. קשה לעשות את זה נכון. לדוגמה, בסרגל התפריטים צריך להשתמש במקשי החצים, אבל לא ב-Alt+חץ או ב-Command+חץ. אלה קיצורי דרך למעבר לדף הקודם ולדף הבא בהיסטוריית הגלישה בכרטיסייה בדפדפן. אם המחבר לא יהיה זהיר, סרגל התפריטים יאכל אותם. באגים מהסוג הזה מתרחשים לעיתים קרובות, ואנחנו עדיין לא התחלנו עם ARIA!

גישה של קורא מסך לסרגל התפריטים שלנו

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

אבל זה לא הוגן! סרגל התפריטים פועל בצורה תקינה אצל משתמש רואה.

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

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

הסבר על אב קדמון, הורה וצאצא

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

כשמשתמשים ב-aria-activedescendant כדי להצביע מסרגל התפריטים הממוקד לפריט תפריט ספציפי, קורא המסך יודע עכשיו לאן המשתמש עבר, אבל לא מידע נוסף על האובייקט. מה זה div בכלל? כאן נכנס לתמונה מאפיין התפקיד. אנחנו משתמשים ב-role="menubar" על הרכיב המכיל של הכול, ואז ב-role="menu" על קבוצות של פריטים, וב-role="menuitem" על … תרועת התזמורת … פריטי התפריט הנפרדים.

מה קורה אם פריט התפריט יכול להוביל לתפריט צאצא? המשתמש צריך לדעת את זה. משתמשים שרואים יכולים לראות תמונה קטנה של משולש בסוף התפריט, אבל קורא המסך לא יודע לקרוא תמונות באופן אוטומטי, לפחות בשלב הזה. אנחנו יכולים להוסיף את הסמל aria-expanded="false" לכל פריט תפריט שניתן להרחיב, כדי לציין שיש משהו שניתן להרחיב והוא לא מורחב. בנוסף, היוצרים צריכים להוסיף את התו role="none" למעלה מהמשולש img כדי לציין שהתוכן מיועד למטרות יופי בלבד. כך קורא המסך לא יקריא מידע מיותר על התמונה.

תיקון באגים במקלדת

הגישה למקלדת היא חלק מ-HTML הליבה, אבל קל לשנות אותה. לדוגמה:

• תיבת סימון שמשתמשת במקש הרווח כדי להפעיל או להשבית אותה, אבל המחבר שכח להפעיל את preventDefault(). עכשיו מקש הרווח מאפשר גם להחליף את המצב של תיבת הסימון וגם להזיז את הדף למטה, כפי שזו התנהגות ברירת המחדל של מקש הרווח בדפדפן.
• תיבת דו-שיח מודאלית של ARIA רוצה לפתות את הניווט באמצעות Tab להיכנס אליה. אם המחבר יטעה ולא יאשר באופן ספציפי את הלחצן Control‎ + Tab כדי לפתוח כרטיסייה חדשה בתיבת הדו-שיח, היא לא תפעל כצפוי.
• המחבר יוצר רשימת בחירה ומטמיע את המקשים למעלה ולמטה. עם זאת, המחבר עדיין צריך להוסיף את הלחצנים Home,‏ End,‏ PageUp,‏ PageDown או ניווט לפי האות הראשונה.

המחברים צריכים לפעול לפי דפוסים ידועים. מידע נוסף זמין בקטע מקורות מידע.

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

באגים במקלדת הם כמעט תמיד באגים בתוכן האינטרנט, במיוחד ב-HTML וב-JavaScript, ולא ב-ARIA.

למה יש כל כך הרבה?

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

אחרי הכל, אם המחבר לא משתמש מנוסה בקורא מסך, משהו ישתבש ב-ARIA. בדוגמה של סרגל התפריטים, יכול להיות שהמחבר חשב שצריך להשתמש בתפקיד 'option' כשהתפקיד הנכון הוא 'menuitem'. הם עלולים לשכוח להשתמש ב-aria-expanded, לשכוח להגדיר ולמחוק את aria-activedescendant בזמנים הנכונים או לשכוח להוסיף סרגל תפריטים שמכיל את שאר התפריטים. מה לגבי מספרי הפריטים בתפריט? בדרך כלל, קוראי מסך מציגים את הפריטים בתפריט עם הודעה כמו 'פריט 3 מתוך 5', כדי שהמשתמשים ידעו איפה הם נמצאים. בדרך כלל הדפדפן סופר אותם באופן אוטומטי, אבל במקרים מסוימים ובשילובים מסוימים של דפדפנים וקוראי מסך, יכול להיות שהמספרים ייחושבו באופן שגוי, והמחבר יצטרך לשנות את המספרים האלה באמצעות aria-posinset ו-aria-setsize.

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

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

סיכום

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

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

מקורות מידע נוספים

במסמך W3C's ARIA Authoring Practices מתוארים המאפיינים החשובים של הניווט באמצעות מקלדת בכל דוגמה, ומופיע קוד JavaScript, ‏ CSS ו-ARIA פעיל. הדוגמאות מתמקדות במה שעובד היום, ולא כוללות מידע על נייד.

מהו Accessibility API?

ממשק API לנגישות מאפשר לקורא מסך או לטכנולוגיה מסייעת אחרת לדעת מה נמצא בדף ומה קורה בו. דוגמאות לכך הן MSAA,‏ IA2 ו-UIA. לממשק API לנגישות יש שני חלקים:

• 'עץ' של אובייקטים שמייצג היררכיית מאגרים. לדוגמה, מסמך יכול להכיל כמה פסקאות. פסקה יכולה לכלול טקסט, תמונות, קישורים וקישוטי טקסט. לכל פריט בעץ האובייקטים יכולים להיות מאפיינים, כמו תפקיד (מה אני?), שם או תווית, ערך שהמשתמש הזין, תיאור ומצבים בוליאניים, כמו focusable,‏ focused,‏ required ו-checked. ARIA יכולה לשנות את כל אחד מהמאפיינים האלה.
  • קוראי מסך משתמשים בעץ כדי לעזור למשתמשים לנווט במצב מאגר וירטואלי, למשל "עכשיו עליך לעבור לכותרת הבאה".
• סדרה של אירועים שמתרחשים ומתארים שינויים בעץ, כמו "focus is now over here!". קורא המסך משתמש באירועים כדי לספר למשתמש מה קרה זה עתה. כשמתבצע שינוי חשוב בסימון HTML או ARIA, מתרחש אירוע שמספר לקורא המסך שמשהו השתנה.

HTML מתאים היטב לממשקי ה-API האלה לנגישות. כש-HTML לא מספיק, אפשר להוסיף ARIA כדי שהדפדפן יחליף את הסמנטיקה של ה-HTML לפני שליחת עץ האובייקטים או האירועים לקורא המסך.