Windows ऐप सुलभता का परिचय — UI Automation और युक्तियुक्त समायोजन आवश्यकताओं की तैयारी

“मध्य-कैरियर भर्ती जो दृष्टिबाधित हैं, मुख्य आदेश-प्रवेश ऐप स्क्रीन रीडर से उपयोग नहीं कर सकते। वे वेब ब्राउज़र और मेल बिना समस्या उपयोग करते हैं, पर केवल हमारे व्यावसायिक ऐप का पठन सही नहीं चलता। क्या कुछ हो सकता है?” — ग्राहकों के IT विभागों से इस तरह के परामर्श बढ़ रहे हैं।

एक पृष्ठभूमि कानूनी ढाँचा है। विकलांग व्यक्तियों के प्रति भेदभाव उन्मूलन अधिनियम का 2021 संशोधन 1 अप्रैल 2024 से प्रभावी हुआ, और विकलांग व्यक्तियों को “युक्तियुक्त समायोजन देना” व्यवसायों के लिए भी बाध्यता बन गया।¹ आगे, कर्मचारी–कंपनी संबंध जैसा प्रारंभिक (रोज़गार क्षेत्र) विकलांग व्यक्तियों के रोज़गार संवर्धन अधिनियम का क्षेत्र है, जिसने अप्रैल 2016 से नियोक्ताओं को युक्तियुक्त समायोजन देने के लिए बाध्य किया है।² यह विचार कि “सुलभता वेबसाइट विषय है और इन-हाउस Windows ऐप से कोई लेना-देना नहीं” अब न कानूनी रूप से टिकता है न व्यवहार में।

दूसरी ओर, विकास फर्श से “पता नहीं क्या करें” ईमानदार जगह है। Windows डेस्कटॉप ऐप की सुलभता पर वेब से कम जानकारी है, और कोई जादुई बाद-का समाधान नहीं। निराशा की भी ज़रूरत नहीं। यदि समझें कि स्क्रीन रीडर ऐप कैसे पढ़ता है (UI Automation) और नाम, कीबोर्ड व रंग की बुनियाद अपनाएँ, व्यावसायिक ऐप की उपयोगिता काफी सुधरती है। और उसमें बहुत कुछ हर उपयोगकर्ता की उत्पादकता बढ़ाता है, विकलांगता हो या न हो।

जापानी व्यावसायिक ऐप डेवलपरों और IT स्टाफ के लिए, यह लेख कानूनी ढाँचे और मानकों की न्यूनतम छँटाई से, 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["प्राथमिकताएँ कैसे तय करें"]

चित्र 1: यह लेख कानूनी ढाँचे को तंत्र, कार्यान्वयन, सत्यापन और प्राथमिकताओं से एक ही प्रवाह में जोड़ता है।

1. निष्कर्ष पहले

• युक्तियुक्त समायोजन देना 1 अप्रैल 2024 से व्यवसायों के लिए भी बाध्यता है। जब विकलांग व्यक्ति बाधा हटाने का आशय दर्शाए, अत्यधिक भार न होने वाली सीमा में प्रतिक्रिया चाहिए। रोज़गार क्षेत्र विकलांग व्यक्तियों के रोज़गार संवर्धन अधिनियम के अधीन है, और वह अप्रैल 2016 से नियोक्ता बाध्यता है।¹²
• युक्तियुक्त समायोजन “व्यक्तिगत अनुरोध का रचनात्मक संवाद से उत्तर” की प्रक्रिया है; ऐप को पहले से आसान बनाना “पर्यावरण सुधार” (प्रयास-बाध्यता) है। पूर्ण अग्रिम सहायता बाध्यता नहीं; मायने यह है कि संवाद एकतरफा न ठुकराएँ।¹
• सुलभता के तकनीकी मानदंड 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 सफलता मानदंड (2.1.1) है और साथ ही कुशल संचालक की इनपुट गति स्वयं। टैब क्रम, एक्सेस कुंजी और फ़ोकस संकेत रखना हर उपयोगकर्ता की दक्षता से सीधे जुड़ता है।⁸
• पाठ कंट्रास्ट अनुपात 4.5:1 या अधिक मार्गदर्शक मानें, और जानकारी केवल रंग से न पहुँचाएँ। कंट्रास्ट थीम (उच्च कंट्रास्ट) में हार्ड-कोड रंगों के बजाय सिस्टम रंगों का सम्मान करें।⁸⁹
• सत्यापन को Accessibility Insights for Windows के FastPass और स्क्रीन रीडर से हाथों-हाथ जाँच से जोड़ें। क्योंकि वे एक ही UIA आधार पर हैं, यह काम FlaUI जैसे UI स्वचालित-परीक्षण संपत्तियों के साथ भी परस्पर लाभ देता है।¹⁰
• हर स्क्रीन एक साथ ठीक करने की ज़रूरत नहीं। यथार्थ क्रम है (1) उन स्क्रीनों से जिन्हें वह उपयोगकर्ता उपयोग करता है, (2) नया विकास मानक-अनुरूप, (3) साझा नियंत्रण ठीक कर बग़ल में फैलाएँ।

