स्क्रीन रीडर टेस्टिंग

स्क्रीन रीडर semantics कैसे इस्तेमाल करते हैं

ब्राउज़र DOM को accessibility tree में बदलता है: एक समानांतर संरचना जिसमें हर अर्थपूर्ण element का role (button, link, heading, textbox), नाम, states और properties (expanded, checked, required, invalid) और संबंध होते हैं। ऑपरेटिंग सिस्टम का accessibility API यह tree स्क्रीन रीडर तक पहुँचाता है, जो उसे बोलता है या braille display पर भेजता है। Visual styling किसी element का role नहीं बदलती: button जैसा दिखने वाला div tree में फिर भी generic element है। फिर भी CSS का tree पर असर होता है: display: none और visibility: hidden कंटेंट को tree से हटा देते हैं, और CSS से बना टेक्स्ट (::before और ::after) accessible name का हिस्सा बन सकता है।

इसीलिए native HTML पहले आता है। button element का role button है, उसे फ़ोकस मिलता है, Enter और Space से चलता है और नाम अपने टेक्स्ट से लेता है — बिना अतिरिक्त कोड के। Headings (h1 से h6), lists, th वाली tables, label elements, fieldset और legend, और nav व main जैसे landmarks स्क्रीन रीडर यूज़र्स को वही संरचना देते हैं जो देखने वाले यूज़र देखते हैं। इस पेज की ज़्यादातर WCAG failures 1.3.1 Info and Relationships (संरचना प्रोग्राम से निर्धारित हो सके) और 4.1.2 Name, Role, Value (हर UI कंपोनेंट अपना name, role, states और value उजागर करे) के अंतर्गत आती हैं।

Windows पर डेस्कटॉप स्क्रीन रीडर के दो मुख्य मोड हैं। Browse mode (जिसे virtual cursor भी कहते हैं) में यूज़र arrow keys से पेज पढ़ता है और एक अक्षर से element के प्रकार पर कूदता है; focus mode (forms mode) में keystrokes फ़ोकस वाले कंट्रोल को जाती हैं, जिससे फ़ील्ड में टाइपिंग और arrow keys से widgets चलाना संभव होता है। कई कंट्रोल पर स्क्रीन रीडर अपने-आप मोड बदलते हैं; इस बदलाव को तोड़ने वाले custom widgets डिफ़ेक्ट का आम स्रोत हैं।

Accessible names और descriptions

Accessible name वह है जो स्क्रीन रीडर किसी element के लिए announce करता है, और वॉइस कंट्रोल यूज़र उसे चलाने के लिए यही बोलते हैं। ब्राउज़र इसे W3C की Accessible Name and Description Computation (accname 1.2, अभी Working Draft) के अनुसार निकालते हैं। सरल शब्दों में, नाम इनमें से पहले लागू होने वाले स्रोत से आता है:

• aria-labelledby — referenced element या elements का टेक्स्ट।
• aria-label — element पर ही लिखी string।
• Native labelling — फ़ॉर्म फ़ील्ड के लिए label element, images के लिए alt, tables के लिए caption, fieldset के लिए legend।
• Content — button, link और heading जैसे roles के लिए element का अपना टेक्स्ट।
• Fallbacks — title attribute और inputs के लिए ख़ाली फ़ील्ड के अंदर दिखने वाला hint टेक्स्ट; ये भरोसेमंद नहीं हैं और अकेला नाम नहीं होने चाहिए।

व्यवहार में names, labels और descriptions जाँचना

किसी element को सुनने से पहले ब्राउज़र developer tools के accessibility pane में उसका computed name, role और states देखें: यह बताता है कि कोई चीज़ जैसे announce होती है वैसे क्यों होती है। फिर तीन चीज़ें जाँचें। पहली, हर interactive element का नाम हो — सिर्फ़ icon वाले buttons (search, close, delete, menu) क्लासिक failure हैं। दूसरी, नाम में दिखने वाला label शामिल हो: 2.5.3 Label in Name माँगता है कि जिस कंट्रोल के label में टेक्स्ट है, उसके accessible name में वह टेक्स्ट हो, इसलिए "Send" दिखाने वाले बटन का नाम "Submit form" नहीं हो सकता। तीसरी, नाम संदर्भ से बाहर भी उपयोगी हो: बीस पतों की सूची में "Delete" की जगह "Delete address: 12 MG Road" बेहतर है।

