Windows অ্যাপ অ্যাক্সেসিবিলিটির পরিচিতি — UI Automation ও যুক্তিসঙ্গত সমন্বয়ের প্রয়োজনীয়তার প্রস্তুতি

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

একটি পটভূমি আইনি কাঠামো। প্রতিবন্ধী ব্যক্তিদের প্রতি বৈষম্য নির্মূল আইনের ২০২১ সংশোধন ১ এপ্রিল ২০২৪ থেকে কার্যকর হয়েছে, আর প্রতিবন্ধী ব্যক্তিদের "যুক্তিসঙ্গত সমন্বয় দেওয়া" ব্যবসার জন্যও বাধ্যতা হয়ে গেছে।¹ আরও, কর্মচারী–কোম্পানি সম্পর্ক যেমন খোলার উদাহরণ (কর্মসংস্থান ক্ষেত্র) প্রতিবন্ধী ব্যক্তিদের কর্মসংস্থান প্রসার আইনের এলাকা, যা এপ্রিল ২০১৬ থেকে নিয়োগকর্তাদের যুক্তিসঙ্গত সমন্বয় দিতে বাধ্য করেছে।² "অ্যাক্সেসিবিলিটি ওয়েবসাইট বিষয় এবং ইন-হাউস Windows অ্যাপের সাথে কোনো সম্পর্ক নেই" — এই ধারণা আর আইনগতভাবেও দাঁড়ায় না, বাস্তবেও না।

অন্যদিকে, উন্নয়ন তলা থেকে "কী করব জানি না" সৎ জায়গা। Windows ডেস্কটপ অ্যাপের অ্যাক্সেসিবিলিটিতে ওয়েবের চেয়ে কম তথ্য আছে, আর কোনো জাদুকরী পরবর্তী সমাধান নেই। হতাশ হওয়ারও দরকার নেই। স্ক্রিন রিডার অ্যাপ কীভাবে পড়ে (UI Automation) তা বুঝলে এবং নাম, কীবোর্ড ও রঙের ভিত্তি গ্রহণ করলে ব্যবসায়িক অ্যাপের ব্যবহারযোগ্যতা যথেষ্ট উন্নত হয়। আর তার অনেকটাই প্রতিবন্ধকতা থাকুক বা না থাকুক প্রতিটি ব্যবহারকারীর উৎপাদনশীলতা বাড়ায়।

জাপানি ব্যবসায়িক অ্যাপ ডেভেলপার ও আইটি স্টাফের জন্য এই নিবন্ধ আইনি কাঠামো ও মানদণ্ডের ন্যূনতম ছাঁটাই থেকে, UI Automation-এর ব্যবস্থা, WinForms/WPF বাস্তবায়ন, কীবোর্ড পরিচালনা, রং ও কনট্রাস্ট, এবং যাচাই সরঞ্জাম হয়ে অগ্রাধিকার নির্ধারণের বাস্তব পথ পর্যন্ত একই প্রবাহে জোড়ে।

flowchart TB
    accTitle: এই নিবন্ধের প্রবাহ
    accDescr: এই নিবন্ধের কাঠামো, আইনি কাঠামো ও মানদণ্ডের ছাঁটাই থেকে UI Automation-এর ব্যবস্থা, WinForms ও WPF বাস্তবায়ন, কীবোর্ড পরিচালনা, রং ও কনট্রাস্ট, যাচাই সরঞ্জাম, এবং অগ্রাধিকার নির্ধারণ পর্যন্ত ক্রমে জোড়ে
    law["আইনি কাঠামো ও মানদণ্ড ছাঁটাই"] --> uia["UI Automation-এর ব্যবস্থা"]
    uia --> impl["WinForms/WPF বাস্তবায়ন"]
    impl --> kb["কীবোর্ড পরিচালনা"]
    kb --> color["রং ও কনট্রাস্ট"]
    color --> verify["যাচাই সরঞ্জাম"]
    verify --> prio["অগ্রাধিকার কীভাবে ঠিক করবেন"]

চিত্র ১: এই নিবন্ধ আইনি কাঠামোকে ব্যবস্থা, বাস্তবায়ন, যাচাই ও অগ্রাধিকারের সাথে একই প্রবাহে জোড়ে।

১. আগে উপসংহার

• যুক্তিসঙ্গত সমন্বয় দেওয়া ১ এপ্রিল ২০২৪ থেকে ব্যবসার জন্যও বাধ্যতা। প্রতিবন্ধী ব্যক্তি বাধা সরানোর ইচ্ছা দেখালে, অতিরিক্ত ভার নয় এমন সীমায় প্রতিক্রিয়া চাই। কর্মসংস্থান ক্ষেত্র প্রতিবন্ধী ব্যক্তিদের কর্মসংস্থান প্রসার আইনের অধীন, আর সেটি এপ্রিল ২০১৬ থেকে নিয়োগকর্তা বাধ্যতা।¹²
• যুক্তিসঙ্গত সমন্বয় "ব্যক্তিগত অনুরোধের গঠনমূলক সংলাপ দিয়ে উত্তর" প্রক্রিয়া; অ্যাপকে আগে সহজ করা "পরিবেশ উন্নয়ন" (প্রচেষ্টা-বাধ্যতা)। পূর্ণ আগাম সহায়তা বাধ্যতা নয়; মানে সংলাপ একতরফা প্রত্যাখ্যান করবেন না।¹
• অ্যাক্সেসিবিলিটির প্রযুক্তিগত মানদণ্ড WCAG (JIS X 8341-3:2016)-এ কেন্দ্রীভূত। JIS X 8341-3:2016 WCAG 2.0-এর সমান-বিষয় সংগত মান, আর W3C-এর WCAG2ICT নন-ওয়েব সফটওয়্যারে প্রয়োগের নির্দেশনা দেয়। ডেস্কটপ অ্যাপ একই চিন্তায় যাচাই করা যায়।³⁴
• স্ক্রিন রিডার অ্যাপকে UI Automation (UIA) দিয়ে পড়ে। UIA ট্রিতে প্রতিটি উপাদানের বৈশিষ্ট্য — Name, ControlType ইত্যাদি — এবং Invoke, Value, SelectionItem-এর মতো কন্ট্রোল প্যাটার্ন ঘোষণা ও পরিচালনার বিষয়।⁵
• যে বোতামের Name খালি সেটি শুধু "বোতাম" ঘোষিত হয়। সর্বোচ্চ-অগ্রাধিকার সংশোধন নামকরণ। WinForms AccessibleName ও Label-কে ট্যাব ক্রমে জোড়া ব্যবহার করে; WPF AutomationProperties.Name/LabeledBy।⁶⁷
• প্রতিটি ফাংশন শুধু কীবোর্ড থেকে পৌঁছানো WCAG সাফল্য মানদণ্ড (২.১.১) এবং সঙ্গে দক্ষ পরিচালকের ইনপুট গতি নিজেই। ট্যাব ক্রম, অ্যাক্সেস কী ও ফোকাস ইঙ্গিত রাখা প্রতিটি ব্যবহারকারীর দক্ষতার সাথে সরাসরি জোড়ে।⁸
• পাঠ্য কনট্রাস্ট অনুপাত ৪.৫:১ বা তার বেশি গাইড ধরুন, আর তথ্য শুধু রং দিয়ে পৌঁছাবেন না। কনট্রাস্ট থিমে (উচ্চ কনট্রাস্ট) হার্ড-কোড রঙের বদলে সিস্টেম রং সম্মান করুন।⁸⁹
• যাচাইকে Accessibility Insights for Windows-এর FastPass ও স্ক্রিন রিডার দিয়ে হাতে-কলমে পরীক্ষার সাথে জোড়ুন। কারণ তারা একই UIA ভিত্তিতে, এই কাজ FlaUI-এর মতো UI স্বয়ংক্রিয়-পরীক্ষা সম্পদের সাথেও পারস্পরিক লাভ দেয়।¹⁰
• প্রতিটি স্ক্রিন একসাথে ঠিক করার দরকার নেই। বাস্তব ক্রম (১) যে স্ক্রিনগুলো সেই ব্যবহারকারী ব্যবহার করেন সেগুলো থেকে, (২) নতুন উন্নয়ন মানক-অনুযায়ী, (৩) ভাগ করা কন্ট্রোল ঠিক করে পাশে ছড়ান।

এক বাক্যে: অ্যাক্সেসিবিলিটি সহায়তা "UIA ট্রিতে সঠিক নাম ও পরিচালনা প্রকাশ করা, এবং কীবোর্ড ও রঙের ভিত্তি রাখা"।

২. আইনি কাঠামো ও মানদণ্ডের ছাঁটাই — "বাধ্যতা হয়ে গেল" জিনিস কী বদলাল

২.১. প্রতিবন্ধী ব্যক্তিদের প্রতি বৈষম্য নির্মূল আইন — এপ্রিল ২০২৪ থেকে ব্যবসাও যুক্তিসঙ্গত সমন্বয় দিতে বাধ্য

প্রতিবন্ধী ব্যক্তিদের প্রতি বৈষম্য নির্মূল আইন সেই আইন যা প্রশাসনিক অঙ্গ ও ব্যবসা দ্বারা প্রতিবন্ধী ব্যক্তিদের "অন্যায্য বৈষম্যমূলক আচরণ" নিষিদ্ধ করে, এবং "যুক্তিসঙ্গত সমন্বয় দেওয়া" প্রত্যাশা করে। ২০২১ (রেইওয়া ৩) সংশোধনে ব্যবসা দ্বারা যুক্তিসঙ্গত সমন্বয় দেওয়া, যা প্রচেষ্টা-বাধ্যতা ছিল, বাধ্যতা হয়ে গেছে, আর সংশোধিত আইন ১ এপ্রিল ২০২৪ (রেইওয়া ৬) থেকে কার্যকর হয়েছে।¹

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

