מהם תפקידי ARIA? מדריך מעשי למפתחים

מהם תפקידי ARIA? תפקידי ARIA הם אוצר מילים של 87 ערכים מוגדרים (נכון ל-WAI-ARIA 1.2) האומרים לטכנולוגיות מסייעות מה אלמנט הוא וכיצד עליו להתנהג ללא קשר לתג ה-HTML שלו. תפקיד כמו button, navigation, או dialog מקצה <div> או <span> גנרי לסוג ווידג’ט ידוע, כך שקוראי מסך יכריזו עליו בצורה נכונה ויחשפו את אינטראקציות המקלדת הנכונות.

מדוע בכלל קיימים תפקידי ARIA

כדי להבין מהם תפקידי ARIA, יש לראות שהם פותרים בעיה מבנית ש-HTML לבדו אינו יכול לפתור. לרכיבי HTML מקוריים יש סמנטיקה מרומזת: <button> מכריז על עצמו ככפתור, ניתן להתמקד בו, מגיב למקשי Enter ורווח, ומציג מצב לחוץ בעת הצורך. כאשר מפתחים יוצרים ווידג’טים מותאמים אישית (תיבה משולבת, חלונית כרטיסיות, תצוגת עץ), הם משתמשים לעיתים קרובות ב-<div> ו-<span>, שאינם מכילים סמנטיקה. תפקידי ARIA סוגרים פער זה בכך שהם מאפשרים למחברים לציין במפורש משמעות חסרה.

מפרט WAI-ARIA מתוחזק על ידי קבוצת העבודה של W3C ל-Accessible Rich Internet Applications. הגרסה הראשונה, ARIA 1.0, הפכה להמלצת W3C בשנת 2014; ARIA 1.1 הגיעה בעקבותיה ב-2017, ו-ARIA 1.2 הגיעה למעמד של המלצה ב-2023. תפקידים, מצבים ומאפיינים נוספו עם כל גרסה, וכל אחד מהם מקושר למסמך שיטות כתיבה המתאר את ההתנהגות הצפויה של המקלדת.

הבחנה מרכזית מפרידה בין התפקידים לשתי קטגוריות ה-ARIA האחרות. התפקידים עונים על השאלה: “מה זה?” מצבים ומאפיינים עונים על: “באיזה מצב הוא נמצא?” ו”למה זה קשור?” role="checkbox" מצהיר על סוג הווידג’ט; aria-checked="true" מציין את מצבו הנוכחי. בלבול בין השניים הוא אחד הגורמים הנפוצים ביותר לווידג’טים מותאמים אישית שבורים.

שש קטגוריות התפקידים

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

קטגוריה	מטרה	תפקידים מייצגים
מופשט (Abstract)	הגדרות מחלקת-על, לעולם לא בשימוש בסימון	widget, input, section
ווידג’ט (Widget)	בקרות אינטראקטיביות	button, checkbox, slider, tab
מבנה מסמך (Document structure)	ציוני דרך ואזורים בדף	banner, main, navigation, region
ציון דרך (Landmark)	אזורי דף ניתנים לניווט (תת-קבוצה של מבנה)	banner, complementary, contentinfo, form
אזור חי (Live region)	הכרזה על שינויים בתוכן דינמי	alert, status, log, timer
חלון (Window)	חלונות דפדפן או יישום	dialog, alertdialog

תפקידים מופשטים משמשים רק לארגון הטקסונומיה. למחברים אסור לכתוב role="widget" או role="input" בסימון; הדבר גורם להתנהגות לא מוגדרת ולכישלון באימות. חמש הקטגוריות הנותרות הן אלו שאתם מיישמים בפועל.

קשורים: accessiBe — Superposición de IA que promete cumplimiento WCAG ב-48 שעות.

תפקידים מרומזים והכלל הראשון של ARIA

