অ্যাক্সেসিবল ওয়েব বোতামের জন্য সংক্ষিপ্ত, মতামতপূর্ণ চেকলিস্ট

বোতাম অ্যাক্সেসিবিলিটি পরামর্শের সমস্যা

বোতাম অ্যাক্সেসিবিলিটি নিয়ে বেশিরভাগ নির্দেশনা দুই ধরনের হয়: হয় এটি ৪০ পৃষ্ঠার WCAG ব্যাখ্যা, যা কেউ পড়ে না, অথবা কোনো কার্যকর ধাপ ছাড়া “বোতামকে অ্যাক্সেসিবল করুন” ধরনের অস্পষ্ট পরামর্শ। বৃহস্পতিবার একটি ফিচার শিপ করতে হলে কোনোটিই সাহায্য করে না।

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

1. বোতামের জন্য button এলিমেন্ট ব্যবহার করুন

যদি এটি বোতামের মতো আচরণ করে, তাহলে এটি একটি <button> এলিমেন্ট হওয়া উচিত। onclick সহ <div> নয়, role="button" সহ <span> নয়, href="#" এবং preventDefault সহ <a> নয়।

<button> এলিমেন্ট আপনাকে কিবোর্ড নেভিগেশন, ফোকাস ম্যানেজমেন্ট এবং স্ক্রিন রিডার ঘোষণা বিনামূল্যে দেয়। আপনি যখন <div> ব্যবহার করেন, তখন এসব কিছু শুরু থেকে নিজে বানাচ্ছেন — এবং ভুল হওয়াই স্বাভাবিক।

একমাত্র ব্যতিক্রম: যদি অ্যাকশনটি নতুন পেজে নিয়ে যায় বা URL পরিবর্তন করে, তাহলে <a> এলিমেন্ট ব্যবহার করুন। লিংক এবং বোতাম অর্থগতভাবে আলাদা। স্ক্রিন রিডার ব্যবহারকারীরা এলিমেন্টের ধরন অনুযায়ী নেভিগেট করেন, এবং তারা আশা করেন বোতাম অ্যাকশন করবে আর লিংক নেভিগেট করবে।

2. হিট টার্গেট অন্তত 44×44 পিক্সেল করুন

WCAG 2.5.5 (Level AAA) অনুযায়ী ইন্টারঅ্যাকটিভ এলিমেন্টের ন্যূনতম টার্গেট সাইজ 44×44 CSS পিক্সেল হতে হবে। এটি ভিজ্যুয়াল সাইজের বিষয় নয় — এটি ক্লিকযোগ্য এলাকার বিষয়।

পর্যাপ্ত padding দিয়ে ছোট ভিজ্যুয়াল বোতাম রাখতে পারেন, অথবা pseudo-element দিয়ে হিট টার্গেট বাড়াতে পারেন। মূল বিষয় হলো ব্যবহারকারীকে যেন খুব নিখুঁতভাবে লক্ষ্য করতে না হয়।

মোবাইল ব্যবহারকারী, মোটর প্রতিবন্ধকতা আছে এমন মানুষ, এবং চলন্ত অবস্থায় ডিভাইস ব্যবহার করা যে কেউ ছোট টার্গেট মিস করবেন। 24×24 পিক্সেলের আইকন বোতাম দেখতে পরিষ্কার লাগতে পারে, কিন্তু এটি usability ব্যর্থতা।

3. শুধু ব্রাউজার ডিফল্ট নয়, দৃশ্যমান focus state দিন

ব্রাউজারের ডিফল্ট focus ring কিছু না থাকার চেয়ে ভালো, কিন্তু এটি ব্রাউজারভেদে অসঙ্গত এবং নির্দিষ্ট ব্যাকগ্রাউন্ডে প্রায়ই অদৃশ্য হয়। আপনার design system-এ কাজ করে এমন একটি কাস্টম focus state দরকার।

ভালো focus indicator-এর তিনটি গুণ থাকে:

• উচ্চ contrast: পাশের রঙের তুলনায় অন্তত 3:1
• দৃশ্যমান offset: বোতামের নিজের border বা background-এ লুকিয়ে যাবে না
• সামঞ্জস্যপূর্ণ shape: ব্যবহারকারীরা আপনার interface জুড়ে এটিকে focus indicator হিসেবে চিনতে পারবেন

ভালো কিছু দিয়ে প্রতিস্থাপন না করে outline: none সরাবেন না। এবং focus state এত সূক্ষ্ম করবেন না যে নিখুঁত আলোয় শুধু আপনিই তা দেখতে পান।

4. প্রসঙ্গ ছাড়াও অর্থপূর্ণ বোতাম label লিখুন

স্ক্রিন রিডার ব্যবহারকারীরা প্রায়ই বোতামগুলোর মধ্যে লাফিয়ে নেভিগেট করেন। তখন তারা আশপাশের প্রসঙ্গ ছাড়াই বোতাম label-এর একটি তালিকা শুনতে পান।

