স্বয়ংক্রিয় অ্যাক্সেসযোগ্যতা পরীক্ষা

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

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

স্বয়ংক্রিয়, ম্যানুয়াল এবং সহায়ক প্রযুক্তি—প্রতিটি পরীক্ষাই সম্ভাব্য সর্বাধিক প্রবেশগম্য পণ্য তৈরির জন্য অপরিহার্য। আমাদের পরীক্ষাগুলো মানদণ্ড হিসেবে ওয়েব কন্টেন্ট অ্যাক্সেসিবিলিটি গাইডলাইনস (WCAG) ২.১-এর কনফরমেন্স লেভেল A এবং AA-এর উপর নির্ভর করে।

মনে রাখবেন যে আপনার শিল্পক্ষেত্র, পণ্যের ধরন, স্থানীয় ও দেশের আইন ও নীতিমালা, অথবা সামগ্রিক প্রবেশগম্যতার লক্ষ্যই নির্ধারণ করে দেয় কোন নির্দেশিকা অনুসরণ করতে হবে এবং কোন স্তর পূরণ করতে হবে। যদি আপনার প্রকল্পের জন্য কোনো নির্দিষ্ট স্ট্যান্ডার্ডের প্রয়োজন না হয়, তবে WCAG-এর সর্বশেষ সংস্করণটি অনুসরণ করার পরামর্শ দেওয়া হয়। প্রবেশগম্যতা নিরীক্ষা, সঙ্গতির প্রকার/স্তর, WCAG এবং POUR সম্পর্কিত সাধারণ তথ্যের জন্য " ডিজিটাল প্রবেশগম্যতা কীভাবে পরিমাপ করা হয়? " অংশে ফিরে যান।

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

• প্রতিবন্ধী ব্যক্তিদের নিয়ে ব্যবহারযোগ্যতা পরীক্ষা চালান।
• আপনার দলে কাজ করার জন্য প্রতিবন্ধী ব্যক্তিদের নিয়োগ করুন।
• ডিজিটাল অ্যাক্সেসিবিলিটি বিষয়ে বিশেষজ্ঞ কোনো ব্যক্তি বা প্রতিষ্ঠানের সাথে পরামর্শ করুন।

স্বয়ংক্রিয় পরীক্ষার মূল বিষয়গুলি

স্বয়ংক্রিয় অ্যাক্সেসিবিলিটি টেস্টিং সফটওয়্যার ব্যবহার করে পূর্বনির্ধারিত অ্যাক্সেসিবিলিটি কনফরমেন্স স্ট্যান্ডার্ডের সাথে তুলনা করে আপনার ডিজিটাল পণ্যের অ্যাক্সেসিবিলিটি সংক্রান্ত সমস্যাগুলো স্ক্যান করে।

স্বয়ংক্রিয় প্রবেশগম্যতা পরীক্ষার সুবিধাসমূহ:

• পণ্যের জীবনচক্রের বিভিন্ন পর্যায়ে দ্রুত পরীক্ষাগুলোর পুনরাবৃত্তি করুন।
• দৌড়াতে মাত্র কয়েকটি ধাপ এবং খুব দ্রুত ফলাফল।
• পরীক্ষাগুলো চালাতে বা ফলাফল বুঝতে খুব বেশি অ্যাক্সেসিবিলিটি জ্ঞানের প্রয়োজন হয় না।

স্বয়ংক্রিয় প্রবেশগম্যতা পরীক্ষার অসুবিধাসমূহ:

• স্বয়ংক্রিয় টুলগুলো আপনার পণ্যের সমস্ত অ্যাক্সেসিবিলিটি ত্রুটি ধরতে পারে না।
• মিথ্যা ইতিবাচক প্রতিবেদন (এমন একটি সমস্যা প্রতিবেদন করা যা প্রকৃত WCAG লঙ্ঘন নয়)
• বিভিন্ন পণ্যের ধরণ এবং ভূমিকার জন্য একাধিক সরঞ্জামের প্রয়োজন হতে পারে।

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

স্বয়ংক্রিয় সরঞ্জামের প্রকারভেদ

