ऑटोमेटेड सुलभता टेस्टिंग

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

बाकी मॉड्यूल में हमने गियर को डिज़ाइन करने और बनाने से लेकर सुलभता की जांच करने तक का काम किया है. हम तीन चरणों वाली टेस्टिंग प्रोसेस का इस्तेमाल करेंगे. इसमें ऑटोमेटेड, मैन्युअल, और सहायक टेक्नोलॉजी टेस्टिंग टूल और तकनीक शामिल हैं. हम इन टेस्टिंग मॉड्यूल में एक ही डेमो का इस्तेमाल करेंगे, ताकि वेब पेज को ऐक्सेस न किया जा सके.

हर तरह की जांच—ऑटोमेटेड, मैन्युअल, और सहायक तकनीक—सबसे ज़्यादा ऐक्सेस किए जा सकने वाले प्रॉडक्ट तक पहुंचने के लिए अहम है.

हमारे टेस्ट, हमारे मानकों के तौर पर, वेब कॉन्टेंट सुलभता दिशा-निर्देश (डब्ल्यूसीएजी) के 2.1 अनुपालन लेवल A और AA पर भरोसा करते हैं. याद रखें कि आपके उद्योग, प्रॉडक्ट टाइप, स्थानीय/देश के कानून और नीतियों या सुलभता से जुड़े लक्ष्यों के आधार पर यह तय होगा कि किन दिशा-निर्देशों का पालन करना है और किन लेवल को पूरा करना है. अगर आपको अपने प्रोजेक्ट के लिए किसी खास स्टैंडर्ड की ज़रूरत नहीं है, तो आपको डब्ल्यूसीएजी के सबसे नए वर्शन का इस्तेमाल करना चाहिए. सुलभता ऑडिट, कन्फ़ॉर्मैंस टाइप/लेवल, डब्ल्यूसीएजी, और पीओयूआर की सामान्य जानकारी के लिए, "डिजिटल सुलभता का आकलन कैसे किया जाता है?" लेख को फिर से पढ़ें.

जैसा कि आप जानते ही हैं कि सुलभता सुविधाओं के इस्तेमाल का मकसद दिव्यांग लोगों की मदद करना नहीं है. लेकिन, यह एक अच्छा शुरुआत है, क्योंकि इससे आपको एक ऐसी मेट्रिक मिलती है जिसकी जांच की जा सकती है. हमारा सुझाव है कि आप सुलभता के नियमों के हिसाब से टेस्ट करने के अलावा भी अन्य कार्रवाइयां करें. जैसे, दिव्यांग लोगों के लिए उपयोगिता की जांच करना, अपनी टीम में काम करने के लिए दिव्यांग लोगों को काम पर रखना या डिजिटल सुलभता की विशेषज्ञता रखने वाले किसी व्यक्ति या कंपनी से सलाह लेना.

अपने-आप होने वाले टेस्टिंग की बुनियादी बातें

ऑटोमेटेड सुलभता टेस्टिंग की सुविधा आपके डिजिटल प्रॉडक्ट को स्कैन करने के लिए सॉफ़्टवेयर का इस्तेमाल करती है. इसकी मदद से, सुलभता से जुड़ी समस्याओं का पता लगाया जाता है. ऐसा पहले से तय किए गए सुलभता मानकों के हिसाब से किया जाता है.

अपने-आप होने वाली सुलभता जांच के फ़ायदे:

• प्रॉडक्ट के लाइफ़साइकल के अलग-अलग चरणों में, आसानी से बार-बार टेस्ट किए जा सकते हैं
• सेट करने के लिए बस कुछ चरण और तुरंत नतीजे पाएं
• टेस्ट करने या नतीजों को समझने के लिए, सुलभता सुविधाओं के बारे में थोड़ी-बहुत जानकारी होना ज़रूरी है

अपने-आप होने वाली सुलभता जांच के नुकसान:

• ऑटोमेटेड टूल, आपके प्रॉडक्ट की सुलभता से जुड़ी सभी गड़बड़ियों को नहीं पकड़ते
• फ़ॉल्स पॉज़िटिव की शिकायत की गई (इस समस्या के बारे में बताया गया है कि वह डब्ल्यूसीएजी का सही उल्लंघन नहीं है)
• अलग-अलग प्रॉडक्ट टाइप और भूमिकाओं के लिए, एक से ज़्यादा टूल की ज़रूरत हो सकती है