এখানে দুটি বাস্তব পার্থক্য গুরুত্বপূর্ণ।

1. "আগে থেকে সব কিছু জায়গায় রাখা" যা বাধ্যতা হয়ে গেছে তা নয়। অনির্দিষ্ট সংখ্যক প্রতিবন্ধী ব্যক্তির লক্ষ্যে আগাম উন্নয়ন — ম্যানুয়াল পর্যালোচনা ও প্রশিক্ষণের মতো নরম দিক, সুবিধা বাধামুক্ত করার মতো শক্ত দিক — "পরিবেশ উন্নয়ন" বলা হয়, আর এটি প্রচেষ্টা-বাধ্যতা।¹ ব্যবসায়িক অ্যাপকে আগে থেকে স্ক্রিন রিডার দিয়ে ব্যবহারযোগ্য অবস্থায় রাখা পরিবেশ-উন্নয়ন প্রচেষ্টা হিসেবে ভাবা যায়। পরিবেশ উন্নয়ন যত এগিয়েছে, ব্যক্তিগত যুক্তিসঙ্গত সমন্বয় দেওয়ার ভার তত হালকা।
2. কর্মসংস্থান ক্ষেত্র প্রতিবন্ধী ব্যক্তিদের প্রতি বৈষম্য নির্মূল আইনের অধীন নয় বরং প্রতিবন্ধী ব্যক্তিদের কর্মসংস্থান প্রসার আইনের অধীন। একই লিফলেট বলে কর্মসংস্থান ও কাজ কর্মসংস্থান প্রসার আইনের বিধান অনুসরণ করে।¹ আর সেই আইনে, এপ্রিল ২০১৬ (হেইসেই ২৮) থেকে কার্যকর সংশোধন দিয়ে, কর্মসংস্থানে প্রতিবন্ধকতা বৈষম্য নিষেধ এবং অতিরিক্ত ভার নয় এমন সীমায় যুক্তিসঙ্গত সমন্বয় দেওয়া নিয়োগকর্তাদের বাধ্যতা।² খোলার পরামর্শ "কর্মচারী ব্যবসায়িক অ্যাপ ব্যবহার করতে পারেন না" প্রকৃতপক্ষে ২০২৪-এর অনেক আগে থেকেই বাধ্যতার এলাকায় আছে।

flowchart TB
    accTitle: যুক্তিসঙ্গত সমন্বয় ও পরিবেশ উন্নয়নের অবস্থান
    accDescr: সাধারণ ব্যবসা ও প্রতিবন্ধী ব্যক্তির সম্পর্ক বৈষম্য নির্মূল আইনের অধীন, আর ব্যক্তিগত অনুরোধে গঠনমূলক সংলাপ দিয়ে যুক্তিসঙ্গত সমন্বয় দেওয়া এপ্রিল ২০২৪ থেকে বাধ্যতা; কর্মসংস্থান ক্ষেত্র এপ্রিল ২০১৬ থেকে কর্মসংস্থান প্রসার আইনের অধীন নিয়োগকর্তা বাধ্যতা; অ্যাপকে আগে সহজ করা পরিবেশ উন্নয়ন, প্রচেষ্টা-বাধ্যতা
    scene{"কোন দৃশ্য?"}
    scene -->|ব্যবসা + প্রতিবন্ধকতা| kaisho["বৈষম্য আইন"]
    scene -->|কর্মসংস্থান / কাজ| koyou["কর্মসংস্থান আইন"]
    kaisho --> moushide["সংলাপ দিয়ে অনুরোধ"]
    moushide --> hairyo["সমন্বয় দিন"]
    hairyo -.-> hairyoN["২০২৪ থেকে বাধ্যতা"]
    koyou --> koyougimu["সমন্বয় দিন"]
    koyougimu -.-> koyouN["২০১৬ থেকে বাধ্যতা"]
    kaisho -.-> kankyo["আগে সহজ অ্যাপ"]
    kankyo -.-> kankyoN["পরিবেশ উন্নয়ন"]
    kankyoN -.-> kankyoN2["প্রচেষ্টা-বাধ্যতা"]
    kankyo -.-> moushide

চিত্র ২: শাসক আইন দৃশ্য অনুসারে ভাগে; যুক্তিসঙ্গত সমন্বয় বাধ্যতা, আর আগাম সংশোধন পরিবেশ উন্নয়ন, প্রচেষ্টা-বাধ্যতা।

কোনো ব্যক্তিগত ক্ষেত্র আইনে কীভাবে ধরা হয় পরিস্থিতির উপর নির্ভর করে। এই নিবন্ধ আইনি ব্যাখ্যায় পা দেয় না; প্রতিক্রিয়া চাওয়া হলে প্রকৌশলী কী করতে পারেন সেই দৃষ্টিকোণ থেকে এগোয়। প্রাথমিক উৎসের জন্য ক্যাবিনেট অফিস ও স্বাস্থ্য, শ্রম ও কল্যাণ মন্ত্রণালয়ের উপকরণ দেখুন।¹²

২.২. JIS X 8341-3 ও WCAG — "ওয়েব মানদণ্ড" সফটওয়্যারেও বিস্তৃত

প্রযুক্তিগত-মানদণ্ড পাশে তারা JIS X 8341-3:2016-এ কেন্দ্রীভূত। এই মান ISO/IEC 40500:2012-এর সংগত মান, আর মানের মূল অংশ W3C-এর WCAG 2.0-এর একই বিষয়।³ "অ্যাক্সেসিবিলিটি সহায়তা" কী নিয়ে গঠিত তা সুনির্দিষ্ট জানতে চাইলে WCAG সাফল্য মানদণ্ড (এখন WCAG 2.1/2.2-এ বিস্তৃত) পড়া সবচেয়ে ছোট পথ, আর WAIC-এর জাপানি অনুবাদও প্রকাশিত।⁸

"WCAG কি ওয়েব বিষয়বস্তুর মানদণ্ড?" প্রশ্ন ন্যায্য, কিন্তু W3C WCAG2ICT (Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies) নামক Group Note-এ সাজিয়েছে WCAG 2.0/2.1/2.2 সাফল্য মানদণ্ড নন-ওয়েব নথি ও সফটওয়্যারে কীভাবে প্রয়োগ করবেন।⁴ অর্থাৎ "পাঠ্য বিকল্প", "কনট্রাস্ট", "কীবোর্ড পরিচালনা", এবং "রং একমাত্র উপায় নয়" চিন্তা Windows ডেস্কটপ অ্যাপে ওয়েবের মতো একই কাঠামোতে প্রয়োগ করা যায়। এই নিবন্ধের অধ্যায় ৩ থেকে সেই চিন্তাকে সুনির্দিষ্ট WinForms/WPF বাস্তবায়নে নামিয়ে দেয়।

flowchart TB
    accTitle: JIS X 8341-3 ও WCAG-এর সম্পর্ক
    accDescr: JIS X 8341-3:2016 WCAG 2.0-এর সমান-বিষয় সংগত মান, আর WCAG2ICT দেখায় WCAG সাফল্য মানদণ্ড নন-ওয়েব সফটওয়্যারে কীভাবে প্রয়োগ করবেন, তাই Windows ডেস্কটপ অ্যাপ একই কাঠামোতে যাচাই করা যায়
    wcag["WCAG 2.0 （W3C）"] ---|সমান-বিষয় সংগত মান| jis["JIS X 8341-3:2016"]
    wcag --> ict["WCAG2ICT"]
    ict --> soft["নন-ওয়েব সফটওয়্যারে প্রয়োগ"]
    soft --> app["Windows ডেস্কটপ অ্যাপ"]

চিত্র ৩: JIS X 8341-3:2016 WCAG 2.0-এর সংগত মান, আর WCAG2ICT একই মানদণ্ড ডেস্কটপ অ্যাপে বিস্তৃত করে।

৩. সহায়ক প্রযুক্তি অ্যাপ কীভাবে পড়ে — UI Automation ত্রয়ী

৩.১. UIA ট্রি, বৈশিষ্ট্য ও কন্ট্রোল প্যাটার্ন

Windows-এ UI Automation (UIA) নামক অ্যাক্সেসিবিলিটি ভিত্তি তৈরি আছে। UIA এমন ব্যবস্থা যা স্ক্রিন রিডারের মতো সহায়ক প্রযুক্তিকে UI তথ্য পেতে এবং মানক ইনপুট ছাড়া অন্য উপায়ে UI পরিচালনা করতে দেয়, আর অ্যাপ পক্ষ (প্রোভাইডার) ও সহায়ক-প্রযুক্তি পক্ষ (ক্লায়েন্ট)-এর মধ্যে মধ্যস্থতা করে।⁵

UIA-এর জগত নিচের ত্রয়ী হিসেবে বোঝা যায়।⁵

স্ক্রিন রিডার কোনো বোতামে ফোকাস করলে "অর্ডার নিশ্চিত করুন বোতাম" ঘোষণা মোটামুটি Name + কন্ট্রোল ধরন-এর সংযোগ। ব্যবহারকারী "চালাও" কাজ করলে সহায়ক প্রযুক্তি Invoke প্যাটার্ন দিয়ে সেই বোতাম চাপে। অর্থাৎ Name ও প্যাটার্ন সঠিকভাবে প্রকাশিত থাকলে পড়া ও পরিচালনা যায়; প্রকাশ না থাকলে স্ক্রিনে দেখা গেলেও না-থাকার সমান।

