ARIA (Accessible Rich Internet Applications) היא קבוצת תכונות שמוסיפים לקוד HTML כדי לספר לטכנולוגיות מסייעות — בעיקר קוראי מסך — מה רכיב הוא, באיזה מצב הוא נמצא ואיך הוא קשור לרכיבים אחרים. למשל: שהכפתור הזה פותח תפריט, שהתפריט כרגע סגור, ושהשגיאה הזו שייכת לשדה הטלפון. ARIA לא משנה איך הרכיב נראה או מתנהג — רק איך הוא מתואר. ולכן הכלל הראשון שלה הוא בדרך כלל: אל תשתמשו בה אם יש רכיב HTML מובנה שעושה את העבודה.
הכללים של W3C לשימוש ב-ARIA
המסמך Using ARIA של W3C מגדיר כמה כללים. בתמצית:
- אם אפשר להשתמש ברכיב או בתכונה של HTML עם המשמעות וההתנהגות שצריך — משתמשים בהם, במקום להלביש ARIA על רכיב אחר.
- לא משנים את המשמעות המובנית של רכיב, אלא אם באמת אין ברירה.
- כל רכיב אינטראקטיבי עם ARIA חייב לעבוד במקלדת.
- לא מסתירים מטכנולוגיה מסייעת רכיב שאפשר להגיע אליו בפוקוס (בלי
aria-hidden="true"אוrole="presentation"על רכיב כזה).
למה יותר ARIA לא אומר יותר נגישות
WebAIM Million 2026 מצא ARIA ב-82.7% מעמודי הבית — עם יותר מ-133 תכונות ARIA בעמוד בממוצע. אבל בעמודים עם ARIA נמצאו בממוצע 59.1 שגיאות שזוהו אוטומטית, לעומת 42 בעמודים בלי ARIA. זה מתאם, לא בהכרח סיבה ותוצאה: עמודים עם ARIA הם בדרך כלל גם מורכבים יותר. אבל זה מראה ש-ARIA לבד לא פותרת בעיות, ושימוש לא נכון בה יכול להוסיף כאלה. ARIA שגויה גרועה לפעמים מהיעדר ARIA: היא גורמת לקורא המסך להבטיח התנהגות שהרכיב לא מספק.
דוגמה: כפתור
הגרסה הבעייתית — div שמתחפש לכפתור:
<div class="btn" role="button" tabindex="0" onclick="send()">שליחה</div>
גם עם role ו-tabindex, הוא עדיין לא מגיב למקשי Enter ורווח בלי קוד JavaScript נוסף. הגרסה הנכונה פשוטה יותר:
<button type="button" onclick="send()">שליחה</button>
פוקוס, מקלדת ותיאור לקורא המסך — הכול מגיע מובנה. זה הכלל הראשון בפעולה.
איפה ARIA כן נחוצה
| מצב | תכונה נפוצה | מה היא עושה |
|---|---|---|
| כפתור עם אייקון בלבד (חיפוש, סגירה, תפריט) | aria-label |
נותנת לכפתור שם שקורא המסך מקריא |
| כפתור שפותח ומקפל תפריט או אזור | aria-expanded |
מודיעה אם האזור פתוח או סגור |
| הודעת שגיאה או הסבר לשדה | aria-describedby |
מקשרת את ההסבר לשדה, כדי שיוקרא איתו |
| הודעה שמופיעה בלי טעינת עמוד ("נוסף לסל") | aria-live |
גורמת לקורא המסך להכריז על השינוי |
| הקישור לעמוד הנוכחי בתפריט | aria-current |
מודיעה "עמוד נוכחי" |
| אייקון קישוטי ליד טקסט | aria-hidden |
מסתירה אותו מקורא המסך כדי שלא יוקרא סתם |
דוגמה: כפתור תפריט מובייל
<button type="button" aria-expanded="false" aria-controls="main-menu"> <span class="icon" aria-hidden="true"></span> תפריט </button>
כשהתפריט נפתח, הקוד משנה את aria-expanded ל-true. אם הערך לא מתעדכן, קורא המסך ימשיך להכריז "מקופל" — וזו בדיוק ARIA שמשקרת. על תפריטים נגישים כתבתי בתפריט ניווט לאתר.
הטעויות הנפוצות
- role בלי התנהגות —
role="button",role="tab"אוrole="menu"בלי הקוד שמממש את המקלדת שהתפקיד הזה מבטיח. - aria-label שסותר את הטקסט הגלוי — הכפתור כתוב "הזמינו עכשיו" וקורא המסך אומר "כפתור ראשי". משתמשים בשליטה קולית אומרים את מה שהם רואים, וזה לא עובד.
- aria-hidden על משהו שמקבל פוקוס — המשתמש מגיע לרכיב שקורא המסך לא מכיר.
- role="menu" על תפריט ניווט של אתר — התפקיד הזה מיועד לתפריטי יישום (כמו תפריט קובץ), ומשנה את האופן שבו קורא המסך מנווט. לתפריט אתר מספיקים
navורשימת קישורים. - תכונות שמועתקות מספרייה בלי להבין אותן — ונשארות עם ערכים שלא מתעדכנים.
ARIA ונגישות של האתר כולו
ARIA היא כלי עדין להשלמת פערים, לא דרך להנגיש אתר. רוב בעיות הנגישות — ניגודיות, טקסט חלופי, תוויות לטפסים, קישורים ריקים — נפתרות ב-HTML ובתוכן, בלי ARIA בכלל. ותוספי נגישות ש"מוסיפים ARIA אוטומטית" נוטים לייצר בדיוק את הטעויות שברשימה למעלה. ראו תוסף נגישות לאתר וניווט במקלדת.
שאלות נפוצות
איך בודקים אם ה-ARIA באתר תקינה?
כלים אוטומטיים כמו axe מזהים שגיאות בסיסיות (תכונה לא חוקית, ערך חסר). אם היא באמת עובדת — רק בבדיקה עם קורא מסך ומקלדת. ראו בדיקה עם קורא מסך.
וורדפרס מוסיף ARIA לבד?
חלק מרכיבי הליבה כן, ותבניות טובות משתמשות בה נכון. אבל תוספים ובוני עמודים מוסיפים לעיתים קרובות ARIA שגויה. ראו הנגשת אתר וורדפרס.
אם יש לי HTML סמנטי, צריך ARIA בכלל?
בדרך כלל רק במקומות ספציפיים: כפתורי אייקון, רכיבים שנפתחים ונסגרים, והודעות דינמיות.
בתבניות שאני כותב, HTML סמנטי בא קודם ו-ARIA רק איפה שהוא באמת חסר. פירוט בעמוד הנגשת אתרים, ואפשר לפנות אליי.
אהבתם את המאמר?
