جب کوئی AI ٹول مواد تیار کر رہا ہو، ڈیٹا سیٹ پر کارروائی کر رہا ہو، یا کوئی خود مختار کام چلا رہا ہو، تو صارف کو باہر نکلنے کا ایک واضح راستہ ہونا چاہیے۔ بہت سے انٹرفیس ہنگامی طور پر روکنے (emergency stop) کے عمل کو محض ایک ضمنی چیز سمجھتے ہیں۔ وہ بٹن کے لیبل کو "Stop" سے بدل کر "Stopped" کر دیتے ہیں اور سمجھتے ہیں کہ کام مکمل ہو گیا۔ رنگ شاید خاکستری (gray) ہو جائے۔ اینیمیشن شاید ہموار لگے۔ اس کے باوجود ٹاسک سرور پر چلتا رہتا ہے، اور صارف کو اندازہ ہی نہیں ہوتا کہ کچھ غلط ہوا ہے۔ اسکرین ریڈر استعمال کرنے والے شخص کے لیے یہ ناکامی مزید سنگین ہے۔ انہیں آڈیو کے ذریعے تصدیق ملتی ہے کہ عمل ختم ہو گیا ہے، جبکہ کام خاموشی سے پس منظر میں جاری رہتا ہے۔ یہ کوئی معمولی بگ نہیں ہے۔ یہ اعتماد کا ٹوٹنا ہے۔

ایک خاموش اسٹاپ بٹن کا جھوٹ

ایک برا اسٹاپ بٹن آپ کے صارفین سے جھوٹ بولتا ہے۔ یہ "Stopped" کا لفظ دکھاتا ہے جبکہ ٹاسک کسی کنٹینر یا ریموٹ ورکر پر کہیں چل رہا ہوتا ہے۔ ایسا اس لیے ہوتا ہے کیونکہ فرنٹ اینڈ ڈویلپرز اکثر سرور کی طرف سے روکنے کی تصدیق ملنے سے پہلے ہی انٹرفیس کو پرامیدانہ طور پر (optimistically) اپ ڈیٹ کر دیتے ہیں۔ ایک بصری صارف شاید اس فرق کو پکڑ لے اگر پروگریس بار چلتی رہے یا لاگ اسکرول ہوتا رہے، لیکن اسکرین ریڈر استعمال کرنے والے صارف کے پاس ایسا کوئی دوسرا ذریعہ نہیں ہوتا۔ وہ مکمل طور پر اس بات پر انحصار کرتے ہیں جو انٹرفیس اعلان کرتا ہے۔ اگر بٹن کا متن وقت سے پہلے بدل جائے اور کوئی آڈیو فیڈ بیک اصل صورتحال کو واضح نہ کرے، تو صارف یہ سمجھ لیتا ہے کہ ہنگامی صورتحال ختم ہو گئی ہے جبکہ ایسا نہیں ہوتا۔ یہاں رسائی (Accessibility) محض ایک فیچر کی درخواست نہیں ہے۔ یہ ایک حفاظتی ضرورت ہے۔

دو مختلف حالتیں

ایک حقیقی ہنگامی کنٹرول کو دو الگ الگ ذمہ داریاں سنبھالنی چاہئیں۔ پہلا، سسٹم آپ کی درخواست قبول کرتا ہے۔ دوسرا، سسٹم اختیار واپس لیتا ہے۔ یہ دونوں ایک ہی چیز نہیں ہیں۔ قبولیت (Acceptance) کا مطلب ہے کہ فرنٹ اینڈ نے آپ کی بات سنی اور پیغام آگے پہنچا دیا۔ منسوخی (Revocation) کا مطلب ہے کہ بیک اینڈ نے اصل میں عمل کو ختم کر دیا ہے۔ چونکہ نیٹ ورک لیٹنسی، جاب کیوز اور آرکیسٹریشن لیئرز موجود ہوتی ہیں، اس لیے ان دو لمحات کے درمیان وقفہ چند سیکنڈ تک ہو سکتا ہے۔ اس دوران، آپ کے انٹرفیس کو سچائی بتانی چاہیے کہ آپ کس مرحلے میں ہیں۔ دونوں مراحل کو ایک ہی لمحے میں سمو دینا اس بنیادی ڈھانچے کا فرض ہے جو حقیقت میں موجود ہی نہیں ہے۔ آپ کے صارفین کو اس خوش فہمی کی قیمت چکانی پڑے گی۔

