सुलभता समीक्षा कैसे करें?

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

स्वचालित परीक्षण उपकरणों से शुरुआत करें

कई एक्सेसिबिलिटी समस्याओं की पहचान स्वचालित उपकरणों से की जा सकती है। कुछ लोकप्रिय टूल हैं — WAVE, Tenon, Accessibility Insights, Google Lighthouse, Siteimprove और Siteimprove Chrome एक्सटेंशन। आप axe-core का उपयोग कर कुछ जांचें स्वचालित भी कर सकते हैं। ये टूल HTML स्ट्रक्चर, ARIA एट्रिब्यूट्स और कलर कॉन्ट्रास्ट से जुड़ी कई सामान्य त्रुटियों का पता लगाते हैं।

कीबोर्ड नेविगेशन से परीक्षण करें

कीबोर्ड नेविगेशन उन उपयोगकर्ताओं के लिए आवश्यक है जो माउस का उपयोग नहीं कर सकते या करना नहीं चाहते। इसमें स्क्रीन रीडर उपयोगकर्ता और मोटर-डिसएबिलिटी वाले उपयोगकर्ता शामिल हैं। एक अच्छा कीबोर्ड अनुभव देने के लिए टैब क्रम तार्किक होना चाहिए और फोकस स्पष्ट रूप से दिखाई देना चाहिए। साथ ही, सुनिश्चित करें कि उपयोगकर्ता को बहुत अधिक टैब पोजिशनों से नहीं गुजरना पड़े।

क्या जाँचना है

• क्या आप दोहराव वाले कंटेंट को छोड़ सकते हैं?

एक “skip link” प्रदान करें, जो उपयोगकर्ता को नेविगेशन जैसे दोहराए जाने वाले कंटेंट को छोड़कर सीधे मुख्य सामग्री पर ले जाए। यह लिंक टैब क्रम में सबसे पहले होना चाहिए और फोकस होने पर दिखाई देना चाहिए।

• क्या सभी इंटरैक्टिव एलिमेंट्स कीबोर्ड से पूरी तरह काम करते हैं?

हर इंटरैक्टिव तत्व (जैसे डायलॉग, स्लाइडर, ट्री-व्यू, ड्रैग-एंड-ड्रॉप) कीबोर्ड से एक्सेसिबल होना चाहिए या वैकल्पिक तरीका होना चाहिए।

• क्या आप Shift+Tab से पीछे नेविगेट कर सकते हैं?

कुछ एप्लिकेशन्स केवल आगे की टैबिंग की अनुमति देती हैं, लेकिन पीछे नहीं, जिससे “कीबोर्ड ट्रैप” बनता है। सुनिश्चित करें कि आप दोनों दिशाओं में टैब कर सकते हैं।

• क्या कोई कीबोर्ड ट्रैप है?

ध्यान रखें कि फोकस किसी क्षेत्र में फंस न जाए। क्या आप केवल कीबोर्ड से ओवरले या डायलॉग से बाहर निकल सकते हैं? यदि नहीं, तो यह एक कीबोर्ड ट्रैप है।

• क्या डायलॉग खुलने पर फोकस उसके भीतर सीमित रहता है?

डायलॉग सक्रिय होने पर कीबोर्ड फोकस उसी के भीतर रहना चाहिए, ताकि उपयोगकर्ता बाहर की सामग्री पर गलती से न जा सके।

• क्या फोकस हमेशा स्पष्ट दिखता है?

हर इंटरैक्टिव तत्व में स्पष्ट फोकस इंडिकेटर होना चाहिए। यदि कीबोर्ड उपयोगकर्ता नहीं देख सकता कि फोकस कहाँ है, तो वह इंटरैक्ट नहीं कर पाएगा।

• क्या कोई छिपी सामग्री फोकस में आ रही है?

ऐसा कंटेंट जो दृश्य रूप से छिपा है, उसे टैब क्रम में नहीं होना चाहिए।

• क्या hover से दिखने वाले तत्वों के कीबोर्ड समकक्ष मौजूद हैं?

ऐसा hover-कंटेंट कीबोर्ड से भी एक्सेसिबल होना चाहिए। यह केवल कीबोर्ड और टच उपयोगकर्ताओं दोनों के लिए आवश्यक है।

• क्या गैर-इंटरैक्टिव तत्व फोकस में आ रहे हैं?

गैर-इंटरैक्टिव कंटेंट फोकस में नहीं आना चाहिए। यदि कोई एलिमेंट फोकस में आता है, तो उपयोगकर्ता उम्मीद करता है कि वह उस पर कार्य कर सके।

• क्या टैब क्रम प्राकृतिक और तार्किक है?

यदि tabindex बदल दिया गया है या DOM क्रम में असंगति है, तो नेविगेशन भ्रमित कर सकता है।

ब्रेकपॉइंट्स पर जांच करें

