‏دسترس‌پذیری یه قابلیت عملیاتیه، نه یه فیچر

نویسنده با یه مثال شروع می‌کنه: یه مهندس ارشد یه فرم پرداخت رو تو یه بعدازظهر با کمک هوش مصنوعی می‌سازه و مسیر اصلی هم تمیز کار می‌کنه. ولی دو هفته بعد معلوم می‌شه یه کاربر نابینا که با اسکرین‌ریدر کار می‌کنه نمی‌تونه خرید رو تموم کنه، چون دکمهٔ «Pay Now» در واقع یه با کلیک‌هندلره؛ نه نقش (role) داره، نه فوکوس‌پذیره. به گفتهٔ نویسنده همین فاصله بین «کدی که اجرا می‌شه» و «محصولی که آدما واقعاً می‌تونن باهاش کار کنن»، یکی از چالش‌های اصلی مهندسی تو دوران هوش مصنوعیه.

تو مقاله اومده که مدل قدیمیِ «ممیزی» (audit) دیگه به‌تنهایی جواب نمی‌ده. ممیزی برای فروش، تدارکات و مسائل حقوقی لازمه، ولی موقع ساختن فیچر تو اسپرینت کمکی نمی‌کنه و مشکلات رو قبل از مرج نمی‌گیره. نویسنده می‌گه دسترس‌پذیری یه حالت نیست که بهش برسی، بلکه چیزیه که باید مدام نگهش داری. طبق گزارش WebAIM Million، تو اجرای ۲۰۲۶ حدود ۹۵.۹٪ صفحه‌ها خطای قابل‌تشخیص WCAG داشتن، با میانگین ۵۶.۱ خطا در هر صفحه.

حرف اصلی نویسنده اینه که رابط کاربریِ تولیدشده با هوش مصنوعی «به‌طور پیش‌فرض» غیرقابل‌دسترسه؛ نه گاهی، بلکه پیش‌فرض. سه تا نیرو مدل رو به این سمت هل می‌ده: بیشتر کد React روی گیت‌هاب مارک‌آپ غیرمعنایی داره پس مدل همونو یاد می‌گیره؛ آدما خروجی رو چشمی قضاوت می‌کنن پس بازخورد به ظاهر پاداش می‌ده نه به ساختار؛ و توکن کمتری از یه دکمهٔ درست با aria-expanded می‌گیره، پس مدل بدون محدودیت مسیر ارزون رو می‌ره.

نویسنده وایب‌کدینگ (vibe coding) رو هم مطرح می‌کنه؛ روشی که آدم کامل به مدل تکیه می‌کنه و دیف‌ها رو بدون خوندن قبول می‌کنه. طبق گزارش، ۲۵٪ استارتاپ‌های یه دورهٔ Y Combinator کدی داشتن که ۹۵٪‌اش رو هوش مصنوعی تولید کرده بود. به گفتهٔ نویسنده همون میان‌بری که بازبینی امنیت رو رد می‌کنه، بازبینی دسترس‌پذیری رو هم رد می‌کنه؛ گزارش امنیتی Veracode هم نشون داده بخش زیادی از کد تولیدشده با AI آسیب‌پذیریِ امنیتی مثل XSS داره و مدل‌های بزرگ‌تر هم بهترش نکردن.

به گفتهٔ نویسنده گاردریل‌ها سرعت رو کم نمی‌کنن. اصل «shift-left» می‌گه اگه مشکل دسترس‌پذیری موقع بازبینی طراحی گرفته بشه فقط یه کامنته، ولی اگه تو production پیدا بشه تبدیل به یه پروژهٔ اصلاح می‌شه که ساعت‌ها وقت می‌بره. چیزی که سرعت رو کم می‌کنه کارِ غیرمنتظره‌ست، نه خودِ دسترس‌پذیری.

راه‌حل نویسنده «سیستم»‌ه نه قهرمان. بهترین نقطهٔ شروع دیزاین‌سیستمه، چون یه کامپوننتِ درست هزاران بار استفاده می‌شه؛ مثالش GOV.UK Design System‌ه که هم تست خودکار داره هم تست دستی با اسکرین‌ریدرهایی مثل JAWS و NVDA و VoiceOver. بعدش دسترس‌پذیری می‌ره تو ورک‌فلوی مهندسی (تو Definition of Done و بازبینی PR) و آخرش با ابزارهای خودکار مثل eslint-plugin-jsx-a11y، Pa11y و addon-a11y استوری‌بوک اجباری و قابل‌سنجش می‌شه.

نویسنده چند الگوی عملی هم می‌گه: مدل رو قبل از تولید با قوانین Cursor یا Copilot محدود کن؛ ویجت‌های پیچیده مثل کامبوباکس و مودال رو دستی نساز و از کتابخونه‌های آماده مثل Radix UI و React Aria ارث‌بری کن؛ و موقع تحویل طراحی، ترتیب فوکوس و لیبل‌ها رو از قبل مشخص کن. از نگاه کسب‌وکار هم فشار قانونی (مثل European Accessibility Act) و الزام مشتری‌ها به ارائهٔ مدرک دسترس‌پذیری (VPAT/ACR) زیاد شده، و بازار بزرگی از کاربرای معلول سرِ سایت‌های غیرقابل‌دسترس از دست می‌ره.

نکات کلیدی:

• دسترس‌پذیری باید مثل امنیت و پایداری یه قابلیت عملیاتی و مداوم باشه، نه یه ممیزی تک‌باره
• رابط کاربریِ تولیدشده با هوش مصنوعی به‌طور پیش‌فرض غیرقابل‌دسترسه و AI این شکاف رو صنعتی کرده
• گرفتن مشکل موقع طراحی فقط یه کامنته، ولی تو production یه پروژهٔ اصلاحِ پرهزینه می‌شه
• دیزاین‌سیستم، Definition of Done و تست خودکار تو CI ستون‌های اصلی راه‌حلن
• هیچ ابزار خودکاری نمی‌تونه جای تست با کاربر واقعیِ معلول رو بگیره