প্রথম অনলাইন স্বয়ংক্রিয় অ্যাক্সেসিবিলিটি টেস্টিং টুলগুলোর মধ্যে একটি ১৯৯৬ সালে সেন্টার ফর অ্যাপ্লায়েড স্পেশাল টেকনোলজি (CAST) দ্বারা তৈরি করা হয়েছিল, যার নাম ছিল " দ্য ববি রিপোর্ট "। বর্তমানে, বেছে নেওয়ার জন্য ১০০টিরও বেশি স্বয়ংক্রিয় টেস্টিং টুল রয়েছে!

স্বয়ংক্রিয় টুল বাস্তবায়নের পরিধি অ্যাক্সেসিবিলিটি ব্রাউজার এক্সটেনশন থেকে শুরু করে কোড লিন্টার, ডেস্কটপ ও মোবাইল অ্যাপ্লিকেশন, অনলাইন ড্যাশবোর্ড, এবং এমনকি ওপেন-সোর্স এপিআই পর্যন্ত বিস্তৃত, যা ব্যবহার করে আপনি আপনার নিজস্ব স্বয়ংক্রিয় টুলিং তৈরি করতে পারেন।

আপনি কোন স্বয়ংক্রিয় টুলটি ব্যবহার করবেন তা বিভিন্ন বিষয়ের উপর নির্ভর করতে পারে, যার মধ্যে রয়েছে:

• আপনি কোন সামঞ্জস্যের মান এবং স্তর অনুযায়ী পরীক্ষা করছেন? এর মধ্যে WCAG 2.2, WCAG 2.1, US Section 508 , অথবা অ্যাক্সেসিবিলিটি নিয়মের একটি সংশোধিত তালিকা অন্তর্ভুক্ত থাকতে পারে।
• আপনি কোন ধরনের ডিজিটাল পণ্য পরীক্ষা করছেন? এটি একটি ওয়েবসাইট, ওয়েব অ্যাপ, নেটিভ মোবাইল অ্যাপ, পিডিএফ, কিয়স্ক বা অন্য কোনো পণ্য হতে পারে।
• সফটওয়্যার ডেভেলপমেন্ট লাইফসাইকেলের কোন পর্যায়ে আপনি আপনার প্রোডাক্টটি পরীক্ষা করছেন?
• টুলটি সেট আপ করতে এবং ব্যবহার করতে কত সময় লাগে? একজন ব্যক্তি, দল বা কোম্পানির জন্য?
• পরীক্ষাটি কে পরিচালনা করছেন: ডিজাইনার, ডেভেলপার, কিউএ, নাকি অন্য কেউ?
• আপনি কত ঘন ঘন অ্যাক্সেসিবিলিটি পরীক্ষা করাতে চান? রিপোর্টে কী কী বিবরণ অন্তর্ভুক্ত করা উচিত? সমস্যাগুলো কি সরাসরি টিকেটিং সিস্টেমের সাথে যুক্ত করা উচিত?
• আপনার পরিবেশে এবং আপনার দলের জন্য কোন সরঞ্জামগুলো সবচেয়ে ভালো কাজ করে?

এছাড়াও আরও অনেক অতিরিক্ত বিষয় বিবেচনা করার আছে। আপনার এবং আপনার দলের জন্য সেরা টুলটি কীভাবে নির্বাচন করবেন সে সম্পর্কে আরও তথ্যের জন্য WAI-এর " ওয়েব অ্যাক্সেসিবিলিটি মূল্যায়ন টুল নির্বাচন " শীর্ষক নিবন্ধটি দেখুন।

ডেমো: স্বয়ংক্রিয় পরীক্ষা

স্বয়ংক্রিয় অ্যাক্সেসিবিলিটি টেস্টিং ডেমোর জন্য, আমরা ক্রোমের লাইটহাউস ব্যবহার করব। লাইটহাউস হলো একটি ওপেন-সোর্স, স্বয়ংক্রিয় টুল যা পারফরম্যান্স, এসইও এবং অ্যাক্সেসিবিলিটির মতো বিভিন্ন ধরনের অডিটের মাধ্যমে ওয়েব পেজের মান উন্নত করার জন্য তৈরি করা হয়েছে।

