عامل دسترس‌پذیری GitHub؛ مدل عمومی، داده اختصاصی و مرز اصلاح خودکار

GitHub در ۱۵ مه ۲۰۲۶ تجربه آزمایشی عامل عمومی دسترس‌پذیری خود را شرح داد. هدف، کمک بلادرنگ به مهندسان در Copilot CLI و VS Code و پیدا کردن یا اصلاح خطاهای ساده و عینی پیش از production است. نکته مهم مقاله درباره انتخاب بزرگ‌ترین مدل نیست؛ درباره داده‌های دستی auditشده، روش اجرای خطی و دانستن محدودیت‌هاست.

#چرا accessibility برای عامل دشوار است؟

بخشی از خطاها عینی‌اند: نبودن label، ترتیب نادرست heading یا کنتراست قابل اندازه‌گیری. اما دسترس‌پذیری فقط فهرست ruleها نیست. تجربه کاربر با screen reader، keyboard، zoom، زبان و ساختار تعامل ترکیب می‌شود. عاملی که یک warning را برطرف کند اما focus را جابه‌جا یا معنای component را خراب کند، مشکل را حل نکرده است.

GitHub گزارش می‌کند عامل وقتی روی مسئله‌ای آموزش دیده که برای همان تجربه به‌صورت دستی audit و remediation شده، مؤثرتر است. این نتیجه برای تیم‌های دیگر هم کاربرد دارد: داده عمومی WCAG به‌تنهایی زمینه محصول را نمی‌داند. نمونه‌های اصلاح‌شده داخل همان design system، naming و الگوی component، سیگنال بهتری برای عامل می‌سازند.

#نقش sub-agent و قالب خروجی

در آزمایش GitHub، استفاده از sub-agentها مصرف token را کارآمدتر کرده است. عامل اصلی می‌تواند مسئله را تقسیم کند، یک sub-agent rule یا component را بررسی کند و نتیجه را به قالبی مشخص برگرداند. preformatted template ارتباط میان مراحل را پایدارتر می‌کند؛ این موضوع در ظاهر ساده است، اما خروجی آزاد و نامنظم، ارزیابی و ادغام را دشوار می‌سازد.

GitHub همچنین از اجرای methodical و خطی سخن می‌گوید. برای accessibility، ترتیب مهم است: ابتدا صفحه یا component را پیدا کن، سپس معیار مرتبط را تعیین کن، بعد تغییر کمینه بساز و در پایان با ابزار و کاربر بررسی کن. عامل چندمرحله‌ای که هم‌زمان چند فایل را تغییر دهد، ممکن است علت و اثر را مخلوط کند.

#عامل جای متخصص نیست

مقاله تأکید می‌کند این سیستم برای تقویت تلاش‌های موجود است، نه جایگزینی متخصص دسترس‌پذیری. عامل باید وقتی confidence پایین است یا مسئله به تجربه کاربر وابسته است، آن را به مسیر پشتیبانی انسانی هدایت کند. این رفتار «ناتوانی» نیست؛ بخشی از طراحی قابل اعتماد است.

تجربه GitHub هنوز pilot است و شرکت امیدوار است در آینده agent را open source کند. برای تیم محصول، نقطه شروع یک corpus کوچک از issueهای auditشده، خروجی قابل diff و approval انسانی است. اصلاح خودکار زمانی ارزش دارد که معیار موفقیت، کاربر واقعی و تکرارپذیری آزمون روشن باشد.

دسترس‌پذیری باید در چرخه توسعه زود دیده شود، نه در آخرین مرحله انتشار. عامل می‌تواند خطای روشن را سریع علامت‌گذاری کند، اما آزمون با keyboard و screen reader باید در محیط واقعی ادامه یابد. نگهداری گزارش اصلاح‌ها نیز به تیم اجازه می‌دهد بفهمد کدام الگوها مرتب تکرار می‌شوند و کجا به اصلاح component پایه نیاز است.