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

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

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

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

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

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

• दिव्यांग लोगों के साथ मिलकर, उपयोगिता की जांच करें.
• अपनी टीम में काम करने के लिए, दिव्यांग लोगों को नौकरी पर रखें.
• डिजिटल ऐक्सेसिबिलिटी के बारे में जानकारी रखने वाले किसी व्यक्ति या कंपनी से सलाह लें.

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

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

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

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

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

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

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

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

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

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

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

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

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

डेमो: ऑटोमेटेड टेस्ट

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

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

चरण 1

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

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

दूसरा चरण

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

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

तीसरा चरण

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

चौथा चरण

पेज लोड का विश्लेषण करें पर क्लिक करें. इसके बाद, Lighthouse को टेस्ट चलाने के लिए समय दें.

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

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

पांचवां चरण

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

पहली समस्या: ARIA रोल

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

हमारे डेमो में, न्यूज़लेटर के लिए साइन अप करने वाला बटन काम नहीं कर रहा है:

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

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

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

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

दूसरी समस्या: ARIA hidden

"[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>

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

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

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

पांचवी समस्या: लिंक टेक्स्ट

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

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

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

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

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

सबसे आसान पैटर्न वाला विकल्प इस्तेमाल करें. इसमें सबसे ज़्यादा टेक्नोलॉजी कवरेज मिलता है. इसके लिए, <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 की ज़रूरी शर्तों को पूरा कर सके.

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

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

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

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

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

छठा चरण

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

हमने सुलभता से जुड़े इन सभी अपडेट को एक नए CodePen पर लागू कर दिया है.

अगला चरण

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