תפקידים ותכונות של ARIA: הבחירות הטובות ביותר בהשוואה

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

Accessible Rich Internet Applications (ARIA) הוא מפרט W3C המוסיף סמנטיקה לרכיבי HTML שאין להם אותם בצורה מקורית. תפקיד מתאר מהו אלמנט (כפתור, tab, דיאלוג), בעוד שתכונה מתארת ​​את ה-מצב שלו או היחסים שלו (aria-expanded, aria-controls, aria-labeledby). הכלל הראשון של ARIA, שפורסם על ידי W3C ב-Using ARIA, הוא בוטה: אם יש אלמנט HTML מקורי שכבר עושה את העבודה, השתמש בו ואל תוסיף ARIA.

הסיבה היא ש-ARIA לא משנה את התנהגות הדפדפן. <div role="button"> אינו מקבל מיקוד עם Tab, אינו מגיב למקש Enter או לרווח, ואינו נשלח עם טופס. זה רק משנה את מה שהטכנולוגיה המסייעת מכריזה. כל אינטראקציה חייבת להיות מיושמת עם JavaScript ולנהל אותה בקפידה. בפרוייקטים של XHTML/CSS שבהם ה-HTML סטטי וה-JS מינימלי, זה אומר שכל אחד מתפקידי ותכונות aria שמתווסף הוא הבטחה שהקוד שלך חייב למלא.

הכלל השני של ARIA מבקש לא לשנות את הסמנטיקה המקורית אלא אם כן היא בלתי ניתנת לשינוי. אלמנט <h2 role="tab"> שובר את מבנה הכותרות ומבלבל קוראי מסך שמנווטים לפי אזורים. הכלל השלישי דורש שכל פקדי ה-ARIA יהיו ניתנים להפעלה עם מקלדת. הרביעי מבקש לא להשתמש ב-aria-hidden="true" על אלמנטים שמקבלים פוקוס. החמישי, והנשכח ביותר, מזכיר לנו שכל אלמנט אינטראקטיבי דורש שם נגיש: תפקיד ללא תווית הוא כפתור השתקה.

איך לבחור: קריטריונים לפני הרשימה

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

1. האם יש אלמנט HTML מקורי? אם כן, השתמש בו. <button>, <details>, <dialog>, <input type="checkbox"> מכסים יותר מקרים ממה שאנשים חושבים.
2. האם הווידג’ט צריך מצבים דינמיים? אם הוא משתנה בין פתוח/סגור, נבחר/לא נבחר, או מורחב/מכווץ, אתה צריך תכונות מצב (aria-expanded, aria-selected, aria-pressed).
3. האם צריך קשרים בין אלמנטים? תכונות יחס (aria-controls, aria-labeledby, aria-describedby, aria-owns) מחברות בין חלקים שעץ הנגישות לא יכול להסיק מה-DOM.
4. האם צריך הודעות חיות? אזורים חיים (aria-live, role="status", role="alert") פותרים עדכונים מבלי להזיז את הפוקוס.
5. האם אני יכול לתחזק אותו? דפוס ARIA מורכב ללא בדיקות מקלדת או קורא מסך הוא גרוע יותר מאשר אין כלום.

עלות התחזוקה היא הקריטריון המתעלמים ממנו ביותר. role="tablist" עשוי היטב דורש ניהול מקשי חצים, סיבוב tabindex, סנכרון של aria-selected ו-aria-controls, והסתרה נכונה של פאנלים לא פעילים. אם הצוות לא יכול להתמודד עם זה, מערכת קישורים עם עוגנים נגישה יותר וזולה יותר.

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

השוואת תפקידי ARIA השימושיים ביותר

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