ऑटोमेटेड टेस्टिंग, अपनी वेबसाइट या ऐप्लिकेशन की सुलभता की जांच करने का एक बेहतरीन तरीका है. हालांकि, यह ज़रूरी नहीं है कि सभी तरह की जांच अपने-आप हो जाएं. मैन्युअल सुलभता टेस्टिंग मॉड्यूल में जिन एलिमेंट को अपने-आप नहीं चलाया जा सकता उनकी सुलभता जांच करने के तरीके के बारे में हम ज़्यादा जानेंगे.

ऑटोमेटेड टूल के टाइप

पहले ऑनलाइन सुलभता टेस्टिंग टूल में से एक को सेंटर फ़ॉर अप्लाइड स्पेशल टेक्नोलॉजी (सीएएसटी) ने 1996 में "द बॉबी रिपोर्ट" के नाम से बनाया था. फ़िलहाल, हमारे पास 100 से भी ज़्यादा ऑटोमेटेड टेस्टिंग टूल उपलब्ध हैं!

अपने-आप लागू होने वाले टूल कई तरह के होते हैं. इनमें सुलभता ब्राउज़र एक्सटेंशन से लेकर कोड लिंटर, डेस्कटॉप और मोबाइल ऐप्लिकेशन, ऑनलाइन डैशबोर्ड, और यहां तक कि ओपन-सोर्स एपीआई भी शामिल हैं. इनका इस्तेमाल अपने-आप काम करने वाला टूल बनाने के लिए किया जा सकता है.

अपने-आप काम करने वाले किस टूल का इस्तेमाल करना है, यह कई बातों पर निर्भर करता है. जैसे:

• आपको कन्फ़ॉर्मैंस के किन स्टैंडर्ड और लेवल की जांच करनी है? इसमें डब्ल्यूसीएजी 2.1, डब्ल्यूसीएजी 2.0, यू.एस. सेक्शन 508 या सुलभता नियमों की बदली गई सूची शामिल हो सकती है.
• आपको किस तरह के डिजिटल प्रॉडक्ट को टेस्ट करना है? यह कोई वेबसाइट, वेब ऐप्लिकेशन, नेटिव मोबाइल ऐप्लिकेशन, PDF, कीऑस्क या अन्य प्रॉडक्ट हो सकता है.
• सॉफ़्टवेयर डेवलपमेंट की लाइफ़ साइकल के किस हिस्से में, अपने प्रॉडक्ट को टेस्ट किया जा रहा है?
• टूल को सेट अप और इस्तेमाल करने में कितना समय लगता है? किसी व्यक्ति, टीम या कंपनी के लिए?
• टेस्ट कौन कर रहा है: डिज़ाइनर, डेवलपर, QA वगैरह?
• आपको कितनी बार सुलभता की जांच करवानी है? रिपोर्ट में कौनसी जानकारी शामिल की जानी चाहिए? क्या समस्याएं, सीधे तौर पर टिकट बेचने वाले सिस्टम से जुड़ी होनी चाहिए?
• आपके लिए कौनसे टूल सबसे सही काम करते हैं? आपकी टीम के लिए?

इसके अलावा, कई और बातों पर ध्यान देना ज़रूरी है. अपने और अपनी टीम के लिए सबसे बढ़िया टूल चुनने के बारे में ज़्यादा जानकारी के लिए, WAI का "Selecting Web Accessibility मूल्यांकन टूल" का लेख देखें.

डेमो: अपने-आप होने वाला टेस्ट

ऑटोमेटेड सुलभता टेस्टिंग डेमो के लिए, हम Chrome के Lighthouse का इस्तेमाल करेंगे. लाइटहाउस एक ओपन सोर्स टूल है, जो अपने-आप काम करता है. इसे कई तरह के ऑडिट, जैसे कि परफ़ॉर्मेंस, एसईओ, और सुलभता की मदद से, वेब पेजों की क्वालिटी को बेहतर बनाने के लिए बनाया गया है.

