8 মিনিট

React ও Flutter UI রিভিউর জন্য অ্যাক্সেসিবিলিটি প্রম্পট

React এবং Flutter UI রিভিউর জন্য অ্যাক্সেসিবিলিটি প্রম্পট: কপি-পেস্ট করার মতো প্রম্পট ও সহজ রিভিউ ধাপ — কীবোর্ড, ফোকাস অর্ডার, লেবেল, কনট্রাস্ট এবং স্ক্রীন রিডার পরীক্ষা সহ।

React ও Flutter UI রিভিউর জন্য অ্যাক্সেসিবিলিটি প্রম্পট

মানুষ কী মিস করে যখন তারা UI-কে অ্যাক্সেসিবল করতে চায়

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

সাধারণত প্রথমে যা ভেঙে পড়ে তা অপেক্ষাকৃতই একরকম। একটা পেজ ঠিকঠাক দেখাতে পারে, দ্রুত ভিজ্যুয়াল চেক পাস করতে পারে, তবুও কীবোর্ড বা স্ক্রীন রিডারের সাথে ব্যবহার করা কঠিন হতে পারে।

UI-তে নিম্নলিখিত জায়গাগুলো প্রথমে ব্যথা দেয়:

  • কীবোর্ড অ্যাক্সেস: গুরুত্বপূর্ণ কন্ট্রোলগুলো পৌঁছাতে পারছেন না, বা কোনো মডালে আটকে যাচ্ছেন
  • ফোকাস অর্ডার ও ফোকাস স্টেট: ফোকাস এলোমেলো নাচে, অথবা আপনি দেখতেই পাচ্ছেন না কোথায় ফোকাস রয়েছে
  • লেবেল ও নাম: ইনপুট ও বোতামগুলোর স্পষ্ট বা উপস্থিত অ্যাক্সেসিবল নাম নেই
  • ঘোষণা: ডাইনামিক আপডেট হচ্ছে কিন্তু স্ক্রীন রিডারকে বলে দেওয়া হচ্ছে না
  • কনট্রাস্ট ও স্পষ্টতা: টেক্সট, আইকন, এবং এরর স্টেটগুলো দেখা কঠিন

চ্যালেঞ্জটা হলো কত সহজে regressions (পেছনে ফেরা) ঘটতে পারে। ছোট পরিবর্তন—যেমন বোতামকে আইকনে বদলানো, কার্ডকে জেসচার হ্যান্ডলারে র‍্যাপ করা, বা কাস্টম ড্রপডাউন যোগ করা—এইগুলো কীবোর্ড সাপোর্ট সরিয়ে দিতে পারে, ফোকাস অর্ডার ভাঙাতে পারে, বা লেবেল হারিয়ে যেতে পারে, এবং অনেকে তা দেখতে পায় না।

একটি সাধারণ দৃশ্য: একটি React ফর্মে ইনপুটের ভিতরে নতুন “clear” আইকন যোগ করা হলো। এটা সহায়ক মনে হয়, কিন্তু আইকন ফোকাসযোগ্য নয়, নাম নেই, এবং ক্লিক ইভেন্ট চুরি করছে। ফলাফল—কীবোর্ড ব্যবহারকারীরা এটা চালু করতে পারেন না, এবং স্ক্রীন রিডার ব্যবহারকারীরা অনলেবেলড কন্ট্রোল শুনে।

এই পোস্টটি আপনাকে দুইটি জিনিস দেবে: কপি করে ব্যবহার করার মতো প্রম্পট যা আপনি আপনার UI কোড (React ও Flutter) নিয়ে ব্যবহার করতে পারেন, এবং একটি রিপিটেবল রিভিউ ফ্লো যা আপনি কয়েক মিনিটের মধ্যে চালাতে পারবেন। লক্ষ্য প্রথম দিনেই নিখুঁত হওয়া নয়—লক্ষ্য হলো সেই ইস্যুগুলো ধরা যা বাস্তব ব্যবহারকারীদের ব্লক করে।

যদি আপনি প্রোডাক্ট স্ক্রিন তৈরি করেন কিন্তু অ্যাক্সেসিবিলিটি স্পেশালিস্ট না হন, এটি আপনার জন্য। এটি Koder.ai-এর মতো চ্যাট-বিল্ডার ব্যবহারকারী দলের জন্যও ফিট করে, যেখানে UI পরিবর্তন দ্রুত হতে পারে এবং আপনাকে দ্রুত, ধারাবাহিক চেক করতে হবে। একটি ব্যবহারিক শুরু দরকার হলে, এই রিয়্যাক্ট ও ফ্লাটার UI রিভিউর অ্যাক্সেসিবিলিটি প্রম্পটগুলো প্রতিবার আপনি UI শিপ করলে পুনরায় ব্যবহার করার জন্য ডিজাইন করা হয়েছে।

চিহ্নিত 5টি চেক যা দ্রুত বেশিরভাগ ইস্যু ধরবে

আপনার কাছে যদি কেবল 15 মিনিট থাকে কোনো স্ক্রিন রিভিউ করার জন্য, এই চেকগুলো সেই সমস্যা গুলো খুঁজে পাবে যা বেশিরভাগ সময় মানুষকে ব্লক করে। এগুলো React ও Flutter দুটোতেই কাজ করে এবং উপরের টপিকে ঐক্যবদ্ধভাবে ফিট করে।

1) আপনি কি কেবল কীবোর্ড দিয়েই এটি ব্যবহার করতে পারেন?