اپنی انٹرفیس میں چار حالتوں کی نقشہ سازی

اپنے UI کو چار واضح حالتوں کے گرد بنائیں تاکہ صارفین کو ہمیشہ معلوم ہو کہ وہ کہاں کھڑے ہیں۔

  • Running (چل رہا ہے): واضح طور پر لیبل شدہ "Stop task" بٹن دکھائیں۔ اسے ہر وقت نظر آنے دیں۔ اسے ٹیبز یا ایکارڈین (accordion) پینلز کے نیچے نہ چھپائیں۔
  • Requesting (درخواست بھیجی جا رہی ہے): بٹن کو ڈس ایبل (disable) کر دیں تاکہ صارف بار بار درخواستیں نہ بھیج سکے۔ "Stop requested" کا پیغام دکھائیں۔ یہ ایمانداری اہم ہے۔ یہ صارف کو بتاتا ہے کہ ان کا حکم عمل میں ہے اور سسٹم نے ابھی تک تکمیل کی تصدیق نہیں کی ہے۔
  • Stopped (رک گیا ہے): بٹن کو ڈس ایبل کر دیں۔ ایک رسید آئی ڈی (receipt ID) دکھائیں۔ یہ صارف کو ثبوت دیتا ہے کہ سرور نے جواب دیا ہے اور اسٹاپ کو لاگ کیا گیا ہے۔ یہ ایک دعوے کو ریکارڈ میں بدل دیتا ہے۔
  • Failed (ناکام رہا): "Try stop again" کا بٹن فعال کریں۔ ایک مخصوص ناکامی کا پیغام دکھائیں۔ صارف کو کبھی بھی خاموش بے یقینی کی حالت میں نہ چھوڑیں۔ اگر سرور کا ٹائم آؤٹ ہو گیا یا کوئی ایرر آیا، تو صاف بتائیں۔

ان حالتوں کو بصری اور سمعی دونوں طرح کے فیڈ بیک کو چلانا چاہیے۔ جب حالت تبدیل ہو، تو اسکرین ریڈرز کو ایک مناسب طریقے سے منظم لائیو ریجن (live region) کے ذریعے نیا لیبل اور اسٹیٹس بتانا چاہیے۔ ایک ڈس ایبل بٹن اور ٹیکسٹ اعلان اس الجھن کو روکتا ہے کہ آیا کنٹرول اب بھی فعال ہے یا نہیں۔

ڈیزائن کے اصول جو دباؤ میں بھی کارآمد رہیں

ہنگامی کنٹرولز عام بٹنوں کے مقابلے میں ڈیزائن کا ایک مختلف بوجھ اٹھاتے ہیں۔ صارفین پریشان، جلد بازی میں، یا غیر متوقع نتائج پر ردعمل دے رہے ہو سکتے ہیں۔ اس تناؤ میں آپ کے انٹرفیس کا قابل استعمال رہنا ضروری ہے۔

رنگ کو بطور واحد اشارہ استعمال نہ کریں۔ ایک بٹن کا سرخ سے سبز ہونا کچھ دیکھنے والے صارفین کی مدد کرتا ہے، لیکن کلر بلائنڈ اور اسکرین ریڈر استعمال کرنے والے صارفین کو متن اور ساختی تبدیلیوں کی ضرورت ہوتی ہے۔ رنگ کو واضح لیبلز، آئیکونोग्राफी کو ٹیکسٹ متبادل، اور اسٹیٹس اعلانات کے ساتھ جوڑیں۔

کنٹرولز کو ہوور مینیوز (hover menus) میں نہ چھپائیں۔ ہنگامی صورتحال کے دوران کسی کو بھی ڈراپ ڈاؤن میں تلاش نہیں کرنا چاہیے۔ اسٹاپ بٹن بنیادی ویو پورٹ (viewport) میں ہونا چاہیے، جو ہمیشہ بغیر کسی مشکل کرسر کی حرکت کے پہنچ میں ہو۔

