Screen Reader ও Caption Learning-কে আরও Accessible করে কীভাবে

শিক্ষামূলক ওয়েবসাইটে ছবির জন্য Alt Text দেওয়া বা ভিডিওতে CC বোতাম রাখাই যথেষ্ট নয়। একজন শিক্ষার্থী screen reader দিয়ে পেজের heading বুঝতে না পারলে, keyboard দিয়ে quiz শেষ করতে না পারলে বা caption-এ গুরুত্বপূর্ণ শব্দ ভুল থাকলে কনটেন্ট ব্যবহার করা কঠিন হয়ে পড়ে।

তাই Accessible learning technology বা সবার জন্য ব্যবহারযোগ্য শিক্ষাপ্রযুক্তি তৈরির কাজটি content, design ও development—তিন জায়গা থেকেই শুরু করতে হয়। Screen reader-এর জন্য semantic HTML, সঠিক label ও keyboard access যেমন দরকার, তেমনি ভিডিওর জন্য নির্ভুল ও সময়ের সঙ্গে সামঞ্জস্যপূর্ণ caption প্রয়োজন।

WCAG 2.2-এর Success Criterion 1.2.2 অনুযায়ী prerecorded synchronized media-তে থাকা audio content-এর জন্য caption Level A requirement। তবে media যদি text-এর বিকল্প হিসেবে দেওয়া হয় এবং সেটি স্পষ্টভাবে চিহ্নিত থাকে, সেখানে ব্যতিক্রম রয়েছে। ভালো caption-এ কথোপকথনের পাশাপাশি প্রয়োজনীয় speaker identification এবং অর্থ বোঝার জন্য দরকারি non-speech audio information-ও থাকা উচিত।

স্ক্রিন রিডার পেজের কোন তথ্যের ওপর নির্ভর করে

Screen reader দৃশ্যমান layout দেখে মানুষের মতো পেজের অর্থ অনুমান করে না। Browser ও operating system-এর মাধ্যমে পাওয়া text, element-এর role, accessible name, state, heading structure এবং অন্যান্য programmatically available information ব্যবহার করে কনটেন্ট উপস্থাপন করে।

এ কারণেই একটি পেজ দেখতে পরিষ্কার হলেও screen reader ব্যবহারকারীর জন্য বিভ্রান্তিকর হতে পারে। যেমন, বড় ও bold text দেখতে heading হলেও HTML-এ সেটি সাধারণ paragraph হলে সহায়ক প্রযুক্তি তাকে heading হিসেবে শনাক্ত করবে না।

কিছু সাধারণ পার্থক্য দ্রুত বোঝা যায়:

Semantic HTML আগে, ARIA পরে

কোনো native HTML element দিয়েই কাজটি করা গেলে custom <div> বা <span> দিয়ে একই control বানিয়ে পরে ARIA যোগ করা সাধারণত ভালো শুরু নয়।

W3C-এর “First Rule of ARIA Use” অনুযায়ী প্রয়োজনীয় semantics ও behaviour native HTML দিয়েই পাওয়া গেলে native element-কে অগ্রাধিকার দেওয়া উচিত। কারণ ARIA একটি element-এর অর্থ assistive technology-কে জানাতে পারে, কিন্তু keyboard behaviour, focus management বা interaction নিজে থেকে তৈরি করে দেয় না।

সাধারণ button-এর ক্ষেত্রে:

<button type=”button”>পরবর্তী লেসন</button>

এটি এমন custom element-এর তুলনায় সহজ ও নির্ভরযোগ্য, যেখানে developer-কে role, keyboard interaction, focus এবং state আলাদাভাবে সামলাতে হয়।

Custom widget বা dynamic state-এর ক্ষেত্রে ARIA দরকার হতে পারে। তবে “ARIA যোগ করা হয়েছে” মানেই control accessible—এমন ধরে নেওয়া ঠিক নয়।

আরও পড়ুনঃ AI Tool-এ শিক্ষার্থীর Data আপলোডের আগে Privacy Risk

Heading-কে শুধু visual style বানাবেন না

Lesson title, chapter ও subsection-এর কাঠামো HTML heading element দিয়ে প্রকাশ করা দরকার। এতে screen reader ব্যবহারকারী heading list দেখতে এবং heading ধরে দ্রুত পেজে চলাচল করতে পারেন।

WCAG 2.2-এর SC 2.4.6 Level AA অনুযায়ী heading ও label সংশ্লিষ্ট topic বা purpose বর্ণনা করবে।