हमारा डेमो एक ऐसी वेबसाइट है जिसे मेडिकल मिस्ट्रीज़ क्लब नाम के एक संगठन के लिए बनाया गया है. डेमो के लिए, इस साइट को जान-बूझकर ऐक्सेस नहीं किया जा सकता. इस तरह की कुछ सुलभता आपको दिख सकती हैं और कुछ को (सभी नहीं) हमारे अपने-आप होने वाले टेस्ट में शामिल किया जाएगा.

पहला चरण

अपने Chrome ब्राउज़र का इस्तेमाल करके, Lighthouse एक्सटेंशन इंस्टॉल करें.

टेस्टिंग वर्कफ़्लो में Lighthouse को इंटिग्रेट करने के कई तरीके हैं. हम इस डेमो के लिए Chrome एक्सटेंशन का इस्तेमाल करेंगे.

दूसरा चरण

हमने CodePen में डेमो बनाया है. अगले टेस्ट पर जाने के लिए, इसे डीबग मोड में देखें. यह ज़रूरी है, क्योंकि यह डेमो वेब पेज के चारों तरफ़ मौजूद <iframe> को हटा देता है. इससे कुछ टेस्टिंग टूल में रुकावट आ सकती है. CodePen के डीबग मोड के बारे में ज़्यादा जानें.

तीसरा चरण

Chrome DevTools खोलें और Lighthouse टैब पर जाएं. "सुलभता" को छोड़कर, अन्य सभी कैटगरी के विकल्पों से सही का निशान हटाएं. मोड को डिफ़ॉल्ट के रूप में रखें और वह डिवाइस टाइप चुनें जिस पर आप जांच कर रहे हैं.

चौथा चरण

"पेज लोड का विश्लेषण करें" बटन पर क्लिक करें और Lighthouse को उसकी जांच करने का समय दें.

जांच पूरी होने के बाद, Lighthouse एक स्कोर दिखाता है, जिससे यह पता चलता है कि आप जिस प्रॉडक्ट की जांच कर रहे हैं उसे कितनी आसानी से ऐक्सेस किया जा सकता है. Lighthouse स्कोर का पता लगाने के लिए, समस्याओं की संख्या, उन्हें अलग-अलग तरह की समस्याओं, और मिली समस्याओं से जुड़े उपयोगकर्ताओं पर पड़ने वाले असर के आधार पर मापा जाता है.

स्कोर के अलावा, Lighthouse रिपोर्ट में, इस बात की पूरी जानकारी शामिल होती है कि उसने किन समस्याओं का पता लगाया है. साथ ही, रिपोर्ट में उन समस्याओं को ठीक करने के बारे में ज़्यादा जानकारी देने वाले संसाधनों के लिंक भी दिए जाते हैं. इस रिपोर्ट में वे टेस्ट भी शामिल होते हैं जो पास हो गए हैं या लागू नहीं हैं. साथ ही, मैन्युअल रूप से जांच करने के लिए, दूसरे आइटम की सूची भी होती है.

पांचवां चरण

आइए, अब अपने-आप मिलने वाली सुलभता की हर समस्या का उदाहरण देखते हैं और काम के स्टाइल और मार्कअप को ठीक करते हैं.

समस्या 1: ARIA भूमिकाएं

पहली समस्या के बारे में बताया गया है: "ARIA [role] वाले एलिमेंट में बच्चों को खास [role] का होना ज़रूरी होता है. ऐसे एलिमेंट में से कुछ या सभी ज़रूरी बच्चे मौजूद नहीं होते. ARIA की कुछ पैरंट भूमिकाओं में खास चाइल्ड भूमिकाएं होनी चाहिए, ताकि वे अपने मनचाहे सुलभता फ़ंक्शन कर सकें." ARIA भूमिका के नियमों के बारे में ज़्यादा जानें.

हमारे डेमो में, न्यूज़लेटर की सदस्यता लेने वाला बटन काम नहीं करता है:

<button role="list" type="submit" tabindex="1">Subscribe</button>

चलिए, इसे ठीक करते हैं.