পেজে মাউস ছাড়া ঘোরার চেষ্টা করুন। Tab ও Shift+Tab দিয়ে নেভিগেট করুন, Enter ও Space দিয়ে.activate করুন, এবং যেখানে উইজেট দেখায় সেটার মতো মেনু/ট্যাব/লিস্টে অ্যারো কী ব্যবহার করুন।

একটি দ্রুত ইঙ্গিত: যদি আপনি কোনো মডালে আটকে যান, বা কোনো গুরুত্বপূর্ণ কন্ট্রোল (যেমন “Close”) পৌঁছাতে না পারেন, তাহলে কিছু ভুল আছে।

2) ফোকাস অর্ডার কি যুক্তিযুক্ত এবং ফোকাস কি দৃশ্যমান?

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

3) কন্ট্রোলগুলোর কি পরিষ্কার নাম আছে?

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

4) কনট্রাস্ট ও টেক্সট সাইজ কি ঠিক আছে?

খুব ছোট টেক্সট, ডিসেবেলড টেক্সট, এবং রঙিন বোতামের টেক্সট চেক করুন। জুম করে দেখুন: ফন্ট সাইজ বাড়ান এবং নিশ্চিত করুন লেআউট ওভারল্যাপ করে না বা কী কনটেন্ট কাটছে না।

5) পরিবর্তনগুলো কি স্পষ্টভাবে ঘোষণা করা হচ্ছে?

কিছু পরিবর্তন হলে (এরর, লোডিং, সাকসেস), ব্যবহারকারীদের অনুমান করতে হবে না। ইনলাইন এরর টেক্সট ব্যবহার করুন ফিল্ডের কাছে, ফর্ম এররগুলো ঘোষণা করুন, এবং লোডিং স্টেটগুলো স্পষ্ট করুন।

আপনি যদি Koder.ai-এ স্ক্রিন তৈরি করেন, তাকে বলুন “verify keyboard-only flow, focus order, and screen reader labels for this page,” এবং তারপর উপরের ধাপগুলো ব্যবহার করে ফলাফল রিভিউ করুন।

UI পরিবর্তন করার আগে আপনার রিভিউ স্কোপ সেট করুন

Accessibility কাজ দ্রুত হয় যখন আপনি ঠিক করে রাখেন কী রিভিউ করবেন এবং “ভালো পর্যাপ্ত” মানে কী, কোনো কম্পোনেন্টের দিকে হাত দেওয়ার আগেই। একটি সীমিত স্কোপও অ্যাক্সেসিবিলিটি প্রম্পটগুলিকে আরও কার্যকর করে, কারণ মডেলটি বাস্তব স্ক্রিন ও বাস্তব ইন্টারঅ্যাকশনে ফোকাস করতে পারে।

গুরুত্বপূর্ণ যাত্রাপথগুলো বাছাই করুন

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

বেশিরভাগ অ্যাপের জন্য, সেটা এমন কিছু হতে পারে: লগইন, একটি প্রাথমিক “ক্রিয়েট বা বাই” ফ্লো (চেকআউট, বুকিং, সাবমিট), এবং একটি অ্যাকাউন্ট এলাকা যেমন সেটিংস বা প্রোফাইল।

তারপর প্রতিটি জার্নিতে নির্দিষ্ট স্ক্রিনগুলো লিখে নিন (যদিও সেটা কেবল ৫ থেকে ৮ স্ক্রিনই হোক)। “মধ্যবর্তী” স্টেটগুলোও অন্তর্ভুক্ত করুন: এরর মেসেজ, খালি স্টেট, লোডিং স্টেট, এবং কনফার্মেশন ডায়ালগ—এসবই সাধারণত ফোকাস ও স্ক্রীন রিডার আউটপুট ভেঙে দেয়।

একটি বাস্তব উদাহরণ: আপনি যদি Koder.ai-এ একটি ছোট CRM স্ক্রিন বানান, তাহলে স্কোপটা হতে পারে “sign in -> open Contacts -> add contact -> save -> see success message।” এই এক জার্নি ফর্ম, ভ্যালিডেশন, ডায়ালগ, এবং ঘোষণা সবকিছু কভার করে।

“পাস” কী মানে তা ঠিক করুন

প্র্যাকটিক্যাল হোন। WCAG AA-শৈলীর প্রত্যাশার দিকে লক্ষ্য রাখুন, কিন্তু সেটা এমন সরল চেকগুলোতে অনুবাদ করুন যা আপনি দ্রুত প্রয়োগ করতে পারেন: কীবোর্ড পুরো পথে কাজ করে, ফোকাস দৃশ্যমান ও যুক্তিযুক্ত, নাম ও লেবেল অর্থবহ, এবং কনট্রাস্ট পাঠযোগ্য।

সীমিত সময়ের জন্য সাদাসিধে পাস/ফেইল নোট ফরম্যাট ব্যবহার করুন যাতে সময় নষ্ট না হয় বিতর্ক করে। প্রতিটি স্ক্রিনের জন্য নোট লিখুন:

  • Check: (keyboard, focus order, labels, contrast, announcements)
  • Result: Pass or Fail
  • Evidence: এক বাক্যে কী ঘটল
  • Fix guess: কী পরিবর্তন প্রয়োজন হতে পারে (কম্পোনেন্ট, prop, স্টাইলিং)
  • Retest: পরিবর্তনের পরে কী পরীক্ষা করবে