পেজের logical structure অনুযায়ী heading সাজানোও ভালো অভ্যাস। অকারণে heading level লাফালে document structure বোঝা কঠিন হতে পারে। তবে শুধু একটি level skip হওয়াকেই স্বয়ংক্রিয় WCAG failure বলা ঠিক নয়। মূল প্রশ্ন হলো—কনটেন্টের সম্পর্ক ও কাঠামো assistive technology-এর কাছে পরিষ্কারভাবে প্রকাশ হচ্ছে কি না।

Alt Text-এ ছবির উদ্দেশ্য লিখুন

সব ছবির জন্য একই ধরনের Alt Text প্রয়োজন হয় না। কোনো ছবি তথ্য দিচ্ছে, কোনোটি link বা button-এর কাজ করছে, আবার কোনোটি নিছক সাজসজ্জা।

WCAG 1.1.1 অনুযায়ী non-text content-এর text alternative তার উদ্দেশ্য বা প্রয়োজনীয় তথ্য প্রকাশ করবে।

ধরা যাক একটি image link থেকে worksheet download করা যাবে:

<a href=”worksheet.pdf”>

  <img src=”download.svg” alt=”Worksheet ডাউনলোড করুন”>

</a>

এখানে icon-এর রং বা আকৃতি বর্ণনা করার চেয়ে link-এর কাজ জানানো বেশি দরকার।

Decorative image হলে:

<img src=”divider.svg” alt=””>

Chart, graph বা জটিল diagram-এর সব তথ্য এক লাইনের Alt Text-এ ঢোকানোর চেষ্টা করাও ঠিক নয়। প্রয়োজন হলে সংক্ষিপ্ত alternative-এর পাশাপাশি মূল লেখায় বা আলাদা long description-এ বিস্তারিত দেওয়া যেতে পারে।

Placeholder দিয়ে form label-এর কাজ চালাবেন না

Quiz, registration, search বা assignment submission form-এ প্রতিটি control-এর উদ্দেশ্য পরিষ্কার হওয়া দরকার।

WAI-এর forms guidance অনুযায়ী label-কে সংশ্লিষ্ট form control-এর সঙ্গে programmatically যুক্ত করা উচিত। Placeholder অতিরিক্ত নির্দেশনা বা format-এর উদাহরণ দিতে পারে, কিন্তু label-এর বিকল্প নয়। ব্যবহারকারী টাইপ শুরু করলে placeholder সাধারণত আর দেখা যায় না।

উদাহরণ:

<label for=”student-email”>ইমেইল</label>

<input id=”student-email” type=”email”>

Icon-only button-এ দৃশ্যমান লেখা দেওয়া সম্ভব না হলে accessible name দরকার হতে পারে:

<button aria-label=”ক্যাপশন চালু করুন”>

  …

</button>

তবে আগে থেকেই অর্থপূর্ণ visible label বা native labeling থাকলে অকারণে আরেকটি ARIA name যোগ করার প্রয়োজন নেই।

বাংলা পেজের ভাষা HTML-এ জানান

WCAG 2.2-এর Language of Page, SC 3.1.1 Level A অনুযায়ী ওয়েবপেজের default human language programmatically নির্ধারণযোগ্য হতে হবে।

বাংলা পেজে একটি সাধারণ implementation:

<html lang=”bn”>

পেজের কোনো passage বা phrase অন্য ভাষায় হলে WCAG 3.1.2 Level AA প্রাসঙ্গিক হতে পারে। তবে proper name, technical term, ভাষা নির্ধারণ করা যায় না এমন শব্দ এবং surrounding ভাষায় স্বাভাবিকভাবে গৃহীত কিছু শব্দের ক্ষেত্রে ব্যতিক্রম রয়েছে।

তাই বাংলা লেখায় HTML, ARIA বা অন্য প্রতিষ্ঠিত technical term দেখলেই প্রতিটি শব্দের জন্য আলাদা lang attribute বসাতে হবে—এমন নিয়ম নেই। অন্য ভাষার কোনো দীর্ঘ অংশ বা phrase-এর pronunciation ও interpretation গুরুত্বপূর্ণ হলে ভাষা সঠিকভাবে চিহ্নিত করা বেশি প্রাসঙ্গিক।

Mouse সরিয়ে keyboard দিয়েও পরীক্ষা করুন

Accessibility review-এর একটি সহজ প্রাথমিক ধাপ হলো mouse ব্যবহার না করে পেজ চালানো।

পরীক্ষার সময় দেখুন:

• প্রয়োজনীয় link, button ও form control keyboard দিয়ে পাওয়া যাচ্ছে কি না;
• focus order অর্থপূর্ণ কি না;
• বর্তমানে focus কোথায় আছে তা দৃশ্যমান কি না;
• menu, dialog বা media player-এ focus আটকে যাচ্ছে কি না;
• video controls keyboard দিয়ে ব্যবহার করা যাচ্ছে কি না;
• কোনো component-এ ঢোকার পর standard keyboard interaction দিয়ে সেখান থেকে বের হওয়া যাচ্ছে কি না।

WCAG-এর Focus Order criterion keyboard navigation-এর sequence অর্থপূর্ণ রাখার কথা বলে। No Keyboard Trap criterion অনুযায়ী keyboard focus কোনো component-এ আটকে থাকা উচিত নয়।

W3C-এর Easy Checks এ ধরনের keyboard test-কে প্রাথমিক accessibility review-এর অংশ হিসেবে রাখে। তবে এটিকে পূর্ণ WCAG evaluation ধরে নেওয়া যাবে না।

Auto-caption-কে চূড়ান্ত caption হিসেবে প্রকাশ করবেন না

Automatic speech recognition caption তৈরির শুরুটা দ্রুত করতে পারে। কিন্তু generated text review না করে প্রকাশ করলে ভুল নাম, সংখ্যা, technical term বা sentence break শিক্ষার্থীর বোঝাপড়ায় সমস্যা তৈরি করতে পারে।

W3C WAI automatic caption-কে accurate caption তৈরির starting point হিসেবে ব্যবহার করার কথা বলে। YouTube-ও creators-কে automatic captions review করে ভুল transcription সংশোধনের সুযোগ দেয়।

বাংলা শিক্ষামূলক ভিডিওতে বিশেষভাবে দেখুন:

• ব্যক্তি, প্রতিষ্ঠান ও technical term-এর বানান ঠিক আছে কি না;
• সংখ্যা, formula বা abbreviation বদলে গেছে কি না;
• বক্তা পরিবর্তন বোঝা যাচ্ছে কি না;
• অর্থপূর্ণ sound information বাদ পড়েছে কি না;
• caption audio-এর আগে বা পরে চলে যাচ্ছে কি না;
• line break এমন জায়গায় হয়েছে কি না, যেখানে অর্থ বোঝা কঠিন।

Caption-কে “পরিষ্কার” করার নামে বক্তব্য ইচ্ছামতো সংক্ষিপ্ত করাও ঠিক নয়। WAI-এর transcription guidance অনুযায়ী speech এবং অর্থ বোঝার জন্য প্রাসঙ্গিক non-speech sound যথাযথভাবে ধরে রাখা উচিত। প্রয়োজন হলে speaker identification-ও দিতে হয়।

নিজস্ব ওয়েব ভিডিওতে caption track যোগ করার উপায়

W3C WAI ওয়েবে caption-এর প্রচলিত format হিসেবে WebVTT উল্লেখ করে। HTML-এর <track> element দিয়ে timed text track যোগ করা যায়।

একটি সাধারণ উদাহরণ:

<video controls>

  <source src=”lesson.mp4″ type=”video/mp4″>

  <track

    kind=”captions”

    src=”lesson-bn.vtt”

    srclang=”bn”

    label=”বাংলা”>

</video>

এখানে srclang caption track-এর ভাষা এবং label ব্যবহারকারীর সামনে দেখানো নাম নির্ধারণ করতে পারে।

File যুক্ত করেই কাজ শেষ নয়। Caption track load হচ্ছে কি না, keyboard দিয়ে control পাওয়া যাচ্ছে কি না এবং mobile ও desktop environment-এ player ব্যবহার করা যাচ্ছে কি না—প্রকাশের আগে সেগুলো পরীক্ষা করা দরকার।

YouTube বর্তমানে .srt, .sbv/.sub-সহ একাধিক subtitle ও caption file format গ্রহণ করে। Creatorরা YouTube Studio থেকে caption edit করতে পারেন।

১৮ আগস্ট ২০২৬ পর্যন্ত Coursera-এর official accessibility documentation-এ course lecture video-তে closed captioning-এর কথা উল্লেখ রয়েছে। আলাদা learner documentation-এ video settings থেকে subtitles চালু বা বন্ধ করার ব্যবস্থাও দেখানো হয়েছে। তবে translated subtitle কোন ভাষায় পাওয়া যাবে, তা course ও উপলভ্য translation-এর ওপর নির্ভর করতে পারে।