بٹنوں کو پوائنٹر کے ذریعے دبانا آسان بنائیں۔ تناؤ سے باریک موٹر کنٹرول (fine motor control) کم ہو جاتا ہے۔ زیادہ پیڈنگ اور ایک بڑا ہٹ ٹارگٹ (hit target) استعمال کریں۔ اگر صارف کانپ رہا ہے یا چلتی ٹرین میں ٹریک پیڈ استعمال کر رہا ہے، تب بھی وہ کلک کرنے میں کامیاب ہونا چاہیے۔

یقینی بنائیں کہ کی بورڈ استعمال کرنے والے تیزی سے بٹن تک پہنچ سکیں۔ ٹیب آرڈر (tab order) کسی کو ہنگامی کنٹرول تک پہنچنے سے پہلے تیس عناصر کے چکر لگانے پر مجبور نہیں کرنا چاہیے۔ ایک اسکن لنک (skip link) یا منطقی فوکس کی جگہ پر غور کریں جو اسٹاپ ایکشن کو فوری پہنچ میں رکھے۔

غلطی سے دبائے جانے والے کی بورڈ شارٹ کٹس سے بچیں۔ وہ عالمی (global) شارٹ کٹس جو کسی عمل کو روکتے ہیں، ایسی ترکیبوں (combinations) پر مشتمل ہونے چاہئیں جنہیں غلطی سے دبانا مشکل ہو۔ اگر سیو (save) یا پرنٹ (print) کا کوئی عام شارٹ کٹ آپ کے اسٹاپ کمانڈ کے ساتھ ٹکرا جاتا ہے، تو کوئی اسے غلطی سے چلا دے گا اور اس کا کام ضائع ہو جائے گا۔

ہنگامی حالات کے لیے کثیر مرحلہ وار تصدیق کا استعمال نہ کریں۔ ایک تصدیقی ڈائیلاگ ایک دیوار کی طرح ہے، حفاظتی ریلنگ کی طرح نہیں۔ اس وقت تک کہ صارف "کیا آپ کو یقین ہے؟" پڑھے اور دوبارہ کلک کرے، غیر مطلوبہ آؤٹ پٹ پہلے ہی بھیجا جا چکا ہو سکتا ہے۔ ایک فیصلہ کن عمل ہی کافی ہونا چاہیے۔

رسیدیں، نیٹ ورک کا نقصان، اور ایماندارانہ حدود

ایک رسید آئی ڈی (receipt ID) اس بات کا ثبوت ہے کہ سرور نے جواب دیا ہے۔ یہ اس بات کا ثبوت نہیں ہے کہ ہر بعد کے اثرات (downstream effects) واپس اپنی اصل حالت میں آ گئے ہیں۔ اسٹاپ کمانڈ پہنچنے تک آپ کا AI ٹاسک بیرونی APIs، فائل رائٹس، یا میسج کیوز (message queues) کو متحرک کر چکا ہو سکتا ہے۔ آرکیسٹریٹر (orchestrator) کو روکنے سے اس بات کی ضمانت نہیں ملتی کہ ہر چائلڈ پروسیس فوری طور پر رک گیا ہے۔ اپنے پیغامات اور اپنی دستاویزات میں اس حد کے بارے میں ایماندار رہیں۔

آپ کو ایسے ناکامی کے طریقوں (failure modes) کے لیے بھی ڈیزائن کرنے کی ضرورت ہے جو آپ کے سرور روم سے باہر واقع ہوں۔ یہ ٹیسٹ کریں کہ جب صارف اسٹاپ پر کلک کرنے کے فوراً بعد نیٹ ورک کنیکٹیویٹی کھو دیتا ہے تو کیا ہوتا ہے۔ یہ ٹیسٹ کریں کہ جب جواب سو ملی سیکنڈ کے بجائے دس سیکنڈ لے لے تو کیا ہوتا ہے۔ اگر درخواست (request) لٹک جائے، تو آپ کا انٹرفیس ہمیشہ کے لیے "Requesting" میں پھنسے رہنے کے بجائے فیلڈ اسٹیٹ (failed state) میں ٹائم آؤٹ ہو جانا چاہیے۔ صارفین اس بات کو جاننے کے حقدار ہیں کہ کب رابطہ منقطع ہو چکا ہے۔

