Windows app accessibility का परिचय — UI Automation और reasonable accommodation requirements की तैयारी

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

एक पृष्ठभूमि कानूनी ढाँचा है। विकलांग व्यक्तियों के प्रति भेदभाव उन्मूलन अधिनियम का 2021 amendment 1 अप्रैल 2024 से प्रभावी हुआ, और विकलांग व्यक्तियों को “reasonable accommodation देना” व्यवसायों के लिए भी obligation बन गया।¹ आगे, employee–कंपनी संबंध जैसा प्रारंभिक (employment क्षेत्र) विकलांग व्यक्तियों के रोजगार संवर्धन अधिनियम का क्षेत्र है, जिसने अप्रैल 2016 से employers को reasonable accommodation देने के लिए बाध्य किया है।² यह विचार कि “accessibility websites विषय है और in-house Windows app से कोई लेना-देना नहीं” अब न कानूनी रूप से टिकता है न practice में।

दूसरी ओर, development फर्श से “पता नहीं क्या करें” ईमानदार जगह है। Windows desktop app की accessibility पर web से कम जानकारी है, और कोई जादुई बाद-का समाधान नहीं। निराशा की भी ज़रूरत नहीं। यदि समझें कि screen reader app कैसे पढ़ता है (UI Automation) और name, keyboard व रंग की बुनियाद अपनाएँ, business app की usability काफी सुधरती है। और उसमें बहुत कुछ हर user की productivity बढ़ाता है, विकलांगता हो या न हो।

Japanese business-app developers और IT staff के लिए, यह लेख कानूनी ढाँचे और standards की न्यूनतम छँटाई से, UI Automation के mechanism, WinForms/WPF implementation, keyboard operations, रंग व contrast, और validation tools से होते हुए प्राथमिकताएँ तय करने के यथार्थ तरीके तक एक ही प्रवाह में जोड़ता है।

flowchart TB
    accTitle: इस लेख का प्रवाह
    accDescr: इस लेख की structure, कानूनी ढाँचे और standards की छँटाई से UI Automation के mechanism, WinForms और WPF implementation, keyboard operations, रंग व contrast, validation tools, और प्राथमिकताएँ तय करने तक क्रम से जोड़ती है
    law["कानूनी ढाँचा और standards छँटाई"] --> uia["UI Automation का mechanism"]
    uia --> impl["WinForms/WPF implementation"]
    impl --> kb["Keyboard operations"]
    kb --> color["रंग और contrast"]
    color --> verify["Validation tools"]
    verify --> prio["प्राथमिकताएँ कैसे तय करें"]

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

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

• Reasonable accommodation देना 1 अप्रैल 2024 से व्यवसायों के लिए भी obligation है। जब विकलांग व्यक्ति बाधा हटाने का आशय दर्शाए, excessive burden न होने वाली सीमा में response चाहिए। Employment क्षेत्र विकलांग व्यक्तियों के रोजगार संवर्धन अधिनियम के अधीन है, और वह अप्रैल 2016 से employer obligation है।¹²
• Reasonable accommodation “व्यक्तिगत अनुरोध का constructive dialogue से उत्तर” की process है; app को पहले से आसान बनाना “environmental improvement” (effort-obligation) है। पूर्ण अग्रिम support obligation नहीं; मायने यह है कि संवाद एकतरफा न ठुकराएँ।¹
• Accessibility के technical मानदंड WCAG (JIS X 8341-3:2016) में केंद्रित हैं। JIS X 8341-3:2016 WCAG 2.0 की identical-content corresponding standard है, और W3C का WCAG2ICT non-web software पर लागू करने का guidance देता है। Desktop apps उसी सोच से जाँचे जा सकते हैं।³⁴
• Screen reader app को UI Automation (UIA) से पढ़ता है। UIA tree पर प्रत्येक element की properties — Name, ControlType आदि — और Invoke, Value, SelectionItem जैसे control patterns announcement व operations की content हैं।⁵
• जिस button का Name खाली हो वह केवल “button” announce होता है। सर्वोच्च-प्राथमिकता सुधार naming है। WinForms AccessibleName और Label को tab order से जोड़ना उपयोग करता है; WPF AutomationProperties.Name/LabeledBy।⁶⁷
• हर function केवल keyboard से पहुँचना WCAG success criterion (2.1.1) है और साथ ही कुशल operator की input गति स्वयं। Tab order, access keys और focus indication रखना हर user की दक्षता से सीधे जुड़ता है।⁸
• Text contrast ratio 4.5:1 या अधिक मार्गदर्शक मानें, और जानकारी केवल रंग से न पहुँचाएँ। Contrast themes (high contrast) में hard-coded रंगों के बजाय system colors का सम्मान करें।⁸⁹
• Validation को Accessibility Insights for Windows के FastPass और screen reader से hands-on जाँच से जोड़ें। क्योंकि वे एक ही UIA foundation पर हैं, यह काम FlaUI जैसे UI automated-testing assets के साथ भी परस्पर लाभ देता है।¹⁰
• हर screen एक साथ ठीक करने की ज़रूरत नहीं। यथार्थ क्रम है (1) उन screens से जिन्हें वह user उपयोग करता है, (2) नया development standard-compliant, (3) shared controls ठीक कर बग़ल में फैलाएँ।

एक वाक्य में: Accessibility support “UIA tree पर सही name और operations expose करना, और keyboard व रंग की बुनियाद रखना” है।

2. कानूनी ढाँचे और standards की छँटाई — “obligation बनी” चीज़ क्या बदली

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