আমাদের ডেমোটি হলো ‘মেডিকেল মিস্ট্রিজ ক্লাব’ নামক একটি কাল্পনিক সংস্থার জন্য তৈরি করা একটি ওয়েবসাইট। ডেমোর জন্য এই সাইটটি ইচ্ছাকৃতভাবে অ্যাক্সেস-অযোগ্য রাখা হয়েছে। এই অ্যাক্সেস-অযোগ্যতার কিছু অংশ আপনার কাছে দৃশ্যমান হতে পারে, এবং কিছু (তবে সব নয়) আমাদের স্বয়ংক্রিয় পরীক্ষায় ধরা পড়বে।

ধাপ ১

আপনার ক্রোম ব্রাউজার ব্যবহার করে লাইটহাউস এক্সটেনশনটি ইনস্টল করুন।

আপনার টেস্টিং ওয়ার্কফ্লোতে লাইটহাউসকে অন্তর্ভুক্ত করার অনেক উপায় আছে। এই ডেমোর জন্য আমরা ক্রোম এক্সটেনশনটি ব্যবহার করেছি।

ধাপ ২

আমরা কোডপেন-এ একটি ডেমো তৈরি করেছি। পরবর্তী পরীক্ষাগুলো শুরু করার জন্য এটিকে ডিবাগ মোডে দেখুন। এটি গুরুত্বপূর্ণ, কারণ এটি ডেমো ওয়েব পেজটিকে ঘিরে থাকা <iframe> টি সরিয়ে দেয়, যা কিছু টেস্টিং টুলের কাজে বাধা সৃষ্টি করতে পারে।

CodePen-এর ডিবাগ মোড সম্পর্কে আরও জানুন।

ধাপ ৩

Chrome DevTools খুলুন এবং Lighthouse ট্যাবে যান। 'Accessibility' ছাড়া বাকি সব ক্যাটাগরি অপশন আনচেক করুন। মোডটি ডিফল্ট রাখুন এবং যে ডিভাইসে টেস্টগুলো চালাচ্ছেন, তার ধরনটি বেছে নিন।

ধাপ ৪

'Analyze page load'-এ ক্লিক করুন এবং Lighthouse-কে তার পরীক্ষাগুলো চালানোর জন্য সময় দিন।

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

স্কোরের পাশাপাশি, লাইটহাউস রিপোর্টে কী কী সমস্যা শনাক্ত করা হয়েছে সে সম্পর্কে বিস্তারিত তথ্য এবং সেগুলোর প্রতিকার সম্পর্কে আরও জানতে রিসোর্সের লিঙ্ক অন্তর্ভুক্ত থাকে। রিপোর্টটিতে কোন পরীক্ষাগুলো পাস করেছে বা প্রযোজ্য নয়, তার ফলাফল এবং ম্যানুয়ালি পরীক্ষা করার জন্য অতিরিক্ত আইটেমের একটি তালিকাও থাকে।

ধাপ ৫

এখন, স্বয়ংক্রিয়ভাবে শনাক্ত হওয়া প্রতিটি অ্যাক্সেসিবিলিটি সমস্যার একটি করে উদাহরণ দেখুন এবং প্রাসঙ্গিক স্টাইল ও মার্কআপ ঠিক করুন।

ইস্যু ১: ARIA ভূমিকা

প্রথম সমস্যাটিতে বলা হয়েছে: "যেসব এলিমেন্টের একটি ARIA [role] আছে এবং যাদের চাইল্ড রোলে একটি নির্দিষ্ট [role] থাকা প্রয়োজন, তাদের ক্ষেত্রে সেই প্রয়োজনীয় চাইল্ড রোলগুলোর কিছু বা সবগুলো অনুপস্থিত থাকে। কিছু ARIA প্যারেন্ট রোলের তাদের উদ্দিষ্ট অ্যাক্সেসিবিলিটি ফাংশনগুলো সম্পাদনের জন্য নির্দিষ্ট চাইল্ড রোল থাকা আবশ্যক।" ARIA রোলের নিয়মাবলী সম্পর্কে আরও জানুন।

আমাদের ডেমোতে, নিউজলেটার সাবস্ক্রাইব বাটনটি কাজ করছে না:

<button role="list" type="submit" tabindex="1">Subscribe</button>

চলুন এটা ঠিক করি।