एक वाक्य में: सुलभता सहायता “UIA ट्री पर सही नाम और संचालन उजागर करना, और कीबोर्ड व रंग की बुनियाद रखना” है।

2. कानूनी ढाँचे और मानकों की छँटाई — “बाध्यता बनी” चीज़ क्या बदली

2.1. विकलांग व्यक्तियों के प्रति भेदभाव उन्मूलन अधिनियम — अप्रैल 2024 से व्यवसाय भी युक्तियुक्त समायोजन देने के लिए बाध्य

विकलांग व्यक्तियों के प्रति भेदभाव उन्मूलन अधिनियम वह कानून है जो प्रशासनिक अंगों और व्यवसायों द्वारा विकलांग व्यक्तियों के “अन्यायपूर्ण भेदभावपूर्ण व्यवहार” को प्रतिबंधित करता है, और “युक्तियुक्त समायोजन देना” अपेक्षित करता है। 2021 (रेइवा 3) संशोधन में व्यवसायों द्वारा युक्तियुक्त समायोजन देना, जो प्रयास-बाध्यता था, बाध्यता बन गया, और संशोधित अधिनियम 1 अप्रैल 2024 (रेइवा 6) से प्रभावी हुआ।¹

कैबिनेट कार्यालय पत्रक के अनुसार युक्तियुक्त समायोजन देना उस सीमा में प्रतिक्रिया देना है जो अत्यधिक भार न हो, जब विकलांग व्यक्ति आशय दर्शाए कि समाज में बाधा हटाने के लिए कोई प्रतिक्रिया चाहिए। और क्योंकि सामग्री विकलांगता विशेषता, दृश्य और स्थिति से भिन्न होती है, एक “रचनात्मक संवाद” जिसमें विकलांग व्यक्ति और व्यवसाय संवाद जोड़कर प्रतिक्रिया साथ सोचें पर ज़ोर है। रचनात्मक संवाद एकतरफा ठुकराना युक्तियुक्त समायोजन बाध्यता का उल्लंघन बन सकता है, कहा गया है।¹

यहाँ दो व्यावहारिक भेद मायने रखते हैं।

1. “पहले से सब कुछ रखना” वह नहीं जो बाध्यता बनी। अनिर्दिष्ट संख्या के विकलांग व्यक्तियों के लिए अग्रिम सुधार उपाय — नरम पक्ष जैसे मैनुअल समीक्षा और प्रशिक्षण, कठोर पक्ष जैसे सुविधा बाधा-मुक्त बनाना — “पर्यावरण सुधार” कहलाते हैं, और यह प्रयास-बाध्यता है।¹ व्यावसायिक ऐप को स्क्रीन रीडर से उपयोग योग्य अवस्था में पहले रखना पर्यावरण-सुधार प्रयास माना जा सकता है। जितना पर्यावरण सुधार आगे बढ़ा, व्यक्तिगत युक्तियुक्त समायोजन का भार उतना हल्का।
2. रोज़गार क्षेत्र विकलांग व्यक्तियों के प्रति भेदभाव उन्मूलन अधिनियम के अधीन नहीं बल्कि विकलांग व्यक्तियों के रोज़गार संवर्धन अधिनियम के अधीन है। वही पत्रक कहता है कि रोज़गार और काम उस अधिनियम के प्रावधानों का पालन करते हैं।¹ और उस अधिनियम के अधीन, अप्रैल 2016 (हेइसेई 28) से प्रभावी संशोधन से, रोज़गार में विकलांगता भेदभाव का निषेध और अत्यधिक भार न होने वाली सीमा में युक्तियुक्त समायोजन देना नियोक्ताओं पर बाध्य है।² प्रारंभिक परामर्श “कर्मचारी व्यावसायिक ऐप उपयोग नहीं कर सकता” वास्तव में 2024 से बहुत पहले बाध्यता के क्षेत्र में रहा है।

flowchart TB
    accTitle: युक्तियुक्त समायोजन और पर्यावरण सुधार की स्थिति
    accDescr: सामान्य व्यवसाय और विकलांग व्यक्ति का संबंध भेदभाव उन्मूलन अधिनियम के अधीन है, और व्यक्तिगत अनुरोध का रचनात्मक संवाद से उत्तर देकर युक्तियुक्त समायोजन देना अप्रैल 2024 से बाध्यता है; रोज़गार क्षेत्र अप्रैल 2016 से रोज़गार संवर्धन अधिनियम के अधीन नियोक्ता बाध्यता है; ऐप को पहले आसान बनाना पर्यावरण सुधार, प्रयास-बाध्यता है
    scene{"कौन सा दृश्य?"}
    scene -->|"व्यवसाय + विकलांगता"| kaisho["भेदभाव अधिनियम"]
    scene -->|"रोज़गार / काम"| koyou["रोज़गार अधिनियम"]
    kaisho --> moushide["संवाद से अनुरोध"]
    moushide --> hairyo["समायोजन दें"]
    hairyo -.-> hairyoN["बाध्यता 2024 से"]
    koyou --> koyougimu["समायोजन दें"]
    koyougimu -.-> koyouN["बाध्यता 2016 से"]
    kaisho -.-> kankyo["पहले आसान ऐप"]
    kankyo -.-> kankyoN["पर्यावरण सुधार"]
    kankyoN -.-> kankyoN2["प्रयास-बाध्यता"]
    kankyo -.-> moushide