flowchart TB
    accTitle: UI Automation ত্রয়ী
    accDescr: অ্যাপ প্রোভাইডার হিসেবে UIA ট্রিতে প্রতিটি উপাদানের বৈশিষ্ট্য ও কন্ট্রোল প্যাটার্ন প্রকাশ করে; স্ক্রিন রিডার ক্লায়েন্ট হিসেবে Name ও ControlType ঘোষণা করে এবং Invoke-এর মতো প্যাটার্ন দিয়ে পরিচালনা করে
    app["অ্যাপ （প্রোভাইডার）"] --> tree["UIA ট্রি"]
    tree --> prop["বৈশিষ্ট্য （Name, ControlType ইত্যাদি）"]
    tree --> pat["প্যাটার্ন （Invoke, Value ইত্যাদি）"]
    sr["স্ক্রিন রিডার （ক্লায়েন্ট）"] -->|ঘোষণা করে| prop
    sr -->|পরিচালনা করে| pat

চিত্র ৪: স্ক্রিন রিডার অ্যাপ UIA ট্রিতে যে বৈশিষ্ট্য ও প্যাটার্ন প্রকাশ করেছে সেগুলো ঘোষণা ও পরিচালনার জন্য ব্যবহার করে।

৩.২. স্ক্রিন রিডার একটি UIA ক্লায়েন্ট

Windows-এ ব্যবহৃত মূল স্ক্রিন রিডারের মধ্যে আছে Windows-এ তৈরি Narrator; বিনামূল্যে ওপেন সোর্স NVDA;¹¹ এবং জাপানে ব্যাপক ব্যবহৃত বাণিজ্যিক PC-Talker। ঘোষণার ধরন আলাদা, কিন্তু ডেস্কটপ অ্যাপের UI পড়ার প্রাথমিক পথ প্রতিটি ক্ষেত্রেই UIA। তাই অ্যাপ-পক্ষের প্রতিক্রিয়া "কোনো নির্দিষ্ট স্ক্রিন রিডারের সহায়তা" নয় বরং UIA-তে সঠিক তথ্য প্রকাশ-এ কেন্দ্রীভূত।

flowchart TB
    accTitle: মূল স্ক্রিন রিডারদের সাধারণ পথ
    accDescr: অ্যাপ UIA-তে সঠিক তথ্য প্রকাশ করলে Narrator, NVDA ও PC-Talker সবাই একই পথে UI পড়তে পারে, তাই অ্যাপ-পক্ষের প্রতিক্রিয়া নির্দিষ্ট স্ক্রিন রিডার নয় বরং UIA-তে প্রকাশে কেন্দ্রীভূত
    app["অ্যাপ"] -->|তথ্য প্রকাশ করে| uia["UI Automation （UIA）"]
    uia --> nar["Narrator"]
    uia --> nvda["NVDA"]
    uia --> pct["PC-Talker"]
    app -.-> goal["প্রতিক্রিয়া UIA-তে প্রকাশে কেন্দ্রীভূত"]

চিত্র ৫: মূল স্ক্রিন রিডাররা সবাই UIA-কে পথ ধরে, তাই অ্যাপের প্রতিক্রিয়া UIA-তে প্রকাশে কেন্দ্রীভূত।

৩.৩. "যে বোতামের নাম খালি" কীভাবে ঘোষিত হয়?

একটি সুনির্দিষ্ট উদাহরণ। ধরুন টুলবারে একটি সেভ বোতাম শুধু ফ্লপি-ডিস্ক আইকন দেখায়। দৃষ্টিসম্পন্ন ব্যবহারকারীর কাছে আইকন অর্থ পৌঁছায়, কিন্তু Name খালি থাকলে স্ক্রিন রিডার এই বোতাম শুধু "বোতাম" হিসেবে ঘোষণা করে। পাশের "খুলুন" ও "মুদ্রণ" একই হলে ব্যবহারকারী শুধু "বোতাম, বোতাম, বোতাম" শোনেন এবং কোনটি কোনটি জানার উপায় থাকে না। Microsoft-এর অ্যাক্সেসিবিলিটি-সংশোধন নির্দেশিকাও নামহীন বোতাম, এবং শুধু "Image" ঘোষিত ছবিকে, ব্যবহারকারীর কাজ থামানো প্রতিনিধি সমস্যা হিসেবে তালিকা করে।⁷

সৌভাগ্যক্রমে WinForms ও WPF উভয় মানক কন্ট্রোলে শুরু থেকেই UIA সহায়তা আছে, আর অনেক ক্ষেত্রে Name পাঠ্য বা লেবেল থেকে স্বয়ংক্রিয় সিদ্ধান্ত হয়। যা ভাঙে সাধারণত (১) আইকন-শুধু, নামের উপাদান নেই, (২) লেবেলের সাথে সংযোগ নেই, অথবা (৩) কাস্টম অঙ্কন যা UIA ট্রিতে তথ্য দেয় না। পরের দুই অধ্যায় ফ্রেমওয়ার্ক অনুসারে কীভাবে ঠিক করবেন দেখে।

flowchart TB
    accTitle: ঘোষণা ভাঙার তিনটি সাধারণ উপায়
    accDescr: ঘোষণা ভাঙে যখন আইকন-শুধু বলে নামের উপাদান নেই, যখন লেবেলের সাথে সংযোগ নেই, অথবা যখন কাস্টম অঙ্কন UIA ট্রিতে তথ্য দেয় না, আর শেষে শুধু বোতাম হিসেবে ঘোষিত হয়
    c1["আইকন-শুধু, উপাদান নেই"] --> broken["Name খালি হয়ে যায়"]
    c2["লেবেলের সাথে সংযোগ নেই"] --> broken
    c3["কাস্টম অঙ্কন তথ্য দেয় না"] --> broken
    broken --> result["শুধু বোতাম হিসেবে ঘোষিত"]

চিত্র ৬: ঘোষণা ভাঙা সাধারণত তিনটি প্যাটার্নের একটিতে নেমে আসে: নামের উপাদান অপর্যাপ্ত, সংযোগ অপর্যাপ্ত, অথবা কাস্টম অঙ্কন।

৪. WinForms-এ বাস্তবায়ন — AccessibleName ও ট্যাব ক্রম

৪.১. যে কন্ট্রোলের Text স্বয়ংক্রিয় Name হয়, আর যেগুলোর হয় না

WinForms-এ Button বা CheckBox-এর মতো পাঠ্য দেখানো কন্ট্রোল Text বৈশিষ্ট্যের মানকে UIA Name হিসেবে ব্যবহার করে। অন্যদিকে ComboBox, ListBox, ListView, PictureBox, ProgressBar, TabControl, TextBox, TreeView ইত্যাদি Text-কে Name করে না। এগুলোর অন্য উপায়ে নাম চাই।⁶

সবচেয়ে রক্ষণাবেক্ষণযোগ্য উপায় লক্ষ্য কন্ট্রোলের ঠিক আগের ট্যাব ক্রমে বর্ণনামূলক Label রাখা। লক্ষ্য কন্ট্রোলের TabIndex Label-এর TabIndex-এর ঠিক পরে আসলে সেই Label-এর পাঠ্য স্বয়ংক্রিয়ভাবে UIA Name হিসেবে ব্যবহৃত হয়। স্ক্রিনে দেখা লেবেল ও ঘোষণা মেলে, আর শব্দ দুবার পরিচালনা করতে হয় না।⁶¹²

Label রাখা না গেলে AccessibleName স্পষ্ট সেট করুন। সম্পূরক ব্যাখ্যা চাইলে AccessibleDescription, আর ভূমিকা চেহারার থেকে আলাদা হলে AccessibleRoleও সেট করা যায়।¹³

flowchart TB
    accTitle: WinForms কন্ট্রোলের নাম কীভাবে সিদ্ধান্ত হয়
    accDescr: Button ইত্যাদিতে Text যেমন-তেমন UIA Name হয়; TextBox-এর মতো কন্ট্রোলে যার Text পুনর্ব্যবহৃত হয় না, ঠিক আগের ট্যাব ক্রমে রাখা Label-এর পাঠ্য ব্যবহৃত হয়; Label রাখা না গেলে AccessibleName স্পষ্ট সেট করুন
    ctrl["কন্ট্রোল"] --> qtext{"যে ধরনের Text Name হয়?"}
    qtext -->|হ্যাঁ| usetext["Text যেমন-তেমন Name হয়"]
    qtext -->|না| qlabel{"ঠিক আগের ট্যাব ক্রমে Label?"}
    qlabel -->|হ্যাঁ| uselabel["Label-এর পাঠ্য Name হিসেবে ব্যবহৃত"]
    qlabel -->|না| explicit["AccessibleName স্পষ্ট সেট করুন"]

চিত্র ৭: WinForms Name-এর জন্য সিদ্ধান্ত ক্রম Text, ঠিক আগের ট্যাব ক্রমের Label, AccessibleName।

// An icon-only toolbar button: state the name for announcement explicitly
saveToolStripButton.AccessibleName = "Save";

// An image-only button: name + a supplementary explanation
btnSearchCustomer.AccessibleName = "Search customer";
btnSearchCustomer.AccessibleDescription = "Search the customer master by customer code or name";

// Set it directly on an input field where you cannot place a Label in the immediately preceding tab order
txtOrderNo.AccessibleName = "Order number";

// A PictureBox reused as a chart display: match the role to the reality as well
pictureBoxChart.AccessibleRole = AccessibleRole.Chart;
pictureBoxChart.AccessibleName = "Monthly order-count chart";

সতর্কতা হিসেবে, Visual Studio-এর Properties প্যানে AccessibleName একবার সেট করে তারপর খালি করলে ডিজাইনার ফাইলে খালি-স্ট্রিং সেটিং থেকে যেতে পারে এবং ডিফল্ট নাম সমাধানে বাধা দেয়। ডিজাইনার ফাইল থেকে সংশ্লিষ্ট লাইন মুছুন।⁶