এভাবে রিয়্যাক্ট ও ফ্লাটার দুটোতেই রিভিউ কনসিস্টেন্ট থাকে এবং কাউকে সমস্যাটা বোঝানোর জন্য পুনরায় ব্যাখ্যা করার দরকার পড়ে না।

React কম্পোনেন্টের জন্য কপি-পেস্ট প্রম্পট (কীবোর্ড, লেবেল, রোল)

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

আপনি যদি চ্যাট-ভিত্তিক বিল্ডার যেমন Koder.ai ব্যবহার করেন, স্ক্রিন বা কম্পোনেন্ট জেনারেট করার ঠিক পরে এই প্রম্পট যোগ করুন যাতে সমস্যা ছড়ানোর আগেই ঠিক করা যায়।

Review this React component for keyboard navigation issues. 
- Can every interactive element be reached with Tab and activated with Enter/Space?
- List the exact problems you see in the code.
- Propose fixes with small code edits.

Check focus order and focus visibility.
- Describe the expected focus order for a keyboard-only user.
- Point out where focus could get lost (modals, menus, drawers).
- Tell me exactly where to add :focus-visible styles (which elements, which CSS).

Find missing accessible names.
- Identify inputs, buttons, and icons without clear labels.
- Suggest label + htmlFor, aria-label, aria-labelledby, or visible text.
- If there is helper/error text, connect it with aria-describedby.

Identify interactive elements that are not buttons/links.
- Find div/span with onClick, custom dropdowns, and clickable cards.
- Suggest correct semantics (button/a) or add role, tabIndex, and keyboard handlers.

List screen reader announcements that will be confusing.
- Predict what a screen reader will announce for key controls.
- Rewrite UI text to be shorter and clearer.
- Suggest aria-live usage for status changes (loading, errors, saved).

প্রম্পট পাঠানোর আগে এই তথ্যগুলো যোগ করুন যাতে আপনি জেনেরিক পরামর্শ না পেয়ে ব্যবহারযোগ্য ফিক্স পান:

  • কম্পোনেন্ট কী (উদাহরণ: “login form”, “pricing toggle”, “settings modal”).
  • কীবোর্ড পথ যা ব্যবহারকারীরা অনুসরণ করবে (শুরু ও শেষ পয়েন্ট)।
  • ব্যবহার করা UI লাইব্রেরি (MUI, Chakra, Radix, custom components)।
  • টেস্ট করার স্টেটগুলো (loading, error, disabled, empty results)।
  • একটি নির্দিষ্ট ব্যবহারকারী লক্ষ্য (উদাহরণ: “change plan and confirm”).

Flutter উইজেটগুলোর জন্য কপি-পেস্ট প্রম্পট (Semantics, ফোকাস, জেসচার)

Ship accessible UI faster
Build your next React or Flutter screen by chat, then iterate with your accessibility checklist.

সামঞ্জস্যপূর্ণ ফল পেতে উইজেট স্নিপেট (বা পুরো স্ক্রিন) পেস্ট করে নির্দিষ্ট চেক জানতে বলুন। এই প্রম্পটগুলো সবচেয়ে ভালো কাজ করে যখন আপনি উইজেট ট্রি, স্ক্রিন কীভাবে পৌঁছানো হয়, এবং কোনো কাস্টম জেসচারের বিবরণ যোগ করেন।

রিভিউতে পেস্ট করার জন্য প্রম্পট

Review this Flutter widget tree for keyboard navigation and focus traversal.
Call out focus traps, missing focus order, and places where Tab/Shift+Tab will feel confusing.
Suggest exact widget changes (Focus, FocusTraversalGroup, Shortcuts, Actions).
Check this screen for missing Semantics labels, hints, and tap targets.
Point to the exact widgets that need Semantics(label/hint), tooltip, or exclusion.
Also flag controls under 48x48 logical pixels and suggest fixes.
Find custom gestures that break accessibility (GestureDetector/Listener).
Replace them with accessible widgets or add keyboard + semantics support.
If a gesture is required, describe how a keyboard user triggers the same action.
Audit error messages and validation on this form.
What should be announced to a screen reader, and when?
Suggest how to expose errors via Semantics and focus movement after submit.
Propose a consistent focus highlight style across screens.
It should be obvious on dark/light themes and work with keyboard navigation.
Show a small code example using FocusTheme/ThemeData.

সহজ ফিক্স যা অ্যাসিস্ট্যান্টের প্রস্তাব থাকা উচিত

প্রত্যাশা করুন উত্তরগুলো কিছু কনক্রিট প্যাটার্ন উল্লেখ করবে:

  • প্রধান কনটেন্টকে FocusTraversalGroup-এ র‍্যাপ করুন এবং প্রয়োজনে FocusTraversalOrder সেট করুন।
  • কম্পোজিট কন্ট্রোলগুলোর জন্য Semantics (বা MergeSemantics) ব্যবহার করুন, এবং ডুপ্লিকেট লেবেল পরিহার করুন।
  • GestureDetector-এর বদলে InkWell, IconButton, ListTile, SwitchListTile ব্যবহার করুন যেখানে সম্ভব।
  • নন-টেক্সট ইনপুটের জন্য Shortcuts + Actions যোগ করুন (উদাহরণ: Enter-এ activate করা, Escape-এ close করা)।

কাস্টম কার্ডকে বোতামের মতো আচরণ করাতে একটি ন্যূনতম উদাহরণ:

Semantics(
  button: true,
  label: 'Add payment method',
  hint: 'Opens the add card screen',
  child: Focus(
    child: InkWell(
      onTap: onPressed,
      child: Card(child: child),
    ),
  ),
)