ইনপুট ফিল্ডের পাশের "সাবস্ক্রাইব" বোতামটিতে একটি ভুল ARIA রোল প্রয়োগ করা হয়েছে। এক্ষেত্রে, রোলটি সম্পূর্ণরূপে মুছে ফেলা যেতে পারে।

<button type="submit" tabindex="1">Subscribe</button>

ইস্যু ২: ARIA লুকানো

"[aria-hidden="true"] এলিমেন্টগুলোর মধ্যে ফোকাসযোগ্য ডিসেন্ডেন্ট থাকে। একটি [aria-hidden="true"] এলিমেন্টের মধ্যে থাকা ফোকাসযোগ্য ডিসেন্ডেন্টগুলো স্ক্রিন রিডারের মতো সহায়ক প্রযুক্তির ব্যবহারকারীদের জন্য সেই ইন্টারেক্টিভ এলিমেন্টগুলোকে অনুপলব্ধ করে তোলে। aria-hidden নিয়ম সম্পর্কে আরও জানুন ।

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>

চলুন এটা ঠিক করি।

ইনপুট ফিল্ডটিতে aria-hidden="true" অ্যাট্রিবিউটটি প্রয়োগ করা ছিল। এই অ্যাট্রিবিউটটি যোগ করলে এলিমেন্টটি (এবং এর অধীনে থাকা সবকিছু) সহায়ক প্রযুক্তি থেকে আড়াল হয়ে যায়।

<input type="email" placeholder="Enter your e-mail address" tabindex="-1" required>

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

সমস্যা ৩: বাটনের নাম

বাটনগুলোর কোনো অ্যাক্সেসিবল নাম নেই। যখন কোনো বাটনের অ্যাক্সেসিবল নাম থাকে না, তখন স্ক্রিন রিডার সেটিকে "বাটন" হিসেবে ঘোষণা করে, ফলে স্ক্রিন রিডারের ওপর নির্ভরশীল ব্যবহারকারীদের জন্য এটি ব্যবহার অযোগ্য হয়ে পড়ে।

বাটনের নাম রাখার নিয়মকানুন সম্পর্কে আরও জানুন ।

<button role="list" type="submit" tabindex="1">Subscribe</button>

চলুন এটা ঠিক করি।

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

<button type="submit" tabindex="1">Subscribe</button>

সমস্যা ৪: ছবির alt অ্যাট্রিবিউট

ইমেজ এলিমেন্টগুলোতে [alt] অ্যাট্রিবিউট নেই। তথ্যমূলক এলিমেন্টগুলোর জন্য সংক্ষিপ্ত ও বর্ণনামূলক অল্টারনেট টেক্সট ব্যবহার করা উচিত। ডেকোরেটিভ এলিমেন্টগুলোকে খালি alt অ্যাট্রিবিউট দিয়ে উপেক্ষা করা যেতে পারে। ইমেজ অল্টারনেট টেক্সটের নিয়মকানুন সম্পর্কে আরও জানুন ।

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png">
</a>

চলুন এটা ঠিক করি।

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

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png"
    alt="Go to the home page.">
</a>

ইস্যু ৫: লিঙ্ক টেক্সট

লিঙ্কের কোনো সুস্পষ্ট নাম থাকে না। লিঙ্ক টেক্সট (এবং ছবি লিঙ্ক হিসেবে ব্যবহৃত হলে তার বিকল্প টেক্সট) যদি সুস্পষ্ট, অনন্য এবং ফোকাসযোগ্য হয়, তবে তা স্ক্রিন রিডার ব্যবহারকারীদের জন্য নেভিগেশন অভিজ্ঞতা উন্নত করে। লিঙ্ক টেক্সটের নিয়মাবলী সম্পর্কে আরও জানুন ।

<a href="#!"><svg><path>...</path></svg></a>

চলুন এটা ঠিক করি।

পৃষ্ঠার সমস্ত কার্যকর ছবিতে অবশ্যই এই তথ্য অন্তর্ভুক্ত থাকতে হবে যে লিঙ্কটি ব্যবহারকারীদের কোথায় নিয়ে যায়। এই সমস্যার সমাধানের একটি উপায় হলো, ছবির সাথে এর উদ্দেশ্য সম্পর্কে বিকল্প টেক্সট যোগ করা, যেমনটি আপনি উদাহরণে লোগো ছবিতে করেছেন। এটি <img> ট্যাগ ব্যবহার করা ছবির জন্য খুব ভালোভাবে কাজ করে, কিন্তু <svg> ট্যাগের ক্ষেত্রে এই পদ্ধতিটি ব্যবহার করা যায় না।

