דוגמאות לתפקידים של ARIA: מדריך מלא

מאת Niquelao Resource Desk · עודכן ב־ 28 בספטמבר 2026

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

נקודות חשובות

תפקידי ARIA אומרים לטכנולוגיה המסייעת מהו פריט; הם אף פעם לא מוסיפים התנהגות, מיקוד או תמיכה במקלדת בעצמם.
הכלל הראשון של השימוש ב-ARIA הוא העדפת רכיבי HTML מקוריים, שכבר נושאים תפקידים מרומזים, מצבים וניהול מקלדת.
שש קטגוריות התפקידים של WAI-ARIA 1.2 הן ווידג’ט, מבנה מסמך, ציון דרך, אזור חי, חלון ומופשט - תפקידים מופשטים לעולם לא צריכים להופיע בסימון שלך.
תפקידי דרך הם ה-ARIAs החסכוני ביותר ובסיכון הנמוך ביותר שתוכל להוסיף לאתר XHTML/CSS קיים.
תפקידי ווידג’טים דורשים כמעט תמיד מיפוי JavaScript עבור אינטראקציה עם מקלדת וטיפול במצב, או שהם יוצרים חוויה גרועה יותר מ-HTML רגיל.
אימות כל תפקיד עם קורא מסך ובודק אוטומטי; תפקיד חוקי במפרט עדיין עשוי להיות שגוי עבור התוכן שלך.

מה בעצם עושים תפקידי ARIA

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

מפרט ה-WAI-ARIA, המתוחזק על ידי קבוצת העבודה של Accessible Rich Internet Applications של W3C, מגדיר תפקידים כמו גם מצבים ומאפיינים. תפקידים הם שכבת ה”מה זה”; מצבים ומאפיינים כמו aria-expanded, aria-checked וaria-label הם שכבת “באיזה מצב זה נמצא”. תפקיד ללא המצבים הנדרשים שלו אינו שלם - role="checkbox" דורש aria-checked, ו-role="combobox" דורש aria-expanded בתוספת רשימה מבוקרת.

רכיבי HTML מקוריים נושאים תפקידים מרומזים. <button> מתאים לתפקיד הלחצן, <nav> לניווט, <h1> דרך <h6> לכותרת, ו-<input type="checkbox"> לתיבת הסימון. מכיוון שהדפדפן מספק אוטומטית את התפקיד, התנהגות המקלדת והמצב, הכלל הראשון של השימוש ב-ARIA - המתועד במדריך ARIA Authoring Practices של W3C - הוא להשתמש בסמנטיקה מקורית בכל פעם שקיים אלמנט שווה ערך. חפש תפקידים מפורשים רק כאשר אף אלמנט מקורי אינו מתאים, כגון תצוגת עץ מותאמת אישית או חלונית עם כרטיסיות הבנויה מ-

שש קטגוריות התפקיד של WAI-ARIA

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

קשורים: — עם תוכנית חינם עבור empezar hoy mismo.

קטגוריה	מטרה	תפקידים לדוגמה	נדרש JavaScript?
יישומון	בקרות אינטראקטיביות	`button`, `checkbox`, `tab`, `slider`, `combobox`	כן - מקלדת + מצב
מבנה המסמך	ארגון תוכן	`heading`, `list`, `listitem`, `table`, `Article`	לא
ציון דרך	אזורי עמוד לניווט	`באנר`, `ראשי`, `ניווט`, `משלים`	לא
אזור חי	הכרזה על עדכונים דינמיים	`תראה`, `status`, `log`, `timer`	בדרך כלל - כדי להפעיל עדכונים
חלון	חלונות משנה ודיאלוגים	`דיאלוג`, `alertdialog`	כן — ניהול מיקוד
תקציר	תפקידי מעמד-על, מעולם לא נכתבו	`יישומון`, `קלט`, `קטע`, `נקודת ציון`	לא רלוונטי - אין להשתמש ב-

תפקידים מופשטים קיימים רק כדי לארגן את הטקסונומיה. כתיבת role="input" או role="section" ב-HTML שלך היא שגיאת אימות ומייצרת הודעות בלתי צפויות מכיוון שלתפקידים אלו אין התנהגות מוגדרת עבור טכנולוגיה מסייעת.

דוגמאות לתפקידים נקודתיים

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

<header role="banner">
  <nav role="navigation" aria-label="Principal">
    <ul>...</ul>
  </nav>
</header>
<main role="main">
  <article>...</article>
  <aside role="complementary" aria-label="Artículos relacionados">...</aside>
</main>
<footer role="contentinfo">...</footer>

כל תפקיד סמן מתאים לאלמנט מקורי - באנר ל<header> ברמה העליונה, main ל<main>, נווט ל<nav>, משלים ל<aside>, contentinfo ל<footer>. כאשר אתה משתמש באלמנט המקורי, התפקיד משתמע ואין לחזור עליו. התכונה המפורשת role זוכה במקומה רק כאשר אתה תקוע עם סימון <div> שאינך יכול לשנות, דבר שכיח בתבניות ישנות יותר ובפלט של CMS.

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