flowchart TB
    accTitle: খালি-স্ট্রিং AccessibleName থেকে যাওয়ার সমস্যা
    accDescr: Properties প্যানে AccessibleName একবার সেট করে তারপর খালি করলে ডিজাইনার ফাইলে খালি-স্ট্রিং সেটিং থেকে যায় এবং ডিফল্ট নাম সমাধানে বাধা দেয়, তাই ডিজাইনার ফাইল থেকে সংশ্লিষ্ট লাইন মুছে ঠিক করেন
    set["AccessibleName সেট করুন"] --> erase["Properties প্যানে খালি করুন"]
    erase --> remain["খালি-স্ট্রিং সেটিং থেকে যায়"]
    remain --> block["ডিফল্ট নাম সমাধানে বাধা দেয়"]
    block -.-> fix["ডিজাইনার ফাইল থেকে সংশ্লিষ্ট লাইন মুছুন"]

চিত্র ৮: Properties প্যানে খালি করলেও খালি স্ট্রিং থেকে যায়, তাই ডিজাইনার ফাইল থেকে সংশ্লিষ্ট লাইন মুছে ঠিক করেন।

৪.২. অর্ডার-প্রবেশ স্ক্রিনে সাধারণ উন্নয়ন

ব্যবসায়িক অ্যাপে আমরা প্রকৃতপক্ষে যে জায়গাগুলো প্রায়ই ঠিক করি সেগুলো চেকলিস্ট হিসেবে সাজানো।

প্রতিটি কয়েক লাইনের সংশোধন, কিন্তু স্ক্রিন-রিডার ব্যবহারকারীর জন্য এটি "ব্যবহার করা যায় না এমন স্ক্রিন" ও "ব্যবহার করা যায় এমন স্ক্রিন"-এর দ্বিধা।

৫. WPF-এ বাস্তবায়ন — AutomationProperties ও AutomationPeer

৫.১. AutomationProperties.Name / LabeledBy / HelpText

WPF-এ Button-এর মতো কন্ট্রোল যার Content স্ট্রিং, সেই বিষয়বস্তুকে UIA Name হিসেবে ব্যবহার করে। আইকন-শুধু বোতামের (Image বা Path) Name-এর উপাদান নেই, তাই AutomationProperties.Name দিয়ে বলুন, অথবা কাছে প্রদর্শন পাঠ্য থাকলে AutomationProperties.LabeledBy দিয়ে জোড়ুন।⁷

TextBox-এ গুরুত্বপূর্ণ সতর্কতা আছে। TextBlock-এর Text Name হিসেবে পুনর্ব্যবহৃত হয়, কিন্তু TextBox-এর Text UIA Value বৈশিষ্ট্য পাশে প্রকাশিত হয় এবং Name হয় না। ইনপুট ফিল্ডের জন্য প্রদর্শন-লেবেল TextBlock-কে LabeledBy দিয়ে জোড়া প্রথম প্রার্থী। ঘোষণা ও অন-স্ক্রিন প্রদর্শন মেলে, আর শব্দ দুবার পরিচালনা এড়ান।¹⁴

<!-- An input field: associate the display label with LabeledBy -->
<TextBlock x:Name="OrderNoLabel" Text="Order number" />
<TextBox
    AutomationProperties.LabeledBy="{Binding ElementName=OrderNoLabel}"
    AutomationProperties.AutomationId="OrderNoTextBox" />

<!-- An icon-only button: state the name, and a supplement if needed -->
<Button
    AutomationProperties.Name="Confirm order"
    AutomationProperties.HelpText="Confirm the order being entered and allocate inventory">
    <Path Data="{StaticResource CheckIconGeometry}" Width="16" Height="16" />
</Button>

flowchart TB
    accTitle: WPF কন্ট্রোলের নাম কীভাবে সিদ্ধান্ত হয়
    accDescr: যার Content স্ট্রিং সেই বিষয়বস্তু Name হয়; অন্যথায় কাছের প্রদর্শন লেবেলকে LabeledBy দিয়ে জোড়া প্রথম প্রার্থী; সেটিও না থাকলে AutomationProperties.Name বলুন; TextBox-এর Text Value পাশে প্রকাশিত, Name নয়
    ctrl["কন্ট্রোল"] --> qc{"Content কি স্ট্রিং?"}
    qc -->|হ্যাঁ| auto["বিষয়বস্তু Name হয়"]
    qc -->|না| ql{"কাছে প্রদর্শন লেবেল?"}
    ql -->|হ্যাঁ| lb["LabeledBy দিয়ে জোড়ুন"]
    ql -->|না| nm["Name স্পষ্ট সেট করুন"]
    tbx["TextBox-এর Text"] -.-> val["Value হিসেবে প্রকাশিত, Name নয়"]

চিত্র ৯: WPF Name-এর জন্য ক্রম Content স্ট্রিং, LabeledBy, স্পষ্ট সেটিং; TextBox-এর Text Name হয় না।

Name-এ না-মাপা সম্পূরক তথ্য AutomationProperties.HelpText দিয়ে প্রকাশ করা যায়।⁷ আর AutomationId UI স্বয়ংক্রিয় পরীক্ষায় উপাদান শনাক্তকরণের শনাক্তকারী, তাই স্ক্রিন-ডিজাইন সময়ে নামকরণ রীতি সিদ্ধান্ত পরবর্তীতে কাজে লাগে ("Windows ডেস্কটপ অ্যাপের জন্য UI স্বয়ংক্রিয় পরীক্ষা"-এ গভীরে)।

৫.২. কাস্টম কন্ট্রোলের AutomationPeer চাই

নিজে আঁকা কাস্টম কন্ট্রোল যেমন-তেমন UIA ট্রিতে অর্থপূর্ণ তথ্য প্রকাশ করতে পারে না। WPF-এ UIElement-উদ্ভূত ক্লাসে OnCreateAutomationPeer ওভাররাইড করে AutomationPeer-উদ্ভূত ক্লাস ফেরান নাম, ধরন ও প্যাটার্ন প্রকাশ করতে। বিদ্যমান কন্ট্রোল উত্তরাধিকার করলে সংশ্লিষ্ট Peer (ButtonBase-এর জন্য ButtonBaseAutomationPeer) উত্তরাধিকার করলে ইতিমধ্যে-বাস্তবায়িত আচরণ নিয়ে নিতে পারেন।¹⁵

flowchart TB
    accTitle: AutomationPeer দিয়ে তথ্য কীভাবে প্রকাশ হয়
    accDescr: কাস্টম কন্ট্রোল OnCreateAutomationPeer ওভাররাইড করে AutomationPeer-উদ্ভূত ক্লাস ফেরিয়ে নাম, ধরন ও প্যাটার্ন প্রকাশ করে; বিদ্যমান কন্ট্রোল উত্তরাধিকার করলে সংশ্লিষ্ট Peer উত্তরাধিকার করে ইতিমধ্যে-বাস্তবায়িত আচরণ নিন
    custom["কাস্টম কন্ট্রোল"] --> ov["OnCreateAutomationPeer"]
    ov --> peer["Peer-উদ্ভূত ক্লাস ফেরান"]
    peer --> pub["নাম, ধরন ও প্যাটার্ন প্রকাশ"]
    inherit["বিদ্যমান কন্ট্রোল উত্তরাধিকার"] -.-> basepeer["সংশ্লিষ্ট Peer উত্তরাধিকার"]
    basepeer -.-> reuse["ইতিমধ্যে-বাস্তবায়িত আচরণ নিন"]

চিত্র ১০: কাস্টম কন্ট্রোল OnCreateAutomationPeer থেকে Peer ফেরায় এবং UIA-তে তথ্য প্রকাশ করে।

// An example of a control that custom-draws line status as a coloured lamp
public class StatusLamp : Control
{
    public static readonly DependencyProperty IsOnlineProperty =
        DependencyProperty.Register(nameof(IsOnline), typeof(bool), typeof(StatusLamp),
            new FrameworkPropertyMetadata(false,
                FrameworkPropertyMetadataOptions.AffectsRender, OnIsOnlineChanged));

    public bool IsOnline
    {
        get => (bool)GetValue(IsOnlineProperty);
        set => SetValue(IsOnlineProperty, value);
    }

    internal static string NameFor(bool isOnline)
        => isOnline ? "Line status: online" : "Line status: offline";

    private static void OnIsOnlineChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        // Raise a UIA property-changed event the moment the value changes. Without this,
        // a screen reader keeps the old name and cannot notice the change of state
        if (UIElementAutomationPeer.FromElement((UIElement)d) is AutomationPeer peer)
        {
            peer.RaisePropertyChangedEvent(
                AutomationElementIdentifiers.NameProperty,
                NameFor((bool)e.OldValue), NameFor((bool)e.NewValue));
        }
    }

    protected override AutomationPeer OnCreateAutomationPeer()
        => new StatusLampAutomationPeer(this);
}

public class StatusLampAutomationPeer : FrameworkElementAutomationPeer
{
    public StatusLampAutomationPeer(StatusLamp owner) : base(owner) { }

    protected override AutomationControlType GetAutomationControlTypeCore()
        => AutomationControlType.Text; // Text-equivalent if it is a status display with no operation

    protected override string GetNameCore()
        => StatusLamp.NameFor(((StatusLamp)Owner).IsOnline);
}

নাম ফেরানো যথেষ্ট নয়; বদলের মুহূর্তে ইভেন্ট দিয়ে বলাও Peer-এর কাজ। সহায়ক প্রযুক্তির নিজস্ব সময় নেই মান আবার আনার, তাই যে বাস্তবায়ন পরিবর্তন ইভেন্ট তোলে না সেটি "আবার জিজ্ঞাসা করলেই সঠিক" অবস্থায় থাকে, আর স্ক্রিন-রিডার ব্যবহারকারীকে অবস্থা বদল বলা হয় না।

