ARIA এবং HTML

বেশিরভাগ ডেভেলপারই আধুনিক ওয়েবের স্ট্যান্ডার্ড মার্কআপ ল্যাঙ্গুয়েজ, হাইপারটেক্সট মার্কআপ ল্যাঙ্গুয়েজ (HTML)-এর সাথে পরিচিত। তবে, আপনি হয়তো অ্যাক্সেসিবল রিচ ইন্টারনেট অ্যাপ্লিকেশনস (ARIA) (আনুষ্ঠানিকভাবে WAI-ARIA নামে পরিচিত)-এর সাথে ততটা পরিচিত নন: এটি কী, কীভাবে এটি ব্যবহার করা হয়, এবং কখন এটি ব্যবহার করা উচিত আর কখন নয় ।

ডিজিটাল পণ্যগুলোকে সহজলভ্য করে তোলার ক্ষেত্রে, বিশেষ করে স্ক্রিন রিডারের মতো সহায়ক প্রযুক্তির (AT) ক্ষেত্রে, HTML এবং ARIA গুরুত্বপূর্ণ ভূমিকা পালন করে। উভয়ই কন্টেন্টকে ব্রেইল বা টেক্সট-টু-স্পিচ (TTS)-এর মতো বিকল্প ফরম্যাটে রূপান্তর করতে ব্যবহৃত হয়।

ARIA-এর একটি সংক্ষিপ্ত ইতিহাস পর্যালোচনা করুন, এটি কেন গুরুত্বপূর্ণ এবং কখন ও কীভাবে এটি সবচেয়ে ভালোভাবে ব্যবহার করা যায় তা জানুন।

ARIA-এর পরিচিতি

ARIA সর্বপ্রথম ২০০৮ সালে ওয়েব অ্যাক্সেসিবিলিটি ইনিশিয়েটিভ (WAI) গ্রুপ দ্বারা তৈরি করা হয়েছিল—যা ইন্টারনেট পরিচালনা ও নিয়ন্ত্রণকারী বৃহত্তর ওয়ার্ল্ড ওয়াইড ওয়েব কনসোর্টিয়াম (W3C)-এর একটি উপদল।

ARIA কোনো প্রকৃত প্রোগ্রামিং ভাষা নয়, বরং এটি হলো কিছু অ্যাট্রিবিউটের সমষ্টি যা HTML এলিমেন্টের অ্যাক্সেসিবিলিটি বাড়ানোর জন্য সেগুলোতে যোগ করা যায়। এই অ্যাট্রিবিউটগুলো আধুনিক ব্রাউজারে থাকা অ্যাক্সেসিবিলিটি এপিআই (API) ব্যবহার করে সহায়ক প্রযুক্তিগুলোর কাছে ভূমিকা, অবস্থা এবং বৈশিষ্ট্য সম্পর্কে তথ্য প্রেরণ করে। এই যোগাযোগটি অ্যাক্সেসিবিলিটি ট্রি-এর মাধ্যমে সম্পন্ন হয়।

WAI-ARIA , অর্থাৎ অ্যাক্সেসিবল রিচ ইন্টারনেট অ্যাপ্লিকেশনস স্যুট, প্রতিবন্ধী ব্যক্তিদের জন্য ওয়েব কন্টেন্ট এবং ওয়েব অ্যাপ্লিকেশনগুলোকে আরও সহজলভ্য করার একটি উপায় নির্ধারণ করে। এটি বিশেষত HTML, জাভাস্ক্রিপ্ট এবং সংশ্লিষ্ট প্রযুক্তি ব্যবহার করে তৈরি ডাইনামিক কন্টেন্ট এবং উন্নত ইউজার ইন্টারফেস কন্ট্রোলের ক্ষেত্রে সহায়তা করে।

WAI গ্রুপ

অ্যাক্সেসিবিলিটি ট্রি

ARIA, অ্যাক্সেসিবিলিটি ট্রি-এর অংশবিশেষ পরিবর্তন, উন্মোচন এবং পরিবর্ধন করার মাধ্যমে AT ব্যবহারকারীদের জন্য আরও ভালো অভিজ্ঞতা তৈরি করতে ভুল বা অসম্পূর্ণ কোড সংশোধন করে।

অ্যাক্সেসিবিলিটি ট্রি ব্রাউজার দ্বারা তৈরি হয় এবং এটি স্ট্যান্ডার্ড ডকুমেন্ট অবজেক্ট মডেল (DOM) ট্রি-এর উপর ভিত্তি করে গঠিত। DOM ট্রি-এর মতোই, অ্যাক্সেসিবিলিটি ট্রি-তে সমস্ত মার্কআপ এলিমেন্ট, অ্যাট্রিবিউট এবং টেক্সট নোডকে প্রতিনিধিত্বকারী অবজেক্ট থাকে। প্ল্যাটফর্ম-নির্দিষ্ট অ্যাক্সেসিবিলিটি এপিআই-গুলোও এই অ্যাক্সেসিবিলিটি ট্রি ব্যবহার করে এমন একটি উপস্থাপনা প্রদান করতে, যা সহায়ক প্রযুক্তিগুলো বুঝতে পারে।