चित्र 2: शासी अधिनियम दृश्य से बँटता है; युक्तियुक्त समायोजन बाध्यता है, और अग्रिम सुधार पर्यावरण सुधार, प्रयास-बाध्यता है।

व्यक्तिगत मामला कानून में कैसे माना जाए स्थिति पर निर्भर करता है। यह लेख कानूनी व्याख्या में नहीं जाता; जब प्रतिक्रिया माँगी जाए तो अभियंता क्या कर सकता है, उस दृष्टि से आगे बढ़ता है। प्राथमिक स्रोतों के लिए कैबिनेट कार्यालय और स्वास्थ्य, श्रम एवं कल्याण मंत्रालय सामग्री देखें।¹²

2.2. 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 डेस्कटॉप ऐप पर वेब जैसे ही ढाँचे में लागू हो सकती है। इस लेख के अध्याय 3 से वह सोच ठोस 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 डेस्कटॉप ऐप"]

चित्र 3: JIS X 8341-3:2016 WCAG 2.0 की संगत मानक है, और WCAG2ICT उन्हीं मानदंडों को डेस्कटॉप ऐप तक बढ़ाता है।

3. सहायक प्रौद्योगिकी ऐप कैसे पढ़ती है — UI Automation की तिकड़ी

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

चित्र 4: स्क्रीन रीडर ऐप द्वारा UIA ट्री पर उजागर गुणधर्मियों और पैटर्नों का उपयोग घोषणा व संचालन के लिए करता है।

3.2. स्क्रीन रीडर एक 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 उजागर करने पर केंद्रित"]

चित्र 5: मुख्य स्क्रीन रीडर सभी UIA को पथ मानते हैं, इसलिए ऐप की प्रतिक्रिया UIA उजागर करने पर केंद्रित है।

3.3. “खाली Name वाला बटन” किस रूप में घोषित होता है?

एक ठोस उदाहरण। मानें टूलबार में सेव बटन केवल फ्लॉपी-डिस्क आइकन दिखाता है। दृष्टि वाले उपयोगकर्ता को आइकन अर्थ देता है, पर यदि Name खाली छोड़ा गया, स्क्रीन रीडर इस बटन को केवल “बटन” घोषित करता है। यदि पड़ोसी “खोलें” और “छापें” वही हों, उपयोगकर्ता केवल “बटन, बटन, बटन” सुनता है और नहीं जान सकता कौन सा कौन सा है। Microsoft की सुलभता-सुधार मार्गदर्शिका भी बिना Name बटन, और केवल “Image” घोषित चित्र, को प्रतिनिधि समस्याएँ मानती है जो उपयोगकर्ता का काम रोकती हैं।⁷

सौभाग्य से WinForms और WPF दोनों मानक नियंत्रणों में UIA सहायता शुरू से है, और कई मामलों में Name पाठ या लेबल से स्वतः तय होता है। जो टूटता है वह आमतौर पर (1) केवल आइकन, नाम की सामग्री नहीं, (2) लेबल से कोई संबंध नहीं, या (3) कस्टम ड्रॉइंग जो UIA ट्री पर जानकारी नहीं रखती, में से एक है। अगले दो अध्याय प्रति फ्रेमवर्क सुधार देखते हैं।

flowchart TB
    accTitle: घोषणा टूटने के तीन विशिष्ट तरीके
    accDescr: घोषणा तब टूटती है जब केवल आइकन होने से नाम की सामग्री नहीं, जब लेबल से संबंध नहीं, या जब कस्टम ड्रॉइंग UIA ट्री पर जानकारी नहीं रखती, और अंततः केवल बटन घोषित होती है
    c1["केवल आइकन, सामग्री नहीं"] --> broken["Name खाली हो जाता है"]
    c2["लेबल से संबंध नहीं"] --> broken
    c3["कस्टम ड्रॉइंग जानकारी नहीं देती"] --> broken
    broken --> result["केवल बटन घोषित"]

चित्र 6: घोषणा टूटना आमतौर पर तीन पैटर्नों में आता है: नाम सामग्री अपर्याप्त, संबंध अपर्याप्त, या कस्टम ड्रॉइंग।

4. WinForms में कार्यान्वयन — AccessibleName और टैब क्रम

4.1. नियंत्रण जिनका 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 स्पष्ट सेट करें"]

चित्र 7: 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["डिज़ाइनर फ़ाइल से संगत पंक्ति हटाएँ"]