اہمیت کے ساتھ ٹیسٹنگ کیسے کریں

تصدیق (Verification) کو بعد کا کام نہیں سمجھنا چاہیے۔ اپنے انٹرفیس کو ان حقیقی حالات سے گزاریں جن کا سامنا معذور صارفین روزانہ کرتے ہیں۔

صرف کی بورڈ کے ذریعے نیویگیشن۔ اپنا ماؤس ہٹا دیں۔ ہر اسٹیٹ میں 'Tab' کا استعمال کریں۔ اس بات کو یقینی بنائیں کہ آپ ورک فلو میں کہیں سے بھی اسٹاپ بٹن تک پہنچ سکیں، بغیر فوکس پھنسائے یا غیر مرئی (invisible) ٹیب اسٹاپس بنائے بغیر۔

200% براؤزر زوم۔ پیج کو بڑا کریں۔ چیک کریں کہ آیا اسٹاپ بٹن اپنی جگہ بدلتا ہے (reflows) یا غائب ہو جاتا ہے۔ کم بینائی والے صارفین زوم پر انحصار کرتے ہیں، اور لے آؤٹ کا بگڑنا اکثر اہم کنٹرولز کو چھپا دیتا ہے۔

کم حرکت (Reduced motion) کی سیٹنگز۔ آپ کی "Requesting" اسٹیٹ میں شاید کوئی پلسنگ اینیمیشن یا گھومتا ہوا لوڈر استعمال ہو رہا ہو۔ prefers-reduced-motion کا احترام کریں۔ کسی بھی حرکت کے ساتھ جامد (static) بصری اشارے فراہم کریں تاکہ جو صارفین اینیمیشنز کو غیر فعال کرتے ہیں انہیں بھی اسٹیٹ کا واضح فیڈ بیک مل سکے۔

اسکرین ریڈر کے اعلان کی ترتیب۔ اسٹیٹ کی تبدیلیوں کو براڈکاسٹ کرنے کے لیے لائیو ریجن (live region) کا استعمال کریں، لیکن ترتیب کو احتیاط سے ٹیسٹ کریں۔ اعلان کی ترتیب واقعات کی منطقی ترتیب کے مطابق ہونی چاہیے۔ اگر اسکرین ریڈر کے "Stop requested" کہنے سے پہلے ہی بٹن غیر فعال ہو جاتا ہے، تو ٹیسٹ کریں کہ آیا وہ ترتیب الجھن پیدا کرتی ہے۔ معاون ٹیکنالوجی (assistive technology) میں چھوٹے ٹائمنگ بگ پیغام کو خراب کر سکتے ہیں، اس لیے صرف مارک اپ پر بھروسہ کرنے کے بجائے ایک حقیقی اسکرین ریڈر کے ساتھ تصدیق کریں۔

اصل حاصلِ کلام

ایک قابل رسائی (accessible) ہنگامی اسٹاپ بنانے کا مطلب ہے اپنے صارفین کا اتنا احترام کرنا کہ آپ انہیں سچ بتا سکیں۔ انٹرفیس کو سادہ ہونا چاہیے، متوقع طریقے سے حرکت کرنی چاہیے، اور کبھی یہ دکھاوا نہیں کرنا چاہیے کہ ایک درخواست (request) ہی نتیجہ (result) ہے۔ جب دباؤ زیادہ ہو اور ڈیٹا خطرے میں ہو، تو وضاحت صرف وقت ہی نہیں بچاتی بلکہ اعتماد بھی بچاتی ہے۔ ایک ایماندار اسٹاپ بٹن صرف ایک ٹاسک کو نہیں روکتا، بلکہ یہ ثابت کرتا ہے کہ آپ کی پروڈکٹ استعمال کے لیے محفوظ ہے۔