সত্যিই সহায়ক ARIA লেবেল নিয়ে ডেভেলপার গাইড

ARIA লেবেল নামের জন্য, অজুহাতের জন্য নয়

ARIA দরকারি, কিন্তু প্রায়ই অস্পষ্ট HTML-এর প্যাচ হিসেবে ব্যবহৃত হয়। সেখানেই টিমগুলো সমস্যায় পড়ে।

সবচেয়ে সাধারণ উদাহরণ হলো aria-label। এটি নিরীহ মনে হয়: একটি স্ট্রিং যোগ করুন, linter সন্তুষ্ট করুন, এগিয়ে যান। কিন্তু অ্যাক্সেসিবল নাম কোনো সাজসজ্জা নয়। এটি সেই নাম, যা অনেক সহায়ক প্রযুক্তি ব্যবহারকারীদের সামনে তুলে ধরে যখন তারা buttons, links, form fields, headings, landmarks, এবং controls ধরে নেভিগেট করেন।

যদি সেই নাম অস্পষ্ট, পুনরাবৃত্ত, পুরোনো, বা দৃশ্যমান লেবেল থেকে আলাদা হয়, ইন্টারফেস ব্যবহার করা আরও কঠিন হয়ে যায়। কখনও আরও খারাপ: aria-label DOM-এ আগে থেকেই থাকা আরও ভালো টেক্সটকে override করতে পারে।

লক্ষ্য বেশি ARIA যোগ করা নয়। লক্ষ্য হলো প্রতিটি ইন্টারফেস এলিমেন্টের name, role, state, এবং purpose স্পষ্ট করা।

সহজ ভাষায় অ্যাক্সেসিবল নাম

বেশিরভাগ ইন্টারঅ্যাক্টিভ এলিমেন্টের একটি অ্যাক্সেসিবল নাম থাকে। স্ক্রিন রিডার সেই নাম ব্যবহার করে জানায় এলিমেন্টটি কী।

উদাহরণস্বরূপ:

<button>Save changes</button>

একটি স্ক্রিন রিডার এমন কিছু ঘোষণা করতে পারে: “Save changes, button.” role আসে native button এলিমেন্ট থেকে। নাম আসে এর ভেতরের টেক্সট থেকে।

এটাই আদর্শ অবস্থা: দৃশ্যমান টেক্সট এবং অ্যাক্সেসিবল নাম মিলে যায়।

ARIA labeling attributes তখন দরকারি হয়, যখন দৃশ্যমান ইন্টারফেস সম্পূর্ণ নাম দেয় না, অথবা যখন নামটি অন্য কোনো এলিমেন্ট থেকে আসতে হয়। প্রধান attributes হলো:

• aria-label: সরাসরি এলিমেন্টে একটি স্ট্রিং দেয়।
• aria-labelledby: এক বা একাধিক এলিমেন্টের দিকে নির্দেশ করে, যাদের টেক্সট নাম হয়ে যায়।
• aria-describedby: মূল নাম নয়, সহায়ক description text-এর দিকে নির্দেশ করে।

এই তিনটি সম্পর্কিত, কিন্তু একে অন্যের বিকল্প নয়।

প্রথম নিয়ম: native HTML এবং দৃশ্যমান লেবেলকে অগ্রাধিকার দিন

যদি কন্ট্রোলে দৃশ্যমান টেক্সট রাখা যায়, আগে সেটাই করুন।

এটি ভালো:

<button>Delete invoice</button>

এর চেয়ে:

<button aria-label="Delete invoice">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

দ্বিতীয় প্যাটার্নটি icon-only button-এর জন্য বৈধ। কিন্তু ডিজাইন যদি দৃশ্যমান টেক্সট মেনে নিতে পারে, দৃশ্যমান টেক্সট সবার জন্য সহায়ক: screen reader users, speech recognition users, cognitive load-এ থাকা মানুষ, দ্রুত স্ক্যান করা মানুষ, এবং translation tools ব্যবহারকারী মানুষ।