चित्र 8: Properties फलक में साफ़ करने पर भी खाली स्ट्रिंग रहती है, इसलिए डिज़ाइनर फ़ाइल से संगत पंक्ति हटाकर ठीक करें।

4.2. आदेश-प्रवेश स्क्रीन पर सामान्य सुधार

व्यावसायिक ऐप में जो स्थान हम वास्तव में अक्सर ठीक करते हैं, चेकलिस्ट के रूप में सार हैं।

प्रत्येक कुछ पंक्तियों का सुधार है, पर स्क्रीन-रीडर उपयोगकर्ता के लिए यह “अनुपयोगी स्क्रीन” और “उपयोग योग्य स्क्रीन” का द्वार है।

5. WPF में कार्यान्वयन — AutomationProperties और AutomationPeer

5.1. AutomationProperties.Name / LabeledBy / HelpText

WPF में जिसका Content स्ट्रिंग हो, जैसे Button, वह सामग्री 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 नहीं"]

चित्र 9: WPF Name के लिए निर्णय क्रम Content स्ट्रिंग, LabeledBy, स्पष्ट सेटिंग है; TextBox का Text Name नहीं बनता।

Name में न समा पूरक जानकारी AutomationProperties.HelpText से उजागर हो सकती है।⁷ साथ ही AutomationId UI स्वचालित परीक्षण में तत्व पहचान का पहचानकर्ता है, इसलिए स्क्रीन-डिज़ाइन समय नामकरण सम्मेलन तय करना बाद में लाभ देता है (गहराई से “Windows डेस्कटॉप ऐप के लिए UI स्वचालित परीक्षण”)।

5.2. कस्टम नियंत्रण को 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["पहले से लागू व्यवहार लें"]

चित्र 10: कस्टम नियंत्रण 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 नियंत्रण
    participant p as AutomationPeer
    participant s as स्क्रीन रीडर
    c->>p: IsOnline मान बदलता है
    p->>s: Name गुण-परिवर्तन इवेंट उठाएँ
    s->>s: नई अवस्था घोषित करें
    Note over s: बिना इवेंट पुराने नाम पर रहता है

चित्र 11: मान परिवर्तन स्क्रीन रीडर तक तभी पहुँचता है जब AutomationPeer उसे परिवर्तन इवेंट से बताए।

यदि कस्टम नियंत्रण में संचालन हो (दब सके, मान बदल सके, चुना जा सके), GetPattern ओवरराइड कर IInvokeProvider या IRangeValueProvider जैसी पैटर्न इंटरफ़ेस दें।¹⁵ बिंदु यह है कि यदि Peer भी साझा-नियंत्रण-लाइब्रेरी पक्ष पर बनाएँ, उसका उपयोग करने वाली हर स्क्रीन स्वतः समर्थित हो जाती है। वही अध्याय 9 के “बग़ल में फैलाना” की नींव है।

6. क्या हर फ़ंक्शन केवल कीबोर्ड से पहुँचा जा सकता है?

WCAG सफलता मानदंड 2.1.1 (Keyboard) अपेक्षा करता है कि सामग्री की सभी कार्यक्षमता कीबोर्ड इंटरफ़ेस से संचालित हो।⁸ स्क्रीन-रीडर उपयोगकर्ता सिद्धांततः माउस नहीं उपयोग करता, इसलिए कीबोर्ड से न पहुँचने वाला फ़ंक्शन न होने के बराबर है। जाँच दृष्टियाँ निम्न हैं।

WinForms सुलभता वॉकथ्रू भी बुनियाद के रूप में इनपुट फ़ील्ड के ठीक पहले टैब क्रम में लेबल रखना, और जिन नियंत्रणों व मेनू पर उपयोगकर्ता जाना चाहे उन पर एक्सेस कुंजी रखना सूचीबद्ध करता है।¹²

जो ज़ोर देना चाहते हैं वह यह कि यह “विकलांगता सहायता की अतिरिक्त लागत” नहीं। आदेश प्रवेश जैसी नियमित नौकरी में, होम पोज़िशन से हाथ हटाए बिना इनपुट पूरा कर पाना ही संचालक की थ्रूपुट तय करता है। अव्यवस्थित टैब क्रम या माउस-आवश्यक संचालन वह दोष है जो हर उपयोगकर्ता की उत्पादकता हर दिन थोड़ी काटता है। सुलभता सहायता और कीबोर्ड दक्षता एक ही काम के दो नाम हैं (उपयोग वातावरण अनुसार प्राथमिकताओं के लिए “Windows ऐप UX डिज़ाइन” भी देखें)।

flowchart TB
    accTitle: कीबोर्ड सजाने का दोहरा प्रभाव
    accDescr: टैब क्रम, एक्सेस कुंजी और फ़ोकस संकेत सजाना एक साथ दो प्रभाव देता है — सहायक-प्रौद्योगिकी उपयोगकर्ता फ़ंक्शन तक पहुँचता है, और हर संचालक की इनपुट गति — और केवल माउस से उपयोग योग्य फ़ंक्शन न होने के बराबर है
    seibi["कीबोर्ड सजाएँ"] --> a11y["सहायक-टेक उपयोगकर्ता"]
    seibi --> speed["हर संचालक की गति"]
    mouse["केवल-माउस फ़ंक्शन"] -.-> none["न होने के बराबर"]