תפקיד	מה הוא עושה	חלופה מקורית	מלכודת נפוצה
button	פקד שמבצע פעולה	<button>	אי-הוספת טיפול במקשי Enter/רווח או tabindex="0"
link	ניווט לכתובת URL אחרת	<a href>	שימוש בו לפעולות שאינן ניווט
dialog	חלון מודאלי או לא מודאלי	<dialog>	אי-לכידת הפוקוס או אי-החזרתו בסגירה
tablist / tab / tabpanel	ממשק לשוניות	אין חלופה ישירה	אי-סנכרון של aria-selected עם הפאנל הגלוי
menu / menuitem	תפריט אפליקציה	<select> או רשימת קישורים	שימוש בו לתפריטי ניווט באתר
alert	הודעה דחופה ומיידית	role="status" לדברים לא דחופים	שימוש מופרז שמעמיס על קורא המסך
status	עדכון אינפורמטיבי	<output>	אי-הכנסה ל-DOM לפני העדכון
progressbar	התקדמות של משימה	<progress>	אי-עדכון של aria-valuenow
tooltip	תיאור צף	title (מוגבל)	אי-קישור באמצעות aria-describedby
combobox	שדה עם רשימת הצעות	<datalist> (מוגבל)	אי-הכרזה על מספר התוצאות

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

Atributos ARIA imprescindibles y cómo se combinan

התכונות קשורות לארבע משפחות, וכל אחת פותרת בעיה נפרדת.

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

תיוג. aria-label מספק שם כאשר אין טקסט גלוי. aria-labeledby מתייחס למזהה של אלמנט אחר ועדיף כאשר הטקסט כבר קיים על המסך, מכיוון שהוא שומר על מקור אמת יחיד. aria-describedby מוסיף תיאור ארוך יותר, כגון טקסט העזרה של שדה. ההבדל חשוב: השם הוא מה שהמשתמש שומע עם התמקדות; התיאור הוא הקשר נוסף שניתן להפריע לו.

מצבים. אריה-מורחב (נכון/לא נכון) עבור אקורדיונים ותפריטים נפתחים. aria-selected עבור כרטיסיות ואפשרויות. ‘aria-checked’ עבור תיבות סימון מותאמות אישית, עם הערך ‘mixed’ עבור מדינות משולשות. ‘aria-pressed’ עבור לחצני החלפה. aria-disabled כאשר האלמנט עדיין ניתן למיקוד אך אינו ניתן להפעלה, בניגוד לתכונה המקורית disabled, אשר מסירה אותו מסדר הטאבים.

יחסים. aria-controls מציין באיזה אלמנט כפתור שולט. aria-owns מארגן מחדש את עץ הנגישות כאשר ה-DOM אינו משקף את הקשר החזותי. aria-activedescendant מאפשר לך לשמור על מיקוד על מיכל בזמן שהוא מכריז על האלמנט הפעיל, דפוס נפוץ בתיבות משולבות.

אזורים חיים. aria-live="polite" או "אסרטיבי" מגדירים דחיפות. aria-atomic="true" גורם להכרזה על הבלוק כולו במקום רק על החלק שהשתנה. מסננים ‘רלוונטיים לאריה’ שהשינויים מוכרזים.