অ্যাক্সেসিবিলিটি কাজে এটি একটি পুনরাবৃত্ত থিম। Native HTML এবং দৃশ্যমান affordances hidden metadata-এর চেয়ে বেশি সমস্যা সমাধান করে। একই নীতি button semantics-এর ক্ষেত্রেও বিস্তৃতভাবে প্রযোজ্য; আপনার টিম যদি UI controls অডিট করে, আমাদের accessible web buttons-এর checklist এই গাইডের ভালো সঙ্গী।

কখন aria-label সঠিক টুল

যখন কোনো এলিমেন্টের অ্যাক্সেসিবল নাম দরকার এবং রেফার করার মতো উপযুক্ত দৃশ্যমান টেক্সট নেই, তখন aria-label ব্যবহার করুন।

ক্লাসিক উদাহরণ হলো icon-only button:

<button aria-label="Search">
  <svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">
    <!-- icon -->
  </svg>
</button>

এটি যুক্তিসংগত। দৃশ্যমান icon search বোঝায়, কিন্তু SVG path নিজে নির্ভরযোগ্য নাম দেয় না। aria-label একটি নাম সরবরাহ করে।

আরও ভালো ব্যবহারক্ষেত্রের মধ্যে আছে:

• শুধু “X” দিয়ে দেখানো close button।
• একটি navigation landmark যার আরও নির্দিষ্ট নাম দরকার, যেমন aria-label="Product"।
• একটি repeated control যেখানে দৃশ্যমান context button text-এর অংশ নয়।

উদাহরণস্বরূপ:

<nav aria-label="Primary">
  ...
</nav>

<nav aria-label="Footer">
  ...
</nav>

দুটিই navigation landmarks, কিন্তু তাদের labels ব্যবহারকারীদের landmarks ধরে চলার সময় আলাদা করতে সাহায্য করে।

কখন aria-label ভুল টুল

শুধু কোনো test বলেছে এলিমেন্টের label দরকার—এই কারণে aria-label যোগ করবেন না। আগে markup ঠিক করুন।

খারাপ:

<div role="button" tabindex="0" aria-label="Submit">Submit</div>

ভালো:

<button>Submit</button>

প্রথম উদাহরণটি অপ্রয়োজনীয় কাজ তৈরি করে। এখন আপনাকে keyboard behavior, disabled states, form behavior, এবং native buttons যেসব প্রত্যাশা আগেই পূরণ করে সেগুলো আবার তৈরি করতে হবে।

দৃশ্যমান টেক্সটের অর্থ বদলে যায় এমনভাবে rename করতে aria-label ব্যবহার করাও এড়িয়ে চলুন।

<button aria-label="Delete invoice">Remove</button>

এটি ছোট মনে হতে পারে, কিন্তু speech input-এর ওপর নির্ভরশীল ব্যবহারকারীদের বিভ্রান্ত করতে পারে। যদি দৃশ্যমান button-এ “Remove” লেখা থাকে, কিন্তু তার অ্যাক্সেসিবল নাম হয় “Delete invoice,” তাহলে ব্যবহারকারী “click Remove” বললে প্রত্যাশিত ফল নাও পেতে পারেন। WCAG-এর “label in name” requirement ঠিক এই কারণেই আছে: দৃশ্যমান টেক্সট সাধারণত অ্যাক্সেসিবল নামের মধ্যে থাকা উচিত।

একটি ভালো সংস্করণ:

<button aria-label="Remove invoice">Remove</button>

প্রায়ই আরও ভালো:

<button>Remove invoice</button>

দৃশ্যমান টেক্সট আগে থেকেই থাকলে aria-labelledby ব্যবহার করুন

যদি label text পেজে আগে থেকেই থাকে, aria-label-এর চেয়ে aria-labelledby সাধারণত ভালো।

উদাহরণ:

<h2 id="billing-title">Billing address</h2>
<section aria-labelledby="billing-title">
  ...
</section>

section-এর অ্যাক্সেসিবল নাম এখন দৃশ্যমান heading থেকে আসে। এতে string duplicate করতে হয় না, ফলে translation ভুল এবং stale labels কমে।