इनपुट फ़ील्ड के बगल में मौजूद "सदस्य बनें" बटन पर ARIA की गलत भूमिका लागू है. इस स्थिति में, भूमिका को पूरी तरह से हटाया जा सकता है.

<button type="submit" tabindex="1">Subscribe</button>

दूसरी समस्या: ARIA को छिपाया गया

"[aria-hidden="true"] एलिमेंट में फ़ोकस करने लायक डिसेंडेंट हैं. किसी [aria-hidden="true"] एलिमेंट में फ़ोकस करने लायक डिसेंडेंट, स्क्रीन रीडर जैसी सहायक टेक्नोलॉजी का इस्तेमाल करने वाले लोगों को उन इंटरैक्टिव एलिमेंट के लिए उपलब्ध होने से रोकते हैं. aria-hidden नियमों के बारे में ज़्यादा जानें.

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>

चलिए, इसे ठीक करते हैं.

इनपुट फ़ील्ड में aria-hidden="true" एट्रिब्यूट लागू किया गया था. इस एट्रिब्यूट को जोड़ने से, एलिमेंट (और इसके तहत नेस्ट की गई सभी चीज़ें) सहायक टेक्नोलॉजी से छिप जाता है.

<input type="email" placeholder="Enter your e-mail address" tabindex="-1" required>

ऐसे मामले में, आपको इस एट्रिब्यूट को इनपुट से हटा देना चाहिए, ताकि सहायक टेक्नोलॉजी का इस्तेमाल करने वाले लोग, फ़ॉर्म फ़ील्ड में जानकारी ऐक्सेस कर सकें और उसे डाल सकें.

तीसरी समस्या: बटन का नाम

बटन का कोई ऐक्सेस करने योग्य नाम नहीं है. जब किसी बटन का ऐक्सेस किया जा सकने वाला नाम नहीं होता, तो स्क्रीन रीडर सिर्फ़ "बटन" कहता है. इस वजह से, स्क्रीन रीडर का इस्तेमाल करने वाले लोगों के लिए यह किसी काम का नहीं रहता. बटन के नाम से जुड़े नियमों के बारे में ज़्यादा जानें.

<button role="list" type="submit" tabindex="1">Subscribe</button>

चलिए, इसे ठीक करते हैं.

जब पहले अंक में, बटन एलिमेंट से गलत ARIA रोल हटाया जाता है, तो "सदस्यता लें" शब्द, ऐक्सेस किए जा सकने वाले बटन का नाम बन जाता है. यह फ़ंक्शन, सिमैंटिक एचटीएमएल बटन एलिमेंट में बनाया जाता है. ज़्यादा मुश्किल स्थितियों के लिए, अलग से पैटर्न के विकल्प भी दिए गए हैं.

<button type="submit" tabindex="1">Subscribe</button>

चौथी समस्या: इमेज के लिए वैकल्पिक एट्रिब्यूट

इमेज एलिमेंट में [alt] एट्रिब्यूट मौजूद नहीं हैं. जानकारी वाले एलिमेंट में, छोटा और ब्यौरे वाला वैकल्पिक टेक्स्ट होना चाहिए. सजावटी एलिमेंट को खाली ऑल्ट एट्रिब्यूट से अनदेखा किया जा सकता है. इमेज के वैकल्पिक टेक्स्ट के नियमों के बारे में ज़्यादा जानें.

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png">
</a>

चलिए, इसे ठीक करते हैं.

लोगो इमेज एक लिंक भी होती है. इसलिए, इमेज मॉड्यूल से आपको पता चलता है कि इसे कार्रवाई करने लायक इमेज कहा जाता है. साथ ही, इमेज के मकसद के बारे में वैकल्पिक टेक्स्ट जानकारी की भी ज़रूरत होती है. आम तौर पर, पेज पर सबसे पहली इमेज लोगो होती है. इसलिए, यह माना जा सकता है कि आपके AT उपयोगकर्ताओं को यह पता होगा. साथ ही, हो सकता है कि आप अपनी इमेज के ब्यौरे में यह अतिरिक्त जानकारी न जोड़ना चाहें.

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png"
    alt="Go to the home page.">
</a>

समस्या 5: लिंक टेक्स्ट