Description अतिरिक्त जानकारी जोड़ता है, आमतौर पर aria-describedby से: पासवर्ड नियम, तारीख़ का फ़ॉर्मेट, फ़ील्ड से जुड़ा error message। Descriptions name और role के बाद announce होते हैं, कभी-कभी रुककर, और यूज़र उनमें से कुछ बंद कर सकते हैं, इसलिए ज़रूरी जानकारी नाम या दिखने वाले label में होनी चाहिए। फ़ॉर्म labels, निर्देश और error messages accessible फ़ॉर्म गाइड में विस्तार से कवर हैं।

Headings, landmarks और पेज टाइटल

स्क्रीन रीडर यूज़र शायद ही कभी पेज ऊपर से नीचे पढ़ते हैं। वे headings या landmarks की सूची खोलते हैं, या एक heading से दूसरी पर कूदते हैं, ताकि ज़रूरी हिस्सा मिले। इससे संरचना टेस्ट करने योग्य बनती है: headings सूची खोलें और जो दिखता है उससे तुलना करें। हर दिखने वाली heading असली heading element हो, levels hierarchy दिखाएँ (एक मुख्य h1, सेक्शन के लिए h2, उनके अंदर h3), और heading टेक्स्ट अपने सेक्शन का वर्णन करे (2.4.6 Headings and Labels)। heading जैसा दिखने वाला लेकिन markup न किया गया styled टेक्स्ट 1.3.1 फ़ेल करता है।

Landmarks पेज के क्षेत्र चिह्नित करते हैं: header (banner), nav (navigation), main, aside (complementary), footer (contentinfo), साथ में search और form regions। जाँचें कि मुख्य कंटेंट main के अंदर है, दोहराया navigation nav में है, और एक ही प्रकार के कई regions हों तो हर एक का label हो, जैसे "Main menu" और "Footer links"। अंत में, पेज टाइटल सबसे पहले announce होता है: 2.4.2 Page Titled ऐसा टाइटल माँगता है जो विषय या उद्देश्य बताए, और single-page applications को हर route change पर इसे अपडेट करना चाहिए।

Links, buttons, फ़ॉर्म कंट्रोल और images

Links ले जाते हैं; buttons काम करते हैं। फ़ॉर्म सबमिट करने वाला link, या दूसरे पेज पर ले जाने वाला button, यूज़र को उलझाता है क्योंकि role व्यवहार का अनुमान देता है। Link टेक्स्ट से या उसके संदर्भ से उसका उद्देश्य साफ़ हो (2.4.4 Link Purpose (In Context)); "Click here" और "Read more" से भरी links सूची links से नेविगेट करने वालों को निराश करती है। जिन buttons की state होती है वे उसे announce करें: toggle buttons के लिए aria-pressed, और menus, accordions व disclosures खोलने वाले buttons के लिए aria-expanded।

फ़ॉर्म कंट्रोल को नाम, role, मौजूदा value और state (required, invalid, checked, selected) चाहिए, और उनका error message जुड़ा हो ताकि announce हो — accessible फ़ॉर्म गाइड इसे विस्तार से कवर करती है। Images को ऐसा टेक्स्ट विकल्प चाहिए जो वही उद्देश्य पूरा करे (1.1.1 Non-text Content): जानकारी देने वाली images के लिए अर्थपूर्ण alt, सजावटी images के लिए ख़ाली alt ताकि स्क्रीन रीडर उन्हें छोड़ दे; विज़ुअल एक्सेसिबिलिटी गाइड alt text को विस्तार से कवर करती है।

ARIA: roles, states, properties और इस्तेमाल के नियम

WAI-ARIA 1.2 (W3C Recommendation) roles (element क्या है: tab, dialog, menu, alert), states (बदलने वाली स्थितियाँ: aria-expanded, aria-checked, aria-selected) और properties (ज़्यादा स्थिर विशेषताएँ: aria-label, aria-controls, aria-required) परिभाषित करता है। ARIA सिर्फ़ वही बदलता है जो accessibility tree में उजागर होता है; व्यवहार नहीं बदलता। ARIA Authoring Practices Guide साफ़ कहता है कि ARIA roles से ब्राउज़र कीबोर्ड व्यवहार या styling नहीं देते — role="button" वाले div को फिर भी tabindex और key handlers चाहिए।

