SaaS প্রোডাক্ট ও ওয়েব অ্যাপের জন্য WCAG 2.2 AA চেকলিস্ট

একটি SaaS প্রোডাক্টে অ্যাক্সেসিবিলিটির দুটি দিক থাকে: যে মার্কেটিং সাইট প্রোডাক্টটি বিক্রি করে, আর যে অ্যাপ্লিকেশন মানুষ প্রতিদিন ব্যবহার করেন। মার্কেটিং সাইট যেকোনো ওয়েবসাইটের মতোই ব্যর্থ হয়: কম কনট্রাস্ট, অনুপস্থিত অল্ট টেক্সট আর লেবেল ছাড়া ফর্ম। অ্যাপ্লিকেশন নিজের সমস্যা যোগ করে: পাসওয়ার্ড ম্যানেজার আটকে দেওয়া লগইন ফ্লো, কিবোর্ড ফোকাস আটকে রাখা ডায়ালগ, স্ক্রিন রিডার টের পায় না এমন সিঙ্গেল-পেজ নেভিগেশন, লেখা ছাড়া ডেটা টেবিল ও চার্ট, বিকল্প ছাড়া ড্র্যাগ-অ্যান্ড-ড্রপ, এবং সতর্কতা ছাড়াই শেষ হয়ে যাওয়া সেশন। এই চেকলিস্ট একটি সাধারণ SaaS প্রোডাক্টের অংশ ধরে ধরে WCAG 2.2 Level AA পর্যালোচনা করে।

মূল বিষয়গুলো

• WCAG 2.2 অক্টোবর 2023-এ W3C Recommendation হয় এবং নয়টি সাফল্যের মানদণ্ড যোগ করে, যার ছয়টি Level A বা AA-র (W3C (নতুন ট্যাবে খোলে))।
• Accessible Authentication (3.3.8, AA)-এর মানে, লগইন পাসওয়ার্ড মনে রাখা বা দেখে দেখে লেখার ওপর নির্ভর করতে পারবে না, যদি না মানুষ সেটি পেস্ট করতে পারেন বা পাসওয়ার্ড ম্যানেজার ব্যবহার করতে পারেন (W3C (নতুন ট্যাবে খোলে))।
• ইন্টারঅ্যাকটিভ টার্গেট অন্তত 24 × 24 CSS পিক্সেলের হতে হবে, অথবা চারপাশে যথেষ্ট জায়গা থাকতে হবে (2.5.8, AA) (W3C (নতুন ট্যাবে খোলে))।
• “সেভ হয়েছে” বা “3টি ফলাফল”-এর মতো বার্তা ফোকাস না সরিয়েই স্ক্রিন রিডারে পৌঁছাতে হবে (4.1.3, AA) (W3C (নতুন ট্যাবে খোলে))।
• ব্যবসায়িক ও সরকারি ক্রেতারা প্রায়ই একটি Accessibility Conformance Report চান, যা সাধারণত Information Technology Industry Council-এর VPAT টেমপ্লেটে লেখা হয় (ITI (নতুন ট্যাবে খোলে))।

ব্রোশিওর সাইটের চেয়ে SaaS-এর জন্য অ্যাক্সেসিবিলিটি কেন বেশি গুরুত্বপূর্ণ?

মানুষ একটি SaaS প্রোডাক্ট ঘণ্টার পর ঘণ্টা ব্যবহার করেন, প্রায়ই এই কারণে যে তাঁদের নিয়োগকর্তা এটি বেছে নিয়েছেন। মার্কেটিং পেজের একটি বাধা একজন ভিজিটর হারায়; প্রোডাক্টের একটি বাধা কাউকে তাঁর কাজ করা থেকেই আটকে দিতে পারে। এ কারণেই বড় গ্রাহক, বিশ্ববিদ্যালয় ও সরকারি প্রতিষ্ঠান কেনার আগে ক্রমশ বেশি করে অ্যাক্সেসিবিলিটি নিয়ে প্রশ্ন করছে, এবং এ কারণেই উত্তরে শুধু ওয়েবসাইট নয়, অ্যাপ্লিকেশনও থাকতে হবে।