এখানে একটি গুরুত্বপূর্ণ পার্থক্য আছে: কোনো player-এ CC option থাকা এবং প্রয়োজনীয় ভাষায় নির্ভুল caption পাওয়া একই বিষয় নয়।

Caption, transcript ও audio description-এর কাজ আলাদা

এই তিনটি feature-কে একই সমাধান হিসেবে দেখা ঠিক নয়।

Caption মূলত audio information-কে synchronized text হিসেবে দেয়। Transcript ভিডিও না চালিয়ে বক্তব্য পড়তে বা text search করতে কাজে লাগে। কিন্তু prerecorded synchronized video-র ক্ষেত্রে সাধারণ transcript দিয়ে WCAG 1.2.2-এর caption requirement প্রতিস্থাপন করা যায় না।

অন্যদিকে কোনো instructional video-তে graph, diagram, cursor movement বা on-screen text-এর গুরুত্বপূর্ণ তথ্য narration-এ না থাকলে blind বা low-vision learner সেই অংশ হারাতে পারেন। সেখানে visual information-এর description প্রয়োজন হতে পারে।

যেমন presenter যদি শুধু বলেন—

“এখানে ক্লিক করুন।”

তাহলে audio-only context-এ নির্দেশনাটি অস্পষ্ট।

এর বদলে—

“বাম পাশের Settings menu থেকে Subtitles নির্বাচন করুন।”

বললে visual location-এর প্রয়োজনীয় তথ্য narration-এর মধ্যেই পাওয়া যায়।

WCAG-এর দিক থেকেও audio description-এর requirement আলাদা। Prerecorded synchronized media-তে SC 1.2.3 Level A-তে audio description অথবা media alternative দেওয়া যেতে পারে। Level AA conformance লক্ষ্য করলে SC 1.2.5 অনুযায়ী prerecorded video content-এর জন্য audio description প্রয়োজন।

Caption পড়া যাচ্ছে কি না, সেটিও accessibility-এর অংশ

সঠিক transcription থাকলেও text যদি background-এর সঙ্গে মিশে যায়, তাহলে caption ব্যবহার করা কঠিন হবে।

WCAG 2.2-এর SC 1.4.3 Level AA অনুযায়ী সাধারণ text ও background-এর contrast ratio অন্তত 4.5:1 হওয়া দরকার। Large-scale text-এর ক্ষেত্রে ন্যূনতম ratio 3:1। Criterion-টিতে কিছু নির্দিষ্ট exception রয়েছে।

ভিডিওর ওপর hard-coded text বসালে changing background-এর কারণে contrast কমে যেতে পারে। Closed-caption player ব্যবহারকারীকে appearance পরিবর্তনের সুযোগ দিলে কিছু ক্ষেত্রে এই সমস্যা কমানো যায়।

YouTube-এর desktop player-এ বর্তমানে caption-এর font, size, color, opacity, background এবং আরও কিছু presentation setting পরিবর্তনের সুবিধা রয়েছে।

Automated accessibility score-কে চূড়ান্ত সিদ্ধান্ত ভাববেন না

Automated scanner missing label, markup error বা contrast-এর কিছু সমস্যা দ্রুত শনাক্ত করতে পারে। কিন্তু কোনো tool একাই একটি learning platform accessible কি না নিশ্চিত করতে পারে না।

W3C-ও উল্লেখ করে যে automated evaluation tool accessibility-এর সব দিক পরীক্ষা করতে পারে না এবং human judgement প্রয়োজন। কিছু tool false বা misleading result-ও দিতে পারে।

তাই গুরুত্বপূর্ণ learning flow অন্তত একটি বাস্তব screen reader দিয়েও পরীক্ষা করা উচিত।

১৮ আগস্ট ২০২৬ পর্যন্ত official documentation অনুযায়ী:

• NVDA Windows 10 ও পরবর্তী সংস্করণের PC-তে ব্যবহার করা যায়।
• VoiceOver macOS-এর built-in screen reader এবং iPhone-এও পাওয়া যায়।
• TalkBack Android device-এর screen reader হিসেবে ব্যবহৃত হয়।

Testing-এর সময় শুধু homepage নয়, একটি সম্পূর্ণ কাজ শেষ করে দেখুন। যেমন course খুলে lesson পড়া, quiz দেওয়া, validation error বোঝা, video চালানো, caption control ব্যবহার করা এবং পরবর্তী lesson-এ যাওয়া সম্ভব হচ্ছে কি না।