সেই তালিকায় “আরও জানুন” label দেওয়া বোতাম অকেজো। “এখানে ক্লিক করুন” বা “জমা দিন”ও তাই। label-টি অ্যাকশন বর্ণনা করা উচিত: “অ্যাক্সেসিবিলিটি চেকলিস্ট ডাউনলোড করুন”, “আপডেটে সাবস্ক্রাইব করুন”, “এই মন্তব্য মুছুন”।

আপনার design-এ যদি ছোট ভিজ্যুয়াল label দরকার হয়, তাহলে বর্ণনামূলক বিকল্প দিতে aria-label ব্যবহার করুন। তবে আরও ভালো সমাধান হলো এমন label লেখা যা সবার জন্য কাজ করে।

শুধু আইকনযুক্ত বোতামের জন্য aria-label বাধ্যতামূলক। শুধু magnifying glass আইকন থাকা বোতামে aria-label="Search" বা সমতুল্য টেক্সট দরকার। আইকন স্ক্রিন রিডারের কাছে অ্যাক্সেসিবল নয়।

5. যথেষ্ট color contrast নিশ্চিত করুন

WCAG 2.1 অনুযায়ী normal text-এর জন্য contrast ratio অন্তত 4.5:1 এবং large text-এর জন্য 3:1 হতে হবে (18pt বা 14pt bold)। বোতামের label সাধারণত normal text হয়।

সাদা বোতামে হালকা ধূসর টেক্সট ব্যর্থ হয়। হালকা নীল ব্যাকগ্রাউন্ডে ফ্যাকাশে নীলও ব্যর্থ হয়। এসব কম্বিনেশন পরিশীলিত দেখাতে পারে, কিন্তু low vision, color blindness আছে এমন ব্যবহারকারী বা উজ্জ্বল রোদে স্ক্রিন দেখা যে কাউকে বাদ দিয়ে দেয়।

লঞ্চের পরে নয়, design করার সময় contrast checker ব্যবহার করুন। প্রোডাকশনে contrast সমস্যা ঠিক করা ব্যয়বহুল, কারণ এতে প্রায়ই design system পরিবর্তন করতে হয়।

আপনি যদি image processing tool নিয়ে কাজ করেন, অ্যাক্সেসিবল visual asset তৈরি করার সময় privacy বজায় রাখতে client-side processing সাহায্য করতে পারে — বিশেষ করে color combination পরীক্ষা করা বা preview state তৈরি করার সময়।

এই চেকলিস্টে যা নেই

এই তালিকাটি ইচ্ছাকৃতভাবে অসম্পূর্ণ। এতে disabled state semantics, loading state, error handling, বা split button ও dropdown trigger-এর মতো জটিল button pattern নেই। এসব pattern-এর জন্য আলাদা নির্দেশনা দরকার।

কখন বোতাম ব্যবহার করবেন আর কখন অন্য interactive element ব্যবহার করবেন — এই বৃহত্তর প্রশ্নও এটি কভার করে না। তার জন্য semantic HTML এবং accessibility tree বুঝতে হবে — যেগুলো নিজস্ব নিবন্ধ পাওয়ার মতো বিষয়।

এটি যা কভার করে তা হলো low-hanging fruit: প্রায় প্রতিটি code review-তে দেখা যায়, সবচেয়ে বেশি ব্যবহারকারীকে প্রভাবিত করে, এবং development চলাকালে সবচেয়ে সহজে ঠিক করা যায় — এমন ভুলগুলো।

এটি আপনার workflow-তে কীভাবে যুক্ত করবেন

Accessibility checklist তখনই কাজ করে যখন তা development process-এর অংশ হয়, পরে জোড়া লাগানো কিছু নয়। এটি ঘটানোর উপায়:

Design-এ: আপনার design file-এ focus state এবং hit target annotation যোগ করুন। এগুলো developer-দের অনুমানের ওপর ছেড়ে দেবেন না।

Code review-তে: <button> element, icon button-এ aria-label, এবং focus state CSS পরীক্ষা করুন। এগুলো দ্রুত চোখে পড়ে।

Testing-এ: কিবোর্ড দিয়ে আপনার interface-এ tab করুন। আপনি যদি কোনো বোতামে পৌঁছাতে না পারেন বা focus কোথায় আছে দেখতে না পান, আপনার ব্যবহারকারীরাও পারবেন না।

Documentation-এ: আপনার component library-তে বোতাম অ্যাক্সেসিবিলিটি requirement অন্তর্ভুক্ত করুন। ভুল কাজ করার চেয়ে সঠিক কাজ করা সহজ করে দিন।

আপনি যদি production issue debug করেন, HTTP header এবং redirect inspect করার tool assistive technology কীভাবে আপনার markup ব্যাখ্যা করছে তা বুঝতে সাহায্য করতে পারে — বিশেষ করে navigation-এর পরে focus management troubleshooting করার সময়।

এই কাজ এড়িয়ে যাওয়ার খরচ