विकलांग व्यक्तियों के प्रति भेदभाव उन्मूलन अधिनियम वह कानून है जो administrative organs और व्यवसायों द्वारा विकलांग व्यक्तियों के “unjust discriminatory treatment” को प्रतिबंधित करता है, और “reasonable accommodation देना” अपेक्षित करता है। 2021 (Reiwa 3) amendment में व्यवसायों द्वारा reasonable accommodation देना, जो effort-obligation था, obligation बन गया, और संशोधित अधिनियम 1 अप्रैल 2024 (Reiwa 6) से प्रभावी हुआ।¹

Cabinet Office leaflet के अनुसार reasonable accommodation देना उस सीमा में response देना है जो excessive burden न हो, जब विकलांग व्यक्ति आशय दर्शाए कि समाज में बाधा हटाने के लिए कोई response चाहिए। और क्योंकि content विकलांगता विशेषता, दृश्य और स्थिति से भिन्न होती है, एक “constructive dialogue” जिसमें विकलांग व्यक्ति और व्यवसाय संवाद जोड़कर response साथ सोचें पर ज़ोर है। Constructive dialogue एकतरफा ठुकराना reasonable-accommodation obligation का उल्लंघन बन सकता है, कहा गया है।¹

यहाँ दो practical भेद मायने रखते हैं।

1. “पहले से सब कुछ रखना” वह नहीं जो obligation बनी। Unspecified संख्या के विकलांग व्यक्तियों के लिए अग्रिम सुधार उपाय — नरम पक्ष जैसे manual review और training, कठोर पक्ष जैसे सुविधा barrier-free बनाना — “environmental improvement” कहलाते हैं, और यह effort-obligation है।¹ Business app को screen reader से उपयोग योग्य अवस्था में पहले रखना environmental-improvement effort माना जा सकता है। जितना environmental improvement आगे बढ़ा, व्यक्तिगत reasonable accommodation का भार उतना हल्का।
2. Employment क्षेत्र विकलांग व्यक्तियों के प्रति भेदभाव उन्मूलन अधिनियम के अधीन नहीं बल्कि विकलांग व्यक्तियों के रोजगार संवर्धन अधिनियम के अधीन है। वही leaflet कहता है कि employment और काम उस अधिनियम के प्रावधानों का पालन करते हैं।¹ और उस अधिनियम के अधीन, अप्रैल 2016 (Heisei 28) से प्रभावी amendment से, employment में विकलांगता भेदभाव का निषेध और excessive burden न होने वाली सीमा में reasonable accommodation देना employers पर बाध्य है।² प्रारंभिक परामर्श “employee business app उपयोग नहीं कर सकता” वास्तव में 2024 से बहुत पहले obligation के क्षेत्र में रहा है।

flowchart TB
    accTitle: Reasonable accommodation और environmental improvement की स्थिति
    accDescr: सामान्य व्यवसाय और विकलांग व्यक्ति का संबंध भेदभाव उन्मूलन अधिनियम के अधीन है, और व्यक्तिगत अनुरोध का constructive dialogue से उत्तर देकर reasonable accommodation देना अप्रैल 2024 से obligation है; employment क्षेत्र अप्रैल 2016 से रोजगार संवर्धन अधिनियम के अधीन employer obligation है; app को पहले आसान बनाना environmental improvement, effort-obligation है
    scene{"कौन सा दृश्य?"}
    scene -->|"व्यवसाय + विकलांगता"| kaisho["भेदभाव अधिनियम"]
    scene -->|"Employment / काम"| koyou["रोजगार अधिनियम"]
    kaisho --> moushide["संवाद से अनुरोध"]
    moushide --> hairyo["Accommodation दें"]
    hairyo -.-> hairyoN["Obligation 2024 से"]
    koyou --> koyougimu["Accommodation दें"]
    koyougimu -.-> koyouN["Obligation 2016 से"]
    kaisho -.-> kankyo["पहले आसान app"]
    kankyo -.-> kankyoN["Environmental improvement"]
    kankyoN -.-> kankyoN2["Effort-obligation"]
    kankyo -.-> moushide

चित्र 2: शासी अधिनियम दृश्य से बँटता है; reasonable accommodation obligation है, और अग्रिम सुधार environmental improvement, effort-obligation है।

व्यक्तिगत मामला कानून में कैसे माना जाए स्थिति पर निर्भर करता है। यह लेख कानूनी व्याख्या में नहीं जाता; जब response माँगी जाए तो अभियंता क्या कर सकता है, उस दृष्टि से आगे बढ़ता है। Primary sources के लिए Cabinet Office और Ministry of Health, Labour and Welfare सामग्री देखें।¹²

2.2. JIS X 8341-3 और WCAG — “web मानदंड” software तक भी फैलते हैं

Technical-मानदंड पक्ष JIS X 8341-3:2016 में केंद्रित है। यह standard ISO/IEC 40500:2012 की corresponding standard है, और standard का मुख्य भाग W3C के WCAG 2.0 की identical content है।³ यदि ठोस जानना हो कि “accessibility support” क्या है, WCAG success criteria पढ़ना (अब WCAG 2.1/2.2 में विस्तारित) सबसे छोटा path है, और WAIC का Japanese translation भी published है।⁸

प्रश्न “क्या WCAG web content का मानदंड है?” उचित है, पर W3C ने WCAG2ICT (Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies) नामक Group Note में व्यवस्थित किया है WCAG 2.0/2.1/2.2 success criteria non-web documents और software पर कैसे लागू करें।⁴ यानी “text alternative”, “contrast”, “keyboard operations”, और “रंग एकमात्र साधन नहीं” जैसी सोच Windows desktop apps पर web जैसे ही ढाँचे में लागू हो सकती है। इस लेख के अध्याय 3 से वह सोच ठोस WinForms/WPF implementation में उतरती है।