এটি আরও গুরুত্বপূর্ণ, কারণ স্বয়ংক্রিয় পরীক্ষা সমস্যার কেবল একটি অংশ ধরে। axe-core-এর মতো টুল মার্কআপের ত্রুটি খুঁজে পায়, যেমন অনুপস্থিত লেবেল ও কম কনট্রাস্ট। কিন্তু একটি ডায়ালগ ফোকাসকে ঠিক জায়গায় ফিরিয়ে দেয় কি না, একটি চার্টের ডেটা লেখা হিসেবে পাওয়া যায় কি না, বা একটি ওয়ার্কফ্লো কিবোর্ড দিয়ে সম্পন্ন করা যায় কি না, তা এগুলো বলতে পারে না। একটি অ্যাপ্লিকেশনের জন্য স্বয়ংক্রিয় যাচাই ও ম্যানুয়াল পরীক্ষা, দুটোই দরকার।

সাইন-আপ ও লগইন কীভাবে অ্যাক্সেসিবল করবেন?

অথেনটিকেশনেই WCAG 2.2 SaaS-এর জন্য সবচেয়ে গুরুত্বপূর্ণ নতুন শর্তটি যোগ করেছে।

• পেস্ট ও পাসওয়ার্ড ম্যানেজারের অনুমতি দিন (3.3.8, AA)। পাসওয়ার্ড বা কোড ফিল্ডে পেস্ট করা আটকাবেন না, এবং autocomplete="username", autocomplete="current-password" ও autocomplete="one-time-code" ব্যবহার করুন, যাতে ব্রাউজার ও পাসওয়ার্ড ম্যানেজার এগুলো পূরণ করতে পারে।
• ধাঁধাকে ঢোকার একমাত্র পথ করবেন না। যে CAPTCHA মানুষকে বিকৃত লেখা দেখে লিখতে বা ধাঁধা সমাধান করতে বলে, সেটি একটি জ্ঞানগত (cognitive) পরীক্ষা। একটি বিকল্প দিন, এবং এমন যাচাইকে অগ্রাধিকার দিন যাতে ব্যবহারকারীকে কিছু করতে হয় না (W3C (নতুন ট্যাবে খোলে))।
• প্রতিটি ফিল্ডে লেবেল দিন (1.3.1 ও 3.3.2, A)। ইনপুটের সঙ্গে যুক্ত একটি দৃশ্যমান <label> ব্যবহার করুন; প্লেসহোল্ডার টেক্সট টাইপ করলেই মুছে যায় এবং এটি লেবেল নয়।
• ত্রুটি লেখায় জানান (3.3.1, A) এবং সমাধান প্রস্তাব করুন (3.3.3, AA)। “পাসওয়ার্ডে অন্তত 12টি অক্ষর থাকতে হবে” সাহায্য করে; শুধু লাল বর্ডার করে না।
• দুবার জিজ্ঞেস করবেন না (3.3.7, A)। একাধিক ধাপের সাইন-আপে কোম্পানির নাম বা ঠিকানা আগেই চাওয়া হয়ে থাকলে আবার টাইপ করানোর বদলে সেটি নিজে থেকে পূরণ করুন বা মানুষকে বেছে নিতে দিন।
• সাহায্য একই জায়গায় রাখুন (3.2.6, A)। আপনি চ্যাট, সাহায্যের লিংক বা যোগাযোগের তথ্য দিলে ফ্লোর প্রতিটি পেজে সেগুলো একই আপেক্ষিক অবস্থানে রাখুন।

কোন ফর্ম ও ত্রুটির ধরন সবচেয়ে বেশি ব্যর্থতা ঘটায়?

অ্যাপ্লিকেশনের বেশিরভাগ ত্রুটি থাকে ফর্মে। WebAIM-এর 2026 সালের 10 লাখ হোম পেজের সমীক্ষায় 51%-এ ফর্ম লেবেল অনুপস্থিত পাওয়া গেছে (WebAIM (নতুন ট্যাবে খোলে)), আর অ্যাপ্লিকেশনে হোম পেজের চেয়ে অনেক বেশি ফর্ম থাকে।

