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

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

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

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

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

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

• Run usability tests with people with disabilities.
• Hire people with disabilities to work on your team.
• Consult an individual or company with digital accessibility expertise.

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

Automated accessibility testing uses software to scan your digital product for accessibility issues against predefined accessibility conformance standards.

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

• Quickly repeat tests at different stages of the product lifecycle.
• দৌড়াতে মাত্র কয়েকটি ধাপ এবং খুব দ্রুত ফলাফল।
• Little accessibility knowledge is required to run the tests or understand the results.

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

• Automated tools don't catch all of the accessibility errors in your product
• Reported false positives (an issue is reported that isn't a true WCAG violation)
• Multiple tools may be needed for different product types and roles

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

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

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

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

Which automated tool you decide to use can depend on many factors, including:

• আপনি কোন সামঞ্জস্যের মান এবং স্তর অনুযায়ী পরীক্ষা করছেন? এর মধ্যে WCAG 2.2, WCAG 2.1, US Section 508 , অথবা অ্যাক্সেসিবিলিটি নিয়মের একটি সংশোধিত তালিকা অন্তর্ভুক্ত থাকতে পারে।
• What type of digital product are you testing? This could be a website, web app, native mobile app, PDF, kiosk, or other product.
• What part of the software development lifecycle are you testing your product?
• How much time does it take to set up and use the tool? For an individual, team, or company?
• Who is conducting the test: designers, developers, QA, or someone else?
• How often do you want the accessibility to be checked? What details should be included in the report? Should issues be directly linked to a ticketing system?
• Which tools work best in your environment? For your team?

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

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

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

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

ধাপ ১

Using your Chrome browser, install the Lighthouse extension .

There are many ways to integrate Lighthouse into your testing workflow. We use the Chrome extension for this demo.

ধাপ ২

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

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

ধাপ ৩

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

ধাপ ৪

Click Analyze page load and give Lighthouse time to run its tests.

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

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

ধাপ ৫

Now, go through an example of each automated accessibility issue discovered and fix the relevant styles and markup.

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

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

In our demo, the newsletter subscribe button fails:

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

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

The "subscribe" button next to the input field has an incorrect ARIA role applied to it. In this case, the role can be removed completely.

<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>

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

The input field had an aria-hidden="true" attribute applied to it. Adding this attribute hides the element (and everything nested under it) from assistive tech.

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

In this case, you should remove this attribute from the input to allow people using assistive technology to access and enter information into the form field.

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

Buttons don't have an accessible name. When a button doesn't have an accessible name, screen readers announce it as "button," making it unusable for users who rely on screen readers.

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

<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 যোগ করতে পারেন, অথবা অন্যান্য বিকল্প বেছে নিতে পারেন। আপনার পরিবেশ এবং কোডের সীমাবদ্ধতার উপর নির্ভর করে, একটি পদ্ধতির চেয়ে অন্যটি বেশি সুবিধাজনক হতে পারে।

Use the simplest pattern option with the most assistive technology coverage, which is adding a role="img" to the <svg> tag and including a <title> element.

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

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

Background and foreground colors don't have a sufficient contrast ratio. Low-contrast text is difficult or impossible for many users to read. Learn more about color contrast rules .

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

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

ওয়েব পেজটিতে রঙের বৈসাদৃশ্য (কালার কনট্রাস্ট) সংক্রান্ত অনেক সমস্যা শনাক্ত করা হয়েছে। আপনি রঙ এবং বৈসাদৃশ্য মডিউলে যেমন শিখেছেন, সাধারণ আকারের টেক্সটের (১৮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>

ধাপ ৬

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

We've applied all of these automated accessibility updates to a new CodePen .

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

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