W3C की दो बातें इसके इस्तेमाल का सार हैं। लंबे समय से चला आ रहा "first rule of ARIA use" कहता है कि अगर आप ऐसा native HTML element या attribute इस्तेमाल कर सकते हैं जिसमें ज़रूरी semantics और व्यवहार पहले से हैं, तो किसी दूसरे element पर ARIA जोड़ने की बजाय वही करें। और APG का "No ARIA is better than bad ARIA" चेतावनी देता है कि ग़लत ARIA स्क्रीन पर मौजूद चीज़ को ग़लत रूप में पेश करता है, जिससे अनुभव बिना ARIA से भी बदतर हो सकता है। टेस्टिंग में सबसे आम ARIA डिफ़ेक्ट:

• व्यवहार के बिना role — ऐसे elements पर role="button", role="tab" या role="checkbox" जिन्हें कीबोर्ड से फ़ोकस या ऑपरेट नहीं किया जा सकता।
• कभी न बदलने वाली states — मेन्यू खुलने के बाद भी aria-expanded "false" रहता है; दूसरा tab चुनने पर aria-selected नहीं हटता।
• focusable elements वाले कंटेंट पर aria-hidden="true", जिससे कीबोर्ड फ़ोकस ऐसी चीज़ पर जाता है जिसे स्क्रीन रीडर नहीं पहचानता।
• बिना role वाले सादे div या span पर aria-label — WAI-ARIA 1.2 generic role को नाम देना वर्जित करता है, इसलिए यह label शायद announce न हो।
• दिखने वाले label के विपरीत नाम, जो 2.5.3 Label in Name फ़ेल करता है।
• साधारण कंटेंट पर application roles — साइट navigation सूची पर role="menu", या पेज के किसी हिस्से पर role="application", जो स्क्रीन रीडर के keys सँभालने का तरीका बदल देता है।

Dynamic कंटेंट, live regions और status messages

पेज लोड के बिना बदलने वाली हर चीज़ स्क्रीन रीडर यूज़र के लिए अदृश्य है, जब तक वह announce न हो या फ़ोकस उस पर न जाए। दोनों में से सोच-समझकर चुनें। फ़ोकस तब हिलाएँ जब यूज़र को नए कंटेंट पर कार्रवाई करनी हो (dialog खुलना, नया page view लोड होना)। फ़ोकस हिलाए बिना announce तब करें जब यूज़र को बस पता होना चाहिए कि कुछ हुआ: "Saved", "3 results", "Item added to cart", "Uploading 40%"। दूसरा मामला ठीक 4.1.3 Status Messages है, जो माँगता है कि status messages role या properties से प्रोग्राम द्वारा निर्धारित हो सकें ताकि assistive technology उन्हें फ़ोकस मिले बिना प्रस्तुत कर सके।

इसके साधन live regions हैं। role="status" (polite: यूज़र के idle होने पर announce) result counts और पुष्टियों के लिए ठीक है; role="alert" (assertive: बीच में टोकता है) errors जैसे ज़रूरी, समय-संवेदी संदेशों के लिए है; role="log" chat और activity feeds के लिए। टेस्ट करते समय हर बदलाव ट्रिगर करें और सुनें। आम failures: live region उसी पल अपने टेक्स्ट के साथ पेज में डाला जाता है, इसलिए कुछ announce नहीं होता; region display: none से छिपा है; spinner हर आधे सेकंड "loading" बोलता है; या सब कुछ alert है और यूज़र लगातार टोका जाता है।

स्क्रीन रीडर और ब्राउज़र की जोड़ियाँ

स्क्रीन रीडर और ब्राउज़र जोड़ी में टेस्ट होते हैं, क्योंकि नतीजा दोनों मिलकर बनाते हैं। जोड़ियाँ अपने ऑडियंस डेटा और कॉन्ट्रैक्ट के accessibility support baseline से चुनें, सूची छोटी रखें, और हर स्प्रिंट में सब टेस्ट करने की बजाय रिलीज़ दर रिलीज़ उन्हें बदलते रहें।

• Windows — NVDA (मुफ़्त, open source) Firefox या Chrome के साथ; JAWS (commercial) Chrome या Edge के साथ; Windows में built-in Narrator, Edge के साथ।
• macOS — built-in VoiceOver, आमतौर पर Safari के साथ टेस्ट।
• iOS और iPadOS — VoiceOver, Safari और native ऐप्स के साथ।
• Android — TalkBack, Chrome और native ऐप्स के साथ।
• हर नतीजे के साथ स्क्रीन रीडर, ब्राउज़र और OS के वर्ज़न दर्ज करें; वर्ज़न बदलने पर व्यवहार बदलता है।

स्क्रीन रीडर टेस्ट का व्यावहारिक रूटीन

