לפי מאמר הדן בהטמעת סוכני בינה מלאכותית, צוותים בכל מקום ממהרים לפרוס סוכנים אלה, ובמקביל מתלווה לתהליך הנחה רווחת לפיה הסוכנים חכמים מספיק כדי להתמודד עם נושא הנגישות באופן מובנה ומוכן לשימוש. המאמר קובע כי הנחה זו אינה נכונה, והסיבה לכך ברורה: סוכני בינה מלאכותית אינם חיים עם מוגבלות, בעוד שבני אדם כן חיים עם מוגבלות. כאשר צוותים מניחים כי סוכן כבר יודע מה אדם המשתמש בקורא מסך, במכשיר מתג (switch device) או בשליטה קולית באמת צריך מממשק, נוצר מה שהמחברים מכנים "פער הנגישות" (accessibility gap). מודל טוב יותר לא יפתור את הבעיה הזו, אך תכנון ועיצוב מכוונים כן יפתרו אותה.
מדוע בינה מלאכותית אינה יכולה לפתור את בעיית הנגישות בעצמה
לפי המאמר, סוכני בינה מלאכותית מאומנים על גבי רשת האינטרנט כפי שהיא קיימת כיום, והרשת הקיימת אינה נגישה במיוחד. לפי דוח משנת 2026 של WebAIM בנושא נגישות של מיליון דפי הבית המובילים, ל-95% מתוך מיליון האתרים המובילים שנבדקו יש לפחות כשל אחד בהנחיות הנגישות לתוכן אינטרנט (WCAG) בדף הבית שלהם בלבד. בנוסף, כלי בדיקה אוטומטיים, שהם הכלים שרוב הצוותים מסתמכים עליהם כדי לאתר בעיות אלה, מזהים מלכתחילה רק כ-30% עד 40% מהכשלים בקריטריוני ההצלחה של WCAG.
פער זה בא לידי ביטוי באופן שונה בהתאם לאופן שבו אדם חווה את הממשק. משתמשים בקוראי מסך מאבדים מעקב אחר תוכן שנוצר באופן דינמי: ללא ניהול פוקוס נכון או אזורים חיים (live regions), אין להם דרך לדעת האם הדף בכלל ביצע פעולה כלשהי. אנשים עם מוגבלויות מוטוריות מתמודדים עם ממשק שאינו מפסיק לזוז, כך שממשק משתמש שמשתנה ללא הרף הופך למטרה שנעה בקביעות. כמו כן, אנשים עם מוגבלויות קוגניטיביות חווים עומס כתוצאה מסוכנים שמתנהגים בצורה לא עקבית מרגע לרגע.
המאמר מבהיר כי אין בכך כדי לומר שבינה מלאכותית אינה מסוגלת לבנות בצורה נגישה. המשמעות היא שיש להגדיר לה במפורש כיצד נראית תוצאה טובה, והגדרה זו חייבת להיות מעוגנת באופן שבו בני אדם אמיתיים עובדים בפועל.
עיצוב חוויות בינה מלאכותית לאורך ממדי מוגבלות
כדי לבנות מתוך כוונה, הגישה המוצגת במאמר אינה מתחילה בהנדסת פרומפטים (prompt engineering), אלא מתחילה במקום שבו עיצוב טוב תמיד התחיל: באנשים. הגישה מתחלקת לשלושה שלבים מרכזיים:
השלב הראשון הוא הרחבת הפרסונות הקיימות לאורך ממדי מוגבלות שונים. לפי המאמר, סביר להניח שכבר יש לכם פרסונות, ויש להרחיב אותן על פני שלושה ממדים: הממד החזותי (משתמשי קוראי מסך, ראייה ירודה ועיוורון צבעים); הממד המוטורי (משתמשים במקלדת בלבד, גישה באמצעות מתגים ומיומנות תנועה מוגבלת); והממד הקוגניטיבי (משתמשים הזקוקים לפריסות פשוטות יותר, פחות הסחות דעת ותהליכי עבודה צפויים).
כדוגמה לכך, המאמר מציג את ג'יימס, אנליסט תוכניות בסוכנות פדרלית שמעוניין ש-Agentforce יסייע לו לתמצת דוחות עמוסים במהירות רבה יותר. כמשתמש בסיסי, התסכול שלו הוא כללי: תוכן סוכני נטול הקשר ושקיפות לגבי האופן שבו הבינה המלאכותית משתמשת בהוראותיו. כאשר מרחיבים את הפרסונה של ג'יימס לממד החזותי – בהיותו עיוור מלידה המנווט באמצעות קורא מסך וצג ברייל – מטרתו אינה משתנה, אך התסכול שלו מתחדד באופן ניכר. כאשר טקסט מוזרם דינמי ועדכוני שדות אינם מגיעים לקורא המסך שלו, או כאשר הסוכן אינו מנהל את הפוקוס כראוי, עליו להתמצא מחדש שוב ושוב. המאמר מציין כי אין מדובר באי-נוחות קלה, אלא בהבדל שבין סיום עבודתו לבין היתקעות.
השלב השני הוא הגדרת משימות לביצוע (Jobs to be Done) נגישות. משימה סטנדרטית עבור ג'יימס עשויה להיות מנוסחת כך: "בעת ניתוח דוח תוכנית עמוס, אני רוצה ש-Agentforce יתמצת ממצאים ויאכלס שדות ביקורת כדי שאוכל להשלים את ההערכה שלי מהר יותר". לפי המאמר, זוהי התחלה טובה, אך קיים בה מה שמכונה פער מציאות של בינה מלאכותית (AI reality gap), שכן היא אינה מביאה בחשבון מה קורה כאשר ג'יימס כלל אינו יכול לתפוס את העדכון שהתרחש. הגרסה הנגישה שומרת על מטרתו המקורית אך מציינת את הדרישה האמיתית: "אני רוצה שקורא המסך שלי יקבל סיכומים תמציתיים של מה שהשתנה, יידע מתי מתרחשים עדכונים, וישמור על המיקום שלי, כדי שאוכל לאמת ממצאים ולהגיש את ההערכה שלי מהר יותר מבלי לאבד את ההתמצאות שלי". המאמר מדגיש כי מדובר באותה משימה, אך עם הגדרה חדה וכנה יותר של מה שנדרש להצלחה.
השלב השלישי הוא בדיקה עם משתמשים אמיתיים בטכנולוגיה מסייעת, ולא באמצעות סימולציות. עטיית כיסוי עיניים או הנחת העכבר בצד למשך שעות אחר הצהריים לא יעניקו את הניסיון החי של מי שמשתמש בטכנולוגיה מסייעת מדי יום. כלים אוטומטיים ורשימות תיוג של תאימות מחמיצים את החיכוך בעולם האמיתי שמופיע רק בפועל. המאמר ממליץ לגייס משתתפים החיים עם מוגבלויות אלה, לשתף פעולה עם קבוצות סינגור מקומיות למען אנשים עם מוגבלויות, ולתגמל את המשתתפים בצורה הוגנת, שכן הם מומחי תוכן וכך יש להתייחס אליהם.
תרגום מחקר נגישות לדרישות עיצוב בפרומפטים
לאחר שילוב של פרסונה מורחבת עם משימה נגישה לביצוע, ניתן לכתוב קריטריוני קבלה מכלילים (inclusive acceptance criteria). קריטריונים אלה כוללים בדרך כלל שלושה עד חמישה היגדים בינאריים של מעבר או כישלון (pass or fail), כאשר לפחות אחד מהם מכסה מקרה קצה (edge case). המבנה שלהם מוגדר כך: בהינתן [אדם בהקשר מסוים], כאשר [פעולה מתבצעת], אז [תוצאה צפויה מתרחשת].
המאמר מספק דוגמאות לקריטריונים אלה: עבור משתמשי קוראי מסך: בהינתן משתמש ב-VoiceOver המנווט בעדכון משימה דינמי של Agentforce, כאשר הבינה המלאכותית מסיימת לייצר תגובה, אז אזור חי (live region) מודיע למשתמש שתגובה זמינה. עבור משתמשי מקלדת בלבד: בהינתן משתמש מקלדת בלבד המנווט בזרימת עבודה של Agentforce, כאשר פריטי פעולה מופיעים בתגובת הסוכן, אז כל הפעולות ניתנות להגעה בסדר טאב (tab order) סטנדרטי עם מטרות מגע (touch targets) של לפחות 44×44 פיקסלים.
יש להזין קריטריונים אלה ישירות לתוך הפרומפטים ולצמד אותם לבקשה מפורשת למעקות בטיחות (guardrails) מתוך Salesforce Lightning Design System 2. שילוב זה מבטיח שהמודל יכלול פרמטרים של נגישות משום שהדבר נאמר לו במפורש, ולא מתוך תקווה שיסיק אותם בעצמו בצורה נכונה. בינה מלאכותית יכולה להאיץ את הבנייה ולכתוב את הקוד, אך מה שאינה יכולה לעשות זה להיות האדם שנמצא ליד ההגה, ותפקיד זה עדיין מוטל עלינו.
בדיקת נגישות בשלוש רמות משלימות
לפי המאמר, כלי בדיקה אוטומטיים הם קו הבסיס ולא תקרת הזכוכית. כלים אלה מצטיינים באיתור שגיאות תחביר ובעיות ניגודיות לפני שהקוד מופץ, אך הם בודקים רק 30% עד 40% מכשלי קריטריוני ההצלחה של WCAG שקיימים בפועל. לכן, גישת בדיקה מלאה כוללת שלוש שכבות:
- סריקות אוטומטיות לאיתור מוקדם של מה שניתן לזיהוי באופן מכני.
- בדיקות ידניות באמצעות מקלדת וקורא מסך כדי לאשר שכל רכיב שניתן לפעול עליו הוא נגיש ומובן.
- תיקוף משתמשים (User validation) מול אותה קבוצת מחקר שאיתה התחיל התהליך, כדי לבדוק האם התוצר שנבנה אכן עומד בקריטריוני הקבלה שנכתבו. אם הוא אינו עומד בהם, יש להזין את הממצאים בחזרה לפרומפט ולאפשר לבינה המלאכותית לנסות שוב.
פערי נגישות כפערי תהליך
הקו המנחה של המאמר הוא שפער הנגישות אינו כישלון של טכנולוגיית הבינה המלאכותית, אלא פער בתהליך העבודה. יש להתחיל במחקר משתמשים, להשתמש בפרסונות אותנטיות ומורחבות, ולכתוב קריטריוני קבלה ממוקדי נגישות לפני שלב הבנייה. רק לאחר מכן יש לבנות ולבדוק. המאמר מסכם כי עיצוב בדרך זו אינו מסייע רק לאנשים עם מוגבלויות, אלא מייצר חוויה חלקה ואינטואיטיבית יותר עבור כולם.