יש כאן סדר בשתי אזהרות. ראשית, באנר, ראשי ותוכן מידע חייבים להופיע פעם אחת בכל עמוד; מספר ציוני דרך ‘עיקריים’ משבשים את הניווט. שנית, כאשר קיימים מספר ציוני דרך מאותו סוג – נניח שלושה אלמנטים של <nav> – תן לכל אחד מהם aria-label נפרד כדי שמשתמשי קוראי מסך יוכלו להבחין ביניהם ברשימת ציוני הדרך. nav ללא תווית מפורסם באותו אופן כמו האחים שלו, מה שמביס את המטרה.

דוגמאות לתפקידי יישומון

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

לחצן החלפת מצב, למשל, זקוק ל’לחיצה על aria’ כדי להודיע על מצב ההפעלה/כיבוי שלו:

<button type="button" aria-pressed="false" id="mute">
  שקט
</button>

האלמנט <button> מספק את התפקיד, המיקוד וטיפול ב-Enter/Space; JavaScript רק הופך את aria-pressed בין "false" ו-"true". זוהי הצורה האידיאלית של שימוש ב-ARIA - אלמנט מקורי, ARIA מינימלי, סקריפט קטן.

ממשק כרטיסיות מותאם אישית הבנוי מ-

’s הוא המקרה ההפוך. הוא צריך role="tablist" במיכל, role="tab" בכל כרטיסייה, role="tabpanel" בכל חלונית, aria-selected בכרטיסייה הפעילה, aria-controls המקשרים את הכרטיסייה לחלונית, וניווט מקש חץ בין כרטיסיות. אם אתה מתגעגע לאחד מאלה, הווידג’ט מכריז על עצמו כלשוניות אך מתנהג כמו טקסט סטטי. אותו דבר חל על role="slider" (דורש aria-valuenow, aria-valuemin, aria-valuemax ומקשי החצים), role="combobox" (דורש aria-expanded ו-listbox מבוקרת), ו-role="tree" (מחייב aria-expanded keys וחץ מלא).

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

כלל החלטה שימושי: אם יש אלמנט מקורי שעושה את העבודה - <button>, <input type="checkbox">, <select>, <details> - השתמש בו והתעלם לחלוטין מתפקיד הווידג’ט. שמור תפקידי ווידג’ט מותאמים אישית עבור פקדים חדשים באמת ותקציב את JavaScript כדי ליישם את תבנית המקלדת המלאה לפני המשלוח.

דוגמאות למבנה מסמכים ואזור חי

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

<div role="heading" aria-level="2">Novedades del mes</div>

התכונה אריה-level היא חובה כאן - תפקיד כותרת ללא רמה מוכרז ללא דרגה, שובר את מתווה המסמך. באופן דומה, role="list" וrole="listitem" משחזרים סמנטיקה של רשימה כאשר CSS כגון list-style: none או מיכל flex מסירים אותם בדפדפנים מסוימים, ו-role="table", role=“row”, role=“columnheader” ו-role=“cell”בונים מחדש את טבלת הנתונים

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

. בפועל, ארגון מחדש לאלמנטים ממשיים של <ul>, <ol> ו-<table> דורש כמעט תמיד פחות עבודה מאשר שמירה על קבוצה מלאה של תפקידי מבנה.

תפקידי אזור חיים מכריזים על שינוי בתוכן ללא טעינה מחדש של הדף. role="alert" קוטע מיד את קורא המסך ומכיל הודעות שגיאה והתראות דחופות; role="status" ממתין בנימוס והוא בסדר עם אישורים כמו “Guardado”; role="log" מתאים לעדכוני צ’אט ופעילות; role="timer" מתאים לספירה לאחור. הפרט הקריטי הוא שמיכל האזור החי חייב להתקיים ב-DOM לפני שהתוכן משתנה - הזרקת אלמנט חדש עם role="alert" והטקסט שלו בו-זמנית לעתים קרובות לא מייצרת הודעה, מכיוון שהאזור לא היה נוכח למעקב. צור <div role="status"> ריק בעת טעינת העמוד ועדכן את הטקסט שלו מאוחר יותר.

טעויות נפוצות בתפקיד ARIA

תפקידים מיותרים בראש הרשימה. דוגמאות אלו לתפקידי אריה, כגון <button role="button"> ו-<nav role="navigation">, אינן מוסיפות דבר ואינן עומסות את הסימון; התפקיד המרומז כבר קיים. אותה יתירות מופיעה כאשר מפתחים מוסיפים role="heading" ל<h2>.

מצבים נדרשים חסרים מגיעים למקום השני. role="checkbox" ללא aria-checked, role="slider" ללא aria-valuenow, ו-role="combobox" ללא aria-expanded, כולם מייצרים הודעות לא שלמות שמטעות משתמשים. המפרט מפרט את המצבים והמאפיינים הנדרשים עבור כל תפקיד, ובודקים אוטומטיים מסמנים את היעדרם.