• প্রতিটি ইনপুটকে প্রোগ্রাম্যাটিক নাম দিন, এবং রেডিও বাটনের মতো সম্পর্কিত কন্ট্রোলগুলো <fieldset> ও <legend> দিয়ে গ্রুপ করুন।
• ত্রুটির কথা এমন জায়গায় জানান যেখানে মানুষের চোখে পড়বে: ফোকাস ফর্মের ওপরের ত্রুটির সারাংশে বা প্রথম ভুল ফিল্ডে নিয়ে যান, এবং সারাংশের প্রতিটি আইটেম তার ফিল্ডের সঙ্গে লিংক করুন।
• আবশ্যক ফিল্ড লেখা দিয়ে চিহ্নিত করুন, শুধু রং দিয়ে নয় (1.4.1, A)।
• কেউ শুধু একটি অপশন বাছলেই ফর্ম সাবমিট বা প্রেক্ষাপট বদলাবেন না (3.2.2, A); একটি স্পষ্ট অ্যাকশনের জন্য অপেক্ষা করুন।

ডায়ালগ, মেনু ও পপওভার কেমন আচরণ করা উচিত?

কাস্টম কম্পোনেন্টেই কিবোর্ড ও স্ক্রিন রিডার সাপোর্ট সবচেয়ে বেশি ভেঙে পড়ে। WAI-ARIA Authoring Practices Guide প্রতিটি প্যাটার্নের প্রত্যাশিত আচরণ বর্ণনা করে (W3C (নতুন ট্যাবে খোলে))।

• ডায়ালগ: খোলার সময় ফোকাস ডায়ালগের ভেতরে নিয়ে যান, খোলা থাকা অবধি Tab ভেতরেই রাখুন, Escape দিয়ে বন্ধ করুন, এবং যে কন্ট্রোল এটি খুলেছিল সেখানে ফোকাস ফিরিয়ে দিন। নেটিভ <dialog> এলিমেন্ট, অথবা aria-modal="true" ও একটি নামসহ role="dialog" ব্যবহার করুন।
• কোনো কিবোর্ড ফাঁদ নয় (2.1.2, A): প্রতিটি কম্পোনেন্ট থেকে কিবোর্ড দিয়ে বেরিয়ে আসা যেতে হবে।
• দৃশ্যমান ফোকাস (2.4.7, AA), যা স্টিকি হেডার, কুকি ব্যানার বা চ্যাট উইজেটের পেছনে লুকিয়ে থাকে না (2.4.11, AA, 2.2-এ নতুন)।
• টুলটিপ ও পপওভার (1.4.13, AA), যা মানুষ Escape দিয়ে সরাতে পারেন, যার ওপর হোভার করলে তা মিলিয়ে যায় না, এবং সরিয়ে না দেওয়া পর্যন্ত থেকে যায়।
• এক-কী শর্টকাট (2.1.4, A): কোনো অক্ষরের কী চাপলে একটি অ্যাকশন হলে মানুষকে শর্টকাট বন্ধ বা অন্য কী-তে বদলাতে দিন, অথবা সংশ্লিষ্ট কম্পোনেন্টে ফোকাস থাকলেই কেবল সেগুলো সক্রিয় রাখুন।

সিঙ্গেল-পেজ অ্যাপে নেভিগেশন কীভাবে সামলাবেন?

সিঙ্গেল-পেজ অ্যাপে পেজ লোড ছাড়াই URL বদলে যায়, তাই স্ক্রিন রিডার হয়তো জানায়ই না যে কিছু ঘটেছে।