लिंक का समझने लायक नाम नहीं है. समझने लायक, यूनीक, और फ़ोकस करने लायक लिंक टेक्स्ट (और इमेज के लिए इस्तेमाल किया जाने वाला वैकल्पिक टेक्स्ट, जब लिंक के तौर पर इस्तेमाल किया जाए) की मदद से स्क्रीन रीडर इस्तेमाल करने वालों का नेविगेशन अनुभव बेहतर होता है. लिंक टेक्स्ट के नियमों के बारे में ज़्यादा जानें.

<a href="#!"><svg><path>...</path></svg></a>

चलिए, इसे ठीक करते हैं.

पेज पर मौजूद कार्रवाई करने लायक सभी इमेज में यह जानकारी होनी चाहिए कि लिंक, लोगों को कहां भेजेगा. इस समस्या को हल करने का एक तरीका यह है कि आप इस मकसद के लिए इमेज में वैकल्पिक टेक्स्ट जोड़ें, जैसा कि आपने ऊपर दिए गए उदाहरण में लोगो इमेज पर किया था. यह, <img> टैग का इस्तेमाल करने वाली इमेज के लिए बहुत अच्छा काम करता है. हालांकि, <svg> टैग इस तरीके का इस्तेमाल नहीं कर सकते.

<svg> टैग का इस्तेमाल करने वाले सोशल मीडिया आइकॉन के लिए, SVG को टारगेट करने के लिए, दूसरे जानकारी के दूसरे पैटर्न का इस्तेमाल किया जा सकता है. इसके बाद, <a> और <svg> टैग के बीच जानकारी जोड़ी जा सकती है. इसके बाद, इसे उपयोगकर्ताओं से विज़ुअल तौर पर छिपाया जा सकता है, काम करने वाला ARIA या दूसरे विकल्प जोड़े जा सकते हैं. आपके एनवायरमेंट और कोड की पाबंदियों के आधार पर, दूसरे तरीके की तुलना में किसी एक तरीके को प्राथमिकता दी जा सकती है. सबसे सहायक टेक्नोलॉजी कवरेज के साथ, सबसे आसान पैटर्न का इस्तेमाल करें. जैसे, <svg> टैग में role="img" और <title> एलिमेंट जोड़ना.

<a href="#!">
  <svg role="img">
    <title>Connect on our Twitter page.</title>
    <path>...</path>
  </svg>
</a>

समस्या 6: कलर कंट्रास्ट

बैकग्राउंड और फ़ोरग्राउंड के रंगों में ज़रूरत के मुताबिक कंट्रास्ट अनुपात नहीं है. कई लोगों के लिए, कम कंट्रास्ट वाला टेक्स्ट पढ़ना मुश्किल या नामुमकिन होता है. रंग कंट्रास्ट के नियमों के बारे में ज़्यादा जानें.

दो उदाहरण रिपोर्ट किए गए.

चलिए, इसे ठीक करते हैं.

वेब पेज पर कलर कंट्रास्ट से जुड़ी कई समस्याएं मिली हैं. जैसा कि आपने कलर और कंट्रास्ट मॉड्यूल में जाना है, सामान्य साइज़ के टेक्स्ट (18 पॉइंट / 24 पिक्सल से कम) में कलर कंट्रास्ट 4.5:1, जबकि बड़े साइज़ के टेक्स्ट (कम से कम 18 पॉइंट / 24 पिक्सल या 14 पॉइंट / 18.5 पिक्सल बोल्ड) और ज़रूरी आइकॉन को 3:1 की शर्त पूरी करनी होगी.

पेज के शीर्षक के लिए, हरे-नीले रंग के टेक्स्ट को 3:1 रंग के कंट्रास्ट की शर्त पूरी करनी होगी, क्योंकि टेक्स्ट का साइज़ 24 पिक्सल होना चाहिए. हालांकि, टील बटन को सामान्य साइज़ का टेक्स्ट 16px बोल्ड माना जाता है, इसलिए उन्हें 4.5:1 कलर कंट्रास्ट की ज़रूरी शर्त को पूरा करना चाहिए.

