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

איך לשקר לקוראי מסך מרפא את הנגישות, כשהיא לא שוטפת מלח!

מהו ARIA?

בעזרת ARIA, מחברי אתרים יכולים ליצור מציאות חלופית, שתוצג רק לקוראי מסך 🤥

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

כשיש פתק קסום במיקום קבוע, הוא מבטל את האמונות שלנו לגבי מהו כל כלי או משהו לגבי הכלי. דוגמה: "הדבר הזה כאן הוא אקדח דבק!". זו עדיין קופסה כחולה ריקה מונחת על שולחן העבודה, אבל הפתק הדביק הקסום גורם לנו לראות שזהו אקדח דבק. אנחנו יכולים גם להוסיף "ו-30% הוא מלא!". קורא המסך ידווח שיש שם אקדח דבק מלא מ-30%.

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

מה זה לא ARIA?

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

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

איך פועל ARIA?

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

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

למה שנרצה אי פעם לשקר למשתמשים שלנו!?

נניח שחנות האינטרנט המקומית אינה מוכרת את כל הווידג'טים הדרושים לנו. אבל אנחנו MacGyver, באסה. אנחנו יכולים פשוט להמציא ווידג'טים משלנו מתוך ווידג'טים אחרים! FWIW, שבעת הדברים הכי נפוצים של MacGyver הם סכינים שוויצריות, מסטיק, שרשראות נעליים, גפרורים, מהדקי נייר, נרות יום הולדת וסרט דביק. הוא משתמש בהם כדי להכין פצצות ודברים אחרים שלא סתם נמצאים במקום. היא די דומה למחבר אינטרנט שצריך ליצור סרגל תפריטים. סרגלי תפריטים כל כך שימושיים שהייתם חושבים שהם יהיו חלק מ-HTML, אבל הם לא. טוב! לא חשבת שכותבים יהיו מרוצים מקישורים ומלחצנים, אה? כדי שהמחבר ישלב אותן יחד באמצעות הכלים האהובים עליו: divs, תמונות, סגנון, רכיבי handler של קליקים, רכיבי handler של הקשה על מקש, spit ו-ARIA.

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

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

תמיכה באנשים עם לחיצה על העכבר

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

התמודדות עם באגים

באגים במקלדת (HTML!)

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

דוגמאות לבאגים:

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

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

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

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

באגים ב-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 של האמת במקום את האמת האמיתית.

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

קובץ עזר משולב עם פרטי מקלדת ודוגמאות לקודים

• השיטות לעריכת ARIA של W3C: במאמר הזה מתועדת המאפיינים החשובים לניווט במקלדת בכל דוגמה ומספקת קוד JS/CSS/ARIA תקין. הדוגמאות מתמקדות במה שעובד כיום ולא רלוונטיות לנייד.

נספח 2: למה משמשים הכי הרבה ב-ARIA?

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

לפניכם כמה שימושים נפוצים ב-ARIA.

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

נספח 3: מהו ממשק API לנגישות?

בעזרת ממשק API לנגישות, קורא מסך או כלי AT אחר יכולים לדעת מה מופיע בדף ומה קורה כרגע. לדוגמה: MSAA, IA2 ו-UIA. וזה רק Windows! ממשק API לנגישות מורכב משני חלקים:

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

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