sequenceDiagram
    accTitle: স্ক্রিন রিডারকে অবস্থা বদল বলার প্রবাহ
    accDescr: কন্ট্রোলের মান বদলার মুহূর্তে AutomationPeer Name বৈশিষ্ট্য-পরিবর্তন ইভেন্ট তোলে; সহায়ক প্রযুক্তি নিজে আবার আনে না, তাই ইভেন্ট ছাড়া পুরনো নামে থাকে এবং বদল টের পায় না
    participant c as Control
    participant p as AutomationPeer
    participant s as স্ক্রিন রিডার
    c->>p: IsOnline মান বদলায়
    p->>s: Name বৈশিষ্ট্য-পরিবর্তন ইভেন্ট তোলে
    s->>s: নতুন অবস্থা ঘোষণা করে
    Note over s: ইভেন্ট ছাড়া পুরনো নামে থাকে

চিত্র ১১: মান বদল স্ক্রিন রিডারে পৌঁছায় শুধু যখন AutomationPeer পরিবর্তন ইভেন্ট দিয়ে বলে।

কাস্টম কন্ট্রোলে পরিচালনা থাকলে (চাপা যায়, মান বদলানো যায়, নির্বাচন যায়) GetPattern ওভাররাইড করে IInvokeProvider বা IRangeValueProvider-এর মতো প্যাটার্ন ইন্টারফেস দিন।¹⁵ কথা হলো ভাগ করা কন্ট্রোল-লাইব্রেরি পাশে Peerও গড়লে সেটি ব্যবহার করা প্রতিটি স্ক্রিন স্বয়ংক্রিয় সহায়িত হয়। সেটি অধ্যায় ৯-এর "পাশে ছড়ানো"-এর ভিত্তি।

৬. প্রতিটি ফাংশন কি শুধু কীবোর্ড থেকে পৌঁছানো যায়?

WCAG সাফল্য মানদণ্ড ২.১.১ (Keyboard) চায় বিষয়বস্তুর সব কার্যকারিতা কীবোর্ড ইন্টারফেস দিয়ে পরিচালনাযোগ্য হোক।⁸ স্ক্রিন-রিডার ব্যবহারকারী নীতিগতভাবে মাউস ব্যবহার করেন না, তাই যে ফাংশন কীবোর্ড থেকে পৌঁছানো যায় না সেটি না-থাকার সমান। পরিদর্শন দৃষ্টিকোণ নিচের মতো।

WinForms অ্যাক্সেসিবিলিটি ওয়াকথ্রুও ভিত্তি হিসেবে ইনপুট ফিল্ডের ঠিক আগে ট্যাব ক্রমে লেবেল রাখা, এবং যে কন্ট্রোল ও মেনুতে ব্যবহারকারী যেতে চান সেগুলোতে অ্যাক্সেস কী রাখা তালিকা করে।¹²

যে জোর দিতে চাই সেটি হলো এটি "প্রতিবন্ধকতা সহায়তার অতিরিক্ত খরচ" নয়। অর্ডার প্রবেশের মতো নিয়মিত কাজে, হোম পজিশন থেকে হাত না সরিয়ে ইনপুট শেষ করতে পারাই পরিচালকের থ্রুপুট ঠিক করে। এলোমেলো ট্যাব ক্রম বা মাউস-আবশ্যিক পরিচালনা সেই দোষ যা প্রতিটি ব্যবহারকারীর উৎপাদনশীলতা প্রতিদিন একটু কেটে। অ্যাক্সেসিবিলিটি সহায়তা ও কীবোর্ড দক্ষতা একই কাজের দুই নাম (ব্যবহার পরিবেশ অনুসারে অগ্রাধিকারের জন্য "Windows অ্যাপ UX ডিজাইন"ও দেখুন)।

flowchart TB
    accTitle: কীবোর্ড সাজানোর দ্বৈত প্রভাব
    accDescr: ট্যাব ক্রম, অ্যাক্সেস কী ও ফোকাস ইঙ্গিত সাজানো একসাথে দুই প্রভাব দেয় — সহায়ক-প্রযুক্তি ব্যবহারকারী ফাংশনে পৌঁছান, এবং প্রতিটি পরিচালকের ইনপুট গতি — আর শুধু মাউস থেকে ব্যবহারযোগ্য ফাংশন না-থাকার সমান
    seibi["কীবোর্ড সাজান"] --> a11y["সহায়ক-টেক ব্যবহারকারী"]
    seibi --> speed["প্রতিটি পরিচালকের গতি"]
    mouse["শুধু-মাউস ফাংশন"] -.-> none["না-থাকার সমান"]

চিত্র ১২: কীবোর্ড পরিচালনা সাজানো সহায়ক-প্রযুক্তি সহায়তা ও প্রতিটি ব্যবহারকারীর দক্ষতা একসাথে বাস্তবায়ন করে; শুধু-মাউস ফাংশন না-থাকার সমান।

৭. রং ও কনট্রাস্ট — ৪.৫:১ এবং "রং একমাত্র উপায় নয়"

৭.১. কনট্রাস্ট অনুপাতের গাইড ৪.৫:১

WCAG সাফল্য মানদণ্ড ১.৪.৩ (Contrast (Minimum)) পাঠ্য ও পাঠ্যের ছবির জন্য কমপক্ষে ৪.৫:১ কনট্রাস্ট অনুপাত, আর বড় পাঠ্যের জন্য কমপক্ষে ৩:১ চায়।⁸ সাদা পটভূমিতে হালকা-ধূসর পাঠ্য রাখা আধুনিক ডিজাইন এই মানদণ্ডের নিচে পড়া বিরল নয়। ব্যবসায়িক অ্যাপ ব্যবহারকারীদের মধ্যে আছেন যাদের দৃষ্টি ও রং দৃষ্টি বয়সে বদলেছে, আর যারা কারখানার মতো কম আলোয় ব্যবহার করেন। ডিজাইন পর্যালোচনায় কনট্রাস্ট চেকার দিয়ে মাপার অভ্যাস করুন।

৭.২. তথ্য শুধু রং দিয়ে পৌঁছাবেন না

সাফল্য মানদণ্ড ১.৪.১ (Use of Color) হলো রং তথ্য পৌঁছানোর একমাত্র দৃশ্যমান উপায় হওয়া উচিত নয়।⁸ ব্যবসায়িক অ্যাপে নির্দিষ্ট উদাহরণ নিচের মতো।

• ত্রুটি সারি শুধু লাল পাঠ্য দেখানো → ত্রুটি আইকন ও বার্তা কলামও দিন
• আবশ্যিক ফিল্ড শুধু লেবেল রং দিয়ে দেখানো → "*" বা শব্দ "আবশ্যিক" যোগ করুন
• অবস্থা শুধু ল্যাম্প রং দিয়ে দেখানো → রং + আকার, অথবা শব্দ ("চলছে", "থামল")

রং দৃষ্টির বৈচিত্র্য দেখে এটিও "বিশেষ প্রতিক্রিয়া" নয় বরং প্রদর্শন ডিজাইনের ভিত্তি।

flowchart TB
    accTitle: শুধু রং দিয়ে পৌঁছানো তথ্যের প্রতিস্থাপন
    accDescr: শুধু লাল পাঠ্যে ত্রুটি দেখানো প্রদর্শনকে ত্রুটি আইকন প্লাস বার্তা কলাম দিয়ে প্রতিস্থাপন করা হয়; শুধু লেবেল রং দিয়ে আবশ্যিক দেখানোকে শব্দ আবশ্যিক যোগ করে; শুধু ল্যাম্প রং দিয়ে অবস্থাকে আকার বা শব্দের সাথে যোগ করে
    err["শুধু লাল পাঠ্যে ত্রুটি"] --> erra["আইকন ও শব্দও দিন"]
    req["শুধু লেবেল রং দিয়ে আবশ্যিক"] --> reqa["শব্দ আবশ্যিক যোগ করুন"]
    lamp["শুধু ল্যাম্প রং দিয়ে অবস্থা"] --> lampa["রংকে আকার বা শব্দের সাথে যোগ করুন"]

চিত্র ১৩: শুধু রং দিয়ে পৌঁছানোর নির্দিষ্ট উদাহরণ আইকন, শব্দ, এবং আকার বা পাঠ্য যোগ করে প্রতিস্থাপিত হয়।

৭.৩. কনট্রাস্ট থিম (উচ্চ কনট্রাস্ট) অনুসরণ

Windows-এ কনট্রাস্ট থিম (পূর্বে উচ্চ কনট্রাস্ট) আছে যা অগ্রভূমি ও পটভূমির শক্তিশালী পৃথকীকরণের রং পরিকল্পনায় সুইচ করে; ব্যবহারকারী তৈরি থিম বেছে ও সম্পাদনা করতে পারেন যা কনট্রাস্ট অনুপাত সাধারণত ৭:১ বা তার বেশি রাখতে ডিজাইন।⁹ অ্যাপ পক্ষের নীতি সরল: রং হার্ড-কোড করবেন না; সিস্টেম রং সম্মান করুন।

• WinForms: ForeColor/BackColor ডিফল্টে রাখলে ব্যবহারকারীর রং সেটিং ব্যবহৃত হয়। নিজের রং লাগানো জায়গায় SystemInformation.HighContrast দিয়ে জানুন, SystemColors-ভিত্তিক পরিকল্পনায় সুইচ করুন, এবং UserPreferenceChanged ইভেন্ট দিয়ে সেটিং পরিবর্তন অনুসরণ করুন।¹²
• WPF/WinUI: SystemColors-শ্রেণির রিসোর্স রেফারেন্স করলে থিম সুইচ অনুসরণ হয়। যেখানে নিজের ব্রাশ ভরা সেটি ভাঙার কারণ হয়।⁹