সোশ্যাল মিডিয়া আইকনগুলোর জন্য, যেগুলোতে <svg> ট্যাগ ব্যবহৃত হয়, আপনি SVG-কে লক্ষ্য করে একটি ভিন্ন বিকল্প বর্ণনা প্যাটার্ন ব্যবহার করতে পারেন, <a> এবং <svg> ট্যাগের মধ্যে তথ্য যোগ করে ব্যবহারকারীদের কাছ থেকে তা দৃশ্যত লুকিয়ে রাখতে পারেন, একটি সমর্থিত ARIA যোগ করতে পারেন, অথবা অন্যান্য বিকল্প বেছে নিতে পারেন। আপনার পরিবেশ এবং কোডের সীমাবদ্ধতার উপর নির্ভর করে, একটি পদ্ধতির চেয়ে অন্যটি বেশি সুবিধাজনক হতে পারে।

সবচেয়ে সহজ প্যাটার্ন বিকল্পটি ব্যবহার করুন, যাতে সর্বাধিক সহায়ক প্রযুক্তি কভারেজ রয়েছে; আর তা হলো <svg> ট্যাগে role="img" যোগ করা এবং একটি <title> এলিমেন্ট অন্তর্ভুক্ত করা।

<a href="#!">
  <svg role="img">
    <title>Connect on our Twitter page.</title>
    <path>...</path>
  </svg>
</a>

সমস্যা ৬: রঙের বৈসাদৃশ্য

ব্যাকগ্রাউন্ড এবং ফোরগ্রাউন্ড রঙের মধ্যে পর্যাপ্ত কনট্রাস্ট অনুপাত নেই। কম কনট্রাস্টের লেখা অনেক ব্যবহারকারীর জন্য পড়া কঠিন বা অসম্ভব। রঙের কনট্রাস্টের নিয়মকানুন সম্পর্কে আরও জানুন ।

দুটি দৃষ্টান্তের কথা জানানো হয়েছিল।

চলুন এটা ঠিক করি।

ওয়েব পেজটিতে রঙের বৈসাদৃশ্য (কালার কনট্রাস্ট) সংক্রান্ত অনেক সমস্যা শনাক্ত করা হয়েছে। আপনি রঙ এবং বৈসাদৃশ্য মডিউলে যেমন শিখেছেন, সাধারণ আকারের টেক্সটের (১৮pt / ২৪px-এর কম) জন্য রঙের বৈসাদৃশ্যের আবশ্যকতা হলো ৪.৫:১, অপরদিকে বড় আকারের টেক্সট (কমপক্ষে ১৮pt / ২৪px অথবা ১৪pt / ১৮.৫px বোল্ড) এবং অপরিহার্য আইকনগুলোকে অবশ্যই ৩:১-এর আবশ্যকতা পূরণ করতে হবে।

পেজের শিরোনামের জন্য, টিল রঙের টেক্সটটিকে ৩:১ কালার কনট্রাস্টের শর্ত পূরণ করতে হবে, কারণ এটি ২৪ পিক্সেলের একটি বড় আকারের টেক্সট। তবে, টিল রঙের বাটনগুলোকে ১৬ পিক্সেল বোল্ড হওয়ায় সাধারণ আকারের টেক্সট হিসেবে গণ্য করা হয়, তাই সেগুলোকে অবশ্যই ৪.৫:১ কালার কনট্রাস্টের শর্ত পূরণ করতে হবে।

এক্ষেত্রে, আমরা ৪.৫:১ অনুপাত পূরণের জন্য যথেষ্ট গাঢ় একটি টিল রঙ খুঁজে নিতে পারতাম, অথবা বাটনের টেক্সটের সাইজ বাড়িয়ে ১৮.৫ পিক্সেল বোল্ড করে টিল রঙের মান সামান্য পরিবর্তন করতে পারতাম। উভয় পদ্ধতিই ডিজাইনের নান্দনিকতার সাথে সামঞ্জস্যপূর্ণ থাকে।