এই end-to-end পরীক্ষা isolated accessibility score-এর তুলনায় বাস্তব সমস্যাগুলো বেশি স্পষ্ট করে।

প্রথমে কোন কাজগুলো করা সবচেয়ে বাস্তবসম্মত

পুরো platform একবারে পরিবর্তনের চেষ্টা না করে সবচেয়ে বেশি ব্যবহৃত course, lesson, quiz ও video দিয়ে accessibility audit শুরু করা যায়।

Content team প্রথমে image alternative, heading, caption accuracy, transcript এবং visual information-এর বিকল্প বর্ণনা দেখবে। Development team একই সঙ্গে semantic HTML, form labels, accessible names, keyboard navigation, focus behaviour, page language ও media controls পরীক্ষা করতে পারে।

এরপর automated tool দিয়ে দ্রুত detectable সমস্যা খুঁজে manual review ও screen-reader testing করা যুক্তিযুক্ত।

Accessible learning technology তৈরিতে সবচেয়ে কার্যকর সম্পাদকীয় সিদ্ধান্ত হলো accessibility-কে প্রকাশের শেষ ধাপের checklist না বানানো। Script তৈরির সময় visual information কীভাবে বোঝানো হবে, image যোগ করার সময় তার text alternative কী হবে এবং interface তৈরির সময় native HTML ব্যবহার করা যাবে কি না—এসব শুরুতেই ঠিক করলে পরে অনেক সংশোধনের প্রয়োজন কমে।

শেষ কথা

ডিজিটাল অ্যাক্সেসিবিলিটি ভালো করার সবচেয়ে কার্যকর উপায় হলো এটিকে আলাদা কোনো শেষ মুহূর্তের কাজ হিসেবে না দেখা। কনটেন্ট লেখার সময় Alt Text, ভিডিও তৈরির সময় caption ও visual description, আর interface বানানোর সময় semantic HTML ও keyboard access বিবেচনায় রাখলে পরে বড় ধরনের সংশোধনের প্রয়োজন কমে।

Accessible learning technology তৈরির ক্ষেত্রে প্রথম অগ্রাধিকার হওয়া উচিত বাস্তব ব্যবহারযোগ্যতা। একটি lesson screen reader দিয়ে বোঝা যাচ্ছে কি না, keyboard দিয়ে সম্পন্ন করা যাচ্ছে কি না এবং caption সত্যিই নির্ভুল কি না—এই তিনটি পরীক্ষা থেকেই অনেক গুরুত্বপূর্ণ সমস্যা ধরা পড়ে। Automated tool সহায়ক, কিন্তু মানুষের হাতে পরীক্ষা এবং assistive technology দিয়ে বাস্তব workflow যাচাই করার বিকল্প নয়।

শুরু করতে চাইলে সবচেয়ে বেশি ব্যবহৃত একটি course বা lesson বেছে নিন। সেটির heading, image alternative, form control, video caption এবং keyboard navigation পরীক্ষা করুন। ছোট একটি অংশ ঠিকভাবে accessible করার অভিজ্ঞতা পরে পুরো প্ল্যাটফর্মের জন্য আরও বাস্তবসম্মত মানদণ্ড তৈরি করতে সাহায্য করবে।

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

১. Screen reader accessibility নিশ্চিত করতে প্রথমে কী পরীক্ষা করা উচিত?

প্রথমে semantic heading, form label, button-এর accessible name, image-এর Alt Text এবং keyboard navigation পরীক্ষা করুন। এরপর একটি বাস্তব screen reader দিয়ে পুরো lesson বা গুরুত্বপূর্ণ user flow ব্যবহার করে দেখুন।

২. Auto-caption কি শিক্ষামূলক ভিডিওর জন্য যথেষ্ট?

না। Auto-caption একটি খসড়া হিসেবে কাজে লাগতে পারে, কিন্তু প্রকাশের আগে নাম, সংখ্যা, technical term, speaker change, timing এবং প্রয়োজনীয় non-speech audio information যাচাই করা দরকার।

৩. Transcript থাকলে কি caption আলাদা করে দিতে হবে?

Prerecorded synchronized video-এর ক্ষেত্রে transcript caption-এর বিকল্প নয়। Caption audio-এর সঙ্গে সময় মিলিয়ে দেখানো হয়, আর transcript সাধারণত পুরো বক্তব্যের আলাদা text version হিসেবে ব্যবহৃত হয়। তাই accessibility requirement পূরণ করতে দুইটির ভূমিকা আলাদা করে দেখা উচিত।