ARIA ו-HTML

רוב המפתחים מכירים את שפת התיוג הסטנדרטית של האינטרנט המודרני, HyperText Markup Language (HTML). יכול להיות שאתם פחות מכירים את Accessible Rich Internet Applications (ARIA) (בעבר נקרא WAI-ARIA): מה זה, איך משתמשים בזה, מתי כדאי להשתמש בזה ומתי לא כדאי להשתמש בזה.

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

סקירה של היסטוריה קצרה של ARIA, למה היא חשובה ומתי ואיך הכי מומלץ להשתמש בה.

מבוא ל-ARIA

‫ARIA פותחה לראשונה בשנת 2008 על ידי קבוצת Web Accessibility Initiative (WAI) – קבוצת משנה של World Wide Web Consortium (W3C)‎, שמנהלת ומפקחת על האינטרנט.

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

‫"WAI-ARIA,‏ החבילה Accessible Rich Internet Applications, מגדירה דרך להנגשת תוכן אינטרנט ואפליקציות אינטרנט לאנשים עם מוגבלויות. הוא עוזר במיוחד עם תוכן דינמי ואמצעי בקרה מתקדמים בממשק המשתמש שפותחו באמצעות HTML,‏ JavaScript וטכנולוגיות קשורות."

קבוצת WAI

עץ הנגישות

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

עץ הנגישות נוצר על ידי הדפדפן ומבוסס על עץ DOM (Document Object Model) רגיל. בדומה לעץ ה-DOM, עץ הנגישות מכיל אובייקטים שמייצגים את כל רכיבי התיוג, המאפיינים וצמתי הטקסט. ממשקי API להטמעת תכונות נגישות בפלטפורמות ספציפיות משתמשים גם בעץ הנגישות כדי לספק ייצוג שטכנולוגיות מסייעות יכולות להבין.

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

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

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

<div role="button">Self-destruct</div>

מאפיינים מבטאים מאפיינים או קשרים לאובייקט.

<div role="button" aria-describedby="more-info">Self-destruct</div>

<div id="more-info">This page will self-destruct in 10 seconds.</div>

המאפיינים states ו-values מגדירים את התנאים הנוכחיים או את ערכי הנתונים שמשויכים לרכיב.

<div role="button" aria-describedby="more-info" aria-pressed="false">
  Self-destruct
</div>

<div id="more-info">
  This page will self-destruct in 10 seconds.
</div>

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

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

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

בשנת 2014, ארגון W3C פרסם באופן רשמי את ההמלצה לשימוש ב-HTML5. הגרסה הזו כללה כמה שינויים משמעותיים, כולל הוספה של רכיבי ציון דרך כמו <main>,‏ <header>,‏ <footer>,‏ <aside>,‏ <nav> ומאפיינים כמו hidden ו-required. בעזרת רכיבי ומאפייני HTML5 חדשים אלה, בשילוב עם תמיכה משופרת בדפדפן, חלקים מסוימים ב-ARIA חשובים פחות עכשיו.

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

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

כלל 1: לא להשתמש ב-ARIA

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

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

<a role="button">Submit</a>

<button>Submit</button>

אם יש ספק, כדאי להשתמש ברכיבי HTML סמנטיים.

כלל 2: לא מוסיפים (מיותר) ARIA ל-HTML

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

<h2 role="tab">Heading tab</h2>

<div role="tab"><h2>Heading tab</h2></div>

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

כלל 3: תמיד לתמוך בניווט במקלדת

כל אמצעי הבקרה האינטראקטיביים (שלא הושבתו) של ARIA חייבים להיות נגישים באמצעות המקלדת. אפשר להוסיף tabindex= "0" לכל רכיב שצריך מיקוד שלא מתקבל בדרך כלל מהמקלדת. מומלץ להימנע משימוש באינדקסים של מקשי Tab עם מספרים שלמים חיוביים ככל האפשר, כדי למנוע בעיות אפשריות בסדר המיקוד של המקלדת.

<span role="button" tabindex="1">Submit</span>

<span role="button" tabindex="0">Submit</span>

כלל 4: אל תסתירו רכיבים שאפשר להתמקד בהם

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

<div aria-hidden="true">
  <button>Submit</button>
</div>

<div>
  <button>Submit</button>
</div>

כלל 5: שימוש בשמות נגישים לרכיבים אינטראקטיביים

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

שמות נגישים יכולים להיות התוכן שמוקף ברכיב (במקרה של <a>), טקסט חלופי או תווית.

בכל אחת מדוגמאות הקוד הבאות, תווית הנגישות היא Red leather boots.

<!-- A plain link with text between the link tags. -->
<a href="shoes.html">Red leather boots</a>

<!-- A linked image, where the image has alt text. -->
<a href="shoes.html"><img src="shoes.png" alt="Red leather boots"></a>

<!-- A checkbox input with a label. -->
<input type="checkbox" id="shoes">
<label for="shoes">Red leather boots</label>

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

‫ARIA ב-HTML

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

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

כדאי לעיין בדוגמאות.

<a role="heading">Read more</a>

<a aria-label="Read more about some awesome article title">Read More</a>

<ul role="list">...</ul>

<ul>...</ul>

<details>
  <summary role="button">more information</summary>
  ...
</details>

<details>
  <summary>more information</summary>
  ...
</details>

מורכבויות של ARIA

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

יש הרבה דברים שצריך לשים לב אליהם, כולל, בין היתר: אינטראקציות עם המקלדת, ממשקי מגע, תמיכה בטכנולוגיה מסייעת (AT) או בדפדפן, צורכי תרגום, מגבלות סביבתיות, קוד מדור קודם והעדפות משתמשים. ידע מועט בתכנות עלול להזיק – או סתם להיות מעצבן – אם משתמשים בו בצורה לא נכונה.

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