• প্রতিটি রুট পরিবর্তনে ডকুমেন্ট টাইটেল হালনাগাদ করুন, যাতে প্রতিটি ভিউয়ের একটি বর্ণনামূলক টাইটেল থাকে (2.4.2, A)।
• ফোকাস নতুন ভিউয়ের মূল হেডিংয়ে নিয়ে যান, অথবা একটি polite live region-এ পরিবর্তনটি ঘোষণা করুন; Next.js-এর মতো ফ্রেমওয়ার্কে এর জন্য একটি route announcer থাকে।
• ফোকাসের একটি যৌক্তিক ক্রম রাখুন (2.4.3, A): একটি আইটেম মুছে ফেলার পর ফোকাস পেজের একেবারে ওপরে নয়, বরং একটি যুক্তিসংগত পাশের এলিমেন্টে যাওয়া উচিত।
• বারবার আসা নেভিগেশন এড়িয়ে যাওয়ার একটি উপায় দিন (2.4.1, A), যেমন একটি স্কিপ লিংক বা ল্যান্ডমার্ক।

ড্যাশবোর্ড, ডেটা টেবিল ও চার্ট কীভাবে অ্যাক্সেসিবল করবেন?

• টেবিল: হেডারের জন্য <th> ও scope-সহ আসল <table> মার্কআপ এবং একটি ক্যাপশন ব্যবহার করুন (1.3.1, A)। <div> এলিমেন্ট দিয়ে বানানো গ্রিডের জন্য পুরো ARIA grid প্যাটার্ন দরকার, যা ঠিকঠাক করা অনেক বেশি কঠিন।
• চার্ট: প্রতিটি চার্টকে এমন একটি টেক্সট বিকল্প দিন যা মূল বক্তব্যটি জানায়, এবং ডেটা একটি টেবিল হিসেবেও দিন (1.1.1, A)। সিরিজগুলো আলাদা করতে শুধু রঙের ওপর নির্ভর করবেন না (1.4.1, A); লেবেল বা প্যাটার্ন যোগ করুন।
• কনট্রাস্ট: লেখার জন্য 4.5:1 দরকার (1.4.3, AA), আর চার্টের রেখা, আইকন ও ইনপুটের বর্ডারের জন্য পটভূমির তুলনায় 3:1 (1.4.11, AA)। ডার্ক মোড আলাদাভাবে যাচাই করুন। আমাদের কালার কনট্রাস্ট চেকার যেকোনো রঙের জোড়া পরীক্ষা করে।
• স্ট্যাটাস বার্তা (4.1.3, AA): “সেভ হয়েছে”, “আপলোড সম্পূর্ণ” ও ফলাফলের সংখ্যার জন্য role="status" বা একটি live region ব্যবহার করুন, যাতে স্ক্রিন রিডার ব্যবহারকারীরা নিজেদের জায়গা না হারিয়েই সেগুলো শুনতে পান।

WCAG 2.2-এর নতুন মানদণ্ড ওয়েব অ্যাপের জন্য কী বদলায়?

WCAG 2.2 4.1.1 Parsing-ও বাদ দিয়েছে, যার এখন অ্যাক্সেসিবিলিটিতে কোনো বাস্তব প্রভাব নেই (W3C (নতুন ট্যাবে খোলে))।

টাইমআউট, লেআউট ও জুমের কী হবে?

• সেশন টাইমআউট (2.2.1, A): সেশন শেষ হওয়ার আগে মানুষকে সতর্ক করুন এবং একটি সহজ অ্যাকশনে সময় বাড়াতে দিন, যদি না সময়সীমাটি অপরিহার্য হয় বা 20 ঘণ্টার বেশি হয়। চলমান কাজ সেভ করে রাখলে সবচেয়ে খারাপ পরিণতি এড়ানো যায়।
• Reflow (1.4.10, AA): কনটেন্টকে 320 CSS পিক্সেল প্রস্থে (1280 পিক্সেলের স্ক্রিনে 400% জুমের সমান) দুই দিকে স্ক্রল ছাড়াই কাজ করতে হবে; ডেটা টেবিল ও এ ধরনের কনটেন্ট এর ব্যতিক্রম।
• লেখার ব্যবধান (1.4.12, AA): লাইনের উচ্চতা ও অক্ষরের ব্যবধান বাড়ালে লেখা কেটে যাওয়া উচিত নয়, যা নির্দিষ্ট উচ্চতার কন্টেইনারে প্রায়ই ঘটে।
• ওরিয়েন্টেশন (1.3.4, AA): অপরিহার্য না হলে অ্যাপটিকে পোর্ট্রেট বা ল্যান্ডস্কেপে লক করবেন না।

