רוב המפתחים מכירים את שפת הסימון הרגילה של האינטרנט המודרני, 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, חבילת אפליקציות האינטרנט העשירות והנגישות, מגדירה דרך להפוך תוכן אינטרנט ויישומי אינטרנט לנגישים יותר לאנשים עם מוגבלויות. הוא עוזר במיוחד בתוכן דינמי ובפקדים מתקדמים בממשק המשתמש שפותחו באמצעות HTML, JavaScript וטכנולוגיות קשורות".
קבוצת WAI
עץ הנגישות
ב-ARIA משנים קוד שגוי או חלקי כדי ליצור חוויית שימוש טובה יותר ב-AT על ידי שינוי, חשיפה והרחבה של חלקים בעץ הנגישות.
עץ הנגישות נוצר על ידי הדפדפן ועל סמך העץ הרגיל של Document Object Model (DOM). בדומה לעץ ה-DOM, עץ הנגישות מכיל אובייקטים שמייצגים את כל רכיבי תגי העיצוב, המאפיינים וצומתי הטקסט. עץ הנגישות משמש גם ממשקי API לנגישות שספציפיים לפלטפורמה, כדי ליצור ייצוג שטכנולוגיות מסייעות יכולות להבין.
ה-ARIA כשלעצמה לא משנה את הפונקציונליות או את המראה החזותי של הרכיב. המשמעות היא שרק משתמשי AT יבחינו בהבדלים בין מוצר דיגיטלי עם 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>
מצבים/ערכים מגדירים את התנאים הנוכחיים או את ערכי הנתונים המשויכים לרכיב.
<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 בקוד הבסיס מבטיח שלמשתמשים ב-AT יהיה כל המידע שהם צריכים כדי להשתמש באתר, באפליקציה או במוצר דיגיטלי אחר בהצלחה ובשוויון.
לאחרונה, כלי הפיתוח ל-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 מיליונים מצא שבדפי בית עם ARIA היו בממוצע 70% יותר שגיאות שזוהו בדפים בלי ARIA, בעיקר בגלל הטמעה לא נכונה של מאפייני ה-ARIA.
לכלל הזה יש חריגים. יש צורך ב-ARIA כשלרכיב HTML אין תמיכה בנגישות. הסיבה לכך יכולה להיות שהעיצוב אינו מאפשר לרכיב HTML מסוים, או שהתכונה/התנהגות הרצויה אינה זמינה ב-HTML. עם זאת, מצבים כאלה אמורים להיות מועטים.
<a role="button">Submit</a>
<button>Submit</button>
אם יש לכם ספק, השתמשו ברכיבי HTML סמנטיים.
כלל 2: אין להוסיף ל-HTML ARIA (מיותר)
ברוב המקרים, רכיבי HTML פועלים היטב ללא צורך בהוספת ARIA אליהם. למעשה, מפתחים שמשתמשים ב-ARIA צריכים לעיתים קרובות להוסיף קוד נוסף כדי שהרכיבים יהיו פונקציונליים במקרה של רכיבים אינטראקטיביים.
<h2 role="tab">Heading tab</h2>
<div role="tab"><h2>Heading tab</h2></div>
כשמשתמשים ברכיבי HTML באופן מכוון, אפשר לצמצם את העבודה ולקבל קוד עם ביצועים טובים יותר.
כלל 3: תמיכה תמיד בניווט באמצעות המקלדת
כל פקדי ה-ARIA האינטראקטיביים (לא מושבתים) חייבים להיות נגישים באמצעות המקלדת. אפשר להוסיף את tabindex= "0" לכל רכיב שמצריך מיקוד שבדרך כלל לא מקבל מיקוד במקלדת. כדאי להימנע ככל האפשר משימוש באינדקסי כרטיסיות עם מספרים שלמים חיוביים כדי למנוע בעיות אפשריות בסדר המיקוד של המקלדת.
<span role="button" tabindex="1">Submit</span>
<span role="button" tabindex="0">Submit</span>כמובן, אם אפשר, כדאי להשתמש ברכיב
<button> אמיתי במקרה הזה.
כלל 4: אל תסתירו רכיבים שניתנים למיקוד
אין להוסיף role= "presentation" או aria-hidden= "true" לרכיבים
שצריכים להתמקד בהם, כולל רכיבים עם tabindex= "0". כשמוסיפים את התפקידים/המצבים האלה לרכיבים, המערכת שולחת ל-AT הודעה על כך שהרכיבים האלה לא חשובים, ויש לדלג עליהם. דבר זה עלול לגרום לבלבול או הפרעה למשתמשים שמנסים לבצע אינטראקציה עם רכיב.
<div aria-hidden="true"><button>Submit</button></div>
<div><button>Submit</button></div>
כלל 5: שימוש בשמות נגישים לרכיבים אינטראקטיביים
המטרה של הרכיב האינטראקטיבי צריכה להיות מוצגת למשתמש לפני שהוא יודע איך ליצור איתו אינטראקציה. מוודאים שלכל האלמנטים יש שם נגיש לאנשים שמשתמשים במכשירי AT.
שמות נגישים יכולים להיות התוכן שמוקף ברכיב (במקרה של <a>), בטקסט חלופי או בתווית.
השם הנגיש לכל אחת מדוגמאות הקוד הבאות הוא 'מגפי עור אדומים'.
<!-- 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 בדפוסים שדורשים רמת תמיכה גבוהה יותר ב-AT בגלל אילוצים סביבתיים, או כשיטת גיבוי לרכיבי 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/בדפדפן, צורכי תרגום, אילוצים סביבתיים, קוד מדור קודם והעדפות משתמש. קצת ידע בתכנות יכול להזיק, או פשוט מעצבן, אם משתמשים בו בצורה שגויה. הקוד צריך להיות פשוט.
מלבד האזהרות האלה, נגישות דיגיטלית היא לא מצב של הכול או כלום, אלא ספקטרום שמאפשר לראות אזורים אפורים כאלה. כמה פתרונות תכנות יכולים להיראות כ "נכונים", בהתאם למצב. מה שחשוב הוא שתמשיכו ללמוד, לבדוק ולנסות להפוך את העולם הדיגיטלי שלנו לפתוח יותר לכולם.
בדיקת ההבנה
בחינת הידע שלכם ב-ARIA וב-HTML
מהי השיטה המומלצת ליצירת לחצן נגיש?
<div id="saveChanges" aria-role="button" aria-pressed="false" tabindex="0">Go to shop</div><a id="saveChanges" aria-label="Some awesome article title">Go to shop</a><button id="saveChanges" type="button">Go to shop</button>