flowchart TB
    accTitle: JIS X 8341-3 और WCAG का संबंध
    accDescr: JIS X 8341-3:2016 WCAG 2.0 की identical-content corresponding standard है, और WCAG2ICT दिखाता है WCAG success criteria non-web software पर कैसे लागू करें, इसलिए Windows desktop apps उसी ढाँचे में जाँचे जा सकते हैं
    wcag["WCAG 2.0（W3C）"] ---|"Identical content की corresponding standard"| jis["JIS X 8341-3:2016"]
    wcag --> ict["WCAG2ICT"]
    ict --> soft["Non-web software पर लागू"]
    soft --> app["Windows desktop app"]

चित्र 3: JIS X 8341-3:2016 WCAG 2.0 की corresponding standard है, और WCAG2ICT उन्हीं मानदंडों को desktop apps तक बढ़ाता है।

3. Assistive technology app कैसे पढ़ती है — UI Automation की तिकड़ी

3.1. UIA tree, properties और control patterns

Windows में UI Automation (UIA) नामक accessibility foundation बना है। UIA वह mechanism है जिससे screen readers जैसी assistive technology UI जानकारी पाती है और standard input के अलावा UI operate करती है, और यह app पक्ष (provider) व assistive-technology पक्ष (client) के बीच मध्यस्थता करता है।⁵

UIA की दुनिया निम्न तिकड़ी से समझी जा सकती है।⁵

जब screen reader button पर focus करता है, announcement “आदेश पुष्टि करें button” मोटे तौर पर Name + control type का combination है। जब user “execute” operation करे, assistive technology Invoke pattern से वह button दबाती है। यानी यदि Name और pattern सही expose हों तो पढ़ा और operate हो सकता है; यदि न हों, screen पर दिखने पर भी यह न होने के बराबर है।

flowchart TB
    accTitle: UI Automation की तिकड़ी
    accDescr: App provider के रूप में UIA tree पर प्रत्येक element की properties और control patterns expose करता है; screen reader client के रूप में Name और ControlType announce करता है और Invoke जैसे patterns से operate करता है
    app["App（provider）"] --> tree["UIA tree"]
    tree --> prop["Properties（Name, ControlType आदि）"]
    tree --> pat["Patterns（Invoke, Value आदि）"]
    sr["Screen reader（client）"] -->|"Announce करता है"| prop
    sr -->|"Operate करता है"| pat

चित्र 4: Screen reader app द्वारा UIA tree पर expose properties और patterns का उपयोग announcement व operations के लिए करता है।

3.2. Screen reader एक UIA client है

Windows पर मुख्य screen readers में Windows-built-in Narrator; निःशुल्क open-source NVDA;¹¹ और Japan में व्यापक commercial PC-Talker शामिल हैं। Announcement शैली भिन्न है, पर desktop app UI पढ़ने का primary path हर मामले में UIA है। इसलिए app-side response “किसी विशेष screen reader का support” नहीं बल्कि UIA को सही जानकारी expose करने पर केंद्रित है।

flowchart TB
    accTitle: मुख्य screen readers का साझा path
    accDescr: यदि app UIA को सही जानकारी expose करे, Narrator, NVDA और PC-Talker सभी उसी path से UI पढ़ सकते हैं, इसलिए app-side response किसी विशेष screen reader पर नहीं बल्कि UIA expose करने पर केंद्रित है
    app["App"] -->|"जानकारी expose"| uia["UI Automation（UIA）"]
    uia --> nar["Narrator"]
    uia --> nvda["NVDA"]
    uia --> pct["PC-Talker"]
    app -.-> goal["Response UIA expose करने पर केंद्रित"]

चित्र 5: मुख्य screen readers सभी UIA को path मानते हैं, इसलिए app की response UIA expose करने पर केंद्रित है।

3.3. “खाली Name वाला button” किस रूप में announce होता है?

एक ठोस उदाहरण। मानें toolbar में Save button केवल floppy-disk icon दिखाता है। दृष्टि वाले user को icon अर्थ देता है, पर यदि Name खाली छोड़ा गया, screen reader इस button को केवल “button” announce करता है। यदि पड़ोसी “खोलें” और “छापें” वही हों, user केवल “button, button, button” सुनता है और नहीं जान सकता कौन सा कौन सा है। Microsoft की accessibility-improvement guide भी बिना Name button, और केवल “Image” announce चित्र, को representative समस्याएँ मानती है जो user का काम रोकती हैं।⁷

सौभाग्य से WinForms और WPF दोनों standard controls में UIA support शुरू से है, और कई मामलों में Name text या label से automatic तय होता है। जो टूटता है वह usually (1) केवल icon, name की content नहीं, (2) label से कोई संबंध नहीं, या (3) custom drawing जो UIA tree पर जानकारी नहीं रखती, में से एक है। अगले दो अध्याय प्रति framework सुधार देखते हैं।

flowchart TB
    accTitle: Announcement टूटने के तीन typical तरीके
    accDescr: Announcement तब टूटती है जब केवल icon होने से name की content नहीं, जब label से संबंध नहीं, या जब custom drawing UIA tree पर जानकारी नहीं रखती, और अंततः केवल button announce होती है
    c1["केवल icon, content नहीं"] --> broken["Name खाली हो जाता है"]
    c2["Label से संबंध नहीं"] --> broken
    c3["Custom drawing जानकारी नहीं देती"] --> broken
    broken --> result["केवल button announce"]

चित्र 6: Announcement टूटना usually तीन patterns में आता है: name content अपर्याप्त, संबंध अपर्याप्त, या custom drawing।

4. WinForms में implementation — AccessibleName और tab order

4.1. Controls जिनका Text automatic Name बनता है, और जिनका नहीं

WinForms में text दिखाने वाला control, जैसे Button या CheckBox, Text property का मान UIA Name के रूप में उपयोग करता है। दूसरी ओर ComboBox, ListBox, ListView, PictureBox, ProgressBar, TabControl, TextBox, TreeView आदि Text को Name नहीं बनाते। इन्हें name किसी अन्य साधन से चाहिए।⁶

