स्क्रीन रीडर पूर्वावलोकन

वेब एक्सेसिबिलिटी मानकों का संक्षिप्त इतिहास

वेब पर एक्सेसिबिलिटी W3C वेब एक्सेसिबिलिटी इनिशिएटिव (WAI) के मानकों के एक छोटे ढेर और उनका संदर्भ देने वाले राष्ट्रीय कानूनों द्वारा शासित होती है। WCAG 1.0 मई 1999 में प्रकाशित हुआ था, वेब सामग्री को सुलभ बनाने पर पहला औपचारिक मार्गदर्शन। यह काफी हद तक HTML-केंद्रित था और जल्दी ही पुराना हो गया। WCAG 2.0 (दिसंबर 2008) चार सिद्धांतों (बोधगम्य, संचालनीय, समझने योग्य, मजबूत) और तीन अनुपालन स्तरों (A, AA, AAA) के आसपास संगठित एक बड़ा पुनर्लेखन था। यह 2012 में एक ISO मानक (ISO/IEC 40500) बन गया और अधिकांश कानूनों द्वारा अभी भी संदर्भित अनुपालन लक्ष्य है। WCAG 2.1 (जून 2018) ने मोबाइल, कम दृष्टि और संज्ञानात्मक विकलांगताओं को कवर करने वाले 17 नए सफलता मानदंड जोड़े। WCAG 2.2 (अक्टूबर 2023) ने 9 और जोड़े, विशेष रूप से 2.4.11 फोकस अस्पष्ट नहीं और 3.3.8 सुलभ प्रमाणीकरण। WAI-ARIA 1.0 मार्च 2014 में अंतिम रूप से तैयार किया गया था; 1.2 जून 2023 में वर्तमान अनुशंसा है। कानूनी पक्ष पर, अमेरिकी धारा 508 अद्यतन (जनवरी 2018) ने WCAG 2.0 AA को अमेरिकी संघीय खरीद में शामिल किया। यूरोपीय अभिगम्यता अधिनियम (निर्देश 2019/882) 28 जून 2025 को लागू हुआ, यूरोपीय संघ में अधिकांश उपभोक्ता-मुखी डिजिटल उत्पादों को अभिगम्यता मानकों को पूरा करने की आवश्यकता है। अधिकांश देश WCAG का संदर्भ देते हैं, इसलिए WCAG 2.2 AA के लिए निर्माण करना आज किसी भी वैश्विक उत्पाद के लिए व्यावहारिक लक्ष्य है।

आज के स्क्रीन रीडर परिदृश्य

WebAIM Screen Reader User Survey #10 (2024) उस बारे में आधिकारिक स्रोत है कि लोग वास्तव में किन स्क्रीन रीडर का उपयोग करते हैं। पाँच उत्पाद डेस्कटॉप, मोबाइल और ChromeOS पर हावी हैं।

• JAWS (Freedom Scientific, पहली बार 1989 में जारी) विंडोज पर लंबे समय से वाणिज्यिक नेता है। लागत ~$1000+। WebAIM 2024 इसे लगभग 40% सर्वेक्षण उत्तरदाताओं के लिए प्राथमिक स्क्रीन रीडर के रूप में पाता है, NVDA से थोड़ा कम।
• NVDA (NV Access, पहली बार 2006 में जारी, Python में लिखा गया) विंडोज के लिए ओपन-सोर्स विकल्प है। मुफ्त। WebAIM 2024 इसे सबसे अधिक उपयोग किए जाने वाले प्राथमिक स्क्रीन रीडर के रूप में रिपोर्ट करता है, लगभग 47% उत्तरदाता। 15 वर्षों में एक विशिष्ट उपकरण से बाजार के नेता के रूप में NVDA की वृद्धि सहायक तकनीक में महान ओपन-सोर्स सफलता कहानियों में से एक है।
• VoiceOver (Apple, 2005 में macOS पर, 2009 में iOS पर) हर Mac, iPhone, iPad, Apple Watch, Apple TV में बिल्ट-इन आता है। यह सबसे अधिक उपयोग किया जाने वाला मोबाइल स्क्रीन रीडर है। नेविगेशन के लिए Safari और iOS रोटर के साथ कसकर एकीकृत।
• TalkBack (Google, 2009 में Android पर) Android समकक्ष है। Android 4 के बाद से ओपन-सोर्स। इशारों और नेविगेशन मेनू का उपयोग करता है।
• ChromeVox (Google, 2012) और Narrator (Microsoft, 2000, Windows 10 में आधुनिकीकृत) चित्र को पूरा करते हैं। प्रत्येक के पास एक छोटा लेकिन वफादार उपयोगकर्ता आधार है।