ACR কী, এবং আপনার কি এটি দরকার?

একটি Accessibility Conformance Report (ACR) নথিভুক্ত করে একটি প্রোডাক্ট প্রতিটি অ্যাক্সেসিবিলিটি মানদণ্ড কীভাবে পূরণ করে: supports, partially supports বা does not support, মন্তব্যসহ। বেশিরভাগ ACR লেখা হয় Information Technology Industry Council-এর প্রকাশিত VPAT টেমপ্লেটে, যার WCAG, যুক্তরাষ্ট্রের Section 508 মানদণ্ড এবং ইউরোপীয় মানদণ্ড EN 301 549-এর জন্য আলাদা সংস্করণ আছে (ITI (নতুন ট্যাবে খোলে))।

যুক্তরাষ্ট্রের ফেডারেল সংস্থাগুলোকে Section 508 অনুযায়ী অ্যাক্সেসিবল প্রযুক্তি কিনতে হয় (Section508.gov (নতুন ট্যাবে খোলে)), আর EU-র সরকারি প্রতিষ্ঠানগুলো EN 301 549-এর উল্লেখ করে, তাই এই গ্রাহকদের কাছে বিক্রি করা B2B প্রোডাক্টের কাছে কেনাকাটার প্রক্রিয়ায় প্রায়ই একটি ACR চাওয়া হয়। জানা ঘাটতিগুলো উল্লেখ করা একটি সৎ ACR ক্রেতাদের কাছে পূর্ণ সাপোর্টের দাবি করা ACR-এর চেয়ে বেশি কাজের। এটি প্রোডাক্টের পরীক্ষার ওপর ভিত্তি করে হওয়া উচিত, ম্যানুয়াল পরীক্ষাসহ; শুধু একটি স্বয়ংক্রিয় স্ক্যান দিয়ে এটি পূরণ করা যায় না।

আপনি EU-তে ভোক্তাদের কাছে বিক্রি করলে আপনার অনলাইন বিক্রির পদ্ধতিতে European Accessibility Act-ও প্রযোজ্য হতে পারে; আমাদের EAA গাইড এর পরিধি ব্যাখ্যা করে। এটি আইনি পরামর্শ নয়।

একটি SaaS টিম কীভাবে অ্যাক্সেসিবিলিটি পরীক্ষা করবে?

1. মৌলিক বিষয়গুলো স্বয়ংক্রিয় করুন। আপনার end-to-end টেস্টে ও মার্কেটিং সাইটে axe-core বা এ ধরনের কোনো ইঞ্জিন চালান, এবং নতুন লঙ্ঘন পেলে বিল্ড ব্যর্থ করুন। আমাদের ফ্রি অ্যাক্সেসিবিলিটি চেকার যেকোনো পাবলিক পেজে একই ইঞ্জিন চালায়।
2. কিবোর্ড দিয়ে পরীক্ষা করুন। সাইন-আপ, একটি রেকর্ড তৈরি ও সেটিংস বদলানোর মতো মূল ওয়ার্কফ্লোগুলো শুধু Tab, Shift+Tab, Enter, Space, Escape ও অ্যারো কী দিয়ে সম্পন্ন করুন।
3. স্ক্রিন রিডার দিয়ে পরীক্ষা করুন। Windows-এ NVDA এবং macOS ও iOS-এ VoiceOver ফ্রি। নাম, রোল, অবস্থা ও বার্তা ঘোষণা করা হয় কি না যাচাই করুন।
4. জুম ও আকার বদল করুন। 200% টেক্সট জুম এবং 320 পিক্সেল চওড়া উইন্ডো যাচাই করুন।
5. ডিজাইন সিস্টেমে ঠিক করুন। বেশিরভাগ ত্রুটি আসে শেয়ার করা কম্পোনেন্ট থেকে; একটি বাটন বা ডায়ালগ একবার ঠিক করলে তা সব জায়গায় ঠিক হয়ে যায়।