सबसे maintainable तरीका target control के ठीक पहले tab order में descriptive Label रखना है। यदि target control का TabIndex Label के TabIndex के ठीक बाद आए, वह Label text automatic UIA Name बनता है। Screen पर दिखने वाला label और announcement मेल खाते हैं, और शब्द दो बार सँभालने नहीं पड़ते।⁶¹²

यदि Label न रख सकें, AccessibleName स्पष्ट set करें। पूरक व्याख्या चाहिए तो AccessibleDescription, और भूमिका रूप से भिन्न हो तो AccessibleRole भी set कर सकते हैं।¹³

flowchart TB
    accTitle: WinForms control का name कैसे तय होता है
    accDescr: Button आदि के लिए Text ज्यों-का-त्यों UIA Name बनता है; TextBox जैसे controls जिनका Text reuse नहीं होता, ठीक पहले tab order के Label का text उपयोग होता है; Label न रख सकें तो AccessibleName स्पष्ट set करें
    ctrl["Control"] --> qtext{"क्या ऐसा प्रकार जिसका Text Name बने?"}
    qtext -->|"हाँ"| usetext["Text ज्यों का त्यों Name"]
    qtext -->|"नहीं"| qlabel{"ठीक पहले tab order में Label?"}
    qlabel -->|"हाँ"| uselabel["Label का text Name बनता है"]
    qlabel -->|"नहीं"| explicit["AccessibleName स्पष्ट set करें"]

चित्र 7: WinForms Name के लिए decision क्रम Text, ठीक पहले tab order का 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 pane में AccessibleName एक बार set कर फिर साफ़ करें, designer file में empty-string setting रह सकती है और default name resolution में बाधा डालती है। Designer file से matching पंक्ति हटाएँ।⁶

flowchart TB
    accTitle: Empty-string AccessibleName के रह जाने की समस्या
    accDescr: Properties pane में AccessibleName एक बार set कर साफ़ करने पर designer file में empty-string setting रह जाती है और default name resolution में बाधा डालती है, इसलिए designer file से matching पंक्ति हटाकर ठीक करें
    set["AccessibleName set करें"] --> erase["Properties pane में साफ़ करें"]
    erase --> remain["Empty-string setting रह जाती है"]
    remain --> block["Default name resolution में बाधा"]
    block -.-> fix["Designer file से matching पंक्ति हटाएँ"]

चित्र 8: Properties pane में साफ़ करने पर भी empty string रहती है, इसलिए designer file से matching पंक्ति हटाकर ठीक करें।

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

Business app में जो स्थान हम वास्तव में अक्सर ठीक करते हैं, checklist के रूप में सार हैं।

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

5. WPF में implementation — AutomationProperties और AutomationPeer

5.1. AutomationProperties.Name / LabeledBy / HelpText

WPF में जिसका Content string हो, जैसे Button, वह content UIA Name बनती है। केवल-icon button (Image या Path) में Name की content नहीं, इसलिए AutomationProperties.Name से बताएँ, या पास display text हो तो AutomationProperties.LabeledBy से जोड़ें।⁷

TextBox की महत्वपूर्ण चेतावनी है। TextBlock का Text Name के रूप में reuse होता है, पर TextBox का Text UIA Value property पक्ष पर expose होता है और Name नहीं बनता। Input fields के लिए display-label TextBlock को LabeledBy से जोड़ना पहला उम्मीदवार है। Announcement और on-screen display मेल खाते हैं, और शब्द दो बार सँभालने से बचते हैं।¹⁴

<!-- 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 control का name कैसे तय होता है
    accDescr: जिसका Content string हो वह content Name बनती है; अन्यथा पास display label को LabeledBy से जोड़ना पहला उम्मीदवार है; वह भी न हो तो AutomationProperties.Name बताएँ; TextBox का Text Value पक्ष पर expose होता है, Name नहीं
    ctrl["Control"] --> qc{"क्या Content string है?"}
    qc -->|"हाँ"| auto["Content Name बनती है"]
    qc -->|"नहीं"| ql{"पास display label?"}
    ql -->|"हाँ"| lb["LabeledBy से जोड़ें"]
    ql -->|"नहीं"| nm["Name स्पष्ट set करें"]
    tbx["TextBox का Text"] -.-> val["Value के रूप में expose, Name नहीं"]

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

Name में न समा पूरक जानकारी AutomationProperties.HelpText से expose हो सकती है।⁷ साथ ही AutomationId UI automated testing में element identification का identifier है, इसलिए screen-design time naming convention तय करना बाद में लाभ देता है (गहराई से “Windows desktop apps के लिए UI automated testing”)।

5.2. Custom control को AutomationPeer चाहिए

स्वयं खींचा custom control ज्यों-का-त्यों UIA tree पर अर्थपूर्ण जानकारी expose नहीं कर सकता। WPF में UIElement-derived class पर OnCreateAutomationPeer override करें और AutomationPeer-derived class लौटाकर name, type और patterns expose करें। यदि existing control से inherit ले रहे हों, matching Peer (ButtonBase के लिए ButtonBaseAutomationPeer) inherit में लेने से पहले से implement व्यवहार मिलता है।¹⁵

flowchart TB
    accTitle: AutomationPeer से जानकारी कैसे expose होती है
    accDescr: Custom control OnCreateAutomationPeer override कर AutomationPeer-derived class लौटाकर name, type और patterns expose करता है; existing control से inherit हों तो matching Peer inherit में लेकर पहले से implement व्यवहार लें
    custom["Custom control"] --> ov["OnCreateAutomationPeer"]
    ov --> peer["Peer-derived class लौटाएँ"]
    peer --> pub["Name, type और patterns expose"]
    inherit["Existing control से inherit"] -.-> basepeer["Matching Peer inherit में लें"]
    basepeer -.-> reuse["पहले से implement व्यवहार लें"]