एक ही पृष्ठ को प्रत्येक उत्पाद द्वारा अलग-अलग घोषित किया जा सकता है। मजबूत पृष्ठ कम से कम दो में स्वच्छ रूप से परीक्षण करते हैं: आमतौर पर NVDA + Firefox या Chrome, और VoiceOver + Safari।

इस उपकरण के लिए कब पहुंचें

• प्री-लॉन्च ऑडिट। एक मुख्य पृष्ठ (होमपेज, साइनअप फॉर्म, चेकआउट) पेस्ट करें और रैखिक आउटपुट को जोर से पढ़ें। यदि यह आपके लिए समझ में नहीं आता, तो यह स्क्रीन रीडर उपयोगकर्ता के लिए समझ में नहीं आएगा।
• कोड समीक्षा। महत्वपूर्ण मार्कअप परिवर्तनों के साथ PR को मर्ज करने से पहले, रेंडर किए गए HTML को पेस्ट करें और पुष्टि करें कि शीर्षक, स्थलचिह्न और alt टेक्स्ट बरकरार रहे।
• डिज़ाइन हैंडऑफ़ सत्यापन। डिज़ाइनर अपने अंतिम HTML को पेस्ट करके पुष्टि कर सकते हैं कि दृश्य पदानुक्रम अर्थपूर्ण पदानुक्रम से मेल खाता है। एक पृष्ठ जो शीर्षक की तरह दिखता है, उसे DOM में भी होना चाहिए।
• एक्सेसिबिलिटी सिखाना। किसी कक्षा या टीम को दिखाएं कि स्क्रीन रीडर वास्तव में क्या प्राप्त करता है। दृश्य लेआउट और रैखिक आउटपुट के बीच की खाई अक्सर पहली बार होती है जब गैर-विकलांग डेवलपर्स समझते हैं कि अर्थपूर्ण HTML क्यों मायने रखता है।
• WCAG के विरुद्ध अनुपालन जांच। चार सबसे अधिक उल्लंघन किए गए मानदंडों के लिए त्वरित स्पॉट चेक: 1.1.1 गैर-पाठ सामग्री (alt टेक्स्ट), 1.3.1 जानकारी और संबंध (अर्थपूर्ण संरचना), 2.4.4 लिंक उद्देश्य, 4.1.2 नाम, भूमिका, मान।
• CMS / नो-कोड साइट जांच। विज़ुअल संपादक अक्सर शीर्षक के बजाय divs या बिना टेक्स्ट के लिंक उत्पन्न करते हैं। प्रकाशित HTML पेस्ट करें, देखें कि क्या फिसल गया।
• ईमेल टेम्पलेट एक्सेसिबिलिटी। HTML ईमेल को सुलभ बनाना कुख्यात रूप से कठिन है। हर छवि पर alt टेक्स्ट, उचित शीर्षक क्रम और पठनीय पठन प्रवाह को सत्यापित करने के लिए पूर्वावलोकन का उपयोग करें।

स्क्रीन रीडर द्वारा उजागर सामान्य गलतियाँ