প্রায়শই জিজ্ঞাসিত প্রশ্ন

WCAG কি ওয়েব অ্যাপের লগইন-পরবর্তী অংশে প্রযোজ্য?

WCAG যেকোনো ওয়েব কনটেন্টে প্রযোজ্য, লগইনের পেছনের পেজসহ। কোনো নির্দিষ্ট প্রোডাক্টকে আইনত এটি পূরণ করতে হবে কি না, তা এখতিয়ার ও গ্রাহকের ওপর নির্ভর করে, তবে যে ক্রেতারা অ্যাক্সেসিবিলিটি নিয়ে প্রশ্ন করেন, তাঁরা সাধারণত পুরো প্রোডাক্টের কথাই বোঝান।

একটি ওভারলে কি SaaS প্রোডাক্টকে অ্যাক্সেসিবল করতে পারে?

না। ওভারলে কাস্টম কম্পোনেন্টের মূল কোড বদলায় না, আর অ্যাপ্লিকেশনের ত্রুটিগুলো সেখানেই থাকে। অ্যাক্সেসিবিলিটি ওভারলে নিয়ে আমাদের গাইডে একটি শীর্ষস্থানীয় ওভারলে বিক্রেতার বিরুদ্ধে FTC-র পদক্ষেপের কথা আছে।

স্বয়ংক্রিয় টুল WCAG-এর কতটুকু যাচাই করতে পারে?

কেবল একটি অংশ। স্বয়ংক্রিয় নিয়ম নির্ভরযোগ্যভাবে অনুপস্থিত নাম, লেবেল ও কনট্রাস্টের ত্রুটি খুঁজে পায়, কিন্তু অনেক মানদণ্ড, যেমন অর্থবহ ফোকাস ক্রম, কাজের অল্ট টেক্সট ও বোধগম্য ত্রুটির বার্তা, বিচার করতে একজন মানুষ দরকার।

আমাদের WCAG-এর কোন সংস্করণকে লক্ষ্য করা উচিত?

WCAG 2.2 Level AA হলো বর্তমান সংস্করণ। অনেক আইন ও কেনাকাটার নিয়ম এখনো WCAG 2.1 AA-র উল্লেখ করে; 2.2 AA পূরণ করলে বাদ দেওয়া Parsing মানদণ্ড ছাড়া 2.1 AA-ও পূরণ হয়।

আমাদের কি Level AAA পূরণ করতে হবে?

W3C পুরো প্রোডাক্টের জন্য AAA বাধ্যতামূলক করার পরামর্শ দেয় না, কারণ কিছু কনটেন্ট প্রতিটি AAA মানদণ্ড পূরণ করতে পারে না। সাধারণ লক্ষ্য হলো Level AA।

তথ্যসূত্র

• W3C: What's new in WCAG 2.2 (নতুন ট্যাবে খোলে)
• W3C: Web Content Accessibility Guidelines (WCAG) 2.2 (নতুন ট্যাবে খোলে)
• W3C: Understanding 3.3.8 Accessible Authentication (Minimum) (নতুন ট্যাবে খোলে)
• W3C: Understanding 2.5.8 Target Size (Minimum) (নতুন ট্যাবে খোলে)
• W3C: Understanding 4.1.3 Status Messages (নতুন ট্যাবে খোলে)
• W3C: ARIA Authoring Practices Guide: Dialog (modal) pattern (নতুন ট্যাবে খোলে)
• W3C: Inaccessibility of CAPTCHA (নতুন ট্যাবে খোলে)
• ITI: Voluntary Product Accessibility Template (VPAT) (নতুন ট্যাবে খোলে)
• GSA: Section508.gov (নতুন ট্যাবে খোলে)
• WebAIM: The WebAIM Million (2026) (নতুন ট্যাবে খোলে)