Form groups-এর জন্য এটি বিশেষভাবে দরকারি:

<fieldset aria-labelledby="shipping-speed-title">
  <legend id="shipping-speed-title">Shipping speed</legend>

  <label>
    <input type="radio" name="shipping" value="standard">
    Standard
  </label>

  <label>
    <input type="radio" name="shipping" value="express">
    Express
  </label>
</fieldset>

অনেক ক্ষেত্রে native legend ARIA ছাড়াই যথেষ্ট। মূল কথা হলো দৃশ্যমান labels-ই নেতৃত্ব দেবে। ARIA-এর কাজ হলো বিদ্যমান অর্থকে সংযুক্ত করা, তার আলাদা একটি private version তৈরি করা নয়।

নাম নয়, help text-এর জন্য aria-describedby ব্যবহার করুন

Description কোনো label নয়।

এই field-টি বিবেচনা করুন:

<label for="password">Password</label>
<input id="password" type="password" aria-describedby="password-help">
<p id="password-help">Use at least 12 characters.</p>

অ্যাক্সেসিবল নাম হলো “Password.” description হলো “Use at least 12 characters.” একটি screen reader দুটোই ঘোষণা করতে পারে, কিন্তু তাদের উদ্দেশ্য আলাদা।

এটি করবেন না:

<input type="password" aria-label="Use at least 12 characters">

এতে field-এর নাম instruction অনুযায়ী হয়, concept অনুযায়ী নয়। ফর্ম নেভিগেট করা ব্যবহারকারী আগে জানতে চান field-টি কী, তারপর কোন constraints প্রযোজ্য।

Error states-এও এই পার্থক্য গুরুত্বপূর্ণ:

<label for="email">Email</label>
<input
  id="email"
  type="email"
  aria-invalid="true"
  aria-describedby="email-error"
>
<p id="email-error">Enter an email address in the format [email protected].</p>

label স্থিতিশীল থাকে। error message সহায়ক context হয়ে যায়।

পুনরাবৃত্ত controls-এর unique names দরকার

Lists এবং cards-এ ARIA labels প্রায়ই দরকারি হয়ে ওঠে।

খারাপ:

<button>Delete</button>
<button>Delete</button>
<button>Delete</button>

Buttons ধরে নেভিগেট করা একজন screen reader user context ছাড়া তিনবার “Delete, button” শুনতে পারেন।

ভালো:

<button aria-label="Delete report: Q4 revenue">Delete</button>
<button aria-label="Delete report: Hiring plan">Delete</button>
<button aria-label="Delete report: Vendor list">Delete</button>

এটি aria-label-এর একটি বৈধ ব্যবহার: দৃশ্যমান টেক্সট সংক্ষিপ্ত থাকে, আর অ্যাক্সেসিবল নাম object-টি অন্তর্ভুক্ত করে।

তবে এই প্যাটার্ন সাবধানে ব্যবহার করুন। যদি object name কাছাকাছি দৃশ্যমান থাকে, aria-labelledby বেশি maintainable হতে পারে:

<article>
  <h3 id="report-q4">Q4 revenue</h3>
  <button aria-labelledby="delete-q4 report-q4" id="delete-q4">Delete</button>
</article>

অ্যাক্সেসিবল নাম হয় “Delete Q4 revenue.” এতে attribute-এ report title duplicate করতে হয় না।

সবকিছুতে label দেবেন না

প্রতিটি এলিমেন্টের ARIA label দরকার হয় না।

Static text সাধারণত দরকার হয় না। Decorative icons দরকার হয় না। Containers দরকার হয় না, যদি না তাদের meaningful landmark বা widget role থাকে। Over-labeling একটি পেজকে noisy এবং navigate করা কঠিন করতে পারে।

Images-এর জন্য image-specific model ব্যবহার করুন: meaningful images-এর useful alt দরকার; decorative images-এর empty alt="" দরকার। ভালো image text-এর বিকল্প হিসেবে ARIA labels ব্যবহার করবেন না। আপনার টিম যদি এই ধারণাগুলো মিশিয়ে ফেলে, pragmatic image alt text আবার দেখুন এবং image alternatives-কে control names থেকে আলাদা করুন।

