יחידה 10 / 11

בינה מלאכותית בנגישות ועיצוב כולל

רווחים:

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

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

WCAG ואזורי בקרה מרכזיים

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

  • ניגודיות צבע: האם ההבדל בין טקסט לרקע מספיק? (עבור AA, יחס של 4.5:1 לפחות בטקסט רגיל.)
  • טקסט חלופי (טקסט חלופי): האם לתמונות יש טקסט מקביל שמסביר אותן לקורא המסך?
  • גישה למקלדת: האם אפשר לעשות כל דבר בלי עכבר? האם סדר המיקוד הגיוני?
  • מידע בצבע בלבד: ביטויים כמו "מלא שדות אדומים" אינם כוללים את המשתמש עיוור צבעים.
  • תוויות טופס: האם לכל שדה קלט יש תווית שקורא המסך יקרא?
  • יעד מגע: האם הכפתורים גדולים מספיק כדי ללחוץ עליהם בנוחות עם האצבעות?

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

זהירות: רק בגלל שה-AI אומר "זה נראה נגיש" אינו ערובה לנגישות. הבדיקה האוטומטית תופסת רק חלק מהשגיאות של WCAG; השאר יצוצו עם השימוש בפועל.

טקסט חלופי: הסוד של טקסט חלופי טוב

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

ויזואלי

סאבטקסט חלש

סאבטקסט חזק

סמל העגלה (לחצן)

"סמל עגלה, צבע אפור"

"הוסף לעגלה"

תמונת מוצר

"תמונה"

"מעיל חורף כחול, מבט קדמי"

קו דקורטיבי

"קו קישוט"

(להשאיר ריק - דקורטיבי)

גרפיקה

"תמונה גרפית"

"מכירות 2024: גידול בכל רבעון"

שפה והיקף כולל

הנגישות אינה מוגבלת לפקדים טכניים; גם השפה כוללת. טקסט המניח מגדר ("המשתמש ובן זוגו"), אינו כולל על סמך יכולת ("מבט", "לשמוע בקלות"), או מכיל הנחות תרבותיות, לא יכלול חלק מהמשתמשים. ה-AI יכול לסרוק את הטקסט מנקודת מבט זו, אך עליך לוודא שהשפה ה"נייטרלית" שהיא מציעה תישאר טבעית ומובנת; תיקון יתר עלול להפוך את הטקסט למסורבל.

שלושה מיני תיקים

מקרה 1 - שגיאות ניגודיות שנתפסו מוקדם. צוות העביר AI לסרוק את צבעי הטקסט של 20 מסכים וקבע שהניגודיות הייתה מתחת לסף AA ב-7 מקומות. התיקונים בוצעו מבלי להיכנס לפיתוח; עלות התיקון לאחר מכן נמנעה. אבל הצוות עדיין לא דילג על מבחן קורא המסך בפועל.

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

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

הנחיות הניתנות להעתקה

סרוק מראש את תיאור הממשק הזה לצורך נגישות: 1) האם יש מידע שמועבר אך ורק על סמך צבע? 2) האם יש תווית טקסט לכל אלמנט שניתן ללחוץ עליו? 3) האם יש אלמנטים שלא ניתן לגשת אליהם דרך המקלדת? 4) האם סדר המיקוד הגיוני? רשום כל בעיה והצעה. הוסף הערה "נדרש מבחן אמיתי". מתכון: <<text>>

הצע טקסט חלופי עבור תמונות אלה. כלל: להעביר את הפונקציה/משמעות של התמונה, לא את הפרט הדקורטיבי. כתוב את הפעולה עבור סמלי הכפתורים. לתמונות דקורטיביות, אמור "טקסט חלופי צריך להיות ריק". תיאורי הקשר ותמונה: <<list>>

בדוק את הטקסטים האלה עבור שפה כוללת: האם יש הנחות מגדריות, שפה מניעה מבוססת יכולות (כגון "לראות", "לשמוע"), הנחות תרבותיות? הצע חלופות שנותרו טבעיות; אל תתקן יתר על המידה.טקסטים: <<רשימה>>

כתוב שגיאה נגישה וטקסט תווית עבור טופס זה: תווית גלויה לכל שדה, תיאור עבור קורא המסך והודעה המתארת ​​את השגיאה, ללא קשר לצבע (טקסט + סמל). קול וטון: <<card>>שדות טופס: <<list>>

הנחיה חלשה / הנחיה חזקה

חלש: "כתוב טקסט חלופי לתמונה זו."

התוצאה: "תמונה" או טקסט תיאורי מדי שמפספס את הפונקציה.

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

התוצאה: סאבטקסטים קונטקסטואליים, מוכווני פונקציה, מדויקים.

הבדל: הנחיה חזקה מביאה למיקוד פונקציונלי + קונבנצית כפתורים + הבחנה דקורטיבית.

טעויות נפוצות

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

לסיכום

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

משימת יישום

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

רשימת בדיקה

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