इस मामले में, हमें हरा-नीला रंग मिल सकता है, जो 4.5:1 के हिसाब से गहरा है. या हम बटन के टेक्स्ट के साइज़ को 18.5px बोल्ड कर सकते हैं और टील के रंग की वैल्यू में थोड़ा बदलाव कर सकते हैं. इनमें से कोई भी तरीका, डिज़ाइन के लुक के हिसाब से काम करेगा.

पेज पर दो सबसे बड़े हेडिंग को छोड़कर, सफ़ेद बैकग्राउंड पर दिखने वाला सारा स्लेटी रंग का टेक्स्ट, कलर कंट्रास्ट के मामले में भी काम नहीं करता. कलर कंट्रास्ट की ज़रूरी शर्तों को पूरा करने के लिए, इस टेक्स्ट को गहरा करना ज़रूरी है.

समस्या #7 - सूची का स्ट्रक्चर

सूची वाले आइटम (<li>), <ul> या <ol> पैरंट एलिमेंट में शामिल नहीं हैं. स्क्रीन रीडर के लिए ज़रूरी है कि उनमें <ul> या <ol> पैरंट में सूची आइटम (<li>) शामिल हों, ताकि उन्हें ठीक तरह से बोला जा सके.

सूची के नियमों के बारे में ज़्यादा जानें.

<div class="ul">
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</div>

चलिए, इसे ठीक करते हैं.

हमने इस डेमो में एक सीएसएस क्लास का इस्तेमाल किया है, ताकि <ul> टैग के बजाय, बिना क्रम वाली सूची को सिम्युलेट किया जा सके. जब हमने इस कोड को गलत तरीके से लिखा था, तो हमने इस टैग में पहले से मौजूद सिमैंटिक एचटीएमएल सुविधाओं को हटा दिया था. क्लास को असली <ul> टैग से बदलने और उससे जुड़े सीएसएस में बदलाव करने से, हम सुलभता से जुड़ी इस समस्या को ठीक कर देते हैं.

<ul>
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</ul>

समस्या #8 - tabindex

कुछ एलिमेंट में [tabindex] की वैल्यू 0 से ज़्यादा होती है. 0 से ज़्यादा की वैल्यू साफ़ तौर पर नेविगेशन के क्रम को लागू करती है. हालांकि, यह तकनीकी तौर पर मान्य है, लेकिन इससे अक्सर उन लोगों को निराशा होती है जो सहायक टेक्नोलॉजी पर भरोसा करते हैं. Tabindex के नियमों के बारे में ज़्यादा जानें.

<button type="submit" tabindex="1">Subscribe</button>

चलिए, इसे ठीक करते हैं.

जब तक किसी वेब पेज पर स्वाभाविक टैबिंग क्रम को बिगाड़ने की कोई खास वजह न बताई गई हो, तब तक Tabindex एट्रिब्यूट पर पॉज़िटिव इंटीजर होना ज़रूरी नहीं है. टैब किए जाने का सामान्य क्रम बनाए रखने के लिए, हम या तो Tabindex को 0 में बदल सकते हैं या एट्रिब्यूट को पूरी तरह हटा सकते हैं.

<button type="submit">Subscribe</button>

छठा चरण

आपने ऑटोमेटेड सुलभता से जुड़ी सभी समस्याओं को ठीक कर लिया है. अब, नया डीबग मोड पेज खोलें. लाइटहाउस सुलभता ऑडिट फिर से चलाएं. आपका स्कोर पहली बार रन करने वाले स्कोर से काफ़ी बेहतर होना चाहिए.

हमने अपने-आप होने वाले इन सभी अपडेट को नए CodePen पर लागू कर दिया है.

अगला कदम

कमाल कर दिया। आपने पहले ही बहुत कुछ पूरा कर लिया है, लेकिन हमने अभी तक उसे पूरा नहीं किया है! इसके बाद, हम मैन्युअल जांच के बारे में बात करेंगे. इस बारे में मैन्युअल सुलभता टेस्टिंग मॉड्यूल में बताया गया है.

आपने जो सीखा है उसकी जांच करें

अपने-आप होने वाली सुलभता सुविधाओं की जांच के बारे में अपनी जानकारी की जांच करें