একটি সাধারণ ভুল হলো প্রতিটি SVG-কে aria-label দেওয়া। যদি SVG একটি button-এর ভেতরে থাকে এবং button-এর ইতিমধ্যেই নাম থাকে, icon সাধারণত assistive tech থেকে hidden থাকা উচিত:

<button aria-label="Open menu">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

নইলে browser এবং assistive technology combination অনুযায়ী ব্যবহারকারী redundant বা অদ্ভুত announcements শুনতে পারেন।

শুধু code নয়, computed name পরীক্ষা করুন

Accessibility bugs প্রায়ই code review পেরিয়ে যায়, কারণ markup দেখতে plausible লাগে।

Modern browser developer tools computed accessibility tree দেখাতে পারে। Chrome, Edge, Firefox, এবং Safari-তে element inspect করুন এবং role, name, description-এর মতো accessibility information দেখুন। আপনি তিনটি বিষয় পরীক্ষা করছেন:

1. role কি আপনার প্রত্যাশামতো?
2. accessible name কি স্পষ্ট এবং নির্দিষ্ট?
3. description কি name-কে replace না করে সহায়ক?

এরপর real screen reader দিয়ে কয়েকটি flow test করুন। basic বিষয় ধরতে আপনাকে full-time assistive technology expert হতে হবে না। macOS-এ VoiceOver built in। Windows-এ NVDA ব্যাপকভাবে ব্যবহৃত এবং free। Mobile-এ প্রাসঙ্গিক হলে iOS-এ VoiceOver এবং Android-এ TalkBack দিয়ে test করুন।

Automated tools দরকারি, কিন্তু “Open,” “Read more,” বা “Delete” যথেষ্ট contextual কি না তা নির্ভরযোগ্যভাবে বলতে পারে না। Automation-কে net হিসেবে ধরুন, judge হিসেবে নয়। এটি performance auditing-এর মতো: একটি report suspicious areas দেখাতে পারে, কিন্তু impact আপনাকেই interpret করতে হয়। Lighthouse report আতঙ্কিত না হয়ে পড়া-র জন্য আমরা যে calm approach সুপারিশ করি, এখানেও সেটিই প্রযোজ্য।

একটি ব্যবহারিক review checklist

ARIA labels ship করার আগে জিজ্ঞেস করুন:

• এটি কি native HTML হতে পারত?
• label হিসেবে ব্যবহার করা উচিত এমন দৃশ্যমান text কি আছে?
• দৃশ্যমান text থাকলে accessible name কি তা অন্তর্ভুক্ত করে?
• visual context-এর বাইরে navigate করলে repeated controls কি unique?
• help text কি aria-describedby দিয়ে connected, label-এর মধ্যে জোর করে ঢোকানো নয়?
• decorative icons কি assistive technology থেকে hidden?
• browser dev tools-এ computed accessibility name কি কেউ পরীক্ষা করেছে?
• critical flow-এর জন্য অন্তত একটি real screen reader pass কি করা হয়েছে?

এই checklist বেশিরভাগ label সমস্যা user problem হওয়ার আগেই ধরে ফেলে।

ভালো ARIA-এর নীরব শৃঙ্খলা

ভালো ARIA কাজ খুব কমই নাটকীয়। বেশিরভাগই সংযম।

Real buttons ব্যবহার করুন। Real labels ব্যবহার করুন। দৃশ্যমান এবং accessible names মিলিয়ে রাখুন। আরও ভালো দৃশ্যমান source না থাকলেই শুধু aria-label যোগ করুন। পেজে সঠিক text আগে থেকেই থাকলে aria-labelledby ব্যবহার করুন। Supporting instructions এবং errors-এর জন্য aria-describedby ব্যবহার করুন।

আমরা web platform সরাসরি ব্যবহার করলে এটি developers-কে অনেক কিছু বিনামূল্যে দেয়। ARIA আছে gap পূরণের জন্য। দক্ষতা হলো কখন সত্যিই gap আছে তা জানা।