flowchart TB
    accTitle: কনট্রাস্ট থিম অনুসরণ
    accDescr: যেখানে রং হার্ড-কোড সেখানে কনট্রাস্ট থিম সুইচে পরিকল্পনা ভাঙে, তাই SystemColors-ভিত্তিক পরিকল্পনায় সুইচ করুন এবং সেটিং-পরিবর্তন ইভেন্ট দিয়ে অনুসরণ করুন; সিস্টেম রং রেফারেন্স করলে ব্যবহারকারীর রং স্বয়ংক্রিয় অনুসরণ হয়
    theme["কনট্রাস্ট থিমে সুইচ"] --> qh{"রং কীভাবে নির্দিষ্ট?"}
    qh -->|"হার্ড-কোড"| broken["রং পরিকল্পনা ভাঙে"]
    qh -->|"সিস্টেম-রং রেফারেন্স"| ok["ব্যবহারকারী রঙের স্বয়ংক্রিয় অনুসরণ"]
    broken -.-> fix["SystemColors-এ সুইচ"]
    fix -.-> ev["সেটিং-পরিবর্তন ইভেন্ট দিয়ে অনুসরণ"]

চিত্র ১৪: শুধু যেখানে রং হার্ড-কোড সেখানে কনট্রাস্ট থিমে ভাঙে; সিস্টেম-রং রেফারেন্স স্বয়ংক্রিয় অনুসরণ করে।

সঙ্গে, কম দৃষ্টির ব্যবহারকারী প্রায়ই উচ্চ OS বিবর্ধন (DPI স্কেলিং) ব্যবহার করেন, তাই উচ্চ-DPI সহায়তাও অ্যাক্সেসিবিলিটি সহায়তার অংশ। যে অ্যাপের লেআউট ১২৫%–২০০%-এ ভাঙে সেটি সেই বিন্দুতে অনুপযোগী। বিস্তারের জন্য "WinForms-এ উচ্চ-DPI সহায়তা" ও "WPF উচ্চ-DPI সহায়তা" দেখুন।

৮. বাস্তবে যাচাই — Accessibility Insights ও স্ক্রিন-রিডার হাতে-কলমে পরীক্ষা

৮.১. Accessibility Insights for Windows

Microsoft Windows অ্যাপের জন্য অ্যাক্সেসিবিলিটি যাচাই সরঞ্জাম হিসেবে Accessibility Insights for Windows দেয়, তিনটি মূল ব্যবহারের সাথে।¹⁰

• Live Inspect: উপাদানে মাউস হোভার করুন বা কীবোর্ড-ফোকাস করুন, আর তার UIA বৈশিষ্ট্য (Name, ControlType, প্যাটার্ন ইত্যাদি) নিশ্চিত করতে পারেন। "এই বোতামের Name কী" দেখার সবচেয়ে ছোট উপায়।
• FastPass: পাঁচ মিনিটের কম সময়ে উচ্চ-প্রভাব অ্যাক্সেসিবিলিটি সমস্যা ধরার হালকা পরীক্ষা। অনুপস্থিত Name-এর মতো যান্ত্রিকভাবে সিদ্ধান্ত সমস্যা প্রতি নতুন স্ক্রিনে তালিকা হতে পারে।
• Troubleshooting: বিশেষ সমস্যার নির্ণয় ও সংশোধনে সহায়তা। ধরা সমস্যা থেকে এই নিবন্ধে উদ্ধৃত প্রতি-ফ্রেমওয়ার্ক সংশোধন নির্দেশিকায় সরাসরি যেতে পারেন।

Windows SDK-তে অন্তর্ভুক্ত Inspect.exe ও AccEventও UIA ট্রি ও বৈশিষ্ট্য নিশ্চিত করতে পারে, কিন্তু সেগুলো উত্তরাধিকার সরঞ্জাম ধরা হয়, আর এখন Accessibility Insights-এ যাওয়া সুপারিশকৃত।¹⁰

flowchart TB
    accTitle: Accessibility Insights-এর তিন ব্যবহার
    accDescr: Accessibility Insights for Windows Live Inspect দিয়ে UIA বৈশিষ্ট্য নিশ্চিত, FastPass দিয়ে উচ্চ-প্রভাব সমস্যার হালকা পরীক্ষা, এবং Troubleshooting দিয়ে নির্ণয় ও সংশোধন সহায়তা দেয়; Inspect.exe-এর মতো উত্তরাধিকার সরঞ্জাম থেকে যাওয়া সুপারিশকৃত
    ai["Accessibility Insights"] --> live["Live Inspect"]
    ai --> fast["FastPass"]
    ai --> ts["Troubleshooting"]
    live --> livef["UIA বৈশিষ্ট্য নিশ্চিত"]
    fast --> fastf["উচ্চ-প্রভাব সমস্যা ধরুন"]
    ts --> tsf["নির্ণয় ও সংশোধন সহায়তা"]
    legacy["Inspect.exe ইত্যাদি"] -.->|"যাওয়া সুপারিশকৃত"| ai

চিত্র ১৫: Accessibility Insights-এর তিন ব্যবহার নিশ্চিত, ধরা ও নির্ণয়, আর উত্তরাধিকার সরঞ্জাম থেকে যাওয়ার গন্তব্য।

৮.২. স্ক্রিন রিডার দিয়ে হাতে-কলমে পরীক্ষা

সরঞ্জামের স্বয়ংক্রিয় পরীক্ষা শুধু যান্ত্রিকভাবে সিদ্ধান্ত সমস্যা ধরতে পারে। শেষে, সবসময় স্ক্রিন রিডার দিয়ে বাস্তব ব্যবসায়িক পরিচালনা চালান। Windows-নির্মিত Narrator Ctrl+Windows কী+Enter দিয়ে তৎক্ষণাৎ শুরু হয়, আর NVDA বিনামূল্যে আনা যায়।¹¹ পরীক্ষার কৌশল স্ক্রিন না দেখে (বা ডিসপ্লে বন্ধ) শুধু ঘোষণার উপর ভরসা করে এটি চেষ্টা করা যে "একটি অর্ডার প্রবেশ করে নিশ্চিত করুন"-এর মতো বাস্তব কাজ শেষ হতে পারে কি না। নাম থাকলেও ঘোষণা ক্রম অসংগত হওয়া, অথবা ফোকাসের মোডাল থেকে বেরিয়ে যাওয়া, শুধু হাতে-কলমে মেলে।

flowchart TB
    accTitle: সরঞ্জাম যাচাই ও হাতে-কলমে পরীক্ষার সংযোগ
    accDescr: FastPass-এর মতো স্বয়ংক্রিয় পরীক্ষা শুধু যান্ত্রিকভাবে সিদ্ধান্ত সমস্যা ধরতে পারে; বাকি হাতে-কলমে স্ক্রিন রিডার দিয়ে বাস্তব ব্যবসায়িক পরিচালনা চালিয়ে ঘোষণা-ক্রম ও ফোকাস সমস্যা খুঁজে মেলে
    tool["সরঞ্জামের স্বয়ংক্রিয় পরীক্ষা"] --> kikai["যান্ত্রিকভাবে সিদ্ধান্ত সমস্যা"]
    tool -.-> nokori["না-ধরা সমস্যা থেকে যায়"]
    nokori --> sr["স্ক্রিন রিডার দিয়ে হাতে-কলমে পরীক্ষা"]
    sr --> task["ব্যবসায়িক পরিচালনা চালান"]
    task --> mieru["ঘোষণা-ক্রম ও ফোকাস সমস্যা"]

চিত্র ১৬: স্বয়ংক্রিয় পরীক্ষা থেকে যান্ত্রিক সমস্যা তালিকা করুন, আর বাকি স্ক্রিন রিডার দিয়ে হাতে-কলমে খুঁজুন।

৮.৩. উন্নয়ন প্রবাহে গড়া, এবং UI স্বয়ংক্রিয় পরীক্ষা থেকে পারস্পরিক লাভ

যাচাই ব্যক্তি-নির্ভর না থাকুক, তার জন্য নতুন স্ক্রিনের পর্যালোচনা আইটেমে নিচের চেকলিস্ট যোগ করার পরামর্শ।

আর একটা। FlaUI ইত্যাদি দিয়ে UI স্বয়ংক্রিয় পরীক্ষা সেই একই UIA-তে তৈরি যার ব্যবহার স্ক্রিন রিডার করে। অ্যাক্সেসিবিলিটির জন্য রাখা Name ও প্যাটার্ন পরীক্ষা কোডের অংশ হয়, আর পরীক্ষার জন্য ডিজাইন করা AutomationId Live Inspect-এ ডিবাগিং সহজ করে। উল্টোদিকে UIA ট্রিতে না-দেখা UI পরীক্ষা ও সহায়ক প্রযুক্তি দুয়ের কাছেই অদৃশ্য। অ্যাক্সেসিবিলিটি ও পরীক্ষাযোগ্যতা একই বিনিয়োগের দুই মুখ ("Windows ডেস্কটপ অ্যাপের জন্য UI স্বয়ংক্রিয় পরীক্ষা")।

flowchart TB
    accTitle: অ্যাক্সেসিবিলিটি ও UI স্বয়ংক্রিয় পরীক্ষার পারস্পরিক লাভ
    accDescr: স্ক্রিন রিডার ও FlaUI-এর মতো UI স্বয়ংক্রিয় পরীক্ষা একই UIA-তে তৈরি, তাই রাখা Name ও প্যাটার্ন দুই থেকে ব্যবহার হতে পারে, আর UIA ট্রিতে না-দেখা UI দুই থেকে অদৃশ্য
    uia["UIA ট্রি সাজান"] --> sr["স্ক্রিন রিডার পড়তে পারে"]
    uia --> test["UI স্বয়ংক্রিয় পরীক্ষায় ব্যবহার"]
    sr -.-> both["একই বিনিয়োগের দুই মুখ"]
    test -.-> both
    hidden["UIA-তে না-দেখা UI"] -.-> invisible["দুই থেকে অদৃশ্য"]

চিত্র ১৭: একই UIA ভিত্তিতে থাকায় UIA ট্রি সাজানো সহায়ক প্রযুক্তি ও UI স্বয়ংক্রিয় পরীক্ষা দুয়েকেই লাভ দেয়।