ধাপে ধাপে: একটি সহজ কীবোর্ড ও ফোকাস রিভিউ ফ্লো

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

5-ধাপের ফ্লো

একটি “হ্যাপি পাথ” বাছুন যা একজন ব্যবহারকারী নেবে, যেমন সাইন ইন করা, সেটিংস স্ক্রিন খোলা, এবং সেভ করা।

  1. কীবোর্ড দিয়ে পুরো ফ্লোটি করুন। মাউস সরান। Tab এবং Shift+Tab দিয়ে নেভিগেট করুন, Enter এবং Space দিয়ে অ্যাকটিভেট করুন, এবং যেখানে মানায় সেখানে অ্যারো কী ব্যবহার করুন (মেনু, রেডিও গ্রুপ, ট্যাব)। যদি কিছু ক্লিক বা সোয়াইপ ছাড়া না হয়, তাকে চিহ্নিত করুন।
  2. নিশ্চিত করুন ফোকাস সবসময় দৃশ্যমান। প্রতিবার ফোকাস বদলালে আপনাকে সঙ্গে সঙ্গে দেখতে হবে কোথায় সেটা। পাতলা আউটলাইন যা ডার্ক ব্যাকগ্রাউন্ডে লুকিয়ে যায়, CSS দ্বারা সরিয়ে দেওয়া ফোকাস-রিং, বা Flutter উইজেট যেগুলো “active” দেখায় কিন্তু ফোকাস দেখায় না—এসব খুঁজুন।
  3. চেক করুন অর্ডার দৃশ্যমান ক্রমের সাথে মেলে কি না। ফোকাসকে ভিজ্যুয়াল লেআউট ও রিডিং অর্ডার অনুসরণ করা উচিত। সাধারণ সতর্কতা: ফুটারে লাফানো, সাইডবারে আটকা পড়া, বা কোনো ফিল্ড স্কিপ হয়ে যাওয়া কারণ সেটা ফোকাসযোগ্য নয়।
  4. ওভারলে স্ট্রেস-টেস্ট করুন। মেনু, ডায়ালগ, ড্রয়ার খুলুন। ওপেন থাকা অবস্থায় ফোকাসকে ওভারলে-তে যেতে হবে, ওপেন থাকা পর্যন্ত সেখানে থাকা উচিত, এবং ক্লোজ হলে যুক্তিযুক্ত স্থানে ফিরে আসা উচিত। Escape প্রয়োজনমত ওভারলে বন্ধ করা উচিত।
  5. প্রতি পরিবর্তনের পরে আবার পরীক্ষা করুন। একটি সমস্যা সংশোধন করুন, তারপর একই পথ পুনরায় চালান। কি উন্নতি হয়েছে এবং কি খারাপ হয়েছে তা নোট করুন, বিশেষত ফোকাস অর্ডার পরিবর্তন ও নতুন "ডেড এন্ড"-এর জন্য।

কী কী রেকর্ড করবেন

সাদাসিধে রাখুন: পেজের নাম, আপনি কী চাপলেন, কী ঘটল, এবং আপনি কী আশা করেছিলেন। সেই ছোট লগটি সহজেই নিশ্চিত করে যে একটি React রিফ্যাক্টর বা Flutter উইজেট বদল কীবোর্ড অ্যাক্সেস চুপচাপ ভাঙেনি।

স্ক্রীন রিডার-ফ্রেন্ডলি নাম, লেবেল, ও ঘোষণা

স্ক্রীন রিডার আপনার UI “দেখে” না—তারা নাম, রোল, এবং সংক্ষিপ্ত বার্তা নির্ভর করে যে কী পরিবর্তন হয়েছে। যদি নাম অনুপস্থিত বা অস্পষ্ট হয়, অ্যাপটা অনুমানে পরিণত হয়।

ফর্ম ফিল্ড থেকে শুরু করুন। প্রতিটি ইনপুটের একটি আসল লেবেল থাকা দরকার যা ফিল্ড পূরণ হওয়ার পরও সত্য থাকে। প্লেসহোল্ডার হলো হিন্ট, লেবেল নয়—এটি টাইপ করতে শুরু করলে অদৃশ্য হয়ে যায়।

আইকন-ওনলি অ্যাকশনও সাধারণত মিস হয়। একটি ট্র্যাশ আইকন, পেনসিল, বা থ্রি-ডট মেনু একটা অর্থবহ নাম চাইবে যা আউটকামটি ব্যাখ্যা করে, আকৃতিটি নয়। “Delete project” বলতে বোঝায় কী হবে—“Button” বা “Trash” বলার চাইতে ভালো।

হেডিং ও সেকশন লেবেলগুলোর গুরুত্ব আছে কারণ সেগুলো পেজ আউটলাইন হয়। হেডিংগুলো স্টাইলিং নয়, স্ট্রাকচার প্রতিফলিত করবে। স্ক্রীন রিডার ব্যবহারকারী “Billing” বা “Team members” খুঁজতে হেডিং-এ জাম্প করবে, তাই সেই লেবেলগুলো কন্টেন্টের সাথে মিলে যেতে হবে।

এরর মেসেজগুলো স্পেসিফিক ও অ্যাকশানব orientación হওয়া দরকার। “Invalid input” পর্যাপ্ত নয়। বলুন কী ভুল হয়েছে এবং এরপর কী করতে হবে, যেমন “Password must be at least 12 characters” অথবা “Email address is missing the @ sign”.