পৃষ্ঠার দুটি বৃহত্তম শিরোনাম ব্যতীত, সাদা পটভূমির উপর থাকা সমস্ত ধূসর লেখা রঙের বৈসাদৃশ্যের শর্ত পূরণ করতে ব্যর্থ হয়েছে। ৪.৫:১ রঙের বৈসাদৃশ্যের শর্ত পূরণ করার জন্য এই লেখাগুলোকে অবশ্যই গাঢ় করতে হবে।

সমস্যা ৭: তালিকার কাঠামো

তালিকার আইটেমগুলো ( <li> ) <ul> বা <ol> প্যারেন্ট এলিমেন্টের মধ্যে থাকে না। স্ক্রিন রিডার দ্বারা সঠিকভাবে ঘোষিত হওয়ার জন্য তালিকার আইটেমগুলো ( <li> ) অবশ্যই একটি প্যারেন্ট <ul> বা <ol> এর মধ্যে থাকতে হবে।

তালিকার নিয়মাবলী সম্পর্কে আরও জানুন ।

<div class="ul">
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</div>

চলুন এটা ঠিক করি।

এই ডেমোতে আমরা <ul> ট্যাগ ব্যবহার না করে, আনঅর্ডারড লিস্ট অনুকরণ করার জন্য একটি CSS ক্লাস ব্যবহার করেছিলাম। যখন আমরা এই কোডটি ভুলভাবে লিখি, তখন আমরা এই ট্যাগের অন্তর্নিহিত সিমান্টিক HTML বৈশিষ্ট্যগুলো মুছে ফেলেছিলাম। ক্লাসটিকে একটি আসল <ul> ট্যাগ দিয়ে প্রতিস্থাপন করে এবং সংশ্লিষ্ট CSS পরিবর্তন করার মাধ্যমে, আমরা এই অ্যাক্সেসিবিলিটি সমস্যাটি সমাধান করেছি।

<ul>
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</ul>

সমস্যা ৮: ট্যাবইনডেক্স

কিছু এলিমেন্টের tabindex ভ্যালু ০-এর চেয়ে বেশি হয়। ০-এর চেয়ে বেশি ভ্যালু একটি সুস্পষ্ট নেভিগেশন ক্রম নির্দেশ করে। যদিও এটি প্রযুক্তিগতভাবে বৈধ, তবুও এটি প্রায়শই সেইসব ব্যবহারকারীদের জন্য হতাশাজনক অভিজ্ঞতা তৈরি করে যারা সহায়ক প্রযুক্তির উপর নির্ভর করেন। tabindex নিয়মাবলী সম্পর্কে আরও জানুন ।

<button type="submit" tabindex="1">Subscribe</button>

চলুন এটা ঠিক করি।

ওয়েব পেজের স্বাভাবিক ট্যাবিং ক্রম ব্যাহত করার কোনো নির্দিষ্ট কারণ না থাকলে, tabindex অ্যাট্রিবিউটে ধনাত্মক পূর্ণসংখ্যা রাখার কোনো প্রয়োজন নেই। স্বাভাবিক ট্যাবিং ক্রম বজায় রাখতে, আমরা হয় tabindex-কে 0 -তে পরিবর্তন করতে পারি অথবা অ্যাট্রিবিউটটি পুরোপুরি সরিয়ে ফেলতে পারি।

<button type="submit">Subscribe</button>

ধাপ ৬

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

আমরা এই সমস্ত স্বয়ংক্রিয় অ্যাক্সেসিবিলিটি আপডেট একটি নতুন কোডপেন- এ প্রয়োগ করেছি।

পরবর্তী পদক্ষেপ

চমৎকার কাজ। আপনি ইতিমধ্যেই অনেক কিছু সম্পন্ন করেছেন, কিন্তু আমাদের কাজ এখনও শেষ হয়নি! এরপর, আমরা ম্যানুয়াল চেকের দিকে এগিয়ে যাব, যেমনটি ম্যানুয়াল অ্যাক্সেসিবিলিটি টেস্টিং মডিউলে বিস্তারিতভাবে বলা হয়েছে।