चित्र 10: Custom control OnCreateAutomationPeer से Peer लौटाता है और UIA को जानकारी expose करता है।

// 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);
}

Name लौटाना पर्याप्त नहीं; बदलते ही event से बताना भी Peer का काम है। Assistive technology का मान दोबारा लाने का अपना समय नहीं, इसलिए जो implementation change event नहीं उठाता वह “फिर पूछे जाने पर ही सही” अवस्था में है, और screen-reader user को state change नहीं बताया जाता।

sequenceDiagram
    accTitle: Screen reader को state change बताने का प्रवाह
    accDescr: Control का मान बदलते ही AutomationPeer Name property-changed event उठाता है; assistive technology स्वयं दोबारा नहीं लाती, इसलिए बिना event पुराने name पर रहती है और change नहीं देखती
    participant c as Control
    participant p as AutomationPeer
    participant s as Screen reader
    c->>p: IsOnline मान बदलता है
    p->>s: Name property-changed event उठाएँ
    s->>s: नई state announce करें
    Note over s: बिना event पुराने name पर रहता है

चित्र 11: मान change screen reader तक तभी पहुँचता है जब AutomationPeer उसे change event से बताए।

यदि custom control में operations हों (दब सके, मान बदल सके, चुना जा सके), GetPattern override कर IInvokeProvider या IRangeValueProvider जैसी pattern interfaces दें।¹⁵ बिंदु यह है कि यदि Peer भी shared-control-library पक्ष पर बनाएँ, उसका उपयोग करने वाली हर screen automatic supported हो जाती है। वही अध्याय 9 के “बग़ल में फैलाना” की नींव है।

6. क्या हर function केवल keyboard से पहुँचा जा सकता है?

WCAG success criterion 2.1.1 (Keyboard) अपेक्षा करता है कि content की सभी functionality keyboard interface से operate हो।⁸ Screen-reader user सिद्धांततः mouse नहीं उपयोग करता, इसलिए keyboard से न पहुँचने वाला function न होने के बराबर है। जाँच दृष्टियाँ निम्न हैं।

WinForms accessibility walkthrough भी बुनियाद के रूप में input fields के ठीक पहले tab order में label रखना, और जिन controls व menus पर user जाना चाहे उन पर access keys रखना सूचीबद्ध करता है।¹²

जो ज़ोर देना चाहते हैं वह यह कि यह “विकलांगता support की extra लागत” नहीं। आदेश प्रवेश जैसी regular job में, home position से हाथ हटाए बिना input पूरा कर पाना ही operator की throughput तय करता है। अव्यवस्थित tab order या mouse-आवश्यक operations वह दोष है जो हर user की productivity हर दिन थोड़ी काटता है। Accessibility support और keyboard दक्षता एक ही काम के दो नाम हैं (उपयोग environment अनुसार प्राथमिकताओं के लिए “Windows app UX design” भी देखें)।

flowchart TB
    accTitle: Keyboard सजाने का दोहरा प्रभाव
    accDescr: Tab order, access keys और focus indication सजाना एक साथ दो प्रभाव देता है — assistive-technology user function तक पहुँचता है, और हर operator की input गति — और केवल mouse से उपयोग योग्य function न होने के बराबर है
    seibi["Keyboard सजाएँ"] --> a11y["Assistive-tech user"]
    seibi --> speed["हर operator की गति"]
    mouse["केवल-mouse function"] -.-> none["न होने के बराबर"]

चित्र 12: Keyboard operations सजाना assistive-technology support और हर user की दक्षता एक साथ साकार करता है; केवल-mouse functions न होने के बराबर हैं।

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

7.1. Contrast ratio का मार्गदर्शक 4.5:1 है

WCAG success criterion 1.4.3 (Contrast (Minimum)) text और text की images के लिए कम से कम 4.5:1 contrast ratio, और बड़े text के लिए कम से कम 3:1 अपेक्षित करता है।⁸ सफ़ेद background पर हल्का-धूसर text रखने वाला आधुनिक design इस मानदंड से नीचे गिरना दुर्लभ नहीं। Business app users में वे शामिल हैं जिनकी दृष्टि और रंग दृष्टि उम्र से बदली, और जो कारखाने जैसी कम रोशनी में उपयोग करते हैं। Design review पर contrast checker से मापने की आदत डालें।

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

Success criterion 1.4.1 (Use of Color) है कि रंग जानकारी पहुँचाने का एकमात्र visual साधन नहीं होना चाहिए।⁸ Business app में typical उदाहरण निम्न हैं।

• Error पंक्ति केवल लाल text में दिखाना → error icon और message column भी दें
• Required fields केवल label रंग से दिखाना → “*” या शब्द “आवश्यक” जोड़ें
• Status केवल lamp रंग से दिखाना → रंग + आकार, या शब्द (“चल रहा”, “रुका”)

रंग दृष्टि की विविधता देखते यह भी “विशेष response” नहीं बल्कि display design की बुनियाद है।

flowchart TB
    accTitle: केवल रंग से पहुँचाई जानकारी का replacement
    accDescr: केवल लाल text में error दिखाने वाले display को error icon प्लस message column से बदला जाता है; केवल label रंग से required दिखाने को शब्द आवश्यक जोड़कर; केवल lamp रंग से status को आकार या शब्द से जोड़कर
    err["केवल लाल text में error"] --> erra["Icon और शब्द भी दें"]
    req["केवल label रंग से required"] --> reqa["शब्द आवश्यक जोड़ें"]
    lamp["केवल lamp रंग से status"] --> lampa["रंग को आकार या शब्द से जोड़ें"]

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