শুধুমাত্র ARIA কোনো এলিমেন্টের কার্যকারিতা বা বাহ্যিক রূপে কোনো পরিবর্তন আনে না। এর মানে হলো, ARIA-সহ এবং ARIA-বিহীন একটি ডিজিটাল পণ্যের মধ্যে পার্থক্য কেবল AT ব্যবহারকারীরাই লক্ষ্য করবেন। এর আরও একটি অর্থ হলো, কোনো এলিমেন্টকে যথাসম্ভব অ্যাক্সেসিবল করে তোলার জন্য উপযুক্ত কোড এবং স্টাইলিং পরিবর্তন করার দায়িত্ব কেবল ডেভেলপারদেরই।

ARIA-এর তিনটি প্রধান বৈশিষ্ট্য হলো ভূমিকা, বৈশিষ্ট্য এবং অবস্থা/মান।

পেজ বা অ্যাপে কোনো এলিমেন্ট কী এবং কী কাজ করে, তা রোল দ্বারা নির্ধারিত হয়।

<div role="button">Self-destruct</div>

প্রোপার্টি কোনো বস্তুর চারিত্রিক বৈশিষ্ট্য বা তার সাথে সম্পর্ক প্রকাশ করে।

<div role="button" aria-describedby="more-info">Self-destruct</div>

<div id="more-info">This page will self-destruct in 10 seconds.</div>

স্টেট এবং ভ্যালু কোনো এলিমেন্টের সাথে সম্পর্কিত বর্তমান অবস্থা বা ডেটা ভ্যালু নির্ধারণ করে।

<div role="button" aria-describedby="more-info" aria-pressed="false">
  Self-destruct
</div>

<div id="more-info">
  This page will self-destruct in 10 seconds.
</div>

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

সম্প্রতি, ক্রোম ডেভটুলস সম্পূর্ণ অ্যাক্সেসিবিলিটি ট্রি দেখার একটি উপায় তৈরি করেছে, যা ডেভেলপারদের জন্য তাদের কোড কীভাবে অ্যাক্সেসিবিলিটিকে প্রভাবিত করে তা বোঝা সহজ করে তুলেছে।

কখন ARIA ব্যবহার করবেন

২০১৪ সালে, W3C আনুষ্ঠানিকভাবে HTML5 সুপারিশ প্রকাশ করে। এর সাথে কিছু বড় পরিবর্তন আসে, যার মধ্যে <main> , <header> , <footer> , <aside> , <nav> এর মতো যুগান্তকারী এলিমেন্ট এবং hidden ও required এর মতো অ্যাট্রিবিউটের সংযোজন অন্যতম। এই নতুন HTML5 এলিমেন্ট ও অ্যাট্রিবিউটগুলো এবং ব্রাউজারের বর্ধিত সমর্থনের ফলে, ARIA-এর কিছু অংশ এখন আর ততটা গুরুত্বপূর্ণ নয়।

যখন ব্রাউজার কোনো HTML ট্যাগকে তার অন্তর্নিহিত রোলের সাথে ARIA সমতুল্য অ্যাট্রিবিউটসহ সমর্থন করে, তখন সাধারণত এলিমেন্টটিতে ARIA যোগ করার প্রয়োজন হয় না। তবে, ARIA-তে এখনও এমন অনেক রোল, স্টেট এবং প্রপার্টি অন্তর্ভুক্ত রয়েছে যা HTML-এর কোনো সংস্করণেই পাওয়া যায় না। এই অ্যাট্রিবিউটগুলো আপাতত দরকারি হিসেবেই রয়ে গেছে।

এতে আমরা চূড়ান্ত প্রশ্নে এসে দাঁড়াই: কখন আপনার ARIA ব্যবহার করা উচিত? সৌভাগ্যবশত, WAI গ্রুপ ARIA-এর পাঁচটি নিয়ম তৈরি করেছে, যা আপনাকে এলিমেন্টগুলোকে কীভাবে অ্যাক্সেসযোগ্য করা যায় সে বিষয়ে সিদ্ধান্ত নিতে সাহায্য করবে।

নিয়ম ১: ARIA ব্যবহার করবেন না