שימוש לרעה בתפקיד באלמנט הלא נכון הוא שלישי. הצבת role="button" על <a href> עוקפת את סמנטיקה של הקישור ושוברת התנהגות צפויה כמו פתיחה בכרטיסייה חדשה. הצבת role="presentation" או role="none" על אלמנט שניתן למיקוד מסירה את הסמנטיקה שלו תוך השארתו בסדר הטאבים, ויוצרת אלמנט שניתן למיקוד ללא זהות מוכרזת. ושימוש בתפקידים מופשטים כגון role="widget" או role="input" הוא תמיד שגיאה.

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

כיצד לבדוק תפקידי ARIA

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

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

בדוק את עץ הנגישות ישירות ב-Chrome או Firefox DevTools, כאשר החלונית “נגישות” מציגה את התפקיד והשם המחושבים של כל רכיב. זה חושף את הפער בין התפקיד שכתבת לבין התפקיד שהדפדפן חושף בפועל - הדרך המהירה ביותר לזהות תפקיד שנעקף על ידי הורה או מתעלם ממנו לחלוטין.

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

WAI-ARIA — ויקיפדיה: יוזמת נגישות לאינטרנט – יישומי אינטרנט עשירים נגישים (WAI-ARIA) הוא מפרט טכני שפורסם על ידי ה-World Wide Web Consortium (W3C) ש…

שאלות נפוצות

מהם תפקידי ARIA וכיצד הם עובדים?

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

מתי עלי להשתמש בתפקידי ARIA במקום HTML מקורי?

השתמש בתפקידי ARIA רק כאשר שום רכיב HTML מקורי לא מספק את הסמנטיקה הדרושה לך. אלמנטים מקוריים כמו <button>, <nav> ו-<input type="checkbox"> נושאים תפקידים מרומזים בתוספת תמיכה מובנית במקלדת וניהול מצב. הכלל הראשון של השימוש ב-ARIA הוא להעדיף סמנטיקה מקורית, ולהוסיף תפקידים מפורשים רק עבור ווידג’טים מותאמים אישית או סימון מדור קודם, לא ניתן לבנות מחדש.

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

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

האם אוכל להשתמש בתפקידי ARIA בכל רכיב HTML?

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

האם תפקידי ARIA עובדים ללא JavaScript?

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

כיצד אוכל לבדוק אם תפקידי ARIA נכונים?

שלב בדיקה אוטומטית וידנית. הפעל את axe DevTools, WAVE או Lighthouse כדי לזהות תפקידים לא חוקיים ותכונות נדרשות חסרות, ולאחר מכן בדוק עם NVDA, JAWS ו-VoiceOver כדי לאשר הודעות והתנהגות מקלדת. חלונית הנגישות ב-Chrome ו-Firefox DevTools מציגה את התפקיד המחושב, וחושפת את התפקידים שהדפדפן עוקף או מתעלם מהם.

שאלות נפוצות

מהם תפקידי ARIA וכיצד הם עובדים?

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

מתי עלי להשתמש בתפקידי ARIA במקום HTML מקורי?

השתמש בתפקידי ARIA רק כאשר שום רכיב HTML מקורי לא מספק את הסמנטיקה הדרושה לך. אלמנטים מקוריים כמו <button>, <nav> ו-<input type='checkbox'> נושאים תפקידים מרומזים בתוספת תמיכה מובנית במקלדת וניהול מצב. הכלל הראשון של השימוש ב-ARIA הוא להעדיף סמנטיקה מקורית, ולהוסיף תפקידים מפורשים רק עבור ווידג'טים מותאמים אישית או סימון מדור קודם, לא ניתן לבנות מחדש.

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

תפקידי ARIA עונים 'מה זה הפריט הזה', בעוד שתכונות ARIA כגון aria-expanded, aria-checked ו-aria-label עונים 'באיזה מצב זה נמצא' או 'איך קוראים לזה'. התפקידים והתכונות הנדרשות שלהם פועלים יחד: כדוגמאות לתפקידי אריה, role='checkbox' אינו שלם ללא סימון aria, ו-rolle='combobox' צריך להרחיב את aria בתוספת תיבת רשימה מבוקרת.

האם אוכל להשתמש בתפקידי ARIA בכל רכיב HTML?

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

האם תפקידי ARIA עובדים ללא JavaScript?

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

כיצד אוכל לבדוק אם תפקידי ה-ARIA שלי נכונים?

שלב בדיקה אוטומטית וידנית. הפעל את ax DevTools, WAVE או Lighthouse כדי לזהות תפקידים לא חוקיים ותכונות נדרשות חסרות, ולאחר מכן בדוק עם NVDA, JAWS ו-VoiceOver כדי לאשר הודעות והתנהגות מקלדת. חלונית הנגישות ב-Chrome ו-Firefox DevTools מציגה את התפקיד המחושב, וחושף את התפקידים שהדפדפן עוקף או מתעלם מהם.

¿Cumplir WCAG sin tocar el código?

Superposición de IA que promete cumplimiento WCAG ב-48 שעות