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

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

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

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

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

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

ऑटोमेटेड टेस्टिंग की बुनियादी बातें

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

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

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

ऑटोमेटेड सुलभता जांच के नुकसान:

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

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

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

साल 1996 में, Center for Applied Special Technology (CAST) ने ऑनलाइन ऐक्सेसibilit टेस्टिंग टूल को ऑटोमेट किया था. इसे "The Bobby Report" कहा जाता है. फ़िलहाल, ऑटोमेटेड टेस्टिंग के लिए 100 से ज़्यादा टूल उपलब्ध हैं!

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

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

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

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

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

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

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

चरण 1

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

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

दूसरा चरण

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

CodePen के डीबग मोड के बारे में ज़्यादा जानें.

तीसरा चरण

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

चौथा चरण

पेज लोड का विश्लेषण करें पर क्लिक करें और लाइटहाउस को जांच के लिए समय दें.

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

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

पांचवां चरण

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

पहली समस्या: 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>

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

समस्या 3: बटन का नाम

बटन के नाम ऐक्सेस करने लायक नहीं हैं. जब किसी बटन का ऐक्सेस किया जा सकने वाला नाम नहीं होता, तो स्क्रीन रीडर उसे "बटन" के तौर पर पढ़ता है. इस वजह से, स्क्रीन रीडर का इस्तेमाल करने वाले लोगों के लिए यह किसी काम का नहीं रहता.

बटन के नाम से जुड़े नियमों के बारे में ज़्यादा जानें.

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

आइए, इसे ठीक करते हैं.

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

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

समस्या 4: इमेज के ऑल्ट एट्रिब्यूट

इमेज एलिमेंट में [alt] एट्रिब्यूट मौजूद नहीं हैं. जानकारी वाले एलिमेंट में, छोटा और ब्यौरे वाला वैकल्पिक टेक्स्ट होना चाहिए. सजावटी तत्वों को इनके साथ अनदेखा किया जा सकता है एक खाली 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> टैग का इस्तेमाल करने वाले सोशल मीडिया आइकॉन के लिए, ब्यौरे के लिए किसी दूसरे पैटर्न का इस्तेमाल किया जा सकता है. इसके लिए, एसवीजी को टारगेट करें और <a> और <svg> टैग के बीच जानकारी जोड़ें. इसके बाद, इसे उपयोगकर्ताओं से छिपाएं, काम करने वाला ARIA जोड़ें या अन्य विकल्प चुनें. निर्भर करता है कुछ अलग हो सकते हैं, तो एक तरीका कोई दूसरा.

सबसे सहायक पैटर्न के साथ सबसे आसान पैटर्न का इस्तेमाल करें टेक्नोलॉजी कवरेज, जो <svg> टैग में role="img" जोड़ रहा है और <title> एलिमेंट शामिल है.

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

छठी समस्या: कलर कंट्रास्ट

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

दो उदाहरणों की शिकायत की गई थी.

आइए, इसे ठीक करते हैं.

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

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

इस मामले में, हमें ऐसा गहरा टील रंग मिल सकता है जो 4.5:1 के हिसाब से हो या हम बटन के टेक्स्ट का साइज़ बढ़ाकर 18.5 पिक्सल बोल्ड कर सकते हैं. साथ ही, हरे-नीले रंग का मान थोड़ा सा है. दोनों तरीके, डिज़ाइन के सौंदर्य के मुताबिक होते हैं.

सफ़ेद बैकग्राउंड पर मौजूद सभी स्लेटी रंग के टेक्स्ट का कलर कंट्रास्ट भी सही नहीं है. हालांकि, पेज पर मौजूद दो सबसे बड़ी हेडिंग के लिए ऐसा नहीं है. मिलने के लिए इस टेक्स्ट का रंग गहरा होना चाहिए 4.5:1 कलर कंट्रास्ट की ज़रूरी शर्तें.

सातवीं समस्या: सूची का स्ट्रक्चर

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

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

<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 से ज़्यादा होती है. शून्य से ज़्यादा की वैल्यू का मतलब है कि नेविगेशन के क्रम को साफ़ तौर पर दिखाया गया है. हालांकि तकनीकी रूप से मान्य है, लेकिन यह अक्सर मान्य होता है सहायक टेक्नोलॉजी पर भरोसा करने वाले उपयोगकर्ताओं को परेशानी होती है. Tabindex के नियमों के बारे में ज़्यादा जानें.

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

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

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

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

छठा चरण

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

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

अगला चरण

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

देखें कि आपको क्या समझ आया

ऑटोमेटेड सुलभता टेस्टिंग के बारे में अपनी जानकारी को परखें