কপি-পেস্ট রিভিউ প্রম্পট (React ও Flutter)

রিভিউ করার সময়ে (বা যখন আপনি Koder.ai-কে কম্পোনেন্ট আপডেট করতে বলবেন) এই প্রম্পটগুলো ব্যবহার করুন:

  • “Go through this screen and ensure every text input has a visible label, and that the accessible name matches it (React: label + htmlFor, aria-labelledby; Flutter: InputDecoration.labelText).”
  • “Find icon-only buttons and give each an accessible name that explains the action (React: aria-label; Flutter: Tooltip or Semantics(label: ...)).”
  • “Check headings: use proper heading levels in React, and clear section titles in Flutter so the structure reads correctly.”
  • “Rewrite validation errors so they say what happened and how to fix it, and make sure the error is announced when it appears.”

ডাইনামিক আপডেটের জন্য ঘোষণা

অনেক স্ক্রিন রিলোড ছাড়া পরিবর্তন হয়: প্রোফাইল সেভ করা, আইটেম যোগ করা, রেজাল্ট লোড করা। নিশ্চিত করুন এই আপডেটগুলো ঘোষনা করা হয়।

React-এ, aria-live রিজিয়ন ব্যবহার করুন (polite সাধারণ সেভ বার্তার জন্য, assertive গুরুতর এররের জন্য)। Flutter-এ Semantics ব্যবহার করুন এবং স্ট্যাটাস মেসেজগুলো দৃশ্যমান রাখুন (উদাহরণ: একটি ব্যানার বা SnackBar) যাতে সেগুলো পড়ে যায়, কেবল দেখানো নয়। একটি দ্রুত চেক: “Save” ট্রিগার করুন, এবং নিশ্চিত করুন আপনি একটি সংক্ষিপ্ত বার্তা শুনছেন যেমন “Changes saved” আপডেট হওয়ার সময় ফোকাস সেখানে থেকে সরে যায় না।

কনট্রাস্ট ও ভিজ্যুয়াল স্পষ্টতার দ্রুত চেক

Scale your build pace
Upgrade when you need more capacity for frequent UI iterations and review cycles.

আপনি যদি ফোকাস রাখেন সেসব জায়গাগুলোর ওপর যেখানে মানুষটি আসলে সংগ্রাম করে, আপনি কয়েক মিনিটেই বেশিরভাগ কনট্রাস্ট সমস্যা ধরতে পারবেন: ছোট টেক্সট, আইকন, ফোকাস রিং, এবং স্ট্যাটাস রঙ। এই অংশটি React ও Flutter UI রিভিউর অ্যাক্সেসিবিলিটি প্রম্পটের জন্য ব্যবহারিক কারণ এটা যাচাই করা সহজ এবং ঠিক করা সহজ।

10-মিনিটের কনট্রাস্ট পাস

একটা স্ক্রিন 100% জুমে স্ক্যান করে শুরু করুন, তারপর 200% এ। কিছু পড়তে কষ্ট হলে, সাধারণত সেটা কনট্রাস্ট, ওয়েট, বা স্পেসিং সমস্যা—ব্যবহারকারীর সমস্যা নয়।

প্রথমে এই পাঁচটি জায়গা চেক করুন:

  • বডি টেক্সট, ক্যাপশন, ও হেল্পার টেক্সট (বিশেষ করে হালকা ধূসর সাদার উপরে)
  • ডিসেবলড স্টেট (ডিসেবলড দেখাবে ঠিক, তবু পড়তে সহজ থাকা উচিত)
  • লেবেলহীন আইকন (নাজুক আইকন অনেক ব্যবহারকারীর জন্য কার্যত অদৃশ্য)
  • ফোকাস সূচক (রিং/আউটলাইন ব্যাকগ্রাউন্ড থেকে আলাদা হওয়া উচিত)
  • এরর ও সাকসেস মেসেজ (শুধু রঙ নয়, টেক্সট ও আইকনও থাকা উচিত)

একটি দ্রুত রুল-অফ-থাম্ব: যদি আপনাকে ঝাপসা করতে হয়, আপনার ব্যবহারকারীদেরও হবে। যদি আপনি কোনো কালার পেয়ার নিয়ে নিশ্চিত না হন, অস্থায়ভাবে টেক্সটকে বিশুদ্ধ ব্ল্যাক বা হোয়াইটে বদলান—যদি রিডেবিলিটি অনেক বেড়ে যায়, আপনার কনট্রাস্ট কম ছিল।

ফোকাস দৃশ্যমানতা প্রায়ই মিস হয়। নিশ্চিত করুন ফোকাস আউটলাইন যথেষ্ট মোটা এবং ব্যাকগ্রাউন্ডের সাথে একই রঙ নয়। যদি কোনো লিস্টে “selected” স্টেট থাকে, তা গ্রেস্কেলে দেখিয়ে আলাদা হওয়া উচিত—উদাহরণস্বরূপ একটি আইকন, আন্ডারলাইন, বা স্পষ্ট বর্ডার যোগ করে।

মোবাইল স্পষ্টতা: টার্গেট ও থিম

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

দ্রুত থিম-সুইপ করুন: ডার্ক মোড অন/অফ করুন, এবং যদি আপনার অ্যাপ হাই কনট্রাস্ট সাপোর্ট করে, সেটা টেস্ট করুন। সারফেস, ডিভাইডার, ও ফোকাস রিং-এর উপরে টেক্সট চেক করুন। সাধারণ বাগ: ডার্ক মোডে ফোকাস রিং অদৃশ্য হয়ে যাওয়া বা “inactive” আইকন ব্যাকগ্রাউন্ডের সঙ্গে প্রায় একই রঙ হয়ে যাওয়া।