לכל אלמנט HTML יש פונקציית ARIA מרומזת (המסבירה מהם תפקידי ARIA) המוגדרת על ידי מפרט ה-HTML Accessibility API Mapping (AAM). לאלמנט <nav> יש role="navigation" מרומז. ל-<ul> יש role="list" מרומז. ל-<h1> עד <h6> יש role="heading". ל-<table> יש role="table".

הכלל הראשון של W3C לשימוש ב-ARIA קובע בבירור: אם אלמנט או תכונה מקוריים של HTML כבר מעבירים את הסמנטיקה וההתנהגות הנדרשות, השתמשו בהם במקום להשתמש באלמנט עם ARIA. הוספת role="button" ל-<button> אינה נחוצה. גרוע מכך, אם תוסיפו role="button" ל-<div>, תקבלו את ההכרזה אך ללא התנהגות: ללא מיקוד, ללא הפעלה מהמקלדת וללא שליחת טופס.

יתירות אינה תמיד חסרת נזק. דריסת תפקיד מרומז עלולה להוביל לאובדן הסמנטיקה שהטכנולוגיה המסייעת תלויה בה. כתיבת role="presentation" ב-<table> מבטלת לחלוטין את סמנטיקת הטבלה, דבר שייתכן ויהיה מכוון בטבלאות פריסה (layout tables) אך הוא הרסני בטבלאות נתונים.

שווה להסתכל: AudioEye — גישה לתנועה: משולבת אוטומטית עם רוויזיון אנושי.

כיצד תפקידים מתקשרים עם מצבים ומאפיינים

תפקידים משמשים כמכליים עבור המצבים והמאפיינים שהם תומכים בהם. המפרט מגדיר אילו תכונות תקפות עבור אילו תפקידים, ודפדפנים חושפים רק שילובים נתמכים בעץ הנגישות. הבנה מהם תפקידי ARIA עוזרת לדעת ש-role="checkbox" תומך ב-aria-checked עם הערכים true, false או mixed. role="slider" תומך ב-aria-valuenow, aria-valuemin, aria-valuemax, ובאופן אופציונלי ב-aria-valuetext. role="combobox" תומך ב-aria-expanded, aria-controls ו-aria-activedescendant. החלת aria-checked על role="button" היא חסרת משמעות ותתעלם ממנה או תניב תוצאות מבלבלות בחלק מקוראי המסך.

גם המאפיינים הנדרשים הם חשובים. role="checkbox" ללא aria-checked אינו תקין; המצב הוא חובה ולא אופציונלי. role="slider" ללא aria-valuenow משאיר את המשתמש ללא יכולת לקבוע את הערך הנוכחי. מפרט ARIA מגדיר אותם כ”מצבים ומאפיינים נדרשים”, ובודקי תאימות כגון axe-core ו-IBM Equal Access Accessibility Checker מצביעים על היעדרם.

תפקידים, עץ הנגישות ותמיכה בדפדפנים

דפדפנים מתרגמים פונקציות ARIA לממשקי API של נגישות בפלטפורמה (UIA ב-Windows, AXAPI ב-macOS, ATK/AT-SPI ב-Linux), וקוראי מסך משתמשים בממשקי API אלה. תפקיד שאף דפדפן אינו מקצה נכונה הוא למעשה בלתי נראה למשתמשים.

התמיכה משתנה לפי תכונה ודפדפן. פונקציות ליבה כגון “Button”, “Link”, “Header”, “List” ו-”Navigation” נתמכות באופן אוניברסלי. לתפקידים חדשים או מיוחדים יותר (“feed”, “math”, “doc-footnote” ממודול ה-WAI-ARIA של Digital Publishing) יש תמיכה חלקית יותר. role="switch" נתמך בדפדפנים מודרניים, אך הוכרז באופן לא עקבי לפני עשור.

בדיקה על השילובים בפועל שקהל היעד שלכם משתמש בהם נותרת חיונית. ווידג’ט שעובד ב-NVDA עם Firefox עשוי להתנהג אחרת ב-VoiceOver עם Safari, מכיוון ששני קוראי המסך צורכים ממשקי API שונים של הפלטפורמה ומחילים היוריסטיקות שונות.