कीबोर्ड परीक्षण के बाद ब्राउज़र को ज़ूम करें और फिर परीक्षण दोहराएँ। उच्च ज़ूम वाले उपयोगकर्ता अक्सर आपकी “मोबाइल” या “टैबलेट” लेआउट के साथ इंटरैक्ट करते हैं।

शीर्षक (Headings)

हेडिंग्स सामग्री की संरचना दर्शाती हैं। वे उपयोगकर्ताओं और स्क्रीन रीडर्स दोनों को संदर्भ देती हैं।

• क्या पेज पर केवल एक H1 है?
• क्या हेडिंग लेवल्स क्रम में हैं (H2, H3 आदि)?
• क्या हेडिंग्स वर्णनात्मक हैं?

रंग और कंट्रास्ट

पर्याप्त रंग कंट्रास्ट होना चाहिए

टेक्स्ट और बैकग्राउंड के बीच न्यूनतम 4.5:1 कंट्रास्ट अनुपात आवश्यक है। इसके लिए कलर कंट्रास्ट चेकर का उपयोग करें।

रंग जानकारी का एकमात्र माध्यम नहीं होना चाहिए

केवल रंग से सूचना न दें। रंग-अंधता वाले उपयोगकर्ता इसे नहीं पहचान पाएंगे। टेक्स्ट, आइकन या आकार जैसे अतिरिक्त संकेत जोड़ें। उदाहरण के लिए, लाल त्रुटि बॉक्स में “Error” टेक्स्ट या आइकन शामिल करें।

केवल आइकन पर निर्भर न रहें

यदि आइकन किसी महत्वपूर्ण कार्य को दर्शाता है, तो उसके साथ टेक्स्ट भी होना चाहिए। प्रत्येक इंटरैक्टिव आइटम, जैसे मेनू, को लेबल किया जाना चाहिए ताकि स्क्रीन रीडर इसे पढ़ सके।

ऑडियो और वीडियो

यदि आपकी साइट पर वीडियो या ऑडियो है, तो कैप्शन या ट्रांसक्रिप्ट प्रदान करें। WebAIM के कैप्शन और ट्रांसक्रिप्ट गाइड देखें।

• सूचनात्मक वीडियो के लिए ट्रांसक्रिप्ट प्रदान करें।
• ध्वनि वाले वीडियो के लिए कैप्शन आवश्यक हैं।
• जटिल वीडियो के लिए ऑडियो विवरण जोड़ें।
• लाइव वीडियो के लिए लाइव कैप्शन शामिल करें।
• लाइव ऑडियो के लिए टेक्स्ट विकल्प प्रदान करें।

एनिमेशन और ऑटोप्ले मीडिया

स्वचालित रूप से चलने वाले वीडियो, ऑडियो या एनिमेशन ध्यान भंग कर सकते हैं। यदि आवश्यक हो, तो उपयोगकर्ता को इन्हें रोकने और नियंत्रित करने का विकल्प दें।

• स्वतः चलने वाली मीडिया 5 सेकंड से अधिक न हो।
• Play, Pause, Stop नियंत्रण प्रदान करें।

डायनेमिक कंटेंट

JavaScript पेज के हिस्सों को डायनामिक रूप से अपडेट करता है। स्क्रीन रीडर उपयोगकर्ताओं को यह बदलाव सुनाई देना चाहिए। इसके लिए Drupal का Drupal.announce() API उपयोग करें।

यह ARIA Live Regions पर आधारित है।

स्क्रीन रीडर से परीक्षण

स्वचालित परीक्षणों के अलावा, स्क्रीन रीडर से परीक्षण करना महत्वपूर्ण है। इससे पता चलता है कि पेज की जानकारी सुनने योग्य और तार्किक है या नहीं।

• क्या सभी नियंत्रणों के लिए लेबल हैं?
• क्या कस्टम कंट्रोल्स में उचित ARIA रोल्स और एट्रिब्यूट्स हैं?
• क्या सूचना प्रवाह समझने योग्य है?
• क्या लिंक टेक्स्ट संदर्भ से बाहर भी स्पष्ट हैं?
• क्या छवियों में उपयुक्त Alt टेक्स्ट है?

स्क्रीन रीडर के साथ मैन्युअल परीक्षण

कुछ समस्याएँ केवल मैन्युअल परीक्षण से पता चलती हैं। सामान्य स्क्रीन रीडर्स हैं — Mac के लिए VoiceOver और Windows के लिए NVDA।

VoiceOver की बुनियादी जानकारी वीडियो और NVDA की परिचयात्मक वीडियो देखें।

जब आप इनके शॉर्टकट सीख लें, तो मॉनिटर बंद करें और केवल कीबोर्ड व आवाज़ से साइट का परीक्षण करें।

याद रखें, यह अभ्यास समय और धैर्य माँगता है। विभिन्न स्क्रीन रीडर और ब्राउज़र अलग तरह से व्यवहार करते हैं, इसलिए विभिन्न संयोजनों पर परीक्षण करना सबसे अच्छा होता है।