נגישות לתמיכה

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

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

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

שילוב של אמצעי בקרה נגישים בממשק המשתמש

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

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

אמצעי בקרה רגילים

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

WAI-ARIA באמצעי בקרה בהתאמה אישית

Web Accessibility Initiative – אפליקציות אינטרנט עשירות בגישה, WAI-ARIA, מפרט להפיכת הפקדים של ממשק המשתמש לנגישים לקוראי מסך באמצעות קבוצה סטנדרטית של DOM . המאפיינים האלה מספקים לקורא המסך מידע על הפונקציה ועל במצב של אמצעי הבקרה בדף אינטרנט.

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

<div role="toolbar">

המאפיין aria-activedescendant מציין איזה צאצא של סרגל כלים מקבל מיקוד כאשר סרגל הכלים מקבל מיקוד. הקוד tabindex="0" מציין שסרגל הכלים מקבל מיקוד סדר המסמכים.

עיינו במפרט המלא של סרגל כלים לדוגמה שבהמשך:

<div role="toolbar" tabindex="0" aria-activedescendant="button1">
  <img src="buttoncut.png" role="button" alt="cut" id="button1">
  <img src="buttoncopy.png" role="button" alt="copy" id="button2">
  <img src="buttonpaste.png" role="button" alt="paste" id="button3">
</div>

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

למדריך מהיר על הוספת פקדים של WAI-ARIA לאמצעי בקרה מותאמים אישית, ראו דייב ראג'ט (Dave Raggett) מצגת מ-WWW2010.

התמקדות באמצעי בקרה מותאמים אישית

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

כברירת מחדל, רק רכיבי ה-DOM של HTML שיכולים לקבל את המיקוד במקלדת הם עוגנים, לחצנים ופקדי טפסים. עם זאת, הגדרת המאפיין HTML‏ tabIndex לערך 0 תציב את רכיבי ה-DOM בסדר הכרטיסיות שמוגדר כברירת מחדל, וכך תאפשר להם לקבל את המיקוד של המקלדת.

element.tabIndex = 0

element.focus();

ההגדרה tabIndex = -1 מסירה את הרכיב מרצף הטאבים, אבל עדיין מאפשרת לרכיב לקבל את המיקוד של המקלדת באופן פרוגרמטי.

תמיכה בגישה מהמקלדת

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

ניווט

מוודאים שמשתמשים יכולים לנווט בין חלקים שונים בתוסף בלי להשתמש בעכבר. בודקים שאפשר לנווט באמצעות מקלדת בכל שימוש בחלון קופץ. להשתמש במקשי הקיצור של Chrome כדי לקבוע אם ניתן לנווט בתוסף.

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

קיצורי דרך

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

handler פשוט של מקלדת JavaScript יכול להיראות כך. שימו לב איך המאפיין WAI-ARIA aria-activedescendant עודכן בתגובה לקלט של משתמשים, כדי לשקף את סרגל הכלים הפעיל הנוכחי לחצן.

 function optionKeyEvent(event) {
  var tb = event.target;
  var buttonid;

  ENTER_KEYCODE = 13;
  RIGHT_KEYCODE = 39;
  LEFT_KEYCODE = 37;
  // Partial sample code for processing arrow keys.
  if (event.type == "keydown") {
    // Implement circular keyboard navigation within the toolbar buttons
    if (event.keyCode == ENTER_KEYCODE) {
      ExecuteButtonAction(getCurrentButtonID());
      // getCurrentButtonID defined elsewhere
    } else if (event.keyCode == event.RIGHT_KEYCODE) {
      // Change the active toolbar button to the one to the right (circular).
      var buttonid = getNextButtonID();
      // getNextButtonID defined elsewhere
      tb.setAttribute("aria-activedescendant", buttonid);
    } else if (event.keyCode == event.LEFT_KEYCODE) {
      // Change the active toolbar button to the one to the left (circular).
      var buttonid = getPrevButtonID();
      // getPrevButtonID defined elsewhere
      tb.setAttribute("aria-activedescendant", buttonid);
    } else {
      return true;
    }
    return false;
  }
}

<div role="toolbar" tabindex="0" aria-activedescendant="button1" id="tb1"
     onkeydown="return optionKeyEvent(event);"
     onkeypress="return optionKeyEvent(event);">
  <img src="buttoncut" role="button" alt="cut" id="button1">
  <img src="buttoncopy" role="button" alt="copy" id="button1">
  <img src="buttonpaste" role="button" alt="paste" id="button1">
</div>

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

מתן תוכן נגיש

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

טקסט

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

כדי לבדוק את הגמישות של ממשק המשתמש של התוסף, כדאי לבצע את הבדיקה של 200%: אם גודל הטקסט או התצוגה הממוגדלת של הדף מוגדלים ב-200%, האם עדיין אפשר להשתמש בהם?

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

צבעים

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

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

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

צליל

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

תמונות

מומלץ לספק טקסט חלופי מידעתי לתמונות.

<img src="img.jpg" alt="The logo for the extension">

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

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

מידע נוסף

מידע נוסף על נגישות ב-Chrome זמין בערוץ A11ycasts וקריאת המאמר באמצעות מסמכי התיעוד הטכניים לנגישות ב-Chromium.