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

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

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

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

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

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

מהו Accessibility API?

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

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

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