আপনি যদি Koder.ai-তে দ্রুত UI জেনারেট করেন, প্রথম লেআউটের পরে এক অতিরিক্ত রিভিউ ধাপ যোগ করুন: “contrast and focus ring pass” বলুন, ভিজ্যুয়াল পরিশোধনের আগে।

সাধারণ ভুলগুলো যা বারবার ফিরে আসে

অধিকাংশ অ্যাক্সেসিবিলিটি বাগ বারবার আসে কারণ সেগুলো ছোট UI টুইক মনে হয়, বড় প্রোডাক্ট বিহেভিয়র নয়। যখন আপনি React ও Flutter UI রিভিউর জন্য প্রম্পট চালান, প্রথমে এই প্যাটার্নগুলোর দিকে নজর দিন।

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

ফোকাস স্টাইল সরিয়ে ফেলা হয় কারণ “এগুলো কোলাহল লাগায়।” সেটা কীবোর্ড ব্যবহারকারীদের হারিয়ে দেয়। যদি আপনি ডিফল্ট আউটলাইন পরিবর্তন করেন, এরকম কিছু স্পষ্ট দিয়ে প্রতিস্থাপন করুন: একটি শক্তিশালী রিং, ব্যাকগ্রাউন্ড পরিবর্তন, এবং পেজের সাথে পর্যাপ্ত কনট্রাস্ট।

আরেকটি সাধারণ ভুল ফেক বাটন ব্যবহার করা। React-এ div-এর উপর onClick ব্যবহার করা লোভনীয়, এবং Flutter-এ Container+GestureDetector। সঠিক সেম্যান্টিক ছাড়া কীবোর্ড সাপোর্ট ও স্ক্রীন রিডার ক্ষতিগ্রস্ত হয়। নেটিভ কন্ট্রোল (button, a, TextButton, ElevatedButton) আপনাকে ফোকাস, রোল, ডিসেবেলড স্টেট, এবং অ্যাক্টিভেশন বিহেভিয়ার ফ্রি-তে দেয়।

ডায়ালগ ও ফর্ম ফোকাস বাগগুলো সূক্ষ্ম কিন্তু কষ্টদায়ক। মডাল-closing বা ফর্ম সেভ করার পরে ফোকাস প্রায়শই পেজের শীর্ষে লাফিয়ে যায় বা অদৃশ্য হয়। সেটা ঘটে যখন ফোকাস ট্রিগার কন্ট্রোলে পুনরায় রিস্টোর করা হয় না, বা সেভ অ্যাকশন স্ক্রিনকে রেন্ডার করে এবং ফোকাস হারায়। পরে ব্যবহারকারীকে আবার শুরু করে যেখানে ছিলো খুঁজে নিতে হয়।

অতিরিক্ত ARIA (বা Flutter Semantics) ব্যবহার করাও জিনিসগুলো ভাঙাতে পারে। সর্বত্র রোল ও লেবেল যোগ করলে নেটিভ উপাদান যা দিয়ে দেয় তার সাথে কনফ্লিক্ট হতে পারে, ডবল ঘোষণা বা ভুল নাম হতে পারে।

একটি দ্রুত “আবার দেখা সমস্যা” চেক যা আপনি রিভিউ করলে চাইতে পারেন:

  • নিশ্চিত করুন প্রতিটি ইনপুটের একটি স্থায়ী লেবেল আছে, কেবল প্লেসহোল্ডার নয়
  • নিশ্চিত করুন প্রতিটি ইন্টারেকটিভ উপাদান একটি বাস্তব কন্ট্রোল এবং সঠিক রোল আছে
  • নিশ্চিত করুন ফোকাস সবসময় দৃশ্যমান এবং প্রতিস্থাপন ছাড়া সরানো হয় না
  • নিশ্চিত করুন ডায়ালগ, টোস্ট, ও সেভের পরে ফোকাস ট্রিগার-এ ফিরে আসে
  • নিশ্চিত করুন ARIA/Semantics কেবল সেই জিনিস যোগ করে যা নেটিভ কন্ট্রোল দিতে পারে না

আপনি যদি চ্যাট থেকে UI জেনারেট করেন (উদাহরণ Koder.ai), আপনার প্রাম্পটে এসব গ্রহণযোগ্যতা ক্রাইটেরিয়া যোগ করুন যাতে প্রথম খসড়া থেকেই সাধারণ ফাঁদগুলো এড়িয়ে যায়।

উদাহরণ ওয়াক-থ্রু: এক স্ক্রিন, end-to-end

Bake checks into generation
Ask Koder.ai to check keyboard access, focus order, and screen reader names as it builds.

ধরা যাক একটি সরল Settings স্ক্রিন: একটি প্রোফাইল ফর্ম (Name, Email), দুইটি টগল (Email notifications, Dark mode), একটি “Save changes” বোতাম, এবং সেভ করার পরে একটি টোস্ট।

কীবোর্ড দিয়ে শুরু করুন। প্রত্যাশিত ফোকাস অর্ডার ভিজ্যুয়াল ক্রমের সাথে মিলতে হবে—টা-পটু-বটম, লেফট-টু-রাইট। Tab করা কখনও টোস্ট এরিয়া, ফুটার, বা লুকানো মেনুতে লাফ করা উচিত নয়।