चित्र 12: कीबोर्ड संचालन सजाना सहायक-प्रौद्योगिकी सहायता और हर उपयोगकर्ता की दक्षता एक साथ साकार करता है; केवल-माउस फ़ंक्शन न होने के बराबर है।

7. रंग और कंट्रास्ट — 4.5:1 और “रंग एकमात्र साधन नहीं”

7.1. कंट्रास्ट अनुपात का मार्गदर्शक 4.5:1 है

WCAG सफलता मानदंड 1.4.3 (Contrast (Minimum)) पाठ और पाठ की छवियों के लिए कम से कम 4.5:1 कंट्रास्ट अनुपात, और बड़े पाठ के लिए कम से कम 3:1 अपेक्षित करता है।⁸ सफ़ेद पृष्ठभूमि पर हल्का-धूसर पाठ रखने वाला आधुनिक डिज़ाइन इस मानदंड से नीचे गिरना दुर्लभ नहीं। व्यावसायिक ऐप उपयोगकर्ताओं में वे शामिल हैं जिनकी दृष्टि और रंग दृष्टि उम्र से बदली, और जो कारखाने जैसी कम रोशनी में उपयोग करते हैं। डिज़ाइन समीक्षा पर कंट्रास्ट चेकर से मापने की आदत डालें।

7.2. जानकारी केवल रंग से न पहुँचाएँ

सफलता मानदंड 1.4.1 (Use of Color) है कि रंग जानकारी पहुँचाने का एकमात्र दृश्य साधन नहीं होना चाहिए।⁸ व्यावसायिक ऐप में विशिष्ट उदाहरण निम्न हैं।

• त्रुटि पंक्ति केवल लाल पाठ में दिखाना → त्रुटि आइकन और संदेश स्तंभ भी दें
• आवश्यक फ़ील्ड केवल लेबल रंग से दिखाना → “*” या शब्द “आवश्यक” जोड़ें
• स्थिति केवल लैंप रंग से दिखाना → रंग + आकार, या शब्द (“चल रहा”, “रुका”)

रंग दृष्टि की विविधता देखते यह भी “विशेष प्रतिक्रिया” नहीं बल्कि प्रदर्शन डिज़ाइन की बुनियाद है।

flowchart TB
    accTitle: केवल रंग से पहुँचाई जानकारी का प्रतिस्थापन
    accDescr: केवल लाल पाठ में त्रुटि दिखाने वाले प्रदर्शन को त्रुटि आइकन प्लस संदेश स्तंभ से बदला जाता है; केवल लेबल रंग से आवश्यक दिखाने को शब्द आवश्यक जोड़कर; केवल लैंप रंग से स्थिति को आकार या शब्द से जोड़कर
    err["केवल लाल पाठ में त्रुटि"] --> erra["आइकन और शब्द भी दें"]
    req["केवल लेबल रंग से आवश्यक"] --> reqa["शब्द आवश्यक जोड़ें"]
    lamp["केवल लैंप रंग से स्थिति"] --> lampa["रंग को आकार या शब्द से जोड़ें"]

चित्र 13: केवल रंग से पहुँचाने के विशिष्ट उदाहरण आइकन, शब्द, और आकार या पाठ जोड़कर बदले जाते हैं।

7.3. कंट्रास्ट थीम (उच्च कंट्रास्ट) का पालन

Windows में कंट्रास्ट थीम (पूर्व उच्च कंट्रास्ट) हैं जो अग्रभूमि और पृष्ठभूमि के मज़बूत अलगाव वाली रंग योजना पर स्विच करती हैं; उपयोगकर्ता अंतर्निर्मित थीमें चुन और संपादित कर सकता है जो कंट्रास्ट अनुपात सामान्यतः 7:1 या अधिक रखने के लिए डिज़ाइन हैं।⁹ ऐप पक्ष का सिद्धांत सरल है: रंग हार्ड-कोड न करें; सिस्टम रंगों का सम्मान करें।

• 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["सेटिंग-परिवर्तन इवेंट से पालन"]

चित्र 14: केवल जहाँ रंग हार्ड-कोड हो वहाँ कंट्रास्ट थीम में टूटता है; सिस्टम-रंग संदर्भ स्वतः पालन करता है।

साथ ही, कम दृष्टि वाला उपयोगकर्ता अक्सर उच्च OS आवर्धन (DPI स्केलिंग) उपयोग करता है, इसलिए उच्च-DPI सहायता भी सुलभता सहायता का हिस्सा है। ऐप जिसका लेआउट 125%–200% पर टूटे उस बिंदु पर अनुपयोगी है। विवरण के लिए “WinForms में उच्च-DPI सहायता” और “WPF उच्च-DPI सहायता” देखें।