• गायब या बेकार alt टेक्स्ट। alt="image", alt="photo", alt="logo" कुछ नहीं से थोड़ा ही बेहतर हैं। Lazar et al. (2007) ने गायब alt टेक्स्ट को नेत्रहीन वेब उपयोगकर्ताओं की शीर्ष निराशा के रूप में पहचाना। alt टेक्स्ट लिखें जो आसपास के संदर्भ में छवि के उद्देश्य को व्यक्त करे, या विशुद्ध रूप से सजावटी छवियों के लिए alt="" का उपयोग करें ताकि स्क्रीन रीडर उन्हें छोड़ दे।
• शीर्षक स्तर जो छोड़ते हैं या पुनः आरंभ करते हैं। h2 को छोड़कर h1 से h3 पर जाना नेविगेशन को भ्रमित करता है। एक ही पृष्ठ पर कई h1 तत्वों का उपयोग करना (कंपोनेंट-संचालित डिज़ाइन में एक काफी सामान्य पैटर्न) उस दस्तावेज़ रूपरेखा को तोड़ता है जिसके द्वारा स्क्रीन रीडर उपयोगकर्ता नेविगेट करते हैं। WebAIM 2024 पाता है कि स्क्रीन रीडर उपयोगकर्ताओं के लिए शीर्षक सबसे आम नेविगेशन रणनीति है।
• Divitis। <button> या <a> का उपयोग करने के बजाय क्लिक हैंडलर के साथ <div> में क्लिक करने योग्य टेक्स्ट लपेटने का अर्थ है कोई कीबोर्ड समर्थन नहीं, कोई फोकस रिंग नहीं, कोई भूमिका घोषणा नहीं। हमेशा अर्थपूर्ण HTML से शुरू करें और ARIA केवल तभी जोड़ें जब कोई मूल तत्व फिट न हो।
• जहाँ HTML काम करता वहाँ ARIA का उपयोग। ARIA का पहला नियम (W3C WAI-ARIA लेखन प्रथाओं के अनुसार): «यदि आप किसी मूल HTML तत्व का उपयोग कर सकते हैं... तो ऐसा करें»। <button role="button"> अनावश्यक है; <div role="button"> एक संकेत है कि आपको इसके बजाय एक वास्तविक बटन का उपयोग करना चाहिए।
• ARIA गलत तरीके से उपयोग किया गया। एक फोकस करने योग्य तत्व पर aria-hidden="true" इसे स्क्रीन रीडर के लिए अदृश्य बनाता है लेकिन फिर भी कीबोर्ड-फोकस करने योग्य है, एक भ्रमित करने वाले टैब क्रम का नुस्खा। tabindex="0" और कीबोर्ड हैंडलर के बिना role="button" कुछ भी उपयोगी नहीं करता है।
• लेबल के बिना फॉर्म इनपुट। एक संबद्ध <label>, aria-label, या aria-labelledby के बिना एक <input> को बिना संदर्भ के «edit, blank» के रूप में घोषित किया जाता है। प्लेसहोल्डर टेक्स्ट एक विकल्प नहीं है, यह फोकस पर गायब हो जाता है और अक्सर कंट्रास्ट में विफल रहता है।
• «यहाँ क्लिक करें» और «अधिक पढ़ें» लिंक। स्क्रीन रीडर उपयोगकर्ता अक्सर पृष्ठ पर सभी लिंक की सूची निकालकर नेविगेट करते हैं। अकेले «यहाँ क्लिक करें» उन्हें कुछ नहीं बताता। लिंक टेक्स्ट को गंतव्य का वर्णन करें: «2024 WebAIM सर्वेक्षण पढ़ें» «यहाँ अधिक पढ़ें» को हराता है।
• फोकस शैलियों को हटाना। प्रतिस्थापन फोकस संकेतक के बिना outline: none सबसे अधिक उल्लंघन किए गए WCAG मानदंडों में से एक है (2.4.7 फोकस दृश्यमान)। कीबोर्ड उपयोगकर्ताओं, जिनमें कई स्क्रीन रीडर उपयोगकर्ता शामिल हैं, को देखने की आवश्यकता है कि फोकस कहाँ है।

एक नज़र में ARIA: प्रत्येक प्रकार की भूमिका क्या करती है

• स्थलचिह्न भूमिकाएँ (banner, navigation, main, complementary, contentinfo, search) पृष्ठ को क्षेत्रों में विभाजित करती हैं जिनके बीच एक स्क्रीन रीडर उपयोगकर्ता कूद सकता है। अधिकांश में मूल HTML समकक्ष हैं (<header>, <nav>, <main>, <aside>, <footer>)। पहले मूल तत्व का उपयोग करें।
• विजेट भूमिकाएँ (button, checkbox, combobox, menu, tabpanel, आदि) इंटरैक्टिव नियंत्रणों का वर्णन करती हैं। विजेट भूमिकाएँ कीबोर्ड इंटरैक्शन पैटर्न को दर्शाती हैं जिन्हें W3C ARIA लेखन प्रथाएँ गाइड (APG) विस्तार से दस्तावेज़ करता है। यदि आप APG विनिर्देश को सटीक रूप से मेल नहीं कर सकते हैं, तो मूल HTML को प्राथमिकता दें।
• दस्तावेज़ संरचना भूमिकाएँ (article, list, listitem, row, cell, आदि) गैर-इंटरैक्टिव सामग्री का वर्णन करती हैं। अधिकांश में मूल HTML समकक्ष भी होते हैं। उनका उपयोग केवल तभी करें जब मूल तत्व उपलब्ध न हो (उदा. एक कस्टम डेटा ग्रिड बनाना जहाँ <table> फिट नहीं होता)।
• लाइव क्षेत्र (aria-live="polite", aria-live="assertive", role="status", role="alert") स्क्रीन रीडर को फोकस स्थानांतरित किए बिना गतिशील अपडेट की घोषणा करने के लिए कहते हैं। चैट संदेशों, फॉर्म त्रुटियों, लोडिंग स्थितियों के लिए उपयोग किया जाता है। अति प्रयोग सूचना थकान का कारण बनता है; त्रुटि स्थितियों जैसे वास्तविक आपात स्थितियों के लिए assertive को आरक्षित करें।

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