תפקידי ציון דרך ומבנה הדף

תפקידי ציון דרך (Landmark roles) מאפשרים למשתמשי קוראי מסך לקפוץ ישירות לאזורים בדף. שמונת תפקידי ציון הדרך הם banner, complementary, contentinfo, form, main, navigation, region, ו-search. ל-HTML מודרני יש מקבילות מקוריות לרובם: <header> הופך ל-banner, <footer> הופך ל-contentinfo, <main> הופך ל-main, <nav> הופך ל-navigation, <aside> הופך ל-complementary, <form> עם שם נגיש הופך ל-form, ו-<section> עם שם נגיש הופך ל-region.

קשורים: IAAP CPACC / WAS Certification — La certificación profesional que acredita tu experiencia en accesibilidad.

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

טעות נפוצה היא להחיל role="banner" על <div> שנמצא בתוך <main> או <article>. תפקידי ציון דרך יוצרים ציוני דרך רק אם הם אינם מקוננים בתוך תפקידים מסוימים אחרים; banner בתוך main לא יוצג כציון דרך כלל. המיקום ב-DOM חשוב לא פחות מערך התפקיד. עבור אלו התוהים מהם תפקידי ARIA, ציוני דרך אלה הם חלק מרכזי במפרט.

תפקידי אזור חי (Live Region)

כאשר בוחנים מהם תפקידי ARIA, תפקידי אזור חי מכריזים על שינויי תוכן מבלי לשנות את המיקוד. ארבע פונקציות האזור החי הן alert, status, log ו-timer, וכן marquee הכללי יותר. כל אחד מהם נושא ערך aria-live באופן מרומז: alert ו-log מרמזים בפועל על assertive ו-polite, בהתאמה, בעוד ש-status מרמז על polite.

שווה להסתכל: UserWay — Widget de accesibilidad עם תוכנית חינם עבור empezar hoy mismo.

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

אזורים חיים חייבים להתקיים ב-DOM לפני שהתוכן משתנה. הכנסת אלמנט role="alert" והטקסט שלו בו-זמנית גורמת לעיתים קרובות לכך שלא תהיה הכרזה, מכיוון שהאזור לא היה קיים בזמן השינוי. התבנית האמינה היא לרנדר אזור חי ריק בעת טעינת הדף ולעדכן את תוכן הטקסט שלו מאוחר יותר.

מתי לא להשתמש בתפקידי ARIA

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

הוספת תפקיד אינה מוסיפה התנהגות. role="button" על <div> גורם לכך שלא ניתן יהיה להתמקד בו, הוא לא יגיב למקשי Enter או רווח, ולא ישלח את הטופס. עליכם להוסיף tabindex="0", מטפל באירועי מקלדת עבור Enter ורווח, ולעתים קרובות ניהול מצב “מותאם לתפקיד”. בשלב זה, שימוש ב-<button> אמיתי דורש פחות קוד וגורם לפחות שגיאות.

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

מסגרת החלטה לבחירת תפקידים

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

1. זהו את הווידג’ט או האזור. הגדירו מה האלמנט הוא בפועל בשפה פשוטה.
2. בדקו אם יש מקבילה מקורית ב-HTML. עיינו במיפוי HTML-AAM. אם <button>, <select>, <details> או <dialog> מתאימים, השתמשו בהם.
3. אם אין אלמנט מקורי מתאים, בחרו את תפקיד ה-ARIA הקרוב ביותר. ודאו שהוא קיים במפרט הנוכחי ואינו מופשט.
4. הוסיפו מצבים ומאפיינים נדרשים. בדקו את הגדרת התפקיד עבור תכונות חובה.
5. הטמיעו את דפוס האינטראקציה של המקלדת. עקבו אחר מדריך שיטות הכתיבה של WAI-ARIA עבור סוג הווידג’ט.
6. בדקו עם לפחות שני שילובי קורא מסך ודפדפן. אמתו את ההכרזות, המצבים וזרימת המקלדת.

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

כלי בדיקה ואימות