8. व्यवहार में सत्यापन — Accessibility Insights और स्क्रीन-रीडर हाथों-हाथ जाँच

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

चित्र 15: Accessibility Insights के तीन उपयोग पुष्टि, पकड़ना और निदान हैं, और विरासत उपकरणों से जाने का गंतव्य है।

8.2. स्क्रीन रीडर से हाथों-हाथ जाँच

उपकरण की स्वचालित जाँच केवल यांत्रिक रूप से निर्णित समस्याएँ पकड़ सकती है। अंत में, हमेशा स्क्रीन रीडर से वास्तविक व्यावसायिक संचालन चलाएँ। Windows-निर्मित Narrator Ctrl+Windows कुंजी+Enter से तुरंत शुरू होता है, और NVDA निःशुल्क लाया जा सकता है।¹¹ जाँच की तरकीब स्क्रीन देखे बिना (या डिस्प्ले बंद) केवल घोषणा पर भरोसा कर यह आज़माना है कि “एक आदेश दर्ज कर पुष्टि करें” जैसा वास्तविक कार्य पूरा हो सकता है या नहीं। नाम होते हुए भी घोषणा क्रम असंगत होना, या फ़ोकस का मोडल से बाहर निकलना, केवल हाथों-हाथ मिलता है।

flowchart TB
    accTitle: उपकरण सत्यापन और हाथों-हाथ जाँच का संयोजन
    accDescr: FastPass जैसी स्वचालित जाँच केवल यांत्रिक रूप से निर्णित समस्याएँ पकड़ सकती है; शेष हाथों-हाथ स्क्रीन रीडर से वास्तविक व्यावसायिक संचालन चलाकर घोषणा-क्रम और फ़ोकस समस्याएँ खोजकर मिलता है
    tool["उपकरण की स्वचालित जाँच"] --> kikai["यांत्रिक रूप से निर्णित समस्याएँ"]
    tool -.-> nokori["न पकड़ी समस्याएँ रहती हैं"]
    nokori --> sr["स्क्रीन रीडर से हाथों-हाथ जाँच"]
    sr --> task["व्यावसायिक संचालन चलाएँ"]
    task --> mieru["घोषणा-क्रम और फ़ोकस समस्याएँ"]

चित्र 16: स्वचालित जाँच से यांत्रिक समस्याएँ सूचीबद्ध करें, और शेष स्क्रीन रीडर से हाथों-हाथ खोजें।

8.3. विकास प्रवाह में बनाना, और 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["दोनों से अदृश्य"]

चित्र 17: एक ही UIA आधार पर होने से UIA ट्री सजाना सहायक प्रौद्योगिकी और UI स्वचालित परीक्षण दोनों को लाभ देता है।

9. प्राथमिकताएँ कैसे तय करें — हर स्क्रीन एक साथ न ठीक करें

सैकड़ों स्क्रीन की कोर प्रणाली एक साथ ठीक करना लागत और गुणवत्ता दोनों में अयथार्थ है। जो दृष्टिकोण हम सुझाते हैं वह निम्न तीन स्तर हैं।

1. उन स्क्रीनों से ठीक करें जिन्हें वह उपयोगकर्ता नौकरी में उपयोग करता है। युक्तियुक्त समायोजन संबंधित व्यक्ति के अनुरोध का व्यक्तिगत उत्तर देने की प्रक्रिया है।¹ पहले व्यक्ति को स्क्रीन रीडर से वास्तविक नौकरी चलाने दें, और साथ पहचानें कहाँ अटकते हैं। कई मामलों में दैनिक काम की स्क्रीनें कुछ से एक दर्जन तक सिमटती हैं, और उनमें घातक समस्याएँ (बिना नाम बटन, कीबोर्ड से न दबने वाला पुष्टि बटन) दिनों के सुधार में हल हो सकती हैं।
2. नए विकास को मानक-अनुरूप बनाएँ। अध्याय 8 की चेकलिस्ट Definition of Done में जोड़ें, और नई स्क्रीनें शुरू से समर्थित बनाएँ। बाद के सुधार से भिन्न, डिज़ाइन समय बनाने की लागत वृद्धि मामूली है।
3. साझा नियंत्रण ठीक कर बग़ल में फैलाएँ। खोज संवाद, ग्रिड, या तिथि इनपुट जैसे साझा इन-हाउस भागों पर डिफ़ॉल्ट AccessibleName या AutomationPeer लागू करें तो वह उनका उपयोग करने वाली हर स्क्रीन पर बैच में प्रभावी होता है। व्यक्तिगत स्क्रीन एक-एक छूने से कहीं अधिक लागत-प्रभावी चाल है।

flowchart TB
    accTitle: सुधार प्राथमिकता के तीन स्तर
    accDescr: उपयोगकर्ता नौकरी में उपयोग करने वाली स्क्रीनों से ठीक करें, नई विकास को चेकलिस्ट से मानक-अनुरूप बनाएँ, और साझा नियंत्रण ठीक कर हर स्क्रीन तक फैलाएँ
    s1["1. उपयोगकर्ता की स्क्रीनों से ठीक करें"] --> s2["2. नया काम मानक-अनुरूप"] --> s3["3. साझा नियंत्रण से बग़ल में फैलाएँ"]
    s3 -.-> all["उनका उपयोग करने वाली हर स्क्रीन पर बैच में प्रभावी"]

