यह मॉड्यूल, सुलभता जांच के लिए सहायक टेक्नोलॉजी (AT) के इस्तेमाल पर फ़ोकस करता है. दिव्यांग व्यक्ति किसी काम को करने की क्षमता को बढ़ाने, बनाए रखने या बेहतर बनाने के लिए AT का इस्तेमाल कर सकते हैं.
डिजिटल स्पेस में, AT ये काम कर सकते हैं:
- नो/लो-टेक: हेड/माउथ स्टिक, हाथ में मौजूद मैग्निफ़ायर, बड़े बटन वाले डिवाइस
- हाई-टेक: आवाज़ से चालू होने वाले डिवाइस, आई-ट्रैकिंग डिवाइस, अडैप्टिव कीबोर्ड/माइस
- हार्डवेयर: स्विच बटन, एर्गोनॉमिक कीबोर्ड, अपने-आप रीफ़्रेश होने वाला ब्रेल डिवाइस
- सॉफ़्टवेयर: लिखाई को बोली में बदलने वाले प्रोग्राम, लाइव कैप्शन, स्क्रीन रीडर
हमारा सुझाव है कि आप अपने पूरे टेस्टिंग वर्कफ़्लो में कई तरह के ATs का इस्तेमाल करें.
स्क्रीन रीडर टेस्टिंग की बुनियादी बातें
इस मॉड्यूल में, हमारा फ़ोकस सबसे लोकप्रिय डिजिटल ATs, स्क्रीन रीडर पर है. स्क्रीन रीडर, सॉफ़्टवेयर का एक हिस्सा होता है. यह किसी वेबसाइट या ऐप्लिकेशन के कोड को पढ़ता है. इसके बाद, वह उस जानकारी को लोगों के लिए, बोली या ब्रेल आउटपुट में बदलता है.
जो लोग दृष्टिहीन और सुन नहीं सकते हैं, उनके लिए स्क्रीन रीडर बहुत ज़रूरी हैं. हालांकि, वे कम दृष्टि, पढ़ने से जुड़ी समस्या या सीखने-बात से जुड़ी दिव्यांगता वाले लोगों के लिए भी फ़ायदेमंद हो सकते हैं.
वेबसाइट का अलग-अलग ब्राउज़र पर चलना
स्क्रीन रीडर के कई विकल्प उपलब्ध हैं. फ़िलहाल, सबसे लोकप्रिय स्क्रीन रीडर डेस्कटॉप कंप्यूटर के लिए JAWS, NVDA, और VoiceOver हैं. साथ ही, मोबाइल डिवाइसों के लिए VoiceOver और Talkback भी शामिल हैं.
आपके ऑपरेटिंग सिस्टम (ओएस), पसंदीदा ब्राउज़र, और इस्तेमाल किए जाने वाले डिवाइस के आधार पर, एक स्क्रीन रीडर सबसे अच्छा विकल्प हो सकता है. ज़्यादातर स्क्रीन रीडर, खास हार्डवेयर और वेब ब्राउज़र को ध्यान में रखकर बनाए जाते हैं. जब किसी ऐसे ब्राउज़र के साथ स्क्रीन रीडर का इस्तेमाल किया जाता है जिसके लिए उसे कैलिब्रेट नहीं किया गया था, तो आपको ज़्यादा "गड़बड़ी" या अनचाहे व्यवहार का सामना करना पड़ सकता है. स्क्रीन रीडर सबसे अच्छे तरीके से तब काम करते हैं, जब इनका इस्तेमाल इन कॉम्बिनेशन में किया जाता है.
स्क्रीन रीडर के लिए निर्देश
डेस्कटॉप या मोबाइल डिवाइस के लिए, स्क्रीन रीडर सॉफ़्टवेयर को सही तरीके से सेट-अप करने के बाद, आपको स्क्रीन रीडर के दस्तावेज़ (पिछली टेबल में लिंक किए गए) देखने चाहिए. साथ ही, इस टेक्नोलॉजी के बारे में अच्छे से जानने के लिए, कुछ स्क्रीन रीडर के ज़रूरी निर्देशों का पालन करना चाहिए. अगर आपने पहले कभी स्क्रीन रीडर का इस्तेमाल किया है, तो नया स्क्रीन रीडर आज़माएं!
सुलभता जांच के लिए स्क्रीन रीडर का इस्तेमाल करते समय, आपका लक्ष्य कोड में मौजूद उन समस्याओं का पता लगाना होता है जो आपकी वेबसाइट या ऐप्लिकेशन के इस्तेमाल में रुकावट डालते हैं, न कि स्क्रीन रीडर का इस्तेमाल करने वाले लोगों के अनुभव को एम्युलेट करना. इसलिए, कुछ बुनियादी जानकारी, स्क्रीन रीडर के कुछ निर्देशों, और थोड़ी-बहुत या प्रैक्टिस की मदद से, बहुत कुछ किया जा सकता है.
अगर आपको स्क्रीन रीडर और दूसरे AT का इस्तेमाल करने वाले लोगों के उपयोगकर्ता अनुभव को और समझना है, तो यह अहम जानकारी पाने के लिए आपको कई संगठनों और लोगों से जुड़ना होगा. याद रखें कि नियमों के किसी सेट के ख़िलाफ़ कोड की जांच करने के लिए AT का इस्तेमाल करने और उपयोगकर्ताओं से उनके अनुभव के बारे में पूछने से अक्सर अलग नतीजे मिलते हैं. पूरी तरह से बिना किसी भेदभाव के सभी को ध्यान में रखकर बनाए जाने वाले प्रॉडक्ट बनाने के लिए, ये दोनों अहम पहलू हैं.
डेस्कटॉप स्क्रीन रीडर के लिए मुख्य निर्देश
मोबाइल स्क्रीन रीडर के लिए मुख्य निर्देश
स्क्रीन रीडर टेस्टिंग डेमो
डेमो की जांच करने के लिए, हमने MacOS वाले लैपटॉप पर Safari का इस्तेमाल किया और आवाज़ को कैप्चर किया. किसी भी स्क्रीन रीडर का इस्तेमाल करके यह तरीका अपनाया जा सकता है. हालांकि, कुछ गड़बड़ियों का सामना करने का तरीका, इस मॉड्यूल में बताए गए तरीके से अलग हो सकता है.
पहला चरण
अपडेट किए गए CodePen पर जाएं. इस पर अपने-आप और मैन्युअल तरीके से किए जाने वाले सभी अपडेट लागू हैं.
अगले टेस्ट पर जाने के लिए, इसे डीबग मोड में देखें. यह ज़रूरी है, क्योंकि यह डेमो वेबपेज के आस-पास मौजूद <iframe> को हटा देता है. इससे कुछ टेस्टिंग टूल में रुकावट आ सकती है. CodePen के डीबग मोड
के बारे में ज़्यादा जानें.
दूसरा चरण
अपनी पसंद के स्क्रीन रीडर को चालू करें और डेमो पेज पर जाएं. ऐसा हो सकता है कि खास समस्याओं पर ध्यान देने से पहले, आप पूरे पेज पर ऊपर से नीचे की ओर नेविगेट करें.
हमने डेमो में सुधार लागू होने से पहले और बाद में, हर समस्या के लिए अपने स्क्रीन रीडर को रिकॉर्ड किया है. हमारा सुझाव है कि आप इस डेमो को अपने स्क्रीन रीडर का इस्तेमाल करके देखें.
पहली समस्या: कॉन्टेंट का स्ट्रक्चर
शीर्षक और लैंडमार्क, स्क्रीन रीडर का इस्तेमाल करके नेविगेट करने के मुख्य तरीकों में से एक हैं. अगर ये मौजूद नहीं हैं, तो स्क्रीन रीडर का इस्तेमाल करने वाले व्यक्ति को संदर्भ समझने के लिए पूरा पेज पढ़ना होगा. इसमें ज़्यादा समय लग सकता है और इससे आपको परेशानी हो सकती है. अगर डेमो में किसी भी एलिमेंट के ज़रिए नेविगेट करने की कोशिश की जाती है, तो आपको तुरंत पता चल जाएगा कि वह एलिमेंट मौजूद नहीं है.
- लैंडमार्क उदाहरण:
<div class="main">...</div> - टाइटल का उदाहरण:
<p class="h1">Join the Club</p>
अगर आपने सब कुछ सही तरीके से अपडेट किया है, तो कोई विज़ुअल बदलाव नहीं होगा. हालांकि, इससे आपके स्क्रीन रीडर का अनुभव काफ़ी बेहतर हो जाएगा.
चलिए, इसे ठीक करते हैं.
कुछ ऐसी चीज़ें जिन्हें ऐक्सेस नहीं किया जा सकता, सिर्फ़ साइट को देखने से उन्हें पता नहीं लगाया जा सकता. आपको कॉन्टेंट स्ट्रक्चर मॉड्यूल में, हेडिंग लेवल और सिमैंटिक एचटीएमएल की अहमियत याद हो सकती है. कॉन्टेंट का कोई हिस्सा, किसी हेडिंग जैसा दिख सकता है, लेकिन असल में कॉन्टेंट को <div> स्टाइल से रैप किया जाता है.
हेडिंग और लैंडमार्क से जुड़ी समस्या को ठीक करने के लिए, आपको सबसे पहले हर उस एलिमेंट की पहचान करनी होगी जिसे इस तरह मार्क अप किया जाना चाहिए. साथ ही, आपको मिलते-जुलते एचटीएमएल को अपडेट करना होगा. साथ ही, मिलती-जुलती सीएसएस को भी अपडेट करें.
लैंडमार्क उदाहरण: <main>...</main>
टाइटल का उदाहरण: <h1>Join the Club</h1>
अगर आपने सब कुछ सही तरीके से अपडेट किया है, तो कोई विज़ुअल बदलाव नहीं होगा. हालांकि, इससे आपके स्क्रीन रीडर का अनुभव काफ़ी बेहतर हो जाएगा.
दूसरी समस्या: लिंक का कॉन्टेक्स्ट
यह ज़रूरी है कि स्क्रीन रीडर का इस्तेमाल करने वालों को लिंक के मकसद के बारे में जानकारी दी जाए. साथ ही, यह भी बताया जाए कि क्या लिंक उन्हें वेबसाइट या ऐप्लिकेशन के बाहर किसी नई जगह पर रीडायरेक्ट कर रहा है.
अपने डेमो में, हमने ऐक्टिव इमेज के वैकल्पिक टेक्स्ट को अपडेट करते समय ज़्यादातर लिंक ठीक कर दिए हैं. हालांकि, कई ऐसी बीमारियों के बारे में कुछ अतिरिक्त लिंक भी हैं जिन्हें ज़्यादा जानकारी देने से फ़ायदा हो सकता है—खास तौर पर ऐसा तब होता है, जब हम किसी नई जगह पर रीडायरेक्ट करते हैं.
<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease">
Maple syrup urine disease (MSUD)
</a>
स्क्रीन रीडर का इस्तेमाल करने वालों को इस समस्या को ठीक करने के लिए, हम विज़ुअल एलिमेंट पर असर डाले बिना ज़्यादा जानकारी जोड़ने के लिए, कोड को अपडेट करते हैं. इसके अलावा, पढ़ने और सीखने से जुड़ी बीमारियों से जूझ रहे लोगों जैसे और लोगों की मदद के लिए, हम अतिरिक्त विज़ुअल टेक्स्ट जोड़ सकते हैं.
लिंक की ज़्यादा जानकारी जोड़ने के लिए, हम कई अलग-अलग पैटर्न का इस्तेमाल कर सकते हैं. हमारे आसान माहौल के आधार पर, जो सिर्फ़ एक भाषा में काम करता है, उसके लिए ARIA लेबल एक आसान विकल्प है. आपको दिख सकता है कि ARIA लेबल, ओरिजनल लिंक टेक्स्ट को बदल देता है. इसलिए, अपने अपडेट में वह जानकारी ज़रूर शामिल करें.
<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease"
aria-label="Learn more about Maple syrup urine disease on the Rare Diseases website.">
Maple syrup urine disease (MSUD)
</a>
समस्या 3: सजावटी इमेज
हमारे अपने-आप होने वाले टेस्टिंग मॉड्यूल में, Lighthouse इनलाइन SVG को पिक अप नहीं कर सका. यह हमारे डेमो पेज पर, मुख्य स्प्लैश इमेज के तौर पर काम करता है. हालांकि, स्क्रीन रीडर को यह इमेज मिल गई और बिना किसी ज़्यादा जानकारी के "इमेज" के तौर पर उसके बारे में जानकारी दे दी गई. यह बात तब भी लागू होती है, जब SVG में role="img" एट्रिब्यूट साफ़ तौर पर न जोड़ा गया हो.
<div class="section-right">
<svg>...</svg>
</div>
इस समस्या को ठीक करने के लिए, हमें सबसे पहले यह तय करना होगा कि इमेज जानकारी देने वाला है या सजावटी है. उस फ़ैसले के आधार पर, हमें सही इमेज वैकल्पिक टेक्स्ट (जानकारी देने वाली इमेज) जोड़नी होगी या स्क्रीन रीडर का इस्तेमाल करने वालों के लिए उस इमेज को छिपाना होगा (सजावटी).
हमने इमेज को कैटगरी में बांटने के फ़ायदों और नुकसान को ध्यान में रखा और फ़ैसला लिया कि यह सजावटी है. इसका मतलब है कि हम इमेज को छिपाने के लिए कोड को जोड़ना चाहते हैं या उसमें बदलाव करना चाहते हैं. एक तेज़ तरीका यह है कि आप सीधे SVG इमेज में role="presentation" जोड़ें. इससे स्क्रीन रीडर को यह सिग्नल भेजा जाता है कि वह इस इमेज को छोड़कर आगे बढ़ जाए और इसे इमेज ग्रुप में शामिल न करे.
<div class="section-right">
<svg role="presentation">...</svg>
</div>
समस्या 4: बुलेट की सजावट
आपने देखा होगा कि स्क्रीन रीडर, खास बीमारियों वाले सेक्शन में मौजूद सीएसएस बुलेट इमेज को पढ़ता है. इमेज मॉड्यूल में जिस पुराने तरह की इमेज के बारे में चर्चा नहीं की गई है, वहीं इमेज में बदलाव करना ज़रूरी है. इससे कॉन्टेंट के फ़्लो में रुकावट आती है और इससे स्क्रीन रीडर का इस्तेमाल करने वाले व्यक्ति का ध्यान बंट सकता है या भ्रम में पड़ सकता है.
<p class="bullet">...</p>
जैसा कि ऊपर बताए गए सजावटी इमेज के उदाहरण में किया गया है, आप बुलेट क्लास के साथ एचटीएमएल में role="presentation" जोड़ सकते हैं, ताकि उसे स्क्रीन रीडर से छिपाया जा सके. इसी तरह, role="none" काम करेगा. बस यह पक्का करें कि आप aria-hidden: true का इस्तेमाल न करें. ऐसा न करने पर, स्क्रीन रीडर का इस्तेमाल करने वालों को पैराग्राफ़ की सारी जानकारी छिपा दी जाएगी.
<p class="bullet" role="none">...</p>
समस्या 5: फ़ॉर्म फ़ील्ड
फ़ॉर्म मॉड्यूल में, हमने सीखा कि सभी फ़ॉर्म फ़ील्ड में एक विज़ुअल और प्रोग्राम के हिसाब से, अपने-आप बनने वाला लेबल भी होना चाहिए. यह लेबल हमेशा दिखना चाहिए.
हमारे डेमो में, हमारे न्यूज़लेटर के लिए साइन-अप करने के ईमेल फ़ील्ड में विज़ुअल और प्रोग्राम के हिसाब से, अपने-आप होने वाला लेबल, दोनों मौजूद नहीं हैं. इस एलिमेंट में टेक्स्ट प्लेसहोल्डर एलिमेंट मौजूद है. हालांकि, यह लेबल को नहीं बदलता, क्योंकि यह विज़ुअल तौर पर लगातार नहीं दिखता. साथ ही, यह सभी स्क्रीन रीडर के साथ पूरी तरह काम नहीं करता.
<form>
<div class="form-group">
<input type="email" placeholder="Enter your e-mail address" required>
<button type="submit">Subscribe</button>
</div>
</form>
इस समस्या को ठीक करने के लिए, टेक्स्ट प्लेसहोल्डर को एक जैसे दिखने वाले लेबल एलिमेंट से बदलें. वह लेबल एलिमेंट, प्रोग्राम के हिसाब से फ़ॉर्म फ़ील्ड से कनेक्ट होता है. साथ ही, फ़ील्ड में कॉन्टेंट जोड़े जाने के बाद भी लेबल को बनाए रखने के लिए, मूवमेंट को JavaScript के साथ जोड़ा जाता है.
<form>
<div class="form-group">
<input type="email" required id="youremail" name="youremail" type="text">
<label for="youremail">Enter your e-mail address</label>
<button type="submit" aria-label="Subscribe to our newsletter">Subscribe</button>
</div>
</form>
आखिर में खास जानकारी
बधाई! आपने इस डेमो की सभी जांच पूरी कर ली है. ये सभी बदलाव इस डेमो के लिए अपडेट किए गए Codepen में देखे जा सकते हैं.
अब आप अपनी वेबसाइटों और ऐप्लिकेशन की सुलभता की समीक्षा करने के लिए, सीखी हुई बातों का इस्तेमाल कर सकते हैं.
इस सुलभता टेस्टिंग का मकसद ऐसी ज़्यादा से ज़्यादा समस्याओं का पता लगाना है जिनका सामना उपयोगकर्ता को करना पड़ सकता है. हालांकि, इसका मतलब यह नहीं है कि काम पूरा होने के बाद, आपकी वेबसाइट या ऐप्लिकेशन को आसानी से ऐक्सेस किया जा सकेगा. पूरी प्रोसेस के दौरान, अपनी वेबसाइट या ऐप्लिकेशन को सुलभता सुविधाओं के साथ डिज़ाइन करें. साथ ही, इन टेस्ट को प्री-लॉन्च टेस्टिंग में शामिल करके, आपको सबसे ज़्यादा सफलता मिलेगी.
आपने जो सीखा है उसकी जांच करें
अपने-आप होने वाली सुलभता सुविधाओं की जांच के बारे में अपनी जानकारी की जांच करें
सुलभता की जांच करने के लिए, सबसे अच्छा स्क्रीन रीडर कौनसा है?
सहायक टेक्नोलॉजी की मदद से टेस्ट करने का मकसद क्या होता है?