सारे commands सीखने की बजाय कुछ commands अच्छी तरह सीखें। यह रूटीन एक जोड़ी पर पंद्रह से तीस मिनट में ज़्यादातर पेज कवर करता है; शुरू में बोलने की गति आरामदायक रखें और जो सुनें उसे हूबहू लिखें।

• 1. पेज लोड करें — टाइटल announce हुआ? भाषा और आवाज़ सही है?
• 2. Headings सूची — NVDA में NVDA+F7 (Elements list); JAWS में Insert+F6; macOS VoiceOver में VO+U (rotor)। क्या outline दृश्य संरचना से मेल खाती है?
• 3. Landmarks — NVDA में D; JAWS में R; VoiceOver में rotor से Landmarks।
• 4. Links सूची — NVDA में NVDA+F7; JAWS में Insert+F7। क्या हर link अपने आप में समझ आता है?
• 5. क्रम से पढ़ें — NVDA/JAWS में Down Arrow; macOS VoiceOver में VO+Right Arrow; iOS VoiceOver और TalkBack में दाईं ओर swipe।
• 6. कंट्रोल चलाएँ — Tab से हर कंट्रोल पर जाएँ: name, role और state announce होते हैं? Enter/Space से चलाएँ; iOS/Android पर double-tap।
• 7. फ़ॉर्म — labels, required फ़ील्ड और submit पर errors announce होते हैं?
• 8. Dynamic बदलाव — toasts, filters और loading ट्रिगर करें: क्या वे फ़ोकस हिलाए बिना announce होते हैं?
• 9. Dialogs — अपने नाम के साथ dialog के रूप में announce होता है? पीछे का पेज चुप रहता है? बंद होने पर फ़ोकस लौटता है?
• 10. पूरा काम करें — एक असली प्रोसेस (search, checkout) सिर्फ़ स्क्रीन रीडर से पूरा करें।
• NVDA key = Insert (Caps Lock भी सेट किया जा सकता है), VO = Control+Option; NVDA+Space browse और focus mode के बीच बदलता है, और Ctrl बोलना रोकता है।

1. Load the page    Title announced? Language/voice correct?
2. Headings list    NVDA: NVDA+F7 (Elements list) · JAWS: Insert+F6 · VoiceOver macOS: VO+U (rotor)
                   Does the outline match the visual structure?
3. Landmarks        NVDA: D · JAWS: R · VoiceOver: rotor > Landmarks
4. Links list       NVDA: NVDA+F7 · JAWS: Insert+F7 — does each link make sense?
5. Read in order    NVDA/JAWS: Down Arrow · VoiceOver macOS: VO+Right Arrow
                   iOS VoiceOver / TalkBack: swipe right
6. Operate controls Tab to each control: name + role + state announced?
                   Activate: Enter/Space · iOS/Android: double-tap
7. Forms            Labels, required, errors announced on submit?
8. Dynamic changes  Trigger toasts, filters, loading: announced without focus move?
9. Dialogs          Announced as dialog with its name? Background silent? Focus returns on close?
10. Complete task   Finish one real process (search, checkout) with the screen reader only

NVDA key = Insert (Caps Lock can also be set) · VO = Control+Option
NVDA: NVDA+Space toggles browse/focus mode · Ctrl stops speech

आज़माएँ: AI QA चेकलिस्ट जनरेटर

स्क्रीन रीडर टेस्ट केस

इन्हें scope में हर पेज प्रकार और complete process के expected results के रूप में इस्तेमाल करें, और हर नतीजे के साथ जोड़ी दर्ज करें।

• SR-01 — लोड पर पेज टाइटल announce होता है और पेज का वर्णन करता है (2.4.2)।
• SR-02 — पेज की भाषा सही है और टेक्स्ट सही आवाज़ में पढ़ा जाता है; दूसरी भाषा के अंशों पर आवाज़ बदलती है (3.1.1, 3.1.2)।
• SR-03 — Headings सूची तार्किक levels के साथ दृश्य संरचना दिखाती है (1.3.1, 2.4.6)।
• SR-04 — main, navigation, header और footer landmarks मौजूद हैं; दोहराए landmark प्रकारों के labels हैं।
• SR-05 — हर link का उद्देश्य उसके टेक्स्ट या संदर्भ से साफ़ है (2.4.4)।
• SR-06 — हर button और कंट्रोल name, role और state announce करता है; toggles pressed या expanded बताते हैं (4.1.2)।
• SR-07 — जानकारी देने वाली images के अर्थपूर्ण विकल्प हैं; सजावटी images चुप हैं (1.1.1)।
• SR-08 — Custom widgets सही role और हर state बदलाव announce करते हैं (4.1.2)।
• SR-09 — Status messages फ़ोकस हिलाए बिना announce होते हैं (4.1.3)।
• SR-10 — Modal अपने नाम के साथ dialog के रूप में announce होता है, और खुले रहने तक पीछे का पेज नहीं पढ़ा जाता।
• SR-11 — कोई दिखने वाली चीज़ स्क्रीन रीडर से छिपी नहीं है, और कोई छिपी चीज़ पढ़ी नहीं जाती।
• SR-12 — कम से कम एक complete process सिर्फ़ स्क्रीन रीडर से पूरा किया जा सकता है।

डिफ़ेक्ट के उदाहरण

बग टाइटल के रूप में। रिपोर्ट में वर्ज़न सहित जोड़ी, स्टेप और सुना गया सटीक announcement जोड़ें — जैसे: NVDA 2026.x + Firefox, search icon पर Tab, सुना "button", अपेक्षित "Search, button"।

• "Search icon बटन बिना नाम के button के रूप में announce होता है" — 4.1.2 Name, Role, Value।
• "FAQ accordion headers expanded या collapsed state announce नहीं करते" — 4.1.2 Name, Role, Value।
• "Offers पेज पर बारह links, सभी Read more के रूप में announce" — 2.4.4 Link Purpose (In Context)।
• "सेक्शन टाइटल styled div elements हैं; headings सूची खाली है" — 1.3.1 Info and Relationships।
• "Filters लगाने के बाद result count announce नहीं होता" — 4.1.3 Status Messages।
• "Header पर aria-hidden, focusable menu बटन को स्क्रीन रीडर से छिपा देता है" — 4.1.2 Name, Role, Value।
• "Send बटन का aria-label Submit form है; वॉइस कमांड Click Send कुछ नहीं करती" — 2.5.3 Label in Name।
• "कंपनी लोगो logo-final-v2.png के रूप में announce होता है" — 1.1.1 Non-text Content।

आज़माएँ: AI बग टाइटल जनरेटर आज़माएँ: AI बग विवरण जनरेटर

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

संदर्भ

• Accessible Rich Internet Applications (WAI-ARIA) 1.2W3C · 2023W3C Recommendation जो ARIA roles, states और properties परिभाषित करती है — कस्टम विजेट अपना अर्थ सहायक तकनीक को कैसे बताते हैं।
• ARIA Authoring Practices Guide (APG)W3C Web Accessibility Initiative (WAI)आम विजेट (tabs, menus, dialogs, comboboxes) के पैटर्न, अपेक्षित कीबोर्ड इंटरैक्शन और ARIA उपयोग के साथ — वह संदर्भ जिससे टेस्टर कस्टम कंपोनेंट की तुलना करते हैं।
• Accessible Name and Description Computation 1.2W3C · 2026ब्राउज़र किसी एलिमेंट का accessible name और description लेबल, ARIA एट्रिब्यूट और कंटेंट से कैसे निकालते हैं (W3C Working Draft)।
• Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024W3C की Recommendation जो सुलभ वेब कंटेंट के लिए टेस्ट करने योग्य success criteria तय करती है — चार सिद्धांतों और तीन conformance स्तरों (A, AA, AAA) में व्यवस्थित।
• Understanding WCAG 2.2W3C Web Accessibility Initiative (WAI)WCAG 2.2 की हर guideline और success criterion की व्याख्या: उद्देश्य, किसे लाभ, उदाहरण और तकनीकें (नॉर्मेटिव नहीं)।
• Accessibility — MDNMDN Web Docs (Mozilla)सुलभ वेब पेज बनाने और जाँचने की व्यावहारिक गाइड: सिमैंटिक HTML, ARIA, कीबोर्ड सपोर्ट और टेस्टिंग।
• Accessibility — Human Interface GuidelinesAppleiOS और अन्य प्लेटफ़ॉर्म के लिए Apple की एक्सेसिबिलिटी डिज़ाइन गाइडेंस: VoiceOver, Dynamic Type, कंट्रास्ट, टच टारगेट और मोशन।
• Test your app's accessibilityAndroid Developers (Google)Android ऐप की एक्सेसिबिलिटी को TalkBack जैसी सेवाओं से मैन्युअली और प्लेटफ़ॉर्म के टेस्टिंग टूल से ऑटोमेटेड तरीके से कैसे जाँचें।