أعطِ الذكاء الاصطناعي عمل المسودات في نظام التصميم: يكتب توثيق رموز التصميم (Design Tokens)، ويوسّع حالات المكوّنات، وينتج نصوصًا تجريبية واقعية باللغتين، ويقترح كودًا أوليًا. وأبقِ ملكية النظام بيد البشر. فمصدر الرموز المعتمد، وواجهات المكوّنات، وقرارات إمكانية الوصول، ومراجعة الواجهة العربية واتجاه الكتابة من اليمين إلى اليسار (RTL)، كلها تحتاج إلى أشخاص مسؤولين في فريقك، لأن المخرجات المولّدة قد تبدو مكتملة وهي خاطئة بطرق لا تلتقطها الفحوص الآلية.
يفصل هذا الدليل بين الطبقتين، ويقترح مسار مراجعة يسرّع المسودات دون أن ينحرف النظام.
لنظام التصميم طبقة آلية وطبقة قرار. تستطيع التحقق من الطبقة الآلية مقابل شيء تملكه أصلًا: ملف الرموز، أو مواصفة المكوّن، أو قاعدة التسمية. أما طبقة القرار فهي التي تعرّف هذه الأشياء من الأساس: ما الألوان الموجودة، وكيف يتصرف المكوّن، وما معنى «سهل الوصول» في مسار حقيقي، وكيف تُقرأ الواجهة العربية.
ومن هذا الفصل تأتي قاعدتنا العملية في تكنوستاك: اترك للذكاء الاصطناعي توليد ما تستطيع التحقق منه مقابل تعريف يملكه فريقك، وأبقِ التعريفات نفسها، وكل حكم لا يفحصه سكربت، بيد أشخاص يُسألون عنه.
شكل 1: الذكاء الاصطناعي يصوغ، والفريق يقرر. أبقِ القرارات بيد مسؤولي النظام.
- توثيق الرموز وتحويل صيغها. انطلاقًا من ملف رموز معتمد، يصوغ النموذج ملاحظات الاستخدام ويحوّل القيم إلى الصيغ التي تحتاجها كل منصة، ثم يتحقق سكربت بناء من مطابقة الناتج للمصدر؛ فرواية النموذج عمّا فعله ليست دليلًا.
- مصفوفات الحالات. من مكوّن واحد، يعدّد النموذج الأحجام والحالات التي تستحق النظر: الافتراضية، وتحويم المؤشر، والتركيز، والتعطيل، والخطأ، والتحميل. ويقرر المصممون أيها يدعمه النظام.
- نصوص تجريبية واقعية باللغتين. جمل قصيرة وطويلة، عربية وإنجليزية، ممزوجة بأرقام ومصطلحات لاتينية، تكشف مشكلات الالتفاف والفيض التي يخفيها النص الوهمي. واطلب من قارئ عربي مراجعة النص العربي المولّد قبل اعتماده في الاختبارات.
- كود أولي. مسودة أولى للترميز والأنماط من مواصفة المكوّن تمنح المهندسين نقطة بداية، مع مراجعة HTML الدلالي وسلوك التركيز واستخدام الرموز سطرًا سطرًا.
- شرح نتائج الفحص. تكتشف أدوات الفحص الحتمية الألوان أو المسافات المكتوبة يدويًا خارج مجموعة الرموز، ثم يشرح النموذج النتيجة ويقترح إصلاحًا للمراجعة.
- المصدر المعتمد للرموز. ملف أو مستودع واحد، ونظام تسمية، وآلية للتغيير. وأي تعديل مولّد على الرموز يصل طلبَ دمج (Pull request) كأي تعديل آخر.
- واجهات المكوّنات وحالاتها. الخصائص وقواعد التركيب والإصدارات والإيقاف التدريجي قرارات تصميم بعيدة الأثر؛ يقترح النموذج ويقرر المسؤول عن المكتبة.
- حكم العلامة التجارية. لا يعرف النموذج لماذا تبدو علامتك كما تبدو ما لم تشرح له ذلك، وحتى حينها تبقى اقتراحاته خيارات تزنها أنت.
- إمكانية الوصول والسلوك ثنائي اللغة. يتناولهما القسمان التاليان، لأن الواجهة المولّدة تبدو فيهما سليمة وهي خاطئة.
تعرض المرجعية السريعة لمعايير WCAG 2.2 الصادرة عن W3C معايير نجاح تشمل التشغيل بلوحة المفاتيح، والبدائل النصية، ووضوح مؤشر التركيز، وكفاية التباين. تستطيع الأدوات فحص بعضها: يحسب سكربت نسبة التباين ويرصد غياب البديل النصي. استخدم أدوات حتمية لهذه الفحوص بدل تقدير النموذج.
وبعضها يحتاج إلى بشر: هل النص البديل ذو معنى؟ هل ينتقل التركيز بترتيب معقول داخل نافذة حوار؟ هل يعلن قارئ الشاشة الخطأ في اللحظة المناسبة؟ هذه أمور يحددها المسار الحقيقي. والمكوّن الذي اجتاز فحصًا آليًا لم يثبت شيئًا بعد؛ اختبره بلوحة المفاتيح وبقارئ شاشة واحد على الأقل، وباللغتين، قبل أن يدخل المكتبة.
تغيير الاتجاه يحتاج أكثر من قلب التخطيط، ولكل مكوّن قراراته:
- التخطيط والمسافات بخصائص منطقية (البداية والنهاية لا اليسار واليمين)، ليعمل المكوّن نفسه في الاتجاهين.
- الأيقونات تُراجع واحدة واحدة: الأسهم ومؤشرات التقدم التي توحي باتجاه تنعكس غالبًا، أما الشعارات وكثير من الرموز فلا.
- النصوص مختلطة الاتجاه، مثل رموز المنتجات والروابط وأرقام الهواتف والمصطلحات الإنجليزية داخل جملة عربية، يجب أن تبقى مقروءة بترتيبها الصحيح.
- الطباعة تحتاج خطًا عربيًا يشكّل الحروف المتصلة بشكل صحيح، وارتفاع سطر مريحًا، ومن دون تباعد بين الحروف (Letter-spacing) في النص العربي لأنه قد يضر باتصالها.
- الأرقام، غربية كانت أو مشرقية، قرار منتج يُتخذ مرة ويُطبّق باتساق.
والمكوّنات المولّدة تخطئ هذه التفاصيل كثيرًا بطرق تجتاز الفحص الآلي، لذا راجعها مع قرّاء عرب على محتوى حقيقي، وعلى شاشات ضيقة، ومع تكبير النص.
شكل 2: راجع العربية بما يتجاوز الانعكاس. استخدم محتوى حقيقيًا باللغتين.
يقوم نظام تصميم الموقع ثنائي اللغة فوق نموذج محتوى. فوثائق Sanity مثلًا تصف أسلوبين للترجمة: على مستوى الحقل وعلى مستوى المستند. وأيًّا كانت المنصة، اكتب من يملك الترجمات، وكيف تعمل المراجع بين اللغات، وماذا يحدث حين تغيب ترجمة، وكيف تنشر كل لغة. هذه الاختيارات تحدد ما يجب أن تتعامل معه مكوّناتك، مثل نص بديل بلغة أخرى واتجاه آخر. ويغطي دليلنا عن تصميم نماذج المحتوى في أنظمة CMS المنفصلة هذا الجانب.
وقد تحمل المكوّنات المولّدة أنماطًا أو سكربتات غير مستخدمة، فافحص ما يضيفه كل مكوّن جديد إلى الصفحة وأثره في مقاييس التحميل والتفاعل؛ ويشرح دليلنا عن مؤشرات Core Web Vitals ما ينبغي قياسه. واجعل حجم الجهد مناسبًا لمرحلة المنتج: قد يكفي المنتج الناشئ عدد صغير من الرموز وبضعة مكوّنات بدل مكتبة كاملة، كما نناقش في مقالنا عن قرارات البنية من المنتج الأولي إلى التوسع.
- عرّف أولًا. حدّث ملف الرموز أو مواصفة المكوّن قبل توليد أي شيء.
- ولّد في فرع مستقل. ووسّم المسودات المولّدة في طلب الدمج ليعرف المراجعون مواضع التدقيق.
- شغّل الفحوص الحتمية. التحقق من الرموز، وأدوات الفحص، ومخرجات البناء، وفحوص الوصول الآلية.
- راجع حسب الدور. يتحقق المصمم من الحالات وملاءمة العلامة، ويختبر مراجع الوصول لوحة المفاتيح وقارئ الشاشة، ويراجع قارئ عربي الاتجاه والطباعة والصياغة.
- ادمج ووثّق. يعتمد المسؤول عن المكتبة، ويسجل التوثيق القرارات إلى جانب المخرجات المولّدة.
بهذه الطريقة يمكن للذكاء الاصطناعي اختصار وقت المسودات مع بقاء التغييرات تحت مراجعة الفريق. وإن كنت تبني موقعًا ثنائي اللغة أو تعيد بناءه وتريد نظام تصميم بهذه الضوابط، يمكن لفريق خدمة تطوير المواقع مساعدتك.
- اتحاد شبكة الويب العالمية (W3C). How to Meet WCAG 2.2 (Quick Reference).
- Sanity. Localization، من وثائق Sanity.
ممارسة المراجعة الواردة في هذا المقال إرشادات من تكنوستاك، واتباعها أو اجتياز الفحوص الآلية لا يثبت وحده المطابقة لمعايير WCAG.