একটি দ্রুত পাস যা বেশিরভাগ রিভিউ কেসে কাজ করে:

  • ট্যাব চাপুন উপরের দিক থেকে: ফোকাস Name-এ, তারপর Email-এ, তারপর Email notifications টগল, তারপর Dark mode টগল, তারপর Save changes-এ।
  • Shift+Tab করে ফিরে যান এবং নিশ্চিত করুন এটি সঠিকভাবে উল্টোভাবে চলে।
  • টগলের উপর Space চাপলে সেটি টগল করা উচিত। অ্যারো কী ফোকাস আটকে রাখতে থাকা উচিত নয়।
  • Save changes-এ Enter সাবমিট করা উচিত, এবং সাবমিটের পরে ফোকাস অদৃশ্য হয়ে যায় না।
  • টোস্ট দেখলে, যতক্ষণ না তা অ্যাকশনের প্রয়োজন ততক্ষণ ফোকাস যেখানে ছিলো সেখানেই থাকা উচিত।

এখন চেক করুন স্ক্রীন রিডার কী ঘোষণা করে। প্রতিটি কন্ট্রোলের পরিষ্কার নাম, রোল, এবং স্টেট থাকা দরকার। উদাহরণ: “Name, text field, required” এবং “Email notifications, switch, on”। যদি Email ফিল্ডে এরর থাকে, তাহলে এটি তখনও ঘোষণা করা উচিত যখন ফোকাস ফিল্ডে আসে এবং যখন এরর দেখা দেয় (উদাহরণ: “Email, text field, invalid, Enter a valid email address”)। Save বোতাম বলা উচিত “Save changes, button” এবং শুধুমাত্র তখনই ডিসেবলড দেখাতে হবে যখন আপনি কেন তা ডিসেবলড তা জানাচ্ছেন।

কনট্রাস্টের জন্য, ন্যূনতম টেক্সট, প্লেসহোল্ডার টেক্সট, এবং এরর মেসেজ চেক করুন। ফোকাস রিং দুটো থিমে স্পষ্ট দেখা উচিত। এরর স্টেট কেবল রঙের ওপর নির্ভর করা উচিত নয়—একটি আইকন বা স্পষ্ট টেক্সট দিন।

আপনার যা পাওয়া গেলো তা একটি শর্ট ফিক্স লিস্টে পরিণত করুন:

  • ফোকাস অর্ডার ঠিক করুন যাতে তা লেআউটের সাথে মেলে।
  • টগল ও আইকনগুলোর জন্য অনুপস্থিত অ্যাক্সেসিবল নাম যোগ করুন।
  • এররগুলো ফিল্ডের সাথে ঘোষণা করুন (শুধু ব্যানার না)।
  • ফোকাস স্টাইল ও কম কনট্রাস্ট প্লেসহোল্ডার/এরর টেক্সট উন্নত করুন।
  • টোস্টকে নন-ব্লকিং রাখুন, বা কেবল অ্যাকশনের জন্য ফোকাসযোগ্য করুন।

আপনি যদি Koder.ai-এ তৈরি করছেন, স্ক্রিনের বর্ণনা এবং আপনার খুঁজে পাওয়া বিষয়গুলো চ্যাটে পেস্ট করুন এবং জিজ্ঞাসা করুন React অথবা Flutter UI আপডেট করতে যাতে প্রত্যাশিত কীবোর্ড ও স্ক্রীন রিডার আচরণ মেলে।

পরবর্তী ধাপ: এই চেকলিস্টটা পুনরায় ব্যবহার করুন এবং আপনার ওয়ারফ্লোতে বেক করুন

যদি আপনি চান React এবং Flutter UI রিভিউর জন্য এসব অ্যাক্সেসিবিলিটি প্রম্পট দীর্ঘমেয়াদি কাজে লাগুক, সেগুলোকে এককালীন ক্লিনআপ না ভেবে একটি নিয়মিত অভ্যাস হিসেবে বিবেচনা করুন। লক্ষ্য হচ্ছে প্রতিবার একটি নতুন স্ক্রিন বা কম্পোনেন্ট যোগ করলে একই ছোট সেটের চেক চালানো।

UI পরিবর্তনের জন্য একটি একক “definition of done” রাখুন। কিছু শিপ করার আগে দ্রুত একটি পাস করুন যা কীবোর্ড, ফোকাস, নাম, এবং কনট্রাস্ট কভার করে। বারবার করলে এটা মিনিটেই হয়ে যায়।

প্রায় সব UI-তে চালানোর জন্য একটি দ্রুত চেকলিস্ট:

  • কীবোর্ড: আপনি কি প্রতিটি ইন্টারেকটিভ উপাদান পর্যন্ত পৌঁছতে ও মাউস ছাড়া ব্যবহার করতে পারেন?
  • ফোকাস: ফোকাস দৃশ্যমান কি, এবং কি তা যুক্তিযুক্তভাবে চলে?
  • লেবেল: প্রতিটি ফিল্ড ও বোতামের একটি পরিষ্কার নাম আছে কি (আইকনসহ)?
  • ঘোষণা: স্টেট পরিবর্তনগুলো ঘোষণা হয় কি (এরর, লোডিং, সাকসেস)?
  • কনট্রাস্ট: টেক্সট পাঠযোগ্য কি এবং ডিসেবলড স্টেটগুলোও বোঝার যোগ্য?

