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

WAI-ARIA בפקדים בהתאמה אישית
Web Accessibility Initiative - Accessible Rich Internet Applications (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>
אחרי שמוסיפים תפקידים, מצבים ומאפיינים של WAI-ARIA ל-DOM של אמצעי בקרה, Google Chrome מעלה את האירועים המתאימים לקורא המסך. התמיכה ב-WAI-ARIA עדיין בפיתוח, ולכן יכול להיות ש-Google Chrome לא יציג אירוע לכל מאפיין של WAI-ARIA, וקוראי המסך לא יזהו את כל האירועים שמוצגים.
במצגת של דייב רגט מ-WWW2010 יש הדרכה קצרה להוספת אמצעי בקרה של WAI-ARIA לאמצעי בקרה בהתאמה אישית.
מיקוד בפקדים מותאמים אישית
התמקדות במקלדת חיונית למשתמשים שמנווטים באינטרנט בלי עכבר. מוודאים שאמצעי בקרה של הפעלה וניווט, כמו לחצנים, תיבות רשימה וסרגלי תפריטים, יכולים לקבל מיקוד במקלדת.
כברירת מחדל, הרכיבים היחידים ב-HTML DOM שיכולים לקבל מיקוד במקלדת הם תגי עוגן, לחצנים ופקדי טפסים. עם זאת, הגדרת מאפיין ה-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%, האם עדיין אפשר להשתמש בו?
מומלץ להימנע מהוספת טקסט לתמונות. המשתמשים לא יכולים לשנות את הגודל, וקוראי המסך לא יכולים לפרש את התמונות. במקום זאת, כדאי לבחור גופן אינטרנט עם סגנון, כמו אחד מהגופנים שזמינים ב-Google Font API. גופנים לאינטרנט יכולים להשתנות בהתאם לגודל, ואנשים שמשתמשים בקוראי מסך יכולים לגשת אליהם.
צבעים
צריכה להיות ניגודיות מספקת בין צבע הרקע לצבע הטקסט בתוסף. משתמשים בכלי לבדיקת ניגודיות כדי לבדוק אם יש ניגודיות מתאימה בין צבע הרקע לצבע החזית.
כשבודקים את הניגודיות, מוודאים שכל חלק בתוסף שמסתמך על גרפיקה כדי להעביר מידע נראה בבירור. כדי לראות איך תמונה נראית בצורות שונות של לקות בראיית צבעים, אפשר להשתמש בכלים כמו Coblis—Color Blindness Simulator.
כדאי להציע עיצובים שונים בצבעים, או לאפשר למשתמשים להתאים אישית את ערכת הצבעים, כדי ליצור ניגודיות טובה יותר.
צליל
אם התוסף מסתמך על צליל או על סרטון כדי להעביר מידע, צריך לוודא שיש כתוביות או תמליל. מידע נוסף על כתוביות זמין בהנחיות של תוכנית המדיה עם תיאור וכתוביות.
תמונות
כדאי לספק טקסט חלופי לתמונות שיהיה אינפורמטיבי.
<img src="img.jpg" alt="The logo for the extension">
כדאי להשתמש בטקסט החלופי כדי לציין את המטרה של התמונה ולא תיאור מילולי של התוכן שלה. תמונות של רווחים או תמונות שהן רק קישוט צריכות לכלול טקסט חלופי ריק "" או להיות מוסרות לחלוטין מה-HTML ומוצבות ב-CSS.
אם התוסף חייב להשתמש בטקסט בתמונה, צריך לכלול את הטקסט של התמונה בטקסט החלופי. מקור מידע טוב בנושא הוא המאמר של WebAIM על טקסט חלופי מתאים.
מידע נוסף
כדי לקבל מידע נוסף על נגישות ב-Chrome, אפשר לעיין בערוץ A11ycasts ולקרוא את התיעוד הטכני בנושא נגישות ב-Chromium.