Inaccessible বোতাম শুধু WCAG compliance ব্যর্থ করে না — এগুলো workflow ভেঙে দেয়। যে ব্যবহারকারী submit button ক্লিক করতে পারেন না, তিনি form সম্পূর্ণ করতে পারেন না। যে ব্যবহারকারী focus state দেখতে পান না, তিনি keyboard দিয়ে navigate করতে পারেন না। যে ব্যবহারকারী background থেকে button text আলাদা করতে পারেন না, তিনি label পড়তে পারেন না।

এগুলো edge case নয়। বিশ্ব জনসংখ্যার প্রায় ১৫% কোনো না কোনো ধরনের disability নিয়ে বাস করে, এবং temporary impairment (ভাঙা mouse, উজ্জ্বল রোদ, কোলে শিশু ধরা) শেষ পর্যন্ত সবাইকে প্রভাবিত করে।

ভালো খবর হলো বোতাম accessibility বেশিরভাগ ক্ষেত্রেই সমাধান হওয়া সমস্যা। নতুন pattern আবিষ্কার করতে বা browser support-এর জন্য অপেক্ষা করতে হবে না। আপনাকে শুধু platform সঠিকভাবে ব্যবহার করতে হবে এবং নিজের কাজ test করতে হবে।

Key takeaways

• বোতামের জন্য <button> element এবং navigation-এর জন্য <a> element ব্যবহার করুন — semantic পার্থক্য assistive technology-র জন্য গুরুত্বপূর্ণ
• motor impairment এবং mobile user-দের সহায়তা করতে hit target অন্তত 44×44 CSS পিক্সেল নিশ্চিত করুন
• আপনার design system জুড়ে কাজ করে এমন দৃশ্যমান, high-contrast focus state দিন
• আলাদা করে পড়লেও অর্থপূর্ণ এমন button label লিখুন, এবং icon-only button-এর জন্য aria-label ব্যবহার করুন
• ব্যয়বহুল retrofit এড়াতে launch-এর পরে নয়, design-এর সময় color contrast পরীক্ষা করুন

FAQ

Q: keyboard handler যোগ করলে কি <div>-এ role="button" ব্যবহার করতে পারি?

A: পারেন, কিন্তু করা উচিত নয়। আপনাকে Enter, Space, focus management, এবং disabled state ম্যানুয়ালি সামলাতে হবে — এবং নিশ্চিতভাবেই কিছু না কিছু বাদ পড়বে। <button> element ডিফল্টভাবেই এগুলো সঠিকভাবে করে। সেটিই ব্যবহার করুন।

Q: play/pause button-এর মতো state toggle করা button হলে কী করব?

A: বর্তমান state বোঝাতে aria-pressed="true" বা aria-pressed="false" ব্যবহার করুন। button label-এ click করলে যে action হবে সেটিও প্রতিফলিত হওয়া উচিত (চলতে থাকলে “Pause”, paused থাকলে “Play”), বর্তমান state নয়। স্ক্রিন রিডার ব্যবহারকারীদের জানতে হবে button কী করবে, system কোন state-এ আছে তা নয়।

Q: disabled button-এর কি contrast requirement পূরণ করতে হয়?

A: WCAG 2.1 disabled control-কে contrast requirement (1.4.3) থেকে ছাড় দেয়, কিন্তু এটি বিতর্কিত। কম contrast-এর disabled button সবার জন্যই বোঝা কঠিন। disabled button দেখাতেই হলে, সেটি readable করুন। আরও ভালো, সেটি hide করুন বা কেন disabled তা ব্যাখ্যা করুন।

Q: screen reader ছাড়া button accessibility কীভাবে test করব?

A: আপনার keyboard ব্যবহার করুন। interface-এ tab করে দেখুন আপনি প্রতিটি button-এ পৌঁছাতে পারেন কি না, focus কোথায় আছে দেখতে পান কি না, এবং Enter বা Space দিয়ে button activate করতে পারেন কি না। এতে বেশিরভাগ সমস্যা ধরা পড়ে। আরও গভীর testing-এর জন্য Chrome বা Firefox DevTools-এর accessibility inspector ব্যবহার করে computed role এবং label পরীক্ষা করুন।

Q: aria-label এবং aria-labelledby-এর পার্থক্য কী?

A: aria-label সরাসরি একটি text string দেয়। aria-labelledby অন্য একটি element-এর ID reference করে, যার text content label হয়ে যায়। label text DOM-এর অন্য কোথাও আগে থেকেই থাকলে aria-labelledby ব্যবহার করুন। screen-এ দৃশ্যমান নয় এমন label দিতে হলে aria-label ব্যবহার করুন।

Sources

• Web Content Accessibility Guidelines (WCAG) 2.1 — W3C
• Inclusive Components: Toggle Buttons — Heydon Pickering
• The ARIA Button Pattern — W3C ARIA Authoring Practices Guide
• WebAIM: Keyboard Accessibility — WebAIM