चित्र 18: हर स्क्रीन एक साथ ठीक कर नहीं, बल्कि उपयोग में स्क्रीनें, नया काम, और साझा भागों के तीन स्तरों में आगे बढ़ें।

और संवाद का रिकॉर्ड तकनीकी प्रतिक्रिया जितना ही महत्वपूर्ण है। युक्तियुक्त समायोजन “व्यक्तिगत संवाद और समायोजन” की प्रक्रिया है, हर अनुरोध पूर्ण पूरा करने की नहीं। व्यक्ति के साथ वैकल्पिक साधन सोचना (वह काम दूसरी स्क्रीन पर करना, CSV निर्यात तैयार करना, संचालन में कवर करना) और अत्यधिक भार वाले सुधार पर सहमत होना भी रचनात्मक संवाद का वैध परिणाम है।¹ क्या माँगा गया, क्या उत्तर दिया गया, और क्या वैकल्पिक साधन बना, रिकॉर्ड करना संगठन की सद्भावना का प्रमाण बनता है।

flowchart TB
    accTitle: रचनात्मक संवाद और रिकॉर्ड का प्रवाह
    accDescr: विकलांग व्यक्ति के अनुरोध का रचनात्मक संवाद से उत्तर दें; जो सुधार हो सके करें; अत्यधिक भार वाले सुधार पर व्यक्ति से वैकल्पिक साधन सोचें और सहमत हों; क्या माँगा, क्या उत्तर दिया, क्या वैकल्पिक बना, रिकॉर्ड करें
    req["अनुरोध"] --> talk["रचनात्मक संवाद"]
    talk --> q{"क्या भार अत्यधिक है?"}
    q -->|"नहीं"| kaishu["सुधार से उत्तर दें"]
    q -->|"हाँ"| alt["वैकल्पिक साधन सोचें और सहमत हों"]
    kaishu --> rec["इतिहास रिकॉर्ड करें"]
    alt --> rec

चित्र 19: रचनात्मक संवाद में व्यक्ति से सुधार या वैकल्पिक साधन पर सहमत होते हैं, और वह इतिहास रिकॉर्ड में छोड़ते हैं।

10. सारांश

• अप्रैल 2024 से प्रभावी संशोधित विकलांग व्यक्तियों के प्रति भेदभाव उन्मूलन अधिनियम से युक्तियुक्त समायोजन देना व्यवसायों के लिए भी बाध्यता बन गया। रोज़गार क्षेत्र 2016 से विकलांग व्यक्तियों के रोज़गार संवर्धन अधिनियम के अधीन नियोक्ता बाध्यता है। ऐप को पहले आसान बनाना “पर्यावरण सुधार” (प्रयास-बाध्यता) है, और जितना आगे गया, व्यक्तिगत प्रतिक्रियाएँ उतनी हल्की।
• तकनीकी मानदंड WCAG (JIS X 8341-3:2016) में केंद्रित हैं, और वही सोच WCAG2ICT से डेस्कटॉप ऐप पर लागू हो सकती है।
• स्क्रीन रीडर ऐप को UI Automation से पढ़ता है। UIA ट्री, गुणधर्मियाँ (Name/ControlType/AutomationId), और नियंत्रण पैटर्न की तिकड़ी नींव है।
• सर्वोच्च प्राथमिकता Name है। WinForms AccessibleName और Label को टैब क्रम से जोड़ना उपयोग करता है; WPF AutomationProperties.Name/LabeledBy; कस्टम नियंत्रण AutomationPeer।
• हर फ़ंक्शन केवल कीबोर्ड से पहुँचना WCAG सफलता मानदंड है और साथ ही हर संचालक की उत्पादकता। टैब क्रम, एक्सेस कुंजी और फ़ोकस संकेत सजाएँ।
• रंग की तीन बुनियादें कंट्रास्ट अनुपात 4.5:1, रंग एकमात्र साधन नहीं, और कंट्रास्ट थीम में सिस्टम रंगों का सम्मान हैं।
• सत्यापन को Accessibility Insights के FastPass+Live Inspect और Narrator/NVDA से हाथों-हाथ जाँच से जोड़ें, और नई स्क्रीन की चेकलिस्ट के रूप में विकास प्रवाह में बनाएँ।
• हर स्क्रीन एक साथ न ठीक करें; उपयोगकर्ता की स्क्रीनें → नए काम के लिए मानक सहायता → साझा नियंत्रण का बग़ल रोल-आउट क्रम में आगे बढ़ें। युक्तियुक्त समायोजन संवाद की प्रक्रिया है, और इतिहास का रिकॉर्ड संगठन की रक्षा करता है।