আপনার শ্রেষ্ঠ প্রম্পটগুলো টেমপ্লেট হিসেবে সংরক্ষণ করুন। সহজ উপায়—প্রতিটি পরিবর্তনের শেষে পেস্ট করার জন্য একটি “React review prompt” ও একটি “Flutter review prompt” রাখুন। তারপর একটি লাইন যোগ করুন যা নতুন কম্পোনেন্টটি বর্ণনা করে এবং কোনো বিশেষ আচরণ (মডাল, স্টেপার, ইনফাইনাইট স্ক্রল লিস্ট) উল্লেখ করে।

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

যদি আপনি Koder.ai-এ নির্মাণ করেন, প্রম্পটগুলো চ্যাটে পেস্ট করুন এবং নির্দিষ্ট ফিক্স চাইুন, সাধারণ উন্নতির না। তারপর planning mode ব্যবহার করে ইমপ্যাক্ট রিভিউ করুন পরিবর্তন প্রয়োগ করার আগে। অ্যাক্সেসিবিলিটি পাসের আগে একটি স্ন্যাপশট নিন, এবং যদি কোনো ফিক্স লেআউট বা বিহেভিয়ার ভেঙে দেয় তবে rollback ব্যবহার করুন। এর ফলে ফোকাস অর্ডার ও সেমান্টিকস নিয়ে নিরাপদে ইটারেট করা যায়।

অ্যাক্সেসিবিলিটি পাসের পরে, আপনি এটাকে একটি রিলিজ গেটের মতো ব্যবহার করতে পারেন: সোর্স কোড এক্সপোর্ট করে আপনার রেপো ওয়ার্কফ্লোতে জোড়া দিন, অথবা অ্যাপ ডিপ্লয় করে আপডেটেড UI হোস্ট করুন এবং কাস্টম ডোমেইন সংযুক্ত করুন যখন আপনি ফলাফল নিয়ে সন্তুষ্ট হন।

সাধারণ প্রশ্ন

অ্যাক্সেসিবিলিটির জন্য প্রথমে কোন স্ক্রিনগুলো পর্যালোচনা করা উচিত?

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

শুধু কিবোর্ড ব্যবহার করে UI কীভাবে পরীক্ষা করব?

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

কোন বিষয়টি ফোকাসের ক্রমকে যৌক্তিক করে?

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

বাটন ও ফর্ম ফিল্ডে কীভাবে লেবেল দেওয়া উচিত?

সম্ভব হলে প্রতিটি কন্ট্রোলকে স্পষ্ট দৃশ্যমান লেবেল দিন। শুধু আইকন থাকা অ্যাকশনের জন্য এমন একটি অ্যাক্সেসিবল নাম ব্যবহার করুন যা ফলাফল বর্ণনা করে, যেমন আইকনের নাম দেওয়ার বদলে «প্রজেক্ট মুছুন»।

প্লেসহোল্ডার টেক্সট কি ফর্ম লেবেলের বিকল্প হতে পারে?

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

মডাল বা ডায়ালগে ফোকাসের কী হওয়া উচিত?

খোলা ডায়ালগে ফোকাস নিয়ে যান, এটি খোলা থাকা অবস্থায় কিবোর্ড ফোকাস এর ভেতরেই রাখুন, এবং বন্ধ হলে ফোকাস আবার ট্রিগারে ফিরিয়ে দিন। ইন্টারঅ্যাকশনের সঙ্গে মানানসই হলে Escape দিয়ে ডায়ালগ বন্ধ করতে দিন।

কখন আমার অ্যাপের স্ক্রিন রিডারকে পরিবর্তনের ঘোষণা দেওয়া উচিত?

ভ্যালিডেশন ত্রুটি, লোডিং স্ট্যাটাস ও সংরক্ষিত পরিবর্তনের মতো গুরুত্বপূর্ণ আপডেট ঘোষণা করুন। React-এ সংক্ষিপ্ত স্ট্যাটাস বার্তার জন্য একটি aria-live অঞ্চল ব্যবহার করুন; Flutter-এ দৃশ্যমান স্ট্যাটাস টেক্সটকে Semantics-এর মাধ্যমে প্রকাশ করুন এবং স্ক্রিন রিডার সেটি পড়ে কি না পরীক্ষা করুন।

কনট্রাস্ট ও ভিজ্যুয়াল স্বচ্ছতা যাচাই করার দ্রুততম উপায় কী?

হালকা ও গাঢ়, উভয় থিমেই ছোট টেক্সট, সহায়ক টেক্সট, নিষ্ক্রিয় অবস্থা, আইকন, ত্রুটি বার্তা এবং ফোকাস রিং পরীক্ষা করুন। ২০০% জুম করে কনটেন্ট কাটা পড়ে কি না, ওভারল্যাপ হয় কি না, বা কন্ট্রোল ব্যবহার করা কঠিন হয়ে যায় কি না দেখুন।

অ্যাক্সেসযোগ্য নয় এমন কাস্টম বাটন ও জেসচার কীভাবে এড়াব?

প্রথমে নেটিভ কন্ট্রোল ব্যবহার করুন। React-এ ক্লিকযোগ্য div-এর বদলে button ও link এলিমেন্টকে অগ্রাধিকার দিন। Flutter-এ অ্যাকশনের সঙ্গে মানানসই হলে raw GestureDetector-এর বদলে IconButton, InkWell, ListTile ও SwitchListTile-এর মতো উইজেট ব্যবহার করুন।

অ্যাক্সেসিবিলিটি পর্যালোচনার প্রম্পটে কী অন্তর্ভুক্ত করা উচিত?

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

Related posts