7.3. Contrast themes (high contrast) का पालन

Windows में contrast themes (पूर्व high contrast) हैं जो foreground और background के मज़बूत अलगाव वाली color scheme पर switch करती हैं; user built-in themes चुन और edit कर सकता है जो contrast ratio सामान्यतः 7:1 या अधिक रखने के लिए design हैं।⁹ App पक्ष का सिद्धांत सरल है: रंग hard-code न करें; system colors का सम्मान करें।

• WinForms: यदि ForeColor/BackColor default पर छोड़ें, user की color setting उपयोग होती है। जहाँ अपना रंग लगाया हो, SystemInformation.HighContrast से जानें, SystemColors-based scheme पर switch करें, और UserPreferenceChanged event से setting change का पालन करें।¹²
• WPF/WinUI: यदि SystemColors-class resources reference करें, theme switch का पालन होता है। जहाँ अपना brush भरा हो वह टूटने का कारण बनता है।⁹

flowchart TB
    accTitle: Contrast themes का पालन
    accDescr: जहाँ रंग hard-code हो वहाँ contrast theme switch पर scheme टूटती है, इसलिए SystemColors-based scheme पर switch करें और setting-change event से पालन करें; system colors reference करें तो user के रंग automatic पालन होते हैं
    theme["Contrast theme पर switch"] --> qh{"रंग कैसे specify?"}
    qh -->|"Hard-code"| broken["Color scheme टूटती है"]
    qh -->|"System-color reference"| ok["User रंगों का automatic पालन"]
    broken -.-> fix["SystemColors पर switch"]
    fix -.-> ev["Setting-change event से पालन"]

चित्र 14: केवल जहाँ रंग hard-code हो वहाँ contrast themes में टूटता है; system-color reference automatic पालन करता है।

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

8. Practice में validation — Accessibility Insights और screen-reader hands-on जाँच

8.1. Accessibility Insights for Windows

Microsoft Windows apps के लिए accessibility validation tool के रूप में Accessibility Insights for Windows देता है, तीन मुख्य उपयोगों के साथ।¹⁰

• Live Inspect: Element पर mouse hover करें या keyboard-focus करें, और उसकी UIA properties (Name, ControlType, patterns आदि) confirm कर सकते हैं। “इस button का Name क्या है” देखने का सबसे छोटा साधन।
• FastPass: पाँच मिनट से कम में high-impact accessibility समस्याएँ पकड़ने वाली हल्की जाँच। Missing Name जैसी mechanically decided समस्याएँ प्रति नई screen list हो सकती हैं।
• Troubleshooting: विशेष समस्या के निदान और सुधार में सहायता। पकड़ी समस्या से इस लेख में उद्धृत per-framework सुधार guides तक सीधे चल सकते हैं।

Windows SDK में शामिल Inspect.exe और AccEvent भी UIA tree और properties confirm कर सकते हैं, पर वे legacy tools माने जाते हैं, और अब Accessibility Insights पर जाना recommended है।¹⁰

flowchart TB
    accTitle: Accessibility Insights के तीन उपयोग
    accDescr: Accessibility Insights for Windows Live Inspect से UIA properties confirm, FastPass से high-impact समस्याओं की हल्की जाँच, और Troubleshooting से निदान व सुधार सहायता देता है; Inspect.exe जैसे legacy tools से जाना recommended है
    ai["Accessibility Insights"] --> live["Live Inspect"]
    ai --> fast["FastPass"]
    ai --> ts["Troubleshooting"]
    live --> livef["UIA properties confirm"]
    fast --> fastf["High-impact समस्याएँ पकड़ें"]
    ts --> tsf["निदान और सुधार सहायता"]
    legacy["Inspect.exe आदि"] -.->|"जाना recommended"| ai

चित्र 15: Accessibility Insights के तीन उपयोग confirm, पकड़ना और निदान हैं, और legacy tools से जाने का destination है।

8.2. Screen reader से hands-on जाँच

Tool की automatic जाँच केवल mechanically decided समस्याएँ पकड़ सकती है। अंत में, हमेशा screen reader से वास्तविक business operations चलाएँ। Windows-built-in Narrator Ctrl+Windows key+Enter से तुरंत शुरू होता है, और NVDA निःशुल्क लाया जा सकता है।¹¹ जाँच की तरकीब screen देखे बिना (या display बंद) केवल announcement पर भरोसा कर यह आज़माना है कि “एक आदेश दर्ज कर पुष्टि करें” जैसा वास्तविक कार्य पूरा हो सकता है या नहीं। Name होते हुए भी announcement क्रम असंगत होना, या focus का modal से बाहर निकलना, केवल hands-on मिलता है।

flowchart TB
    accTitle: Tool validation और hands-on जाँच का combination
    accDescr: FastPass जैसी automatic जाँच केवल mechanically decided समस्याएँ पकड़ सकती है; शेष hands-on screen reader से वास्तविक business operations चलाकर announcement-क्रम और focus समस्याएँ खोजकर मिलता है
    tool["Tool की automatic जाँच"] --> kikai["Mechanically decided समस्याएँ"]
    tool -.-> nokori["न पकड़ी समस्याएँ रहती हैं"]
    nokori --> sr["Screen reader से hands-on जाँच"]
    sr --> task["Business operations चलाएँ"]
    task --> mieru["Announcement-क्रम और focus समस्याएँ"]

चित्र 16: Automatic जाँच से mechanical समस्याएँ list करें, और शेष screen reader से hands-on खोजें।

8.3. Development प्रवाह में बनाना, और UI automated testing से परस्पर लाभ

Validation व्यक्ति-निर्भर न रहे, इसके लिए नई screens की review मदों में निम्न checklist जोड़ने की सलाह है।