হ্যাঁ, আপনি ঠিকই পড়েছেন। কোনো এলিমেন্টে ARIA যোগ করলেই তা স্বয়ংক্রিয়ভাবে আরও বেশি অ্যাক্সেসিবল হয়ে যায় না। WebAIM Million-এর বার্ষিক অ্যাক্সেসিবিলিটি রিপোর্টে দেখা গেছে যে, ARIA অ্যাট্রিবিউটযুক্ত হোম পেজগুলোতে, ARIA-বিহীন পেজগুলোর তুলনায় গড়ে ৭০% বেশি ত্রুটি শনাক্ত হয়েছে, যার প্রধান কারণ হলো ARIA অ্যাট্রিবিউটগুলোর যথাযথ প্রয়োগ না থাকা।

এই নিয়মের ব্যতিক্রম আছে। যখন কোনো HTML এলিমেন্টে অ্যাক্সেসিবিলিটি সাপোর্ট থাকে না, তখন ARIA ব্যবহার করা আবশ্যক। এর কারণ হতে পারে যে, ডিজাইনটি কোনো নির্দিষ্ট HTML এলিমেন্টের জন্য উপযুক্ত নয়, অথবা কাঙ্ক্ষিত বৈশিষ্ট্য বা আচরণটি HTML-এ উপলব্ধ নেই। তবে, এই ধরনের পরিস্থিতি খুব কমই দেখা যায়।

<a role="button">Submit</a>

<button>Submit</button>

সন্দেহ হলে, সিমান্টিক এইচটিএমএল এলিমেন্ট ব্যবহার করুন।

নিয়ম ২: HTML-এ (অপ্রয়োজনীয়) ARIA যোগ করবেন না।

বেশিরভাগ ক্ষেত্রে, HTML এলিমেন্টগুলো যেমন আছে তেমনই ভালোভাবে কাজ করে এবং সেগুলোতে অতিরিক্ত ARIA যোগ করার প্রয়োজন হয় না। প্রকৃতপক্ষে, ARIA ব্যবহারকারী ডেভেলপারদের প্রায়শই ইন্টারেক্টিভ এলিমেন্টগুলোকে কার্যকরী করার জন্য অতিরিক্ত কোড যোগ করতে হয়।

<h2 role="tab">Heading tab</h2>

<div role="tab"><h2>Heading tab</h2></div>

এইচটিএমএল এলিমেন্টগুলো সঠিক ভাবে ব্যবহার করলে কম পরিশ্রমে আরও ভালো পারফর্ম করা কোড তৈরি হয়।

নিয়ম ৩: সর্বদা কিবোর্ড নেভিগেশন সমর্থন করুন

সমস্ত ইন্টারেক্টিভ (অক্ষম নয়) ARIA কন্ট্রোল অবশ্যই কিবোর্ড অ্যাক্সেসযোগ্য হতে হবে। যে কোনো এলিমেন্টে ফোকাস প্রয়োজন কিন্তু সাধারণত কিবোর্ড ফোকাস পায় না, সেটিতে আপনি tabindex= "0" যোগ করতে পারেন। সম্ভাব্য কিবোর্ড ফোকাস অর্ডার সংক্রান্ত সমস্যা এড়াতে, যখনই সম্ভব ধনাত্মক পূর্ণসংখ্যা সহ ট্যাব ইনডেক্স ব্যবহার করা থেকে বিরত থাকুন।

<span role="button" tabindex="1">Submit</span>

<span role="button" tabindex="0">Submit</span>

নিয়ম ৪: ফোকাসযোগ্য উপাদান লুকাবেন না

যেসব এলিমেন্টে ফোকাস থাকা প্রয়োজন, সেগুলোতে role= "presentation" বা aria-hidden= "true" যোগ করবেন না—এর মধ্যে tabindex= "0" যুক্ত এলিমেন্টও অন্তর্ভুক্ত। যখন আপনি এলিমেন্টগুলিতে এই রোল এবং স্টেটগুলি যোগ করেন, তখন এটি AT-কে এই বার্তা পাঠায় যে এই এলিমেন্টগুলি গুরুত্বপূর্ণ নয় এবং এগুলিকে এড়িয়ে যেতে হবে। এর ফলে বিভ্রান্তি সৃষ্টি হতে পারে অথবা কোনো এলিমেন্টের সাথে ইন্টারঅ্যাক্ট করার চেষ্টাকারী ব্যবহারকারীদের কাজে ব্যাঘাত ঘটতে পারে।

<div aria-hidden="true">
  <button>Submit</button>
</div>

<div>
  <button>Submit</button>
</div>

নিয়ম ৫: ইন্টারেক্টিভ উপাদানগুলোর জন্য প্রবেশযোগ্য নাম ব্যবহার করুন

কোনো ইন্টারঅ্যাক্টিভ উপাদানের উদ্দেশ্য ব্যবহারকারীকে জানানো প্রয়োজন, যাতে তিনি জানতে পারেন কীভাবে সেটির সাথে ইন্টারঅ্যাক্ট করতে হয়। নিশ্চিত করুন যে, সহায়ক প্রযুক্তি (AT) ডিভাইস ব্যবহারকারীদের জন্য সমস্ত উপাদানের একটি সহজলভ্য নাম রয়েছে।