৯. অগ্রাধিকার কীভাবে ঠিক করবেন — প্রতিটি স্ক্রিন একসাথে ঠিক করবেন না

শত শত স্ক্রিনের মূল ব্যবস্থা একসাথে ঠিক করা খরচ ও গুণমান দুয়েই অবাস্তব। যে দৃষ্টিভঙ্গি আমরা সুপারিশ করি সেটি নিচের তিন স্তর।

1. যে স্ক্রিনগুলো সেই ব্যবহারকারী কাজে ব্যবহার করেন সেগুলো থেকে ঠিক করুন। যুক্তিসঙ্গত সমন্বয় সংশ্লিষ্ট ব্যক্তির অনুরোধের ব্যক্তিগত উত্তর দেওয়ার প্রক্রিয়া।¹ আগে ব্যক্তিকে স্ক্রিন রিডার দিয়ে বাস্তব কাজ চালাতে দিন, আর একসাথে চিহ্নিত করুন কোথায় আটকে যান। অনেক ক্ষেত্রে দৈনন্দিন কাজের স্ক্রিন কয়েক থেকে এক ডজন পর্যন্ত সীমাবদ্ধ, আর তাতে মারাত্মক সমস্যা (নামহীন বোতাম, কীবোর্ড থেকে না-চাপা নিশ্চিত বোতাম) দিনের সংশোধনে সমাধান হতে পারে।
2. নতুন উন্নয়নকে মানক-অনুযায়ী করুন। অধ্যায় ৮-এর চেকলিস্ট Definition of Done-এ যোগ করুন, আর নতুন স্ক্রিন শুরু থেকে সহায়িত করুন। পরবর্তী সংশোধনের থেকে আলাদা, ডিজাইন সময়ে গড়ার খরচ বৃদ্ধি সামান্য।
3. ভাগ করা কন্ট্রোল ঠিক করে পাশে ছড়ান। খোঁজ সংলাপ, গ্রিড, বা তারিখ ইনপুটের মতো ভাগ করা ইন-হাউস অংশে ডিফল্ট AccessibleName বা AutomationPeer প্রয়োগ করলে সেটি ব্যবহার করা প্রতিটি স্ক্রিনে ব্যাচে কার্যকর হয়। ব্যক্তিগত স্ক্রিন এক-এক স্পর্শ করার চেয়ে অনেক বেশি খরচ-কার্যকর চাল।

flowchart TB
    accTitle: সংশোধন অগ্রাধিকারের তিন স্তর
    accDescr: ব্যবহারকারী কাজে ব্যবহার করা স্ক্রিন থেকে ঠিক করুন, নতুন উন্নয়নকে চেকলিস্ট দিয়ে মানক-অনুযায়ী করুন, এবং ভাগ করা কন্ট্রোল ঠিক করে প্রতিটি স্ক্রিনে ছড়ান
    s1["১. ব্যবহারকারীর স্ক্রিন থেকে ঠিক করুন"] --> s2["২. নতুন কাজ মানক-অনুযায়ী"] --> s3["৩. ভাগ করা কন্ট্রোল থেকে পাশে ছড়ান"]
    s3 -.-> all["সেটি ব্যবহার করা প্রতিটি স্ক্রিনে ব্যাচে কার্যকর"]

চিত্র ১৮: প্রতিটি স্ক্রিন একসাথে ঠিক করে নয়, বরং ব্যবহারে স্ক্রিন, নতুন কাজ, এবং ভাগ করা অংশের তিন স্তরে এগোন।

আর সংলাপের রেকর্ড প্রযুক্তিগত প্রতিক্রিয়ার সমান গুরুত্বপূর্ণ। যুক্তিসঙ্গত সমন্বয় "ব্যক্তিগত সংলাপ ও সমন্বয়" প্রক্রিয়া, প্রতিটি অনুরোধ পূর্ণ পূরণের নয়। ব্যক্তির সাথে বিকল্প উপায় ভাবা (সেই কাজ অন্য স্ক্রিনে করা, CSV রপ্তানি প্রস্তুত করা, পরিচালনায় ঢাকা) এবং অতিরিক্ত ভারওয়ালা সংশোধনে একমত হওয়াও গঠনমূলক সংলাপের বৈধ ফল।¹ কী চাওয়া হয়েছিল, কী উত্তর দেওয়া হয়েছিল, এবং কী বিকল্প উপায় গড়া হয়েছিল, রেকর্ড করা সংগঠনের সদিচ্ছার প্রমাণ হয়।

flowchart TB
    accTitle: গঠনমূলক সংলাপ ও রেকর্ডের প্রবাহ
    accDescr: প্রতিবন্ধী ব্যক্তির অনুরোধের গঠনমূলক সংলাপ দিয়ে উত্তর দিন; যা সংশোধন করা যায় করুন; অতিরিক্ত ভারওয়ালা সংশোধনে ব্যক্তির সাথে বিকল্প উপায় ভাবুন ও একমত হোন; কী চাওয়া, কী উত্তর, কী বিকল্প গড়া, রেকর্ড করুন
    req["অনুরোধ"] --> talk["গঠনমূলক সংলাপ"]
    talk --> q{"ভার কি অতিরিক্ত?"}
    q -->|"না"| kaishu["সংশোধন দিয়ে উত্তর দিন"]
    q -->|"হ্যাঁ"| alt["বিকল্প উপায় ভাবুন ও একমত হোন"]
    kaishu --> rec["ইতিহাস রেকর্ড করুন"]
    alt --> rec

চিত্র ১৯: গঠনমূলক সংলাপে ব্যক্তির সাথে সংশোধন বা বিকল্প উপায়ে একমত হন, আর সেই ইতিহাস রেকর্ডে রাখেন।

১০. সারসংক্ষেপ

• এপ্রিল ২০২৪ থেকে কার্যকর সংশোধিত প্রতিবন্ধী ব্যক্তিদের প্রতি বৈষম্য নির্মূল আইন থেকে যুক্তিসঙ্গত সমন্বয় দেওয়া ব্যবসার জন্যও বাধ্যতা হয়ে গেছে। কর্মসংস্থান ক্ষেত্র ২০১৬ থেকে প্রতিবন্ধী ব্যক্তিদের কর্মসংস্থান প্রসার আইনের অধীন নিয়োগকর্তা বাধ্যতা। অ্যাপকে আগে সহজ করা "পরিবেশ উন্নয়ন" (প্রচেষ্টা-বাধ্যতা), আর যত এগোবেন ব্যক্তিগত প্রতিক্রিয়া তত হালকা।
• প্রযুক্তিগত মানদণ্ড WCAG (JIS X 8341-3:2016)-এ কেন্দ্রীভূত, আর একই চিন্তা WCAG2ICT থেকে ডেস্কটপ অ্যাপে প্রয়োগ হতে পারে।
• স্ক্রিন রিডার অ্যাপকে UI Automation দিয়ে পড়ে। UIA ট্রি, বৈশিষ্ট্য (Name/ControlType/AutomationId), এবং কন্ট্রোল প্যাটার্নের ত্রয়ী ভিত্তি।
• সর্বোচ্চ অগ্রাধিকার Name। WinForms AccessibleName ও Label-কে ট্যাব ক্রমে জোড়া ব্যবহার করে; WPF AutomationProperties.Name/LabeledBy; কাস্টম কন্ট্রোল AutomationPeer।
• প্রতিটি ফাংশন শুধু কীবোর্ড থেকে পৌঁছানো WCAG সাফল্য মানদণ্ড এবং সঙ্গে প্রতিটি পরিচালকের উৎপাদনশীলতা। ট্যাব ক্রম, অ্যাক্সেস কী ও ফোকাস ইঙ্গিত সাজান।
• রঙের তিন ভিত্তি কনট্রাস্ট অনুপাত ৪.৫:১, রং একমাত্র উপায় নয়, এবং কনট্রাস্ট থিমে সিস্টেম রং সম্মান।
• যাচাইকে Accessibility Insights-এর FastPass+Live Inspect ও Narrator/NVDA দিয়ে হাতে-কলমে পরীক্ষার সাথে জোড়ুন, আর নতুন স্ক্রিনের চেকলিস্ট হিসেবে উন্নয়ন প্রবাহে গড়ুন।
• প্রতিটি স্ক্রিন একসাথে ঠিক করবেন না; ব্যবহারকারীর স্ক্রিন → নতুন কাজের জন্য মানক সহায়তা → ভাগ করা কন্ট্রোলের পাশ রোল-আউট ক্রমে এগোন। যুক্তিসঙ্গত সমন্বয় সংলাপের প্রক্রিয়া, আর ইতিহাসের রেকর্ড সংগঠনকে রক্ষা করে।

প্রথম পদক্ষেপ হিসেবে নিজের মূল স্ক্রিনগুলোর একটি বেছে নিন, Accessibility Insights for Windows-এ FastPass চালান, তারপর শুধু Tab কী দিয়ে কাজ চালান। ত্রিশ মিনিটে আপনার নিজের অ্যাপের বর্তমান অবস্থা অবাক করাভাবে সুনির্দিষ্ট হয়ে যায়।

সম্পর্কিত নিবন্ধ

• Windows ডেস্কটপ অ্যাপের জন্য UI স্বয়ংক্রিয় পরীক্ষা — UI Automation কীভাবে কাজ করে এবং FlaUI দিয়ে মজবুত পরীক্ষা গড়া
• Windows অ্যাপ UX ডিজাইন - ব্যবহার পরিবেশ অনুসারে অগ্রাধিকার
• WinForms-এ উচ্চ-DPI সহায়তা — ৪কে মনিটরে UI কেন ঝাপসা বা ভাঙে, এবং বাস্তব সংশোধন
• WPF উচ্চ-DPI সহায়তা — ‘DPI-সচেতন ধরা হয়’ হলেও কেন ঝাপসা ও রক্তক্ষরণ, এবং কীভাবে ঠিক করবেন
• KomuraSoft কেন ডিজিটাল এজেন্সি ডিজাইন সিস্টেমে ওয়েবসাইট গড়ে — কম খরচ ও উচ্চ গুণমান একসাথে থাকতে পারে
• জাপানি ফন্ট ও অক্ষরের ফাঁদ — ব্যবসায়িক অ্যাপে JIS2004, IVS ও গাইজি সামলানো

