בודקים שלכל אמצעי הבקרה המותאמים אישית יש role מתאים וכל מאפייני ה-ARIA הנדרשים שמעניקים להם את המאפיינים והמצב שלהם.
לדוגמה, הנתונים של תיבת סימון בהתאמה אישית צריכים להיות role="checkbox" ו-aria-checked="true|false" כדי להעביר את המצב בצורה תקינה.
כדאי ללמוד איך משתמשים ב-ARIA וב-HTML כדי להבין מתי כדאי לספק סמנטיקה חסרה לאמצעי בקרה מותאמים אישית.
איך בודקים
כדי לוודא שלכל אמצעי הבקרה האינטראקטיביים המותאמים אישית יש תפקידים מתאימים של ARIA, צריך לבדוק את הדף באמצעות חלונית הנגישות של כלי הפיתוח ל-Chrome או באמצעות קורא מסך.
JAWS ו-NVDA הם שניים מקוראי המסך הפופולריים ביותר ל-Windows. VoiceOver הוא קורא המסך המובנה ב-macOS.
באמצעות CSS, אפשר להגדיר סגנון לרכיבים <div> ו-<button> כדי להעביר את אותן תכונות חזותיות, אבל החוויה שונה מאוד כשמשתמשים בקורא מסך. <div> הוא רק רכיב כללי של קיבוץ, ולכן קורא מסך מקריא רק את תוכן הטקסט של <div>.
ה-<button> מופיע כ'לחצן', אות חזק יותר למשתמש שהוא יכול לבצע איתו פעולה.
אפשר לעיין גם במאמר סמנטיקה וקוראי מסך.
איך לתקן
הפתרון הטוב ביותר לבעיה הזו הוא להימנע לחלוטין מפקדים אינטראקטיביים בהתאמה אישית. לדוגמה, מחליפים <div> שפועל כמו לחצן ב-<button> ממשי.
<button>Learn more</button>
אם אתם חייבים להשתמש ב-<div>, מוסיפים את role="button" ואת aria-pressed="false".
<div role="button" aria-pressed="false">Learn more</div>
עכשיו קוראי מסך מכריזים על התפקיד ועל מצב האינטראקטיבי של <div>.
למה זה חשוב
אם לא השתמשתם בעבר בטכנולוגיה מסייעת, יכול להיות שלא תדעו איך ביצועי התוכן אצל משתמשים בטכנולוגיות מסייעת. רצוי לדבר עם משתמשים שמשתמשים בטכנולוגיה מסייעת באופן קבוע ויכולים לשתף משוב על הביצועים של האתר או אפליקציית האינטרנט שלכם.
דרך נוספת להבין איך משתמשים בטכנולוגיות מסייעות חווים את התוכן שלכם היא לבדוק אותו באמצעות טכנולוגיות מסייעות. שימוש בקורא מסך יעזור לכם להבין טוב יותר איך התוכן מתויג, ואם יש מכשולים לניווט.
משאבים
אפשר לעיין בקוד המקור של הביקורת לפקדים מותאמים אישית יש תפקידים של ARIA