অ্যাক্সেসযোগ্য নাম হতে পারে কোনো এলিমেন্ট দ্বারা পরিবেষ্টিত কন্টেন্ট (যেমন <a> এর ক্ষেত্রে), বিকল্প টেক্সট, বা একটি লেবেল।

নিম্নলিখিত প্রতিটি কোড নমুনার ক্ষেত্রে, অ্যাক্সেসযোগ্য নামটি হলো "Red leather boots"।

<!-- A plain link with text between the link tags. -->
<a href="shoes.html">Red leather boots</a>

<!-- A linked image, where the image has alt text. -->
<a href="shoes.html"><img src="shoes.png" alt="Red leather boots"></a>

<!-- A checkbox input with a label. -->
<input type="checkbox" id="shoes">
<label for="shoes">Red leather boots</label>

কোনো এলিমেন্টের অ্যাক্সেসিবল নাম যাচাই করার বিভিন্ন উপায় আছে, যেমন ক্রোম ডেভটুলস ব্যবহার করে অ্যাক্সেসিবিলিটি ট্রি পরিদর্শন করা অথবা স্ক্রিন রিডার দিয়ে পরীক্ষা করা।

HTML-এ ARIA

যদিও শুধুমাত্র HTML এলিমেন্ট ব্যবহার করাই সর্বোত্তম পন্থা, কিছু নির্দিষ্ট পরিস্থিতিতে ARIA এলিমেন্ট যোগ করা যেতে পারে। উদাহরণস্বরূপ, পরিবেশগত সীমাবদ্ধতার কারণে উচ্চ স্তরের AT সমর্থনের প্রয়োজন এমন প্যাটার্নে আপনি HTML-এর সাথে ARIA যুক্ত করতে পারেন, অথবা এমন HTML এলিমেন্টের বিকল্প পদ্ধতি হিসেবে ব্যবহার করতে পারেন যা সব ব্রাউজার দ্বারা সম্পূর্ণরূপে সমর্থিত নয়।

অবশ্যই, HTML-এ ARIA প্রয়োগ করার জন্য কিছু সুপারিশ রয়েছে। সবচেয়ে গুরুত্বপূর্ণ বিষয়গুলো হলো: ডিফল্ট HTML রোলগুলোকে ওভাররাইড করবেন না, পুনরাবৃত্তি কমান এবং অনাকাঙ্ক্ষিত পার্শ্বপ্রতিক্রিয়া সম্পর্কে সচেতন থাকুন।

কয়েকটি উদাহরণ দেখুন।

<a role="heading">Read more</a>

<a aria-label="Read more about some awesome article title">Read More</a>

<ul role="list">...</ul>

<ul>...</ul>

<details>
  <summary role="button">more information</summary>
  ...
</details>

<details>
  <summary>more information</summary>
  ...
</details>

ARIA-এর জটিলতা

ARIA একটি জটিল বিষয়, এবং এটি ব্যবহার করার সময় আপনার সর্বদা সতর্কতা অবলম্বন করা উচিত। যদিও এই পাঠের কোডের উদাহরণগুলো বেশ সহজবোধ্য, অ্যাক্সেসিবল কাস্টম প্যাটার্ন তৈরি করা দ্রুতই জটিল হয়ে উঠতে পারে।

অনেক বিষয়ে মনোযোগ দিতে হয়, যার মধ্যে রয়েছে: কিবোর্ড ইন্টারঅ্যাকশন, টাচ ইন্টারফেস, এটি/ব্রাউজার সাপোর্ট, অনুবাদের প্রয়োজনীয়তা, পরিবেশগত সীমাবদ্ধতা, লিগ্যাসি কোড এবং ব্যবহারকারীর পছন্দ। কোডিং-এর সামান্য জ্ঞানও ভুলভাবে ব্যবহার করা হলে ক্ষতিকর—কিংবা নিছক বিরক্তিকর—হতে পারে।

ঐসব সতর্কবার্তা বাদ দিলেও, ডিজিটাল অভিগম্যতা এমন কোনো বিষয় নয় যেখানে হয় সবকিছু পাওয়া যাবে, নয়তো কিছুই পাওয়া যাবে না—এটি একটি বিস্তৃত পরিসর, যেখানে এই ধরনের কিছু ধূসর এলাকাও থাকতে পারে। পরিস্থিতিভেদে একাধিক কোডিং সমাধানকেই "সঠিক" বলে মনে করা যেতে পারে। গুরুত্বপূর্ণ বিষয় হলো, আমাদের ডিজিটাল বিশ্বকে সকলের জন্য আরও উন্মুক্ত করে তোলার লক্ষ্যে আপনার শেখা, পরীক্ষা করা এবং চেষ্টা চালিয়ে যাওয়া।