كتب Claude مكوّن React DatePicker، لكن تحقيق إمكانية الوصول وفق WCAG استغرق 3 أيام إضافية

طلبت فريق التطوير من كلود إنشاء مكون DatePicker مخصص في React لنموذج حجز موعد طبي—مع دعم كامل للتنقل بلوحة المفاتيح وقارئات الشاشة. تعاملت الذكاء الاصطناعي مع النسخة الأولى بسرعة. ثم جاءت ثلاثة أيام من التحسين.

ما فعله كلود بشكل جيد

أنشأ كلود أساساً وظيفياً للمكون: بنية JSX وخصائص ARIA الأساسية (`role="dialog"` و `aria-label` و `aria-live`)، ومعالجات لوحة المفاتيح للتنقل بواسطة الأسهم، ومنطق شبكة التقويم. كنقطة انطلاق—قوية: تم ترجمة الكود، وبدا صحيحاً بصرياً، واختبارات يدوية لم تكسر أي شيء. ثبت أن الذكاء الاصطناعي مفيداً بشكل خاص للكود المكرر: إنشاء 42 خلية شبكة، حساب إزاحة أول يوم من الشهر، تنسيق التواريخ لـ `aria-label`. هذا عمل مملل إذا تم يدوياً، وتعامل كلود معه بنظافة. أصبحت المشكلة واضحة فقط بعد توصيل تقنيات المساعدة الحقيقية.

حيث ساءت الأمور

بدأ الاختبار الحقيقي عندما تم تشغيل NVDA على Windows و VoiceOver على macOS. كانت هناك عدة مشاكل:

• فخ التركيز لم يعمل — عند الجدولة داخل الحوار، عاد التركيز إلى المستند الرئيسي
• تم قراءة التواريخ بشكل غير صحيح — قارئ الشاشة قال "1" بدلاً من "الاثنين، 1 يونيو 2026"
• تبديل الشهر كان صامتاً — لم يتم تحديث منطقة `aria-live` عند تغيير الشهر
• إغلاق Escape ولم يعد — بعد إغلاق التقويم، فُقد التركيز بدلاً من العودة إلى زر الزناد
• التباين العالي في Windows — التاريخ المحدد لم يكن مميزاً بصرياً عن الباقي: اعتمد المكون على لون CSS بدون خصائص الحالة

بدا كل نقطة من هذه النقاط في الكود المُنشأ وكأنها "معالج موجود"—لكن السلوك مع قارئ شاشة حقيقي اختلف عن التوقعات.

كيف أصلحناها

كان الخلاص هو WAI-ARIA APG—دليل W3C الرسمي مع نمط محدد لحوارات DatePicker. لا يقول ببساطة "أضف `aria-modal`"، بل يحدد التسلسل الدقيق: أي عنصر يحصل على التركيز عند الفتح، كيفية الحفاظ على فخ التركيز، إلى أين إرجاعه عند الإغلاق، أي `aria-label` مطلوب على أزرار التنقل بالشهر.

"قراءة الكود المُنشأ لا تعني التحقق من إمكانية الوصول. فقط قارئ شاشة

حقيقي يكشف الحقيقة."

تمت إعادة كتابة فخ التركيز باستخدام `querySelectorAll` مع اعتراض يدوي لـ Tab و Shift+Tab. حصلت كل خلية يوم على `aria-label` كامل مثل "الأربعاء، 3 يونيو 2026" بالإضافة إلى `aria-pressed="true"` لحالة المحدد. لوضع التباين العالي، أضفنا `aria-selected` وخطوط عريضة عبر `outline` بدلاً من مجرد لون الخلفية. كانت أدق نقطة هي `aria-live`: يجب أن توجد المنطقة في DOM قبل كتابة النص فيها، وإلا سيتجاهلها قارئ الشاشة. أدرج كلود المنطقة ديناميكياً—هذا التفصيل الدقيق ظهر فقط في الاختبار.

ماذا يعني هذا

يعجل كلود بكتابة الكود القابل للوصول إليه لكنه لا يحل محل اختبارات قارئ الشاشة. الخبر الجيد: بمجرد العمل من خلال WAI-ARIA APG مرة واحدة وتوثيق الحلول، يتم كتابة المكون القابل للوصول التالي بشكل ملحوظ أسرع. تتولى الذكاء الاصطناعي العمل المكرر—لكن تخطي التحقق النهائي مع NVDA و VoiceOver ليس خياراً.