פרט שלעתים קרובות מתעלמים ממנו: תכונות ARIA פועלות רק על אלמנטים בעלי תפקיד חוקי. לא יפורסם aria-expanded על <div> ללא תפקיד. והערכים הבוליאניים של ARIA הם מחרוזות טקסט (“true”, ”false”), לא ערכים בוליאניים של JavaScript; כתיבת aria-expanded=“false”` כמאפיין בוליאני תפיק תוצאות לא עקביות.

שגיאות שהורסות את הנגישות של ווידג’ט

השגיאה היקרה ביותר היא שימוש ב-ARIA כדי לתקן HTML במבנה שגוי. הוספת role="navigation" ל-<div> כאשר כבר היה <nav> זמין מכפילה אזורים ומבלבלת את הניווט לפי נקודות ציון (landmarks).

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

השגיאה השנייה היא המיקוד. ווידג’ט מודאלי שאינו מזיז את הפוקוס בעת פתיחתו, אינו לוכד אותו כשהוא פתוח ואינו מחזיר אותו להדק בסגירה משאיר את משתמש המקלדת מנווט בתוכן בלתי נראה. האלמנט המקורי <dialog> פותר חלק מזה, אבל לא הכל: החזרת המיקוד היא עדיין באחריות המפתח.

השגיאה השלישית היא הסתרת אלמנטים באמצעות aria-hidden בעודם נשארים ניתנים למיקוד. תפריט סגור עם aria-hidden="true" אך ללא display: none או visibility: hidden שומר על הקישורים שלו בסדר הטאב, והמשתמש מגיע לאלמנטים שהוא אינו יכול לראות. השילוב הנכון הוא הסתרה חזותית ומהסתרת עץ הנגישות בו-זמנית.

השגיאה הרביעית היא השם הנגיש החסר. <button> עם סמל SVG יחיד דורש aria-label או <span class="visually-hidden"> עם טקסט. SVG דקורטיבי דורש aria-hidden="true" ו-focusable="false" כך ש-Internet Explorer וכמה דפדפנים ישנים יותר אינם כוללים אותו בסדר הכרטיסיות.

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

Herramientas para probar roles y atributos ARIA

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

אימות סטטי. מאמת ה-W3C ARIA (חלק מ-Nu HTML Checker) מזהה תפקידים לא קיימים, תכונות כתובות בצורה גרועה ושילובים אסורים. ax DevTools ו-Lighthouse מציינים תפקידים ללא שמות נגישים וחסרות תכונות חובה.

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

בדיקה ידנית. נווט בכל הווידג’ט רק באמצעות המקלדת (Tab, Shift+Tab, חצים, Enter, Space, Escape) ולאחר מכן עם NVDA ב-Windows, JAWS אם זמין, או VoiceOver ב-macOS ו-iOS. השילוב של קורא שולחני וקורא נייד מכסה את רוב המקרים האמיתיים.

תיעוד עזר. W3C ARIA Authoring Practices Guide (APG) כולל תבניות מקיפות עם דוגמאות מקלדת וקוד. זה המקור שצריך להתייעץ איתו לפני המצאת דפוס חדש.

Cómo decidir en un proyecto XHTML/CSS real

באתרי XHTML עם CSS ו-JavaScript קלים, האסטרטגיה המשתלמת ביותר היא להתחיל עם HTML מקורי ולהוסיף ARIA רק במקום שבו ה-Native לא מגיע. טופס עם <label>, <fieldset> ו-<legend> נכונים דורש מעט מאוד ARIA. גם טבלת נתונים עם <th scope> לא עושה זאת. תפקידי ARIA מגיעים כאשר מופיעים דפוסים ש-HTML אינו מכסה: כרטיסיות, אקורדיונים, תיבות משולבות עם סינון, דיאלוגים מודאליים והתראות דינמיות.

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

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

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

• תפקידים ותכונות של ARIA אינם מוסיפים התנהגות: תפקיד ללא ניהול מקלדת ומיקוד הוא גרוע יותר מאשר אין כלום.
• הכלל הראשון של ARIA הוא להשתמש ב-HTML מקורי בכל פעם שהוא קיים; <button>, <dialog> ו-<details> מכסים יותר מקרים ממה שניתן לחשוב.
• תכונות מקובצות לפי תיוג, מצבים, מערכות יחסים ואזורים חיים; כל משפחה פותרת בעיה אחרת.
• role="alert" מפריע וrole="status" מחכה: בחירה שגויה מרווה את המשתמש בקורא המסך.
• הערכים הבוליאניים של ARIA הם מחרוזות (“true”/”false”), ותכונות פועלות רק על אלמנטים בעלי תפקיד חוקי.
• בדיקה עם מקלדת וקורא מסך אמיתי היא חובה; המאמתים מזהים רק חלק מהכשלים.

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

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

שאלות נפוצות

¿Cuál es la diferencia entre un roll y un atributo ARIA?

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

¿Cuándo debo usar ARIA en lugar de HTML Nativo?

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

¿Qué significa que un elemento tenga un nombre accesible?

שם נגיש הוא הטקסט שקורא המסך מכריז בעת מיקוד האלמנט. זה מחושב מהתוכן, מ-‘aria-label’, מ-‘aria-labeledby’ או מ-'' משויך, בסדר עדיפות שהוגדר במפרט. תפקיד אינטראקטיבי ללא שם נגיש הוא פקד שהמשתמש אינו יכול לזהות.

¿Por qué mi role="button" no response al teclado?

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

האם זה רע להשתמש ב-aria-hidden="true"?

נכון להסתיר תוכן דקורטיבי או משוכפל מעץ הנגישות, אך אין להחיל זאת על אלמנטים שמקבלים פוקוס. אם אלמנט שניתן לפוקוס נשאר עם aria-hidden="true", משתמש המקלדת עשוי למקד משהו שקורא המסך אינו מכריז. תמיד שלבו את זה עם הסתרה ויזואלית ממשית.

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

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