সম্পর্কিত পরামর্শ ক্ষেত্র

KomuraSoft LLC WinForms/WPF ব্যবসায়িক অ্যাপের অ্যাক্সেসিবিলিটি সংশোধন (স্ক্রিন-রিডার সহায়তা, কীবোর্ড পরিচালনা সাজানো, কনট্রাস্ট-থিম সহায়তা), ভাগ করা কন্ট্রোলে AutomationPeer প্রয়োগ, এবং Accessibility Insights দিয়ে বর্তমান-অবস্থা নির্ণয় ও অগ্রাধিকার-নির্ধারণ পরামর্শ সামলায়। "আমরা নিশ্চিত করতে চাই কর্মচারী আমাদের অ্যাপ স্ক্রিন রিডার দিয়ে ব্যবহার করতে পারেন কি না" পর্যায় থেকে শুরু করা ঠিক।

• Windows অ্যাপ্লিকেশন ডেভেলপমেন্ট
• টেকনিক্যাল কনসালটিং ও ডিজাইন রিভিউ
• যোগাযোগ করুন

তথ্যসূত্র

সম্পর্কিত নিবন্ধ

কাছাকাছি বিষয়ে গভীরে যেতে একই ট্যাগযুক্ত সাম্প্রতিক নিবন্ধ।

সম্পর্কিত বিষয়

এই পৃষ্ঠাগুলো বিষয়টিকে সেবা ও সিদ্ধান্তের বৃহত্তর প্রেক্ষাপটে স্থাপন করে।

এই বিষয়ের সাথে সম্পর্কিত সেবা

নিবন্ধটি নিচের সেবাগুলোর সাথে সরাসরি সম্পর্কিত।

প্রায়শ জিজ্ঞাসিত প্রশ্ন

এই নিবন্ধের বিষয়ে পরামর্শে প্রায়ই আসা প্রশ্ন।

ব্যবসায়িক অ্যাপের অ্যাক্সেসিবিলিটি সহায়তা কি আইন থেকে প্রয়োজন?

প্রতিবন্ধী ব্যক্তিদের প্রতি বৈষম্য নির্মূল আইনের ২০২১ সংশোধন ১ এপ্রিল ২০২৪ থেকে কার্যকর হয়েছে, আর প্রতিবন্ধী ব্যক্তিদের যুক্তিসঙ্গত সমন্বয় দেওয়া ব্যবসার জন্যও বাধ্যতা হয়ে গেছে। যুক্তিসঙ্গত সমন্বয় সেই প্রতিক্রিয়া যা প্রতিবন্ধী ব্যক্তির অনুরোধে ব্যক্তিগত বাধা সেই সীমায় সরায় যা অতিরিক্ত ভার নয়; অ্যাপকে আগে থেকে ব্যবহার সহজ করা "পরিবেশ উন্নয়ন" নামক প্রচেষ্টা-বাধ্যতা। কর্মসংস্থান, যেমন কর্মচারী ও কোম্পানির সম্পর্ক, সেই আইনের অধীন নয় বরং প্রতিবন্ধী ব্যক্তিদের কর্মসংস্থান প্রসার আইনের অধীন, যা এপ্রিল ২০১৬ থেকে কার্যকর সংশোধন থেকে নিয়োগকর্তাদের যুক্তিসঙ্গত সমন্বয় দিতে বাধ্য করেছে। অর্থাৎ "কর্মচারী ব্যবসায়িক অ্যাপ ব্যবহার করতে পারেন না" পরিস্থিতি কিছুকাল ধরে বাধ্যতার এলাকায় আছে। কোনো ক্ষেত্রে কতদূর যাবেন ব্যক্তিগত পরিস্থিতির উপর নির্ভর করে, তাই ক্যাবিনেট অফিস ও স্বাস্থ্য, শ্রম ও কল্যাণ মন্ত্রণালয়ের প্রাথমিক উৎস নিশ্চিত করুন এবং সংশ্লিষ্ট ব্যক্তির সাথে সংলাপ থেকে সিদ্ধান্ত নিন।

স্ক্রিন রিডার Windows ডেস্কটপ অ্যাপ কীভাবে পড়ে?

Narrator ও NVDA-এর মতো স্ক্রিন রিডার অ্যাপের UI-কে UI Automation (UIA) নামক অ্যাক্সেসিবিলিটি ভিত্তি থেকে পড়ে। অ্যাপ পক্ষ অন-স্ক্রিন উপাদানগুলোকে UIA ট্রি নামক কাঠামোতে প্রকাশ করে; প্রতিটি উপাদানে Name (উদ্দেশ্য) ও ControlType (ধরন) এর মতো বৈশিষ্ট্য, এবং Invoke (চাপুন) ও Value (মান) এর মতো কন্ট্রোল প্যাটার্ন থাকে। স্ক্রিন রিডার এই তথ্য "অর্ডার নিশ্চিত করুন বোতাম" হিসেবে ঘোষণা করে এবং প্যাটার্ন থেকে পরিচালনা করে। মানক WinForms ও WPF কন্ট্রোলে এই ব্যবস্থা শুরু থেকেই আছে, তাই ডেভেলপারের মূল কাজ Name খালি না রাখা, UI-কে কীবোর্ড থেকে পরিচালনাযোগ্য করা, এবং কাস্টম কন্ট্রোলে তথ্য প্রয়োগ করা।

বিদ্যমান WinForms অ্যাপে কোথা থেকে শুরু করব?

সবচেয়ে ছোট পথ লক্ষ্য স্ক্রিনে Accessibility Insights for Windows-এর FastPass চালিয়ে খালি Name-ওয়ালা কন্ট্রোল ও ট্যাব-ক্রম সমস্যা তালিকা করা। সংশোধন আইকন-শুধু বোতামে AccessibleName সেট করা, ইনপুট ফিল্ডের ঠিক আগে ট্যাব ক্রমে Label যোগ করা, এবং TabIndex-কে দৃশ্যমান ক্রমের সাথে মেলানো থেকে শুরু হয়। তারপর Narrator বা NVDA শুরু করুন এবং স্ক্রিন না দেখে বাস্তব ব্যবসায়িক পরিচালনা চালান, আর নিশ্চিত করুন কোথায় আটকে যান। প্রতিটি স্ক্রিন একসাথে ঠিক করার দরকার নেই; যে স্ক্রিনগুলো কেউ সত্যি ব্যবহার করেন সেগুলো থেকে শুরু করা, এবং নতুন স্ক্রিনকে চেকলিস্ট দিয়ে মানক-অনুযায়ী করা, বাস্তবসম্মত।

উচ্চ-কনট্রাস্ট (কনট্রাস্ট থিম) সহায়তার জন্য কী করব?

ভিত্তি রং হার্ড-কোড না করা এবং সিস্টেম রং সম্মান করা। WinForms-এ ForeColor/BackColor ডিফল্টে রাখুন বা SystemColors ব্যবহার করুন, অবস্থা SystemInformation.HighContrast দিয়ে জানুন, এবং সুইচ UserPreferenceChanged ইভেন্ট দিয়ে অনুসরণ করুন। WPF ও WinUI-তেও, SystemColors-শ্রেণির রিসোর্স রেফারেন্স করলে থিম সুইচ স্বয়ংক্রিয় অনুসরণ হয়। সঙ্গে তথ্য "শুধু রং দিয়ে" পৌঁছাবেন না — ত্রুটি শুধু লাল দেখানো — এবং এটিকে আইকন বা শব্দের সাথে যোগ করুন। সাধারণ থিমেও WCAG-এর পাঠ্য কনট্রাস্ট অনুপাত ৪.৫:১ বা তার বেশি গাইড হিসেবে ধরা খারাপ আলোয় দোকান ও বয়স্ক ব্যবহারকারীদের জন্য UI আরও পাঠযোগ্য করে।

অ্যাক্সেসিবিলিটি সহায়তা কি UI স্বয়ংক্রিয় পরীক্ষাতেও সাহায্য করে?

হ্যাঁ। FlaUI-এর মতো UI স্বয়ংক্রিয়-পরীক্ষা সরঞ্জাম সেই একই UI Automation-এ তৈরি যার ব্যবহার স্ক্রিন রিডার করে। অ্যাক্সেসিবিলিটির জন্য রাখা Name, ControlType ও কন্ট্রোল প্যাটার্ন পরীক্ষা কোড থেকে যেমন-তেমন ব্যবহার হতে পারে, আর পরীক্ষার জন্য ডিজাইন করা AutomationId উপাদান শনাক্তকরণ স্থিতিশীল করে। উল্টোদিকে কাস্টম-ড্র UI যা UIA ট্রিতে দেখা যায় না, স্ক্রিন রিডার ও পরীক্ষা দুয়ের কাছেই অদৃশ্য। অ্যাক্সেসিবিলিটি ও স্বয়ংক্রিয় পরীক্ষা একই ভিত্তিতে বিনিয়োগ, তাই যেকোনো একটা রাখলে অন্যটির খরচও কমে।

লেখকের প্রোফাইল

নিবন্ধের লেখকের পরিচিতি পৃষ্ঠা।

Go Komura

KomuraSoft LLC-এর প্রতিনিধি

Windows সফটওয়্যার ডেভেলপমেন্ট, প্রযুক্তিগত পরামর্শ ও বাগ তদন্তে বিশেষজ্ঞ, বিশেষ করে বিদ্যমান সিস্টেমযুক্ত প্রকল্প ও পুনরুৎপাদন করা কঠিন বাগে।