पहले कदम के रूप में अपनी मुख्य स्क्रीनों में से एक चुनें, Accessibility Insights for Windows में FastPass चलाएँ, फिर केवल Tab कुंजी से नौकरी चलाएँ। तीस मिनट में आपके अपने ऐप की वर्तमान स्थिति आश्चर्यजनक रूप से ठोस हो जाती है।

संबंधित लेख

• Windows डेस्कटॉप ऐप के लिए UI स्वचालित परीक्षण — UI Automation कैसे काम करता है और FlaUI से मज़बूत परीक्षण बनाना
• Windows ऐप UX डिज़ाइन - उपयोग वातावरण अनुसार प्राथमिकताएँ
• WinForms में उच्च-DPI सहायता — 4K मॉनिटर पर UI क्यों धुंधला या टूटता है, और व्यावहारिक सुधार
• WPF उच्च-DPI सहायता — ‘DPI-जागरूक माना जाता’ होने पर भी क्यों धुंधला और रक्तस्राव, और कैसे ठीक करें
• KomuraSoft डिजिटल एजेंसी डिज़ाइन सिस्टम पर वेबसाइट क्यों बनाता है — कम लागत और उच्च गुणवत्ता साथ रह सकती हैं
• जापानी फ़ॉन्ट और वर्ण के जाल — व्यावसायिक ऐप में JIS2004, IVS और गाइजी सँभालना

संबंधित परामर्श क्षेत्र

KomuraSoft LLC WinForms/WPF व्यावसायिक ऐप की सुलभता सुधार (स्क्रीन-रीडर सहायता, कीबोर्ड संचालन सजाना, कंट्रास्ट-थीम सहायता), साझा नियंत्रणों पर AutomationPeer लागू करना, और Accessibility Insights से वर्तमान-स्थिति निदान व प्राथमिकता-निर्धारण परामर्श सँभालता है। “हम पुष्टि करना चाहते हैं कि कर्मचारी हमारा ऐप स्क्रीन रीडर से उपयोग कर सकता है या नहीं” चरण से शुरू करना ठीक है।

• Windows ऐप विकास
• तकनीकी परामर्श और डिज़ाइन समीक्षा
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

क्या व्यावसायिक ऐप की सुलभता सहायता कानून से आवश्यक है?

विकलांग व्यक्तियों के प्रति भेदभाव उन्मूलन अधिनियम का 2021 संशोधन 1 अप्रैल 2024 से प्रभावी हुआ, और विकलांग व्यक्तियों को युक्तियुक्त समायोजन देना व्यवसायों के लिए भी बाध्यता बन गया। युक्तियुक्त समायोजन वह प्रतिक्रिया है जो विकलांग व्यक्ति के अनुरोध पर व्यक्तिगत बाधा को उस सीमा में हटाती है जो अत्यधिक भार न हो; ऐप को पहले से उपयोग में आसान बनाना "पर्यावरण सुधार" नामक प्रयास-बाध्यता है। रोज़गार, जैसे कर्मचारी और कंपनी का संबंध, उस अधिनियम के अधीन नहीं बल्कि विकलांग व्यक्तियों के रोज़गार संवर्धन अधिनियम के अधीन है, जिसने अप्रैल 2016 से प्रभावी संशोधन से नियोक्ताओं को युक्तियुक्त समायोजन देने के लिए बाध्य किया। यानी "कर्मचारी व्यावसायिक ऐप उपयोग नहीं कर सकता" स्थिति कुछ समय से बाध्यता के क्षेत्र में है। किसी मामले में कितना जाना व्यक्तिगत स्थिति पर निर्भर करता है, इसलिए कैबिनेट कार्यालय और स्वास्थ्य, श्रम एवं कल्याण मंत्रालय के प्राथमिक स्रोत पुष्टि करें और संबंधित व्यक्ति से संवाद से निर्णय लें।

स्क्रीन रीडर 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 के पाठ कंट्रास्ट अनुपात 4.5:1 या अधिक को मार्गदर्शक मानना खराब रोशनी वाली दुकान और वृद्ध उपयोगकर्ताओं के लिए UI अधिक पठनीय बनाता है।

क्या सुलभता सहायता UI स्वचालित परीक्षण में भी मदद करती है?

हाँ। FlaUI जैसे UI स्वचालित-परीक्षण उपकरण उसी UI Automation पर बने हैं जिसका स्क्रीन रीडर उपयोग करते हैं। सुलभता के लिए रखे Name, ControlType और नियंत्रण पैटर्न परीक्षण कोड से ज्यों-के-त्यों उपयोग हो सकते हैं, और परीक्षणों के लिए डिज़ाइन किया AutomationId तत्व पहचान स्थिर करता है। इसके विपरीत कस्टम-ड्रॉ UI जो UIA ट्री में नहीं दिखता, स्क्रीन रीडर और परीक्षण दोनों के लिए अदृश्य है। सुलभता और स्वचालित परीक्षण एक ही आधार में निवेश हैं, इसलिए किसी एक को रखने से दूसरे की लागत भी घटती है।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।