और एक और। FlaUI आदि से UI automated testing उसी UIA पर बना है जिसका screen reader उपयोग करते हैं। Accessibility के लिए रखे Name और patterns test code के भाग बनते हैं, और tests के लिए design किया AutomationId Live Inspect में debugging आसान करता है। इसके विपरीत UIA tree में न दिखने वाला UI tests और assistive technology दोनों के लिए invisible है। Accessibility और testability एक ही investment के दो पहलू हैं (“Windows desktop apps के लिए UI automated testing”)।

flowchart TB
    accTitle: Accessibility और UI automated testing का परस्पर लाभ
    accDescr: Screen reader और FlaUI जैसा UI automated testing एक ही UIA पर बने हैं, इसलिए रखे Name और patterns दोनों से उपयोग हो सकते हैं, और UIA tree में न दिखने वाला UI दोनों से invisible है
    uia["UIA tree सजाना"] --> sr["Screen reader पढ़ सकता है"]
    uia --> test["UI automated testing में उपयोग"]
    sr -.-> both["एक ही investment के दो पहलू"]
    test -.-> both
    hidden["UIA में न दिखने वाला UI"] -.-> invisible["दोनों से invisible"]

चित्र 17: एक ही UIA foundation पर होने से UIA tree सजाना assistive technology और UI automated testing दोनों को लाभ देता है।

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

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

1. उन screens से ठीक करें जिन्हें वह user job में उपयोग करता है। Reasonable accommodation संबंधित व्यक्ति के अनुरोध का व्यक्तिगत उत्तर देने की process है।¹ पहले व्यक्ति को screen reader से वास्तविक job चलाने दें, और साथ पहचानें कहाँ अटकते हैं। कई मामलों में दैनिक काम की screens कुछ से एक दर्जन तक सिमटती हैं, और उनमें घातक समस्याएँ (बिना name button, keyboard से न दबने वाला confirm button) दिनों के सुधार में हल हो सकती हैं।
2. नए development को standard-compliant बनाएँ। अध्याय 8 की checklist Definition of Done में जोड़ें, और नई screens शुरू से supported बनाएँ। बाद के सुधार से भिन्न, design time बनाने की लागत वृद्धि मामूली है।
3. Shared controls ठीक कर बग़ल में फैलाएँ। Search dialog, grid, या date input जैसे shared in-house parts पर default AccessibleName या AutomationPeer लागू करें तो वह उनका उपयोग करने वाली हर screen पर batch में प्रभावी होता है। व्यक्तिगत screens एक-एक छूने से कहीं अधिक cost-effective चाल है।

flowchart TB
    accTitle: सुधार प्राथमिकता के तीन स्तर
    accDescr: User job में उपयोग करने वाली screens से ठीक करें, नई development को checklist से standard-compliant बनाएँ, और shared controls ठीक कर हर screen तक फैलाएँ
    s1["1. User की screens से ठीक करें"] --> s2["2. नया काम standard-compliant"] --> s3["3. Shared controls से बग़ल में फैलाएँ"]
    s3 -.-> all["उनका उपयोग करने वाली हर screen पर batch में प्रभावी"]

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

और संवाद का record technical response जितना ही महत्वपूर्ण है। Reasonable accommodation “व्यक्तिगत संवाद और समायोजन” की process है, हर अनुरोध पूर्ण पूरा करने की नहीं। व्यक्ति के साथ वैकल्पिक साधन सोचना (वह काम दूसरी screen पर करना, CSV export तैयार करना, operations में cover करना) और excessive-burden वाले सुधार पर सहमत होना भी constructive dialogue का वैध परिणाम है।¹ क्या माँगा गया, क्या उत्तर दिया गया, और क्या वैकल्पिक साधन बना, record करना संगठन की सद्भावना का प्रमाण बनता है।

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

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

10. सारांश

• अप्रैल 2024 से प्रभावी संशोधित विकलांग व्यक्तियों के प्रति भेदभाव उन्मूलन अधिनियम से reasonable accommodation देना व्यवसायों के लिए भी obligation बन गया। Employment क्षेत्र 2016 से विकलांग व्यक्तियों के रोजगार संवर्धन अधिनियम के अधीन employer obligation है। App को पहले आसान बनाना “environmental improvement” (effort-obligation) है, और जितना आगे गया, व्यक्तिगत responses उतनी हल्की।
• Technical मानदंड WCAG (JIS X 8341-3:2016) में केंद्रित हैं, और वही सोच WCAG2ICT से desktop apps पर लागू हो सकती है।
• Screen reader app को UI Automation से पढ़ता है। UIA tree, properties (Name/ControlType/AutomationId), और control patterns की तिकड़ी नींव है।
• सर्वोच्च प्राथमिकता Name है। WinForms AccessibleName और Label को tab order से जोड़ना उपयोग करता है; WPF AutomationProperties.Name/LabeledBy; custom controls AutomationPeer।
• हर function केवल keyboard से पहुँचना WCAG success criterion है और साथ ही हर operator की productivity। Tab order, access keys और focus indication सजाएँ।
• रंग की तीन बुनियादें contrast ratio 4.5:1, रंग एकमात्र साधन नहीं, और contrast themes में system colors का सम्मान हैं।
• Validation को Accessibility Insights के FastPass+Live Inspect और Narrator/NVDA से hands-on जाँच से जोड़ें, और नई screens की checklist के रूप में development प्रवाह में बनाएँ।
• हर screen एक साथ न ठीक करें; user की screens → नए काम के लिए standard support → shared controls का बग़ल roll-out क्रम में आगे बढ़ें। Reasonable accommodation संवाद की process है, और इतिहास का record संगठन की रक्षा करता है।

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

