تنمو الإجابة كلمةً بعد كلمة. بالنسبة إلى المبصرين يبدو ذلك تقدمًا. أما إذا قُرئ كل جزء فور ظهوره، فقد يؤدي الناتج نفسه إلى مقاطعات مستمرة. لذلك ليس السؤال ما إذا كان التغيير مرئيًا تقنيًا، بل ما المعلومات التي يحتاجها الشخص في تلك اللحظة.
في معيار النجاح 4.1.3 تتناول WCAG 2.2 رسائل الحالة، التي ينبغي أن تكون قابلة للتحديد برمجيًا دون تغيير التركيز. ويذكر شرح W3C أيضًا تجنّب المقاطعات غير الضرورية. ولا يعني ذلك وجود التزام عام بالإعلان عن كل كلمة مولَّدة حديثًا على حدة. وفي دردشة الذكاء الاصطناعي يكون الفصل بين حالة العمل ومحتوى الإجابة مفيدًا بشكل خاص.
ثلاث حالات بدلًا من إعلان لا ينتهي
لنموذج العرض الخاص بنا ثلاث حالات مفهومة: تم استلام الطلب، والإجابة قيد التوليد، واكتملت الإجابة. وهي توفّر توجيهًا بشأن سير العملية. أما نص الإجابة نفسه فيجيب عن سؤال المضمون، وينبغي أن يبقى بعد ذلك قابلًا للقراءة وفق الوتيرة الخاصة بالشخص.
أثناء الانتظار، قد يعود الشخص إلى حقل الإدخال الخاص به أو يقرأ أجزاء أخرى من الصفحة. ولا ينبغي للواجهة أن تُزيح هذا النشاط جانبًا لمجرد وصول جزء آخر من النص. كما لا يتعيّن على الإجابة المكتملة أن تستحوذ تلقائيًا على تركيز لوحة المفاتيح.
تعتمد الاستجابة المناسبة على الحالة. فالعملية التي لا تزال جارية شيء مختلف عن خطأ يتطلب قرارًا جديدًا. وإذا عُرضت جميع الرسائل على أنها متساوية في الإلحاح، تختفي هذه الأولوية تحديدًا.
نمط HTML صغير يفصل بين المحتوى والحالة
المقتطف التالي من إعدادنا ولا يتضمن أي اتصال بالذكاء الاصطناعي. إنه يُظهر فقط منطقتين لكل منهما وظيفة مختلفة. تحتوي منطقة الإجابة على النص الذي يمكن قراءته لاحقًا. وينقل سطر الحالة القصير الوضع الحالي.
<section aria-labelledby="answer-title">
<h2 id="answer-title">Answer</h2>
<div id="answer"></div>
</section>
<p id="answer-status" role="status" aria-atomic="true"></p>تصف تقنية W3C ARIA22 استخدام role=status مع منطقة حيّة مهذّبة وإعلان محتوى الحالة كاملًا. وتجعل خاصية aria-atomic الصريحة لدينا هذا القصد مرئيًا في المقتطف التعليمي. ولا يُعد ذلك سببًا لوضع نص الإجابة بأكمله، المتنامي باستمرار، في رسالة الحالة القصيرة نفسها.
في التنفيذ الفعلي يُحدَّث سطر الحالة عند الانتقالات ذات المعنى، مثلًا مرة واحدة عند البدء ومرة واحدة بعد الاكتمال التام. أما مدى فائدة رسالة تقدّم فيما بينهما فعلًا، فيجب اختباره مع المسار المحدد ومع التقنيات المساعدة.
عند الفحص بالسمع، فكّر أيضًا في شخص يقرأ بالفعل في موضع آخر أثناء توليد الإجابة. هل يضطر إلى بدء جملته من جديد مرارًا؟ هل يستطيع العثور على الإجابة المكتملة عن قصد لاحقًا؟ تختبر هذه الملاحظات طريقة استخدام النمط بدقة أكبر من مجرد التحقق من أن إعلانًا ما يُسمع في مكان ما.
الإلغاء والأخطاء يحتاجان إلى كلمات خاصة بهما
إذا انقطع الناتج، فلا يجوز أن تعني كلمة «تم» ببساطة أنه لم تعد هناك أحرف تصل. فالنص الذي أُوقف عن قصد قد يكون غير مكتمل. وقد يعني الخطأ التقني أنه لم تُنتَج أي نتيجة قابلة للاستخدام على الإطلاق. وهذه الفروق مكانها لغة الواجهة.
لإجراء فحص أولي، يمكنك استخدام ثلاثة نصوص نموذجية ثابتة وتشغيل الانتقالات يدويًا. لاحظ ما يُعلَن عنه بينما تواصل القراءة، وما إذا كان التركيز يبقى في مكانه، وكيف تصل إلى النص المكتمل. هذا تمرين يمكنك تنفيذه، لكنه لا يُقدَّم هنا على أنه اختبار ناجح لقارئ الشاشة.
إذا أعددت HTML وJavaScript الخاصين بك في صفحة KENJTEC، فإن وضع المطوّر في KENJTEC WebSiteBuilder ai متاح لهذا الغرض، مع معاينة معزولة ونشر للشيفرة الخاصة بك. أنت من ينقل المكوّن بنفسك؛ ولا يُنشئ ذلك خدمة دردشة إضافية مدمجة تعمل بالذكاء الاصطناعي.
تجربة الاستماع الفعلية هي الفيصل
لا يمكن للقطة شاشة أن تُثبت مقاطعةً ولا إعلانًا غير متوقع. لذلك يحتاج الاختبار إلى لوحة مفاتيح وتقنيات مساعدة حقيقية. سجّل الجهاز والمتصفح وقارئ الشاشة المستخدَمة إذا كنت ستُبلغ لاحقًا عن نتيجة محددة.
حتى نمط الحالة الجيد لا يلبّي تلقائيًا كل متطلبات الدردشة سهلة الوصول. إنه يجيب عن سؤال محدود: كيف تصبح حالة العمل مفهومة دون فرض المحتوى على شخص ما كلمةً بعد كلمة؟ والحل الجيد يحافظ على الأمرين معًا: توجيه موثوق، وتحكّم الشخص في وتيرة قراءته الخاصة.
المصادر والحالة
البحث والتوثيق حتى 25 أكتوبر 2026. فهم SC 4.1.3: رسائل الحالة · ARIA22: استخدام role=status لعرض رسائل الحالة.
