تیم‌ها در همه جا برای استقرار عوامل هوش مصنوعی رقابت می‌کنند، و یک فرض رایج در حال ظهور است: این عوامل به اندازه کافی هوشمند هستند تا دسترسی خارج از جعبه را مدیریت کنند. آنها نیستند، و دلیل آن روشن است: عوامل هوش مصنوعی با معلولیت زندگی نمی کنند. مردم آن را انجام می دهند.
وقتی فرض می‌کنیم که یک نماینده قبلاً می‌داند شخصی که از صفحه‌خوان، دستگاه سوئیچ یا کنترل صوتی از یک رابط استفاده می‌کند واقعاً به چه چیزی نیاز دارد، چیزی را ایجاد می‌کنیم که به آن شکاف دسترسی می‌گوییم. یک مدل بهتر مشکل را حل نمی کند، اما طراحی عمدی حل می کند.
در اینجا چیزی است که ما پوشش خواهیم داد:
چرا هوش مصنوعی نمی تواند دسترسی را حل کند؟
طراحی تجربیات هوش مصنوعی در ابعاد مختلف ناتوانی
تحقیقات دسترسی را به الزامات طراحی تبدیل کنید
تست دسترسی در سه سطح
شکاف های دسترسی، شکاف های فرآیندی هستند
چرا هوش مصنوعی نمی تواند دسترسی را حل کند؟
عوامل هوش مصنوعی همانطور که وجود دارد در وب آموزش می بینند و وب به ویژه قابل دسترسی نیست. بر اساس گزارش 1,000,000 برتر دسترسی به صفحه اصلی WebAIM در سال 2026، 95 درصد از یک میلیون سایت برتر آزمایش شده حداقل در صفحه اصلی خود حداقل یک خطای راهنمای دسترسی به محتوای وب (WCAG) دارند. ابزارهای تست خودکار، ابزارهایی که اکثر تیم ها برای رسیدگی به این مسائل به آنها اعتماد می کنند، تنها حدود 30 تا 40 درصد از شکست معیارهای موفقیت WCAG را تشخیص می دهند.
این شکاف بسته به نحوه تجربه یک رابط، خود را متفاوت نشان می دهد. کاربران صفحه‌خوان محتوای تولید شده به صورت پویا را از دست می‌دهند: بدون مدیریت فوکوس مناسب یا مناطق زنده، هیچ راهی برای تشخیص اینکه آیا صفحه واقعاً کاری انجام داده است وجود ندارد. افراد مبتلا به اختلالات حرکتی با رابطی روبرو می شوند که هرگز از حرکت باز نمی ایستد، بنابراین یک رابط کاربری دائما در حال تغییر تبدیل به یک هدف دائما در حال حرکت می شود. افراد دارای ناتوانی های شناختی تحت تأثیر عواملی قرار می گیرند که از لحظه ای به لحظه دیگر ناسازگار رفتار می کنند.
هیچ کدام از اینها به این معنی نیست که هوش مصنوعی نمی تواند مقرون به صرفه بسازد. این بدان معناست که باید صریحاً به او بگوییم «خوب» چه شکلی است. و باید بر اساس نحوه کار افراد واقعی باشد.
بازگشت به ابتدا
طراحی تجربیات هوش مصنوعی در ابعاد مختلف ناتوانی
برای ساختن عمدی، ما با مهندسی سریع شروع نمی کنیم. ما از جایی شروع می کنیم که طراحی خوب همیشه شروع شده است: با مردم. رویکرد ما به سه مرحله تقسیم می شود.
1. شخصیت خود را در ابعاد ناتوانی گسترش دهید
احتمالاً از قبل شخصیت هایی دارید. آنها را در سه بعد گسترش دهید:
- بصری – کاربران صفحه خوان، کم بینایی، کوررنگی
- موتور – فقط کاربران صفحه کلید، دسترسی سوئیچ، مهارت محدود
- شناختی – کاربرانی که به چیدمان های ساده تر، حواس پرتی کمتر و جریان های قابل پیش بینی نیاز دارند
مثال: جیمز را در نظر بگیرید، یک تحلیلگر برنامه در یک آژانس فدرال که می خواهد Agentforce به او کمک کند تا گزارش های متراکم را سریعتر ترکیب کند. به عنوان یک کاربر اصلی، ناامیدی او رایج است: محتوای عاملی که فاقد زمینه و شفافیت در مورد نحوه استفاده هوش مصنوعی از دستورالعمل های وی است.
اکنون شخصیت جیمز را به بعد بصری بسط دهید: او از بدو تولد نابینا بوده و با صفحه‌خوان و نمایشگر بریل حرکت می‌کند. هدف او تغییر نمی کند، اما ناامیدی او به شدت تشدید می شود. زمانی که متن و به‌روزرسانی‌های فیلد جریانی پویا به صفحه‌خوان آن نمی‌رسد، یا زمانی که عامل فوکوس را به درستی مدیریت نمی‌کند، باید بارها و بارها خود را تغییر جهت دهد. این ناراحتی کوچکی نیست. این تفاوت بین انجام کار و گیر افتادن است.
2. تعیین مشاغل در دسترس که باید انجام شوند
یک کار استانداردی که باید برای جیمز انجام شود ممکن است بگوید: “وقتی من در حال تجزیه و تحلیل یک گزارش برنامه متراکم هستم، می‌خواهم Agentforce یافته‌ها را ترکیب کند و زمینه‌های حسابرسی را پر کند تا بتوانم ارزیابی خود را سریعتر تکمیل کنم.” این یک شروع خوب است، اما چیزی را دارد که ما آن را شکاف واقعیت هوش مصنوعی می‌نامیم: وقتی جیمز اصلاً نمی‌تواند به‌روزرسانی را درک کند چه اتفاقی می‌افتد.
نسخه قابل دسترس هدف خود را دست نخورده نگه می‌دارد، اما نیاز واقعی را نام میبرد: “من می‌خواهم به صفحه‌خوان من خلاصه‌های مختصری از آنچه تغییر کرده است، بداند که به‌روزرسانی‌ها چه زمانی اتفاق می‌افتد، و مکان من را ذخیره کند تا بتوانم یافته‌ها را بررسی کنم و ارزیابی خود را سریعتر بدون از دست دادن شرایطم ارسال کنم.” همین موضوع. تعریف واضح تر و صادقانه تر از آنچه موفقیت نیاز دارد.
3. با کاربران واقعی فناوری کمکی تست کنید، نه شبیه سازی
بستن چشم بند یا کنار گذاشتن ماوس برای یک بعدازظهر تجربه فردی را که هر روز از فناوری کمکی استفاده می کند به شما نمی دهد. ابزارهای خودکار و چک لیست های انطباق، اصطکاک دنیای واقعی را که فقط در عمل رخ می دهد، از دست می دهند. شرکت‌کنندگانی را که با این ناتوانی‌ها زندگی می‌کنند استخدام کنید، با گروه‌های محلی حمایت از معلولیت شریک شوید، و به مردم غرامت عادلانه بدهید. آنها متخصص موضوع هستند و باید با آنها رفتار شود.
بازگشت به ابتدا
تحقیقات دسترسی را به الزامات طراحی تبدیل کنید
هنگامی که یک شخصیت گسترده را با یک کار موجود برای انجام ترکیب می کنید، می توانید معیارهای پذیرش جامع را بنویسید: معمولاً سه تا پنج عبارت عبور یا شکست باینری، که حداقل یکی از آنها یک مورد لبه را پوشش می دهد که ساختاری مانند:
داده شده است [a person in context]
چه زمانی [an action is taken]
سپس [an expected outcome occurs].
به عنوان مثال:
- کاربران صفحه خوان: با توجه به اینکه کاربر VoiceOver در حال پیمایش به‌روزرسانی پویا یک کار Agentforce است، وقتی هوش مصنوعی تولید یک پاسخ را به پایان می‌رساند، یک منطقه زنده به کاربر اطلاع می‌دهد که پاسخ در دسترس است.
- فقط کاربران صفحه کلید: با توجه به اینکه یک کاربر فقط صفحه کلید در حال پیمایش یک گردش کار Agentforce است، وقتی موارد اقدام در یک پاسخ عامل ظاهر می شود، پس همه اقدامات در ردیف برگه استاندارد با اهداف لمسی حداقل 44 × 44 پیکسل در دسترس هستند.
این معیارها را مستقیماً در دستورات خود قرار دهید و آنها را با یک درخواست صریح برای نرده‌های محافظ Salesforce Lightning Design System 2 ترکیب کنید. این ترکیب تضمین می‌کند که مدل شامل پارامترهای دسترسی به این دلیل است که شما به آن گفته‌اید، نه به این دلیل که امیدوار بودید آنها را درست انجام دهد.
هوش مصنوعی می تواند ساخت و ساز را سرعت بخشد. می تواند کد بنویسد کاری که او نمی تواند انجام دهد این است که یک مرد مسئول باشد. آن بخش هنوز برای ماست.
بازگشت به ابتدا
تست دسترسی در سه سطح
ابزارهای تست خودکار خط پایه شما هستند، نه سقف شما. آنها در تشخیص خطاهای نحوی و مشکلات کنتراست قبل از ارسال کد عالی هستند، اما به یاد داشته باشید که آنها فقط 30٪ تا 40٪ از شکست های معیارهای موفقیت WCAG را که وجود دارد آزمایش می کنند. روش تست کامل دارای سه لایه است:
- اسکن خودکار برای کشف آنچه که از نظر مکانیکی زود تشخیص داده می شود.
- تست دستی با صفحه‌کلید و صفحه‌خوان برای تأیید اینکه هر عنصر فعال در دسترس و قابل درک است.
- اعتبارسنجی کاربر با همان گروه تحقیقاتی که با آن شروع کرده‌اید، تأیید می‌کند که ساخت در واقع معیارهای پذیرشی که نوشته‌اید را برآورده می‌کند. اگر نشد، آن را به فرمان بازگردانید و اجازه دهید هوش مصنوعی دوباره امتحان کند.
بازگشت به ابتدا
شکاف های دسترسی، شکاف های فرآیندی هستند
نکته اصلی اینجاست: شکاف مقرون به صرفه شکست فناوری هوش مصنوعی نیست. این یک شکاف در روند است. با تحقیقات کاربر شروع کنید. از شخصیت های معتبر و تقویت شده استفاده کنید. قبل از ساخت، معیارهای پذیرش را بنویسید که بر دسترسی متمرکز است. سپس بسازید. سپس تست کنید.
طراحی به این روش نه تنها از افراد دارای معلولیت پشتیبانی می‌کند، بلکه تجربه‌ای روان‌تر و بصری‌تر برای آنها ایجاد می‌کند همه.
بازگشت به ابتدا