संबंधित लेख

• Windows desktop apps के लिए UI automated testing — UI Automation कैसे काम करता है और FlaUI से मज़बूत tests बनाना
• Windows app UX design - उपयोग environment अनुसार प्राथमिकताएँ
• WinForms में high-DPI support — 4K monitor पर UI क्यों धुंधला या टूटता है, और practical सुधार
• WPF high-DPI support — ‘DPI-aware माना जाता’ होने पर भी क्यों धुंधला और bleeding, और कैसे ठीक करें
• KomuraSoft Digital Agency Design System पर website क्यों बनाता है — कम लागत और उच्च quality साथ रह सकती हैं
• Japanese fonts और character के जाल — business apps में JIS2004, IVS और gaiji सँभालना

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

KomuraSoft LLC WinForms/WPF business apps की accessibility सुधार (screen-reader support, keyboard operations सजाना, contrast-theme support), shared controls पर AutomationPeer लागू करना, और Accessibility Insights से current-status निदान व प्राथमिकता-निर्धारण परामर्श सँभालता है। “हम confirm करना चाहते हैं कि employee हमारा app screen reader से उपयोग कर सकता है या नहीं” चरण से शुरू करना ठीक है।

• Windows app development
• Technical consulting और design review
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

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

संबंधित विषय

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

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

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

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

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

क्या business app की accessibility support कानून से आवश्यक है?

विकलांग व्यक्तियों के प्रति भेदभाव उन्मूलन अधिनियम का 2021 amendment 1 अप्रैल 2024 से प्रभावी हुआ, और विकलांग व्यक्तियों को reasonable accommodation देना व्यवसायों के लिए भी obligation बन गया। Reasonable accommodation वह response है जो विकलांग व्यक्ति के अनुरोध पर व्यक्तिगत बाधा को उस सीमा में हटाती है जो excessive burden न हो; app को पहले से उपयोग में आसान बनाना "environmental improvement" नामक effort-obligation है। Employment, जैसे employee और कंपनी का संबंध, उस अधिनियम के अधीन नहीं बल्कि विकलांग व्यक्तियों के रोजगार संवर्धन अधिनियम के अधीन है, जिसने अप्रैल 2016 से प्रभावी amendment से employers को reasonable accommodation देने के लिए बाध्य किया। यानी "employee business app उपयोग नहीं कर सकता" स्थिति कुछ समय से obligation के क्षेत्र में है। किसी मामले में कितना जाना व्यक्तिगत स्थिति पर निर्भर करता है, इसलिए Cabinet Office और Ministry of Health, Labour and Welfare के primary sources confirm करें और संबंधित व्यक्ति से संवाद से decision लें।

Screen reader Windows desktop app कैसे पढ़ता है?

Narrator और NVDA जैसे screen readers app के UI को UI Automation (UIA) नामक accessibility foundation से पढ़ते हैं। App पक्ष on-screen elements को UIA tree नामक structure में expose करता है; प्रत्येक element में Name (उद्देश्य) और ControlType (प्रकार) जैसी properties, और Invoke (दबाएँ) व Value (मान) जैसे control patterns होते हैं। Screen reader यह जानकारी "आदेश पुष्टि करें button" के रूप में announce करता है और pattern से operate करता है। Standard WinForms और WPF controls में यह mechanism शुरू से है, इसलिए developer का मुख्य काम Name खाली न छोड़ना, UI को keyboard से operable बनाना, और custom controls पर जानकारी लागू करना है।

Existing WinForms app पर कहाँ से शुरू करें?

सबसे छोटा path target screen पर Accessibility Insights for Windows का FastPass चलाना और खाली Name वाले controls व tab-order समस्याएँ list करना है। सुधार icon-only buttons पर AccessibleName set करने, input fields के ठीक पहले tab order में Label जोड़ने, और TabIndex को visual order से मिलाने से शुरू होते हैं। फिर Narrator या NVDA शुरू करें और screen देखे बिना वास्तविक business operations चलाएँ, और confirm करें कहाँ अटकते हैं। हर screen एक साथ ठीक करने की ज़रूरत नहीं; जिन screens को कोई वास्तव में उपयोग करता है उनसे शुरू करना, और नई screens को checklist से standard-compliant बनाना, यथार्थ है।

High-contrast (contrast themes) support के लिए क्या करें?

Base रंग hard-code न करना और system colors का सम्मान करना है। WinForms में ForeColor/BackColor default पर छोड़ें या SystemColors उपयोग करें, स्थिति SystemInformation.HighContrast से जानें, और switch का UserPreferenceChanged event से पालन करें। WPF और WinUI में भी, यदि SystemColors-class resources reference करें, theme switch automatic पालन होता है। साथ ही जानकारी "केवल रंग से" न पहुँचाएँ — error केवल लाल दिखाना — और इसे icon या शब्द से जोड़ें। Ordinary theme में भी WCAG के text contrast ratio 4.5:1 या अधिक को मार्गदर्शक मानना खराब रोशनी वाली दुकान और वृद्ध users के लिए UI अधिक readable बनाता है।

क्या accessibility support UI automated testing में भी मदद करती है?

हाँ। FlaUI जैसे UI automated-testing tools उसी UI Automation पर बने हैं जिसका screen reader उपयोग करते हैं। Accessibility के लिए रखे Name, ControlType और control patterns test code से ज्यों-के-त्यों उपयोग हो सकते हैं, और tests के लिए design किया AutomationId element identification स्थिर करता है। इसके विपरीत custom-drawn UI जो UIA tree में नहीं दिखता, screen reader और tests दोनों के लिए invisible है। Accessibility और automated testing एक ही foundation में investment हैं, इसलिए किसी एक को रखने से दूसरे की लागत भी घटती है।

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

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

Go Komura

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

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