इस मॉड्यूल में, सुलभता की टेस्टिंग के लिए, सहायक टेक्नोलॉजी (एटी) का इस्तेमाल करने पर फ़ोकस किया गया है. कोई व्यक्ति, एटी का इस्तेमाल करके किसी टास्क को पूरा करने की अपनी क्षमता को बढ़ा सकता है, उसे बनाए रख सकता है या बेहतर बना सकता है.
डिजिटल स्पेस में, एटी ये हो सकती हैं:
- कम या बिना टेक्नोलॉजी वाली एटी: हेड और माउथ स्टिक, हाथ से पकड़कर इस्तेमाल किए जाने वाले मैग्निफ़ायर, बड़े बटन वाले डिवाइस
- ज़्यादा टेक्नोलॉजी वाली एटी: आवाज़ से चालू होने वाले डिवाइस, आंखों की गतिविधि को ट्रैक करने वाले डिवाइस, अडैप्टिव कीबोर्ड और माउस
- हार्डवेयर: स्विच बटन, एर्गोनॉमिक कीबोर्ड, अपने-आप रीफ़्रेश होने वाला ब्रेल डिवाइस
- सॉफ़्टवेयर: टेक्स्ट-टू-स्पीच प्रोग्राम, लाइव कैप्शन, स्क्रीन रीडर
हमारा सुझाव है कि आप अपनी पूरी टेस्टिंग वर्कफ़्लो में, कई तरह की एटी का इस्तेमाल करें.
स्क्रीन रीडर की टेस्टिंग की बुनियादी बातें
इस मॉड्यूल में, हम डिजिटल एटी के सबसे लोकप्रिय टाइप, स्क्रीन रीडर पर फ़ोकस करते हैं. स्क्रीन रीडर एक ऐसा सॉफ़्टवेयर है जो किसी वेबसाइट या ऐप्लिकेशन के कोड को पढ़ता है. इसके बाद, वह जानकारी को उपयोगकर्ता के लिए, आवाज़ या ब्रेल आउटपुट में बदलता है.
स्क्रीन रीडर, दृष्टिहीन और बहरेपन के साथ-साथ दृष्टिहीनता की समस्या वाले लोगों के लिए ज़रूरी हैं. हालांकि, ये कमज़ोर नज़र वाले लोगों, पढ़ने से जुड़ी समस्याओं, और संज्ञानात्मक समस्याओं वाले लोगों के लिए भी फ़ायदेमंद हो सकते हैं.
ब्राउज़र के साथ काम करना
स्क्रीन रीडर के कई विकल्प उपलब्ध हैं. डेस्कटॉप कंप्यूटर के लिए, सबसे लोकप्रिय स्क्रीन रीडर JAWS, NVDA, और VoiceOver हैं. वहीं, मोबाइल डिवाइसों के लिए, VoiceOver और Talkback सबसे लोकप्रिय स्क्रीन रीडर हैं.
आपके ऑपरेटिंग सिस्टम (ओएस), पसंदीदा ब्राउज़र, और इस्तेमाल किए जा रहे डिवाइस के आधार पर, कोई एक स्क्रीन रीडर सबसे अच्छा विकल्प हो सकता है. ज़्यादातर स्क्रीन रीडर, खास हार्डवेयर और वेब ब्राउज़र को ध्यान में रखकर बनाए जाते हैं. अगर किसी ऐसे ब्राउज़र के साथ स्क्रीन रीडर का इस्तेमाल किया जाता है जिसके लिए उसे कैलिब्रेट नहीं किया गया है, तो आपको ज़्यादा "बग" या अनचाहे व्यवहार का सामना करना पड़ सकता है. स्क्रीन रीडर, इन कॉम्बिनेशन में सबसे बेहतर तरीके से काम करते हैं.
| स्क्रीन रीडर | ओएस | ब्राउज़र के साथ काम करना |
|---|---|---|
| Job Access With Speech (JAWS) | Windows | Chrome, Firefox, Edge |
| Non-Visual Desktop Access (NVDA) | Windows | Chrome और Firefox |
| Narrator | Windows | Edge |
| VoiceOver | macOS | Safari |
| Orca | Linux | Firefox |
| TalkBack | Android | Chrome और Firefox |
| VoiceOver (मोबाइल के लिए) | iOS | Safari |
| ChromeVox | ChromeOS | Chrome |
स्क्रीन रीडर के निर्देश
डेस्कटॉप या मोबाइल डिवाइस के लिए, स्क्रीन रीडर सॉफ़्टवेयर का सही सेटअप करने के बाद, आपको स्क्रीन रीडर के दस्तावेज़ (ऊपर दी गई टेबल में लिंक किया गया) देखने चाहिए. साथ ही, टेक्नोलॉजी के बारे में जानने के लिए, स्क्रीन रीडर के कुछ ज़रूरी निर्देश इस्तेमाल करने चाहिए. अगर आपने पहले किसी स्क्रीन रीडर का इस्तेमाल किया है, तो कोई नया स्क्रीन रीडर आज़माएं!
सुलभता की टेस्टिंग के लिए स्क्रीन रीडर का इस्तेमाल करते समय, आपका मकसद अपने कोड में मौजूद उन समस्याओं का पता लगाना होता है जो आपकी वेबसाइट या ऐप्लिकेशन के इस्तेमाल में रुकावट डालती हैं. आपका मकसद, स्क्रीन रीडर इस्तेमाल करने वाले व्यक्ति के अनुभव की नकल करना नहीं होता. इसलिए, बुनियादी जानकारी, स्क्रीन रीडर के कुछ निर्देश, और थोड़ी (या ज़्यादा) प्रैक्टिस की मदद से, कई काम किए जा सकते हैं.
अगर आपको स्क्रीन रीडर और अन्य एटी का इस्तेमाल करने वाले लोगों के अनुभव के बारे में ज़्यादा जानना है, तो इस अहम जानकारी को पाने के लिए, कई संगठनों और लोगों से संपर्क किया जा सकता है. ध्यान रखें कि नियमों के सेट के हिसाब से कोड की टेस्टिंग के लिए एटी का इस्तेमाल करने और उपयोगकर्ताओं से उनके अनुभव के बारे में पूछने पर, अक्सर अलग-अलग नतीजे मिलते हैं. पूरी तरह से समावेशी प्रॉडक्ट बनाने के लिए, ये दोनों पहलू अहम हैं.
डेस्कटॉप स्क्रीन रीडर के लिए ज़रूरी निर्देश
| एलिमेंट | NVDA (Windows) | VoiceOver (macOS) |
|---|---|---|
| सामान्य निर्देश वाले बटन | Insert | Control+Option |
| ऑडियो रोकें | Control | Control |
| अगला/पिछला पढ़ें | ↓ या ↑ | Control+Option+→ या ← |
| पढ़ना शुरू करें | Insert↓ | Control+Option+A |
| एलिमेंट की सूची/रोटर | NVDA + F7 | Control+Option+U |
| लैंडमार्क | D | Control+Option+U |
| हेडिंग | H | Control+Option+Command+H |
| लिंक | K | Control+Option+Command+L |
| फ़ॉर्म कंट्रोल | F | Control+Option+Command+J |
| टेबल | T | Control+OptionCommand+T |
| टेबल के अंदर | Insert Alt + ↓ ↑ ← → | Control+Option+↓ ↑ ← → |
मोबाइल स्क्रीन रीडर के लिए ज़रूरी निर्देश
| एलिमेंट | TalkBack (Android) | VoiceOver (iOS) |
|---|---|---|
| एक्सप्लोर करें | स्क्रीन पर एक उंगली से खींचें | स्क्रीन पर एक उंगली से खींचें |
| चुनें या चालू करें | दो बार टैप करें | दो बार टैप करें |
| ऊपर या नीचे की ओर स्वाइप करें | दो उंगलियों से, ऊपर या नीचे की ओर स्वाइप करें | तीन उंगलियों से, ऊपर या नीचे की ओर स्वाइप करें |
| पेज बदलना | दो उंगलियों से बाईं या दाईं ओर स्वाइप करें | तीन उंगलियों से बाईं या दाईं ओर स्वाइप करें |
| अगला/पिछला | एक उंगली से बाईं या दाईं ओर स्वाइप करें | एक उंगली से बाईं या दाईं ओर स्वाइप करें |
स्क्रीन रीडर की टेस्टिंग का डेमो
हमने अपने डेमो की टेस्टिंग के लिए, 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>
स्क्रीन रीडर इस्तेमाल करने वाले लोगों के लिए, इस समस्या को ठीक करने के लिए, हम कोड को अपडेट करते हैं, ताकि ज़्यादा जानकारी जोड़ी जा सके. इससे, विज़ुअल एलिमेंट पर कोई असर नहीं पड़ता. इसके अलावा, पढ़ने और संज्ञानात्मक समस्याओं वाले लोगों की मदद करने के लिए, हम विज़ुअल टेक्स्ट भी जोड़ सकते हैं.
लिंक की ज़्यादा जानकारी जोड़ने के लिए, कई अलग-अलग पैटर्न इस्तेमाल किए जा सकते हैं. हमारे एनवायरमेंट में सिर्फ़ एक भाषा इस्तेमाल की जा सकती है. इसलिए, इस स्थिति में एआरआईए लेबल एक आसान विकल्प है. आपको दिख सकता है कि एआरआईए लेबल, ओरिजनल लिंक टेक्स्ट को बदल देता है. इसलिए, पक्का करें कि आपने अपने अपडेट में वह जानकारी शामिल की हो.
<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>
तीसरी समस्या: सजावटी इमेज
ऑटोमेटेड टेस्टिंग वाले हमारे मॉड्यूल में, Lighthouse हमारे डेमो पेज पर, इनलाइन एसवीजी को मुख्य स्प्लैश इमेज के तौर पर नहीं पहचान पाया. हालांकि, स्क्रीन रीडर इसे ढूंढ लेता है और बिना किसी अतिरिक्त जानकारी के, इसे "इमेज" के तौर पर दिखाता है.
ऐसा तब भी होता है, जब एसवीजी में role="img" एट्रिब्यूट साफ़ तौर पर नहीं जोड़ा जाता.
<div class="section-right">
<svg>...</svg>
</div>
इस समस्या को ठीक करने के लिए, हमें सबसे पहले यह तय करना होगा कि इमेज, जानकारी देने वाली है या सजावटी. इसके आधार पर, हमें इमेज के लिए सही वैकल्पिक टेक्स्ट (जानकारी देने वाली इमेज) जोड़ना होगा या स्क्रीन रीडर इस्तेमाल करने वाले लोगों के लिए इमेज को छिपाना होगा (सजावटी).
हमने इमेज को सबसे सही तरीके से कैटगरी में बांटने के फ़ायदों और नुकसानों के बारे में सोचा. इसके बाद, हमने तय किया कि यह सजावटी है. इसका मतलब है कि हमें इमेज को छिपाने के लिए, कोड जोड़ना या उसमें बदलाव करना होगा. एसवीजी
इमेज में सीधे तौर पर role="presentation" जोड़ना एक आसान तरीका है. इससे स्क्रीन रीडर को यह सिग्नल मिलता है कि वह इस इमेज को स्किप कर दे और इसे इमेज ग्रुप में शामिल न करे.
<div class="section-right">
<svg role="presentation">...</svg>
</div>
चौथी समस्या: बुलेट डेकोरेशन
आपने देखा होगा कि स्क्रीन रीडर, दुर्लभ बीमारियों वाले सेक्शन में सीएसएस बुलेट इमेज को पढ़ता है. यह इमेज, इमेज वाले मॉड्यूल में बताई गई इमेज जैसी नहीं है. हालांकि, इसमें बदलाव करना ज़रूरी है, क्योंकि इससे कॉन्टेंट का फ़्लो बिगड़ता है. साथ ही, इससे स्क्रीन रीडर इस्तेमाल करने वाले व्यक्ति का ध्यान भटक सकता है या उसे भ्रम हो सकता है.
<p class="bullet">...</p>
सजावटी इमेज के उदाहरण की तरह, बुलेट क्लास वाले एचटीएमएल में
role="presentation" जोड़ा जा सकता है, ताकि इसे
स्क्रीन रीडर से छिपाया जा सके. इसी तरह, role="none" भी काम करेगा. हालांकि, aria-hidden: true का इस्तेमाल न करें. ऐसा करने पर, स्क्रीन रीडर इस्तेमाल करने वाले लोगों के लिए पैराग्राफ़ की पूरी जानकारी छिप जाएगी.
<p class="bullet" role="none">...</p>
पांचवी समस्या: फ़ॉर्म फ़ील्ड
फ़ॉर्म वाले मॉड्यूल में, हमने सीखा था कि सभी फ़ॉर्म फ़ील्ड में विज़ुअल और प्रोग्रामैटिक लेबल भी होना चाहिए. यह लेबल हमेशा दिखना चाहिए.
हमारे डेमो में, न्यूज़लेटर के लिए साइन-अप करने वाले ईमेल फ़ील्ड में, विज़ुअल और प्रोग्रामैटिक, दोनों तरह के लेबल मौजूद नहीं हैं. इसमें टेक्स्ट प्लेसहोल्डर एलिमेंट है. हालांकि, यह लेबल की जगह नहीं ले सकता, क्योंकि यह विज़ुअल तौर पर हमेशा नहीं दिखता और यह सभी स्क्रीन रीडर के साथ पूरी तरह से काम नहीं करता.
<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 में ये सभी बदलाव देखे जा सकते हैं.
अब, सीखी गई बातों का इस्तेमाल करके, अपनी वेबसाइटों और ऐप्लिकेशन की सुलभता की समीक्षा की जा सकती है.
सुलभता की टेस्टिंग का मकसद, उन सभी संभावित समस्याओं को हल करना है जिनका सामना कोई व्यक्ति कर सकता है. हालांकि, इसका मतलब यह नहीं है कि टेस्टिंग पूरी होने के बाद, आपकी वेबसाइट या ऐप्लिकेशन पूरी तरह से सुलभ हो गया है. वेबसाइट या ऐप्लिकेशन को डिज़ाइन करते समय, पूरी प्रोसेस में सुलभता को ध्यान में रखकर और लॉन्च से पहले की अन्य टेस्टिंग के साथ इन टेस्ट को शामिल करके, सबसे अच्छे नतीजे पाए जा सकते हैं.