প্রোডাক্ট টিমগুলোর একটি অভ্যাস আছে যে তারা অ্যাক্সেসিবিলিটিকে শেষ মুহূর্তের রঙের প্রলেপের মতো বিবেচনা করে। তারা ফিচার তৈরি করে, ইন্টারফেস পালিশ করে এবং তারপর—লঞ্চের মাত্র দুই দিন আগে—একটি স্ক্যানার চালায়। হঠাৎ ড্যাশবোর্ড লাল হয়ে ওঠে। ফর্ম লেবেল নেই। বাটনগুলোর কোনো অ্যাক্সেসিবল নাম নেই। হেডিং লেভেলগুলো কোনো সতর্কতা ছাড়াই h1 থেকে সরাসরি h4-এ লাফিয়ে যাচ্ছে। রঙের সমন্বয় এমন যে টেক্সট ব্যাকগ্রাউন্ডের সাথে মিশে যাচ্ছে। এই তালিকাটি দেখে মনে হতে পারে এটি অনেক বড় সমস্যা, কারণ এটি অনেক আগেই সমাধান করা উচিত ছিল।
এই শেষ মুহূর্তের আতঙ্ক তৈরি হয় কারণ অ্যাক্সেসিবিলিটির কাজগুলো অনেক ম্যানুয়াল এবং ধীরগতির মনে হয়। একজন টেস্টার প্রতিটি টেমপ্লেট হাতে ক্লিক করে একটি স্প্রিন্টের মধ্যে খুব বেশি কিছু কভার করতে পারেন না। কিন্তু এখানে একটি বিষয় এড়িয়ে যাওয়া হয়: দেরিতে ধরা পড়া বেশিরভাগ ব্যর্থতা কোনো সূক্ষ্ম বা একক শৈল্পিক পছন্দ নয়। এগুলো পুনরাবৃত্তিমূলক এবং কাঠামোগত সমস্যা যা ডজন বা শত শত পেজে বারবার ঘটে। আর এই পুনরাবৃত্তির কারণেই অটোমেশন বা স্বয়ংক্রিয় ব্যবস্থা কার্যকর হয়।
মেশিন আসলে কোন কাজে সবচেয়ে সেরা
অ্যাক্সেসিবিলিটি টিমের জাদুর প্রয়োজন নেই। তাদের প্রয়োজন কাভারেজ। একজন দক্ষ হিউম্যান অডিটর কিছু বাছাই করা পেজ পরীক্ষা করতে পারেন, বিচারবুদ্ধি প্রয়োগ করতে পারেন এবং প্রেক্ষাপট বা কনটেক্সট প্রয়োজন এমন সূক্ষ্ম সমস্যাগুলো ধরতে পারেন। অন্যদিকে, একটি মেশিন কোনো ধাপ বাদ না দিয়ে বা ক্লান্ত না হয়ে প্রতি রাতে প্রতিটি পেজ পরীক্ষা করতে পারে। এই সমীকরণে AI-এর গুরুত্ব এই নয় যে এটি WCAG স্ট্যান্ডার্ডের বিকল্প হিসেবে কাজ করে। বরং এটি টিমগুলোর কাজের ধরন বদলে দেয়। একজন টেস্টার যখন র ডেটা বা এরর লগ নিয়ে হিমশিম খাচ্ছেন বা প্রতিটি টেমপ্লেটে ক্লিক করছেন, তার বদলে AI একই ধরনের সমস্যাগুলোকে গ্রুপ করতে পারে, তাদের ফ্রিকোয়েন্সি অনুযায়ী র্যাঙ্ক করতে পারে এবং আপনাকে বলে দিতে পারে কোন ব্যর্থতাগুলো ব্যবহারকারীর অভিজ্ঞতায় (user experience) সবচেয়ে বেশি প্রভাব ফেলছে।
ভলিউম, ট্রায়াজ (triage) এবং প্যাটার্ন শনাক্তকরণের জন্য AI ব্যবহার করুন। এটিকে র স্ক্যানিংয়ের ভার সামলাতে দিন যাতে আপনার টিম সমস্যাগুলো সমাধানের দিকে মনোযোগ দিতে পারে।
সাধারণ ব্যর্থতাগুলো যে সংকেত দেয়
বেশিরভাগ অ্যাক্সেসিবিলিটি ব্যর্থতা স্পষ্ট এবং শনাক্তযোগ্য সংকেত দেয়। একটি স্ক্যানার alt অ্যাট্রিবিউট নেই এমন ছবি শনাক্ত করতে পারে। এটি এমন বাটন খুঁজে পেতে পারে যা DOM-এ আছে কিন্তু তাতে কোনো টেক্সট বা aria-label নেই, যার ফলে স্ক্রিন রিডার ব্যবহারকারীরা বুঝতে পারেন না বাটনটি কী কাজ করে। এটি "click here" বা "read more" লেখা লিঙ্কগুলোকে চিহ্নিত করতে পারে, যা পেজগুলোতে ট্যাব করে চলা ব্যবহারকারীদের গন্তব্য সম্পর্কে ধারণা দেয় না। এটি রঙের এমন সমন্বয় শনাক্ত করে যা কন্ট্রাস্ট রিকোয়ারমেন্ট পূরণ করে না। এটি হেডিং হায়ারার্কি বা ক্রম শনাক্ত করে যা লেভেল স্কিপ করে, ফলে যারা পেজ ম্যাপ করার জন্য হেডিংয়ের ওপর নির্ভর করেন তাদের নেভিগেশনে সমস্যা হয়।
এগুলো প্যাটার্ন-ভিত্তিক সমস্যা। এগুলো কোডের মাধ্যমে অনুমানযোগ্য মার্কার হিসেবে প্রকাশ পায়, যার মানে হলো অটোমেশন ঠিক এই ধরনের কাজ খুঁজে বের করতে পারদর্শী।
প্রকৃত সমস্যা শনাক্ত করার জন্য একটি পাইপলাইন তৈরি করা
একটি ভালো সেটআপ শুধুমাত্র একবার চালানো একটি টুলের ওপর নির্ভর করে না। এটি বিভিন্ন স্তরের সমন্বয়ে গঠিত। প্রথম স্তর হলো একটি রুল ইঞ্জিন যা কোডটি নিজে স্ক্যান করে। ডেভেলপাররা যখন কম্পোনেন্ট লেখেন, তখন এই ইঞ্জিনগুলো WCAG গাইডলাইন অনুযায়ী মার্কআপ পরীক্ষা করে এবং ব্রাউজারে যাওয়ার আগেই আনলেবেলড ইনপুট বা ইনভ্যালিড অ্যাট্রিবিউটগুলোকে চিহ্নিত করে দেয়।
দ্বিতীয় স্তর হলো ব্রাউজার অটোমেশন। স্ট্যাটিক কোড অ্যানালাইসিস এমন কিছু ধরতে পারে না যা একটি মোডাল ওপেন হওয়ার পর, একটি ড্রপডাউন প্রসারিত হওয়ার পর বা একটি ফর্ম ভ্যালিডেশন এরর আসার পর ঘটে। অটোমেটেড ব্রাউজারগুলোর প্রকৃত ইউজার জার্নি—যেমন সাইনআপ ফ্লো, চেকআউট প্রসেস, অ্যাকাউন্ট ড্যাশবোর্ড—এর মধ্য দিয়ে যাওয়া প্রয়োজন, যেখানে ব্যবহারকারীর অ্যাকশনের ভিত্তিতে কন্টেন্ট ডাইনামিকভাবে পরিবর্তিত হয়। যদি আপনার পাসওয়ার্ডের প্রয়োজনীয়তা কেবল একটি ফিল্ড থেকে ফোকাস সরানোর পরে দেখা যায়, তবে শুধুমাত্র একটি কোড স্ক্যানার সেই অ্যানাউন্সমেন্ট ব্যর্থতাটি কখনোই দেখতে পাবে না।
তৃতীয় স্তর হলো যেখানে AI প্রাপ্ত ফলাফলগুলো বিশ্লেষণ করে এবং ডুপ্লিকেটগুলো একত্রিত করে। যদি একই আনলেবেলড আইকন বাটন আশিটি পেজে ব্যবহৃত একটি হেডার কম্পোনেন্টে থাকে, তবে সিস্টেমটির উচিত এটিকে কম্পোনেন্ট-লেভেল ত্রুটি হিসেবে একবার রিপোর্ট করা, আশিটি আলাদা পেজ-লেভেল বাগ হিসেবে নয়। এটি টিমগুলোকে অপ্রয়োজনীয় তথ্যের ভিড়ে হারিয়ে যাওয়া থেকে রক্ষা করে।
চতুর্থ স্তর হলো হিউম্যান রিভিউ বা মানুষের দ্বারা পর্যালোচনা। একটি মেশিন ক্রমাগত পরীক্ষা করতে পারে, কিন্তু রিলিজের আগে একজন মানুষের উচিত এজ কেসগুলো (edge cases) পর্যালোচনা করা। কোনো অটোমেটেড পাইপলাইনেরই চূড়ান্ত সিদ্ধান্ত নেওয়ার ক্ষমতা থাকা উচিত নয়।
টেকনিক্যাল জারগন থেকে অ্যাকশনে রূপান্তর
র স্ক্যানার আউটপুট প্রায়ই ব্যাকলগে পড়ে থাকে কারণ এটি ডেভেলপারদের জন্য নয় বরং অডিটরদের জন্য তৈরি স্পেসিফিকেশনের মতো মনে হয়। "insufficient color contrast ratio" লেখা একটি রিপোর্ট উপেক্ষা করা হয় কারণ এটি শুনতে বিমূর্ত এবং কম গুরুত্বপূর্ণ মনে হয়। পরিবর্তে "সাদা ব্যাকগ্রাউন্ডে ধূসর হেল্প টেক্সট পড়া কঠিন" বললে একজন ডেভেলপার ঠিক কী ঠিক করতে হবে, কোথায় দেখতে হবে এবং কেন এটি প্রকৃত ব্যবহারকারীদের জন্য গুরুত্বপূর্ণ তা স্পষ্টভাবে বুঝতে পারেন। AI টেকনিক্যাল WCAG ব্যর্থতাগুলোকে সহজ ভাষায় অনুবাদ করে এই ব্যবধান ঘুচিয়ে দিতে সাহায্য করতে পারে, যা প্রোডাক্ট টিমগুলো প্রকৃতপক্ষে পড়ে এবং সেই অনুযায়ী কাজ করে।
আপনার প্রতিটি অ্যালার্টকে একইভাবে না দেখে, আপনার প্রাপ্ত ফলাফলের জন্য কনফিডেন্স লেভেল (confidence levels) নির্ধারণ করা প্রয়োজন। উচ্চ কনফিডেন্সের সমস্যাগুলো, যেমন লেবেলহীন ফর্ম ইনপুট, স্বয়ংক্রিয়ভাবে টিকিট তৈরি করতে পারে কারণ WCAG অনুযায়ী এগুলোর সমাধান প্রায় সবসময়ই প্রয়োজন এবং সমাধানটিও সহজ। মাঝারি কনফিডেন্সের ফলাফলগুলো, যেমন সন্দেহজনক অল্ট টেক্সট (alt text) যা বর্ণনামূলক হওয়ার পরিবর্তে কিওয়ার্ড-স্টাফড (keyword-stuffed) হতে পারে, সেগুলো বর্ণনামূলক কি না তা বিচার করার জন্য মানুষের পর্যালোচনার প্রয়োজন। নিম্ন কনফিডেন্সের বিষয়গুলো ম্যানুয়াল টেস্টিংয়ের জন্য রিপোর্টে রাখা উচিত। একটি স্ক্যানার একটি মিসিং অল্ট অ্যাট্রিবিউট (alt attribute) দেখতে পায়, কিন্তু ছবিটি ডেকোরেটিভ নাকি বিষয়বস্তু বোঝার জন্য অপরিহার্য তা সে জানে না। এই প্রেক্ষাপট বোঝার জন্য মানুষের প্রয়োজন।
একবার ঠিক করুন, সব জায়গায় ঠিক করুন
AI টিমগুলোকে সমস্যাগুলো কোথায় পুঞ্জীভূত হয়ে আছে তা খুঁজে পেতে সাহায্য করে। যদি একটি ত্রুটিপূর্ণ বাটন কম্পোনেন্ট ৫০টি স্ক্রিনে ব্যবহার করা হয়, তবে কম্পোনেন্টটি একবার ঠিক করলেই সমস্যার সংখ্যা তাৎক্ষণিকভাবে কমে যাবে। এটি কাজটিকে প্রতিটি পেজ ধরে আলাদাভাবে সমাধান করার পরিবর্তে একটি পদ্ধতিগত কম্পোনেন্ট লাইব্রেরি রক্ষণাবেক্ষণে রূপান্তরিত করে। প্যাটার্ন রিকগনিশন বা ধরন শনাক্তকরণই হলো সেই জায়গা যেখানে AI প্রকৃত সুফল দেয়। এটি শত শত পেজের মধ্যে সংযোগ স্থাপন করে, যাতে টিমগুলোকে চল্লিশটি ভিন্ন ভিন্ন Jira টিকিটে একই বাগ (bug) বারবার ঠিক করতে না হয়।
পুল রিকোয়েস্টের (pull requests) সাথে স্ক্যানার যুক্ত করলে ফিডব্যাক লুপটি অত্যন্ত কার্যকর থাকে। একজন ডেভেলপার মার্জ করার আগেই যখন একটি অ্যালার্ট পান যে তাদের নতুন মার্কআপের কারণে কোনো হেডিং লেভেল বাদ পড়েছে, তখন সেটি ঠিক করতে মাত্র কয়েক মিনিট সময় লাগে। কিন্তু যখন সেই একই সমস্যা প্রোডাকশনে চলে যায় এবং লঞ্চের মাত্র দুই দিন আগে ধরা পড়ে, তখন সেটি ঠিক করতে একটি হটফিক্স (hotfix), রিগ্রেশন টেস্টিং এবং স্টেকহোল্ডারদের সাথে যোগাযোগের প্রয়োজন হয়। এই দ্রুত ফিডব্যাক লুপ সময় বাঁচায় এবং অ্যাক্সেসিবিলিটি ডেট (accessibility debt) কমায়।
কাজের বিভাজন
অটোমেশন নিজে থেকে আপনার পণ্যকে অ্যাক্সেসিবল (accessible) করে তুলবে না। তবে, এটি আপনার টিমকে বারবার একই ধরণের স্পষ্ট ভুলগুলো শিপ (ship) করা থেকে বিরত রাখবে। আপনার CI পাইপলাইনে অটোমেটেড চেক চালান। কন্টেন্ট এডিটর বা নতুন ফিচারের কারণে আসা রিগ্রেশনগুলো ধরার জন্য প্রতি রাতে স্টেজিং সাইটগুলো ক্রল (crawl) করুন। ব্যাকলগগুলো ম্যানেজযোগ্য রাখতে সমস্যাগুলোকে কম্পোনেন্ট অনুযায়ী গ্রুপ করুন। সাইটের সেই অংশগুলোর জন্য মানুষের মনোযোগ সংরক্ষণ করুন যেখানে প্রেক্ষাপট সবচেয়ে বেশি গুরুত্বপূর্ণ: একটি ছবির অল্ট টেক্সট প্রয়োজন কি না তা বিচার করা, জটিল কাস্টম কম্পোনেন্টগুলো মূল্যায়ন করা এবং ব্যবহারকারীর উদ্দেশ্য বোঝার প্রয়োজন হয় এমন ফ্লো (flow) পরীক্ষা করা।
ভলিউম, ট্রায়াজ (triage) এবং প্যাটার্ন রিকগনিশনের জন্য AI ব্যবহার করুন। মেশিনগুলোকে প্রতি রাতে প্রতিটি পেজে বারবার স্ক্যান করার কাজ করতে দিন। মানুষের কাজ হোক বিচার-বুদ্ধি প্রয়োগ করা। এই কাজের বিভাজনের মাধ্যমেই অ্যাক্সেসিবিলিটি লঞ্চের আগের আতঙ্ক থেকে একটি স্বাভাবিক ইঞ্জিনিয়ারিং অভ্যাসে পরিণত হয়।
Source: https://dev.to/henryv/automating-wcag-compliance-with-ai-4ogp
Join the discussion: https://t.me/GyaanSetuAi