כלים אוטומטיים מזהים שגיאות מבניות: ערכי תפקידים לא תקינים, מאפיינים נדרשים חסרים, ותפקידים המוחלים על אלמנטים שאינם תומכים בהם. axe-core, המנוע שמאחורי הרחבות דפדפן רבות, בודק תת-קבוצה מוגדרת של חוקי ARIA. ה-IBM Equal Access Accessibility Checker וה-Nu HTML Checker של W3C מראים גם הם שימוש שגוי בתפקידים.

כלים אוטומטיים אינם יכולים לאמת אם תפקיד מייצר את ההכרזה הנכונה או אם האינטראקציה עם המקלדת עובדת. בדיקה ידנית עם NVDA ו-Firefox, JAWS ו-Chrome, או VoiceOver ו-Safari עדיין נדרשת. תוסף Accessibility Insights for Web משלב בדיקות אוטומטיות עם הערכה ידנית מודרכת הכוללת אימות מקלדת וקורא מסך.

מפרט ה-ARIA עצמו, מדריך שיטות הכתיבה של WAI-ARIA ומסמך המיפוי HTML-AAM הם המקורות המוסמכים למהם תפקידי ARIA. ה-ARIA Reference של MDN Web Docs הוא מקור משני נוח ונבחר היטב המפנה למפרט עבור כל תפקיד.

נקודות מפתח

• תפקידי ARIA מצהירים מה אלמנט הוא; WAI-ARIA 1.2 מגדיר 87 תפקידים בשש קטגוריות, ותפקידים מופשטים לעולם לא יופיעו בסימון.
• לרכיבי HTML מקוריים יש תפקידים מרומזים והתנהגויות מובנות, לכן הכלל הראשון בשימוש ב-ARIA הוא להעדיף אותם על פני div בתוספת role.
• תפקידים דורשים את המצבים והמאפיינים הנתמכים שלהם: role="checkbox" ללא aria-checked אינו תקין ולא ניתן להשתמש בו.
• הוספת תפקיד לעולם אינה מוסיפה התנהגות מקלדת או יכולת מיקוד; אלו חייבים להיות מיושמים ונבדקים בנפרד.
• לתפקידי Landmark ו-Live Region יש כללי מיקום ותזמון שקובעים אם הם יעבדו או לא.
• בודקים אוטומטיים מזהים רק שגיאות מבניות; בדיקה של קוראי מסך עבור שילובי דפדפנים שונים עדיין נדרשת.

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

מקורות וקריאה נוספת

• WAI-ARIA — ויקיפדיה: Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA) הוא מפרט טכני שפורסם על ידי ה-World Wide Web Consortium (W3C) ש…

שאלות נפוצות

מהם תפקידי ARIA במילים פשוטות?

תפקידי ARIA הם תוויות שאתם מצמידים לאלמנטים של HTML כדי לספר לטכנולוגיה מסייעת מה האלמנט מייצג. <div role="button"> יוכרז ככפתור ולא כטקסט גנרי. תפקידים מספקים משמעות שהתג הבסיסי אינו מספק, אך הם אינם מוסיפים התנהגות, טיפול במיקוד או תמיכה במקלדת בעצמם.

מה ההבדל בין תפקידי ARIA למאפייני ARIA?

תפקידים מתארים את סוג האלמנט, בעוד שתכונות מתארות את מצבו, ערכו או קשריו. role="slider" מזהה מחוון; aria-valuenow="50" מדווח על מיקומו הנוכחי ו-aria-labelledby מצביע על התווית שלו. תפקידים ותכונות משמשים יחד וכל תפקיד מגדיר באילו תכונות הוא תומך.

כמה תפקידים של ARIA יש?

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

האם עלי להשתמש בתפקידי ARIA במקום HTML סמנטי?

לא. הכלל הראשון של השימוש ב-ARIA אומר להעדיף אלמנט HTML מקורי בכל פעם שקיים כזה עם הסמנטיקה וההתנהגות הנדרשים. השתמש ב-<button>`` במקום