क्या यह पूर्वावलोकन NVDA / JAWS / VoiceOver के वास्तव में कहने से मेल खाता है?

यह अनुमान लगाता है। यह उपकरण ब्राउज़र के एक्सेसिबिलिटी ट्री (वही संरचना जो स्क्रीन रीडर उपयोग करते हैं) को पढ़ता है और जो घोषित किया जाएगा उसका एक रैखिक संस्करण उत्पन्न करता है। वास्तविक स्क्रीन रीडर उत्पाद-विशिष्ट व्यवहार जोड़ते हैं: फोकस परिवर्तन की घोषणाएँ, तालिका नेविगेशन, तालिका शीर्षक, सूची आइटम गणना, ARIA-लाइव विनम्रता हैंडलिंग, कस्टम वाचालता सेटिंग्स। पूर्वावलोकन को पहले-पास के विवेक की जाँच के रूप में मानें; उत्पादन लॉन्च के लिए, अपने दर्शकों द्वारा उपयोग किए जाने वाले ऑपरेटिंग सिस्टम पर कम से कम एक वास्तविक स्क्रीन रीडर के साथ परीक्षण करें।

WCAG और ARIA के बीच क्या अंतर है?

WCAG (वेब सामग्री अभिगम्यता दिशानिर्देश) आवश्यकताओं की एक सूची है: «हर गैर-पाठ सामग्री में एक पाठ विकल्प होना चाहिए»। यह आपको बताता है कि क्या प्राप्त करना है लेकिन हमेशा कैसे नहीं। ARIA (सुलभ रिच इंटरनेट एप्लिकेशन) WCAG को पूरा करने के उपकरणों में से एक है: HTML विशेषताओं (भूमिकाएँ, राज्य, गुण) का एक सेट जो मूल HTML अपर्याप्त होने पर सहायक तकनीक को शब्दार्थ उजागर करता है। यदि आपका HTML पर्याप्त रूप से अर्थपूर्ण है तो आप बिना किसी ARIA के WCAG को पूरा कर सकते हैं। ARIA उन मामलों के लिए है जब यह नहीं है।

मैं अच्छा alt टेक्स्ट कैसे लिखूँ?

W3C के एक alt निर्णय वृक्ष से तीन नियम: (1) यदि छवि विशुद्ध रूप से सजावटी है, तो alt="" का उपयोग करें ताकि स्क्रीन रीडर इसे पूरी तरह से छोड़ दे। (2) यदि छवि आसपास के पाठ में पहले से मौजूद नहीं जानकारी प्रदान करती है, तो उस जानकारी का संक्षेप में वर्णन करें (आमतौर पर 125 वर्णों के तहत)। (3) यदि छवि कार्यात्मक है (उदा. एक लोगो जो होम से लिंक करता है, या एक आइकन बटन), तो उपस्थिति के बजाय क्रिया का वर्णन करें। «खोज» «आवर्धक कांच आइकन» को हराता है। «की छवि...», «की फोटो...» से बचें, स्क्रीन रीडर पहले से ही घोषणा करते हैं कि तत्व एक छवि है।

मेरी साइट हर जगह divs का उपयोग करती है। मैं कहाँ से शुरू करूँ?

पाँच स्थलचिह्न तत्वों को जोड़कर शुरू करें: <header>, <nav>, <main>, <aside>, <footer>। फिर क्लिक करने योग्य divs को <button> (क्रियाओं के लिए) या <a> (नेविगेशन के लिए) से बदलें। फिर शीर्षकों की ऑडिट करें: प्रत्येक पृष्ठ में एक <h1> और बाकी नेस्टेड क्रम में होने चाहिए। ये तीन कदम एक सामान्य div-भारी साइट पर शायद 70% एक्सेसिबिलिटी समस्याओं को ठीक करते हैं। ARIA और JavaScript फोकस प्रबंधन बाद में आता है, एक बार जब अर्थपूर्ण नींव अपनी जगह पर हो।

क्या मैं यहाँ जो HTML पेस्ट करता हूँ वह कहीं भेजा जाता है?

नहीं। पार्सिंग ब्राउज़र के बिल्ट-इन DOMParser का उपयोग करती है और विश्लेषण पूरी तरह से क्लाइंट-साइड चलता है। DevTools में नेटवर्क टैब खोलें और विश्लेषण पर क्लिक करें, आप रैखिककरण के दौरान शून्य आउटबाउंड अनुरोध देखेंगे। आंतरिक टेम्पलेट्स, अप्रकाशित पृष्ठों या ग्राहक डेटा वाले HTML के लिए सुरक्षित।