স্ক্রিন রিডার ও অ্যাসিস্টিভ টেক-এর জন্য ডিজাইন
এই পাঠে যা শিখবেন
- সিমান্টিক HTML কেন স্ক্রিন-রিডার অ্যাক্সেসিবিলিটির ভিত্তি, এবং ARIA কখন ও কীভাবে ব্যবহার করতে হয়
- লজিক্যাল রিডিং অর্ডার কী এবং ভিজ্যুয়াল লেআউট (CSS) কীভাবে DOM অর্ডার থেকে বিচ্যুত হয়ে সমস্যা তৈরি করে
- অর্থবহ alt টেক্সট লেখার নীতি এবং ডেকোরেটিভ ইমেজ কীভাবে সঠিকভাবে হ্যান্ডল করতে হয়
- সুইচ অ্যাক্সেস ও স্ক্রিন ম্যাগনিফায়ারের মতো অন্যান্য অ্যাসিস্টিভ টেকনোলজির মৌলিক ডিজাইন-প্রয়োজনীয়তা
১ · সিমান্টিক HTML — স্ক্রিন-রিডার অ্যাক্সেসিবিলিটির ভিত্তি
একটি স্ক্রিন রিডারScreen Readerএকটি অ্যাসিস্টিভ টেকনোলজি সফটওয়্যার যা স্ক্রিনের কনটেন্ট টেক্সট-টু-স্পিচ বা রিফ্রেশযোগ্য ব্রেইল ডিসপ্লেতে রূপান্তর করে, দৃষ্টিপ্রতিবন্ধী ব্যবহারকারীদের কম্পিউটার/ফোন ব্যবহার করতে সহায়তা করে।
কোনো একটি পেজ "দেখে" না — এটি পেজের DOM স্ট্রাকচার পড়ে এবং সেটিকে শব্দে রূপান্তর করে। এর
মানে হলো, যদি একটি "বাটন" আসলে একটি স্টাইল করা <div> হয় (আসল
<button> এলিমেন্ট নয়), স্ক্রিন রিডার সেটিকে শুধু একটি সাধারণ টেক্সট ব্লক হিসেবে ঘোষণা
করবে — "বাটন" হিসেবে নয়, ক্লিকযোগ্য বলে বোঝাবে না, এবং কীবোর্ড দিয়ে ফোকাসও নাও করতে পারে।
এই কারণেই সিমান্টিক HTML — সঠিক এলিমেন্ট বেছে নেওয়া (<button> বাটনের
জন্য, <nav> নেভিগেশনের জন্য, <h1>–<h6> হেডিং
হায়ারার্কির জন্য, <label> ফর্ম ইনপুটের জন্য) — অ্যাক্সেসিবিলিটির সবচেয়ে সস্তা ও শক্তিশালী
প্রথম পদক্ষেপ। এটি WCAG-এর Robust নীতির (M10/L43) সরাসরি প্রয়োগ — সঠিক সিমান্টিক HTML
বিভিন্ন অ্যাসিস্টিভ টেকনোলজি দিয়ে নির্ভরযোগ্যভাবে ব্যাখ্যাযোগ্য হয়।
যেখানে HTML-এর নিজস্ব এলিমেন্ট যথেষ্ট নয় (যেমন একটি কাস্টম ড্রপডাউন, একটি ট্যাব ইন্টারফেস, একটি লাইভ
স্ট্যাটাস আপডেট), সেখানে ARIA (Accessible Rich Internet Applications) অ্যাট্রিবিউট
ব্যবহার করা হয় — যেমন aria-label (একটি এলিমেন্টের অ্যাক্সেসিবল নাম দেওয়া),
aria-expanded (একটি ড্রপডাউন খোলা না বন্ধ তা জানানো), বা role="tab" (একটি
কাস্টম এলিমেন্টকে একটি পরিচিত প্যাটার্ন হিসেবে ঘোষণা করা)। একটি গুরুত্বপূর্ণ নিয়ম: "নো ARIA ইজ বেটার
দ্যান ব্যাড ARIA" — ভুলভাবে ব্যবহৃত ARIA সিমান্টিক HTML-এর স্বাভাবিক আচরণ ওভাররাইড করে দিতে পারে
এবং জিনিসগুলো আরও খারাপ করে দিতে পারে। ARIA হলো একটি "শেষ অবলম্বন" টুল, সিমান্টিক HTML-এর বিকল্প নয়।
২ · লজিক্যাল রিডিং অর্ডার
একটি স্ক্রিন রিডার সাধারণত একটি পেজ DOM-এ যে ক্রমে এলিমেন্টগুলো আছে সেই ক্রমেই পড়ে — CSS
দিয়ে ভিজ্যুয়ালি যেভাবেই সেগুলো পুনর্বিন্যস্ত করা হোক না কেন। যেমন, যদি একটি ফর্মের "সাবমিট" বাটন CSS-এর
order প্রোপার্টি বা position: absolute দিয়ে ভিজ্যুয়ালি উপরে সরানো হয় কিন্তু DOM-এ
সেটি এখনও শেষে থাকে, একজন স্ক্রিন-রিডার ব্যবহারকারী পুরো ফর্মটি পড়ার পরই বাটনটি শুনবেন — যা দৃষ্টিসম্পন্ন
ব্যবহারকারীর অভিজ্ঞতা থেকে সম্পূর্ণ ভিন্ন।
এই বিচ্যুতি একটি সাধারণ, সহজেই এড়ানো-যায় এমন বাগ — এবং এটি প্রমাণ করে কেন অ্যাক্সেসিবিলিটি টেস্টিং শুধু "কোড রিভিউ" নয়, বরং সত্যিকারের স্ক্রিন রিডার দিয়ে (যেমন NVDA, JAWS, বা VoiceOver) সরাসরি একটি পেজ ব্যবহার করে পরীক্ষা করা দরকার। M7-এ শেখা ইউজেবিলিটি টেস্টিং-এর নীতিগুলো (M7/L30) এখানেও প্রযোজ্য — শুধু এবার "পর্যবেক্ষক" হিসেবে একজন স্ক্রিন-রিডার ব্যবহারকারীকে সাথে নিয়ে।
৩ · অর্থবহ Alt টেক্সট বনাম ডেকোরেটিভ ইমেজ
প্রতিটি <img> এলিমেন্টের জন্য একটি সিদ্ধান্ত নিতে হয়:
ছবিটি যদি প্রকৃত তথ্য বহন করে (যেমন একটি চার্ট, একটি প্রোডাক্টের ছবি, একটি প্রোফাইল ছবি) — সংক্ষিপ্ত, বর্ণনামূলক
alt টেক্সট দিতে হবে যা ছবির উদ্দেশ্য বোঝায়, শুধু "ছবি" বা ফাইলের নাম নয়।ছবিটি যদি নিছক ভিজ্যুয়াল সাজসজ্জা হয় (যেমন একটি ব্যাকগ্রাউন্ড প্যাটার্ন, একটি ডিভাইডার আইকন) — খালি
alt="" দিতে হবে, যাতে স্ক্রিন রিডার এটি সম্পূর্ণ এড়িয়ে যায়। alt অ্যাট্রিবিউট বাদ দেওয়া ভুল — খালি রাখা সঠিক।
একটি সাধারণ ভুল হলো ফাইলের নাম বা অতি-সাধারণ টেক্সট alt হিসেবে ব্যবহার করা — যেমন
alt="IMG_2481.jpg" বা alt="ছবি" — এগুলো স্ক্রিন-রিডার ব্যবহারকারীর জন্য কোনো
প্রকৃত তথ্য দেয় না, বরং একটি অকেজো শব্দ শোনায়। একটি ভালো নিয়ম: নিজেকে জিজ্ঞাসা করুন, "যদি আমি এই ছবিটি না
দেখে শুধু এই বাক্যটি শুনি, আমি কি ছবিটির উদ্দেশ্য বুঝব?"
৪ · অন্যান্য অ্যাসিস্টিভ টেকনোলজি — সুইচ অ্যাক্সেস ও ম্যাগনিফায়ার
স্ক্রিন রিডার সবচেয়ে বেশি আলোচিত অ্যাসিস্টিভ টেকনোলজি হলেও, একমাত্র নয়। মোটর ডিজেবিলিটি (M10/L43-এ
উল্লেখিত) থাকা কিছু ব্যবহারকারী সুইচ অ্যাক্সেস ব্যবহার করেন — একটি বা দুটি ফিজিক্যাল সুইচ
দিয়ে স্ক্রিনের এলিমেন্টগুলোর মধ্য দিয়ে ধারাবাহিকভাবে স্ক্যান করে, সঠিক এলিমেন্টে পৌঁছালে সুইচ চেপে সিলেক্ট
করে। এর জন্য প্রয়োজন — প্রতিটি ইন্টারঅ্যাক্টিভ এলিমেন্ট কীবোর্ড-ফোকাসযোগ্য হওয়া (এখানেও সিমান্টিক HTML-এর
সুবিধা — একটি আসল <button> স্বয়ংক্রিয়ভাবে ফোকাসযোগ্য, একটি স্টাইল করা
<div> নয়), এবং একটি স্পষ্ট, প্রেডিক্টেবল ফোকাস-অর্ডার।
কম দৃষ্টিশক্তি-থাকা ব্যবহারকারীরা প্রায়ই স্ক্রিন ম্যাগনিফায়ার ব্যবহার করেন, যা স্ক্রিনের একটি অংশ বড় করে দেখায়। এর জন্য ডিজাইনের প্রভাব — টেক্সট রিফ্লো (জুম করলে টেক্সট নতুন করে সাজানো, অনুভূমিক স্ক্রল ছাড়াই), এবং টুলটিপ বা হোভার-নির্ভর তথ্য এড়ানো (কারণ ম্যাগনিফায়ার ব্যবহারকারী একসাথে পুরো স্ক্রিন দেখতে পান না, তাই দূরের একটি হোভার-এলিমেন্ট মিস করা সহজ)। এই দুটো উদাহরণই দেখায় — "অ্যাক্সেসিবল ডিজাইন" মানে শুধু একটি প্রযুক্তির জন্য নয়, বৈচিত্র্যময় ইন্টারঅ্যাকশন-পদ্ধতির জন্য ডিজাইন করা।
সিমান্টিক HTML প্রথমে, ARIA শুধু যেখানে প্রয়োজন সেখানে; DOM-অর্ডার ও ভিজ্যুয়াল-অর্ডার সামঞ্জস্যপূর্ণ রাখা; প্রতিটি ছবির জন্য সচেতন alt-সিদ্ধান্ত নেওয়া — এই তিনটি অভ্যাস একসাথে অধিকাংশ স্ক্রিন-রিডার সমস্যা প্রতিরোধ করে। কিন্তু স্ক্রিন রিডার ছাড়াও সুইচ অ্যাক্সেস ও ম্যাগনিফায়ারের মতো অন্যান্য অ্যাসিস্টিভ টেকনোলজির নিজস্ব চাহিদা মনে রাখা দরকার — L45-এ আমরা দেখব কীভাবে এই সব বিবেচনা মিলে একটি বৃহত্তর "ইনক্লুসিভ ডিজাইন" মাইন্ডসেট গঠন করে।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১
একজন ডেভেলপার একটি "বাটন" স্টাইল করা <div onclick="..."> দিয়ে বানিয়েছেন কারণ
এতে CSS দিয়ে কাস্টমাইজ করা সহজ। এই সিদ্ধান্তের সত্যিকারের খরচ কী?
একটি <div> ডিফল্টভাবে কীবোর্ড-ফোকাসযোগ্য নয়, স্ক্রিন রিডারে "বাটন" হিসেবে ঘোষিত হয়
না, এবং Enter/Space চাপলে সক্রিয় হয় না (শুধু onclick মাউস-ক্লিকে কাজ করে)। এর মানে —
কীবোর্ড-নেভিগেশন-নির্ভর ও স্ক্রিন-রিডার ব্যবহারকারীরা এই "বাটন"টি সম্পূর্ণ ব্যবহার করতে পারবেন না, যদি
না ডেভেলপার ম্যানুয়ালি tabindex, role="button", এবং কীবোর্ড ইভেন্ট হ্যান্ডলার
— এই সবকিছু যোগ করেন, যা প্রকৃতপক্ষে একটি আসল <button> ব্যবহার করার চেয়ে বেশি কাজ।
প্র ০২ একটি ই-কমার্স সাইটে একটি প্রোডাক্ট ছবির alt টেক্সট লেখা হয়েছে "লাল টি-শার্ট, সামনে থেকে দেখা, সাদা ব্যাকগ্রাউন্ডে, ২০২৪ সালের কালেকশন থেকে, মডেল ৫ফুট ৮ইঞ্চি লম্বা..." — এই বর্ণনায় কী সমস্যা আছে?
অতিরিক্ত দীর্ঘ ও বিস্তারিত alt টেক্সট স্ক্রিন-রিডার ব্যবহারকারীর জন্য বোঝা হয়ে ওঠে — প্রতিটি ছবির জন্য এত দীর্ঘ বর্ণনা শুনতে হলে পেজ ব্রাউজ করা ক্লান্তিকর হয়ে যায়। ভালো অনুশীলন হলো সংক্ষিপ্ত ও প্রাসঙ্গিক তথ্য দেওয়া (যেমন "লাল টি-শার্ট, সামনে থেকে দেখা") — বাকি বিস্তারিত তথ্য (কালেকশন, মডেলের উচ্চতা) যদি গুরুত্বপূর্ণ হয়, তা পেজের প্রধান টেক্সট কনটেন্টে থাকা উচিত, যা সব ব্যবহারকারীই দেখতে/শুনতে পান।
প্র ০৩ একটি টিম বলছে, "আমরা ARIA অ্যাট্রিবিউট সব জায়গায় যোগ করে দিয়েছি, তাই আমাদের সাইট এখন অ্যাক্সেসিবল।" এই দাবিতে কী ঝুঁকি আছে?
ARIA শুধুমাত্র একটি এলিমেন্টের অ্যাক্সেসিবল নাম/ভূমিকা/স্টেট ঘোষণা করে — এটি নিজে থেকে কোনো আচরণ (যেমন
কীবোর্ড ইন্টারঅ্যাকশন) তৈরি করে না। ভুল বা অতিরিক্ত ARIA আসলে সিমান্টিক HTML-এর স্বাভাবিক আচরণকে
ওভাররাইড করে জিনিসগুলো আরও খারাপ করে দিতে পারে (যেমন একটি আসল বাটনে ভুল role যোগ করা)। "ARIA
যোগ করা" কোনো চেকবক্স-টাস্ক নয় — প্রতিটি ব্যবহার যাচাই করতে হয় আসলেই একটি স্ক্রিন রিডার দিয়ে টেস্ট করে।
অনুশীলন
-
প্রয়োগ করুন: একটি রেসিপি-শেয়ারিং ওয়েবসাইটের একটি পেজে আছে — একটি প্রোডাক্ট ফটো, একটি
সোশ্যাল-মিডিয়া "শেয়ার" আইকন সারি, একটি রেসিপির ধাপে-ধাপে ইনস্ট্রাকশন তালিকা, এবং ব্যাকগ্রাউন্ডে একটি
আবছা টেক্সচার প্যাটার্ন ছবি। প্রতিটির জন্য alt টেক্সট সিদ্ধান্ত (অর্থবহ বর্ণনা নাকি খালি
alt="") কী হওয়া উচিত এবং কেন?প্রোডাক্ট ফটো: অর্থবহ, সংক্ষিপ্ত বর্ণনামূলক alt (যেমন "সম্পন্ন হওয়া চিকেন বিরিয়ানি, একটি বড় প্লেটে পরিবেশিত")। শেয়ার আইকন: অর্থবহ কিন্তু সংক্ষিপ্ত aria-label/alt (যেমন "ফেসবুকে শেয়ার করুন" — আইকনের ভিজ্যুয়াল বর্ণনা নয়, তার কার্যকারিতা বর্ণনা করা উচিত)। ইনস্ট্রাকশন তালিকা: এটি টেক্সট, ছবি নয় — তবে এটি একটি সিমান্টিক অর্ডারড লিস্ট (
<ol>) হিসেবে মার্কআপ করা উচিত, যাতে স্ক্রিন রিডার ধাপ-সংখ্যা ঘোষণা করে। ব্যাকগ্রাউন্ড টেক্সচার: সম্পূর্ণ ডেকোরেটিভ, তাই খালিalt=""— এটি কোনো তথ্য বহন করে না, তাই উপেক্ষা করাই সঠিক। -
প্রয়োগ করুন: একটি ফর্মে CSS
flex-direction: row-reverseব্যবহার করে "ইমেইল" ইনপুট ফিল্ডকে ভিজ্যুয়ালি "পাসওয়ার্ড" ফিল্ডের আগে দেখানো হয়েছে, কিন্তু HTML-এ পাসওয়ার্ড ফিল্ড আগে লেখা আছে। কেন এটি একটি সমস্যা, এবং কীভাবে ঠিক করবেন?একজন স্ক্রিন-রিডার ব্যবহারকারী DOM অর্ডারে পড়বেন — অর্থাৎ "পাসওয়ার্ড" ফিল্ড আগে শুনবেন, তারপর "ইমেইল" — যা দৃষ্টিসম্পন্ন ব্যবহারকারীর অভিজ্ঞতা থেকে উল্টো এবং বিভ্রান্তিকর। সঠিক সমাধান হলো HTML-এর নিজস্ব অর্ডার (ইমেইল আগে, পাসওয়ার্ড পরে) এবং ভিজ্যুয়াল অর্ডার মিলিয়ে রাখা — যদি ভিজ্যুয়াল কারণে পুনর্বিন্যাস দরকার হয়, CSS Grid/Flexbox-এর ভিজ্যুয়াল-অর্ডার-পরিবর্তনকারী প্রোপার্টি এড়িয়ে বরং HTML-এর সোর্স অর্ডারই পরিবর্তন করা উচিত, যাতে DOM ও ভিজ্যুয়াল অর্ডার সবসময় সামঞ্জস্যপূর্ণ থাকে।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ কগনিটিভ সাইকোলজি, ইন্টারঅ্যাকশন ডিজাইন, ইউজেবিলিটি হিউরিস্টিক্স, ইউজার রিসার্চ, প্রোটোটাইপিং, ইভালুয়েশন মেথড, ভিজ্যুয়াল ডিজাইন, অ্যাক্সেসিবিলিটি ও ক্যাপস্টোন — বাকি পাঠগুলো শীঘ্রই যুক্ত হবে।
- Human-Centered AI কোর্স সহোদর কোর্স AI-নির্দিষ্ট ট্রাস্ট ক্যালিব্রেশন ও এক্সপ্লেইনেবিলিটির গভীর কভারেজ — এই কোর্স সাধারণ, AI-নিরপেক্ষ ইন্টারঅ্যাকশন ডিজাইনের ভিত্তি যোগ করে।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, Machine Learning, Deep Learning, System Design, Cybersecurity, Cloud Computing & DevOps, এবং আরও অনেক কোর্স — সব এক জায়গায়।