WCAG शीर्षक संरचना चेकर

WCAG हेडिंग चेकर क्या है?

एक WCAG हेडिंग चेकर सत्यापित करता है कि वेब पेज पर हेडिंग तत्व (h1, h2, h3, h4, h5, h6) एक तार्किक पदानुक्रम बनाते हैं जिसे स्क्रीन रीडर और अन्य सहायक तकनीकें नेविगेट कर सकती हैं। हेडिंग वह तरीका है जिससे अंधे और कम दृष्टि वाले उपयोगकर्ता एक पृष्ठ को स्किम करते हैं: वे हेडिंग-दर-हेडिंग कूदने के लिए एक स्क्रीन रीडर शॉर्टकट का उपयोग करते हैं, सेकंडों में एक मानसिक सामग्री तालिका बनाते हैं। यदि हेडिंग गायब हैं, क्रम से बाहर हैं, या सजावटी रूप से उपयोग किए गए हैं, तो वह नेविगेशन ध्वस्त हो जाता है। WCAG 2.2 सक्सेस क्राइटीरियन 1.3.1 (जानकारी और संबंध) और 2.4.6 (हेडिंग और लेबल) मांग करते हैं कि हेडिंग संरचना को सही ढंग से व्यक्त करें।

नियम बताने में सरल और तोड़ने में आसान हैं। प्रति पृष्ठ ठीक एक h1 होना चाहिए (पृष्ठ शीर्षक)। प्रत्येक अगला हेडिंग अपने पैरेंट से अधिकतम एक स्तर गहरा होना चाहिए (एक h2 के बाद एक और h2 या एक h3 आ सकता है, लेकिन सीधे h4 नहीं)। हेडिंग खाली नहीं होनी चाहिए। हेडिंग स्तरों को दस्तावेज़ संरचना का वर्णन करना चाहिए, दृश्य आकार का नहीं (केवल इसलिए h4 का उपयोग न करें क्योंकि आप छोटा टेक्स्ट चाहते हैं)। अधिकांश अभिगम्यता ऑडिट हेडिंग पदानुक्रम मुद्दों को पहली चीज़ के रूप में चिह्नित करते हैं जिसे ठीक किया जाना चाहिए क्योंकि वे सामान्य हैं, सत्यापित करना आसान है, और स्क्रीन रीडर उपयोगकर्ताओं के लिए उच्च प्रभाव वाले हैं।

यह टूल आपके द्वारा चिपकाए गए HTML का विश्लेषण करता है (कोई अपलोड नहीं, कोई सर्वर राउंड-ट्रिप नहीं), दस्तावेज़ क्रम में हेडिंग तत्वों के माध्यम से चलता है, और मुद्दों की रिपोर्ट करता है: गुम h1, कई h1, छोड़े गए स्तर, खाली हेडिंग, और पृष्ठ संरचना की एक रूपरेखा। आउटपुट प्रत्येक समस्या का वर्णन करने वाला सादा पाठ है। विकास के दौरान, लॉन्च से पहले, या नियमित अभिगम्यता ऑडिट चक्र के हिस्से के रूप में किसी भी पृष्ठ पर इसे चलाएँ। आउटपुट सरल भाषा में है, संख्यात्मक स्कोर नहीं; लक्ष्य आपको ठीक करने के लिए विशिष्ट मुद्दे देना है, पीछा करने के लिए पासिंग ग्रेड नहीं।

टूल के अंदर क्या है

पृष्ठ का शीर्ष एक टेक्स्टएरिया है जहाँ आप अपना HTML चिपकाते हैं। आप एक पूर्ण दस्तावेज़ (DOCTYPE, html, head, body) या एक खंड (केवल body सामग्री) चिपका सकते हैं। टूल मानक ब्राउज़र DOMParser का उपयोग करके दस्तावेज़ क्रम में सभी h1 से h6 तत्वों को निकालता है, इसलिए विश्लेषण उसी से मेल खाता है जो एक वास्तविक ब्राउज़र करेगा। टेक्स्टएरिया किसी भी आकार के इनपुट को संभालता है; बहुत बड़े दस्तावेज़ (हजारों लाइनें) काम करते हैं लेकिन विश्लेषण में एक सेकंड का अंश अधिक लेते हैं।

हेडिंग जाँचें पर क्लिक करें और परिणाम नीचे दिखाई देते हैं। पहला अनुभाग हेडिंग रूपरेखा है: क्रम में प्रत्येक हेडिंग, स्तर द्वारा इंडेंट की गई, ताकि आप संरचना को सामग्री तालिका के रूप में पढ़ सकें। दूसरा अनुभाग मुद्दों की सूची है: प्रत्येक समस्या अपने विशिष्ट स्थान के साथ, क्या गलत है, और एक संक्षिप्त व्याख्या क्यों यह मायने रखती है। मुद्दों को गंभीरता द्वारा वर्गीकृत किया गया है: त्रुटियाँ (WCAG अनुपालन के लिए ठीक करना आवश्यक है) और चेतावनियाँ (सर्वोत्तम अभ्यास लेकिन सख्त विफलताएँ नहीं)।

आउटपुट ब्राउज़र में रहता है; कुछ भी अपलोड नहीं किया जाता है। आप संशोधनों के बीच फिक्स पर पुनरावृत्ति करने के लिए एक ही HTML को कई बार चिपका सकते हैं। टूल जानबूझकर हेडिंग संरचना के बाहर कुछ भी जाँच नहीं करता (यह alt टेक्स्ट, कंट्रास्ट, फ़ोकस ऑर्डर, ARIA, या किसी अन्य WCAG मानदंड को सत्यापित नहीं करता)। उनके लिए, इस टूल का उपयोग axe DevTools, Lighthouse, या WAVE जैसे व्यापक ऑडिट टूल के साथ करें।

इतिहास और पृष्ठभूमि

शुरुआत से HTML हेडिंग (1991)

Tim Berners-Lee ने 1991 में मूल 18 टैग के हिस्से के रूप में h1 से h6 तत्वों के साथ HTML पेश किया। मूल अर्थपूर्ण इरादा हमेशा दस्तावेज़ संरचना था, दृश्य स्टाइलिंग नहीं। वेब के हेडिंग का पदानुक्रम बहुत पुरानी परंपरा से आता है: मुद्रित दस्तावेज़ (किताबें, पेपर, सरकारी रिपोर्ट) सदियों से संरचना को व्यक्त करने के लिए क्रमांकित अनुभाग स्तरों का उपयोग कर रहे हैं। HTML ने उस मॉडल को सीधे विरासत में लिया। 35 साल की स्थिर अर्थशास्त्र के बावजूद, हेडिंग दुरुपयोग आधुनिक वेब पर सबसे आम अभिगम्यता बगों में से एक है क्योंकि डिज़ाइनर अक्सर पहले दृश्य आकार से शैली करते हैं और बाद में संरचना की जाँच करते हैं।

स्क्रीन रीडर हेडिंग द्वारा नेविगेट करना सीखते हैं (1996 से आगे)

JAWS (Job Access With Speech) को Henter-Joyce ने 1989 में जारी किया और 1990 के दशक के अंत में वेब के लोकप्रिय होने के साथ वेब-पृष्ठ हेडिंग नेविगेशन जोड़ा। JAWS में H कुंजी दबाने से अगली हेडिंग पर कूदता है; क्रमांकित कुंजी 1 से 6 उस विशिष्ट हेडिंग स्तर पर कूदती हैं। तब से प्रत्येक प्रमुख स्क्रीन रीडर (2006 में NVDA, 2005 में VoiceOver, Android पर TalkBack) ने इस शॉर्टकट की नकल की है। WebAIM का वार्षिक स्क्रीन रीडर उपयोगकर्ता सर्वेक्षण लगातार पाता है कि 67 से 70 प्रतिशत स्क्रीन रीडर उपयोगकर्ता पृष्ठ को समझने के लिए अपनी प्राथमिक विधि के रूप में हेडिंग द्वारा नेविगेट करते हैं। टूटी हुई हेडिंग पदानुक्रम इसलिए कॉस्मेटिक समस्या नहीं है।

WCAG 1.0 और अभिगम्यता मानकों का उदय (1999)

वेब कंटेंट एक्सेसिबिलिटी गाइडलाइन्स 1.0 को W3C ने मई 1999 में प्रकाशित किया, वेब अभिगम्यता के लिए पहला अंतरराष्ट्रीय मानक। WCAG 1.0 ने स्पष्ट रूप से आवश्यक किया कि हेडिंग का उपयोग दस्तावेज़ संरचना के लिए किया जाए (चेकपॉइंट 3.5)। WCAG 2.0 (2008) ने इसे सफलता मानदंड 1.3.1 (जानकारी और संबंध, स्तर A) और 2.4.6 (हेडिंग और लेबल, स्तर AA) में परिष्कृत किया। WCAG 2.1 (2018) और 2.2 (2023) ने इन मानदंडों को अपरिवर्तित रखा क्योंकि अंतर्निहित आवश्यकता ध्वनि है। दुनिया भर में अधिकांश अभिगम्यता कानून (अमेरिका में ADA, यूरोप में EAA, ओंटारियो में AODA) अब WCAG 2.1 AA को कानूनी बेसलाइन के रूप में उद्धृत करते हैं।

HTML5 अनुभागीकरण और दस्तावेज़ रूपरेखा (2014)

HTML5 (W3C अनुशंसा 2014) ने अनुभागीकरण तत्व (article, section, nav, aside) और एक रूपरेखा एल्गोरिथम पेश किया जो नेस्टिंग गहराई से हेडिंग पदानुक्रम प्राप्त करने वाला था। एल्गोरिथम किसी भी ब्राउज़र या स्क्रीन रीडर में कभी लागू नहीं किया गया था और 2022 में औपचारिक रूप से अप्रचलित कर दिया गया था। व्यावहारिक मार्गदर्शन है: स्पष्ट हेडिंग स्तरों (h1 से h6) का उपयोग करें और अनुभागीकरण तत्वों को अर्थपूर्ण समूहन के रूप में मानें, हेडिंग गहराई के विकल्प के रूप में नहीं। HTML लिविंग स्टैंडर्ड अब स्पष्ट रूप से कहता है कि हेडिंग स्तरों को स्पष्ट रूप से सेट किया जाना चाहिए।

ARIA भूमिकाएँ और aria-level (2014 के बाद)

WAI-ARIA 1.1 (W3C अनुशंसा 2017) हेडिंग को चिह्नित करने के वैकल्पिक तरीके के रूप में aria-level="N" के साथ role="heading" प्रदान करता है, जब आप मूल h1-h6 तत्वों का उपयोग नहीं कर सकते हैं (उदाहरण के लिए, एक फ्रेमवर्क घटक में जिसे विभिन्न संदर्भों में विभिन्न हेडिंग स्तरों को रेंडर करने की आवश्यकता होती है)। स्क्रीन रीडर role="heading" को मूल तत्व के समान मानते हैं। सर्वोत्तम अभ्यास संभव होने पर मूल तत्वों का उपयोग करना है; केवल तब ARIA का उपयोग करें जब मूल अर्थशास्त्र अनुपलब्ध हो। यह टूल मूल हेडिंग तत्वों और role="heading" वाले तत्वों दोनों की जाँच करता है।

अभिगम्यता मुकदमे और व्यापार मामला (2017 के बाद)

Domino's Pizza बनाम Robles (US सुप्रीम कोर्ट 2019) ने स्थापित किया कि अमेरिकियों के साथ विकलांगता अधिनियम (ADA, 1990) वाणिज्यिक वेबसाइटों पर लागू होता है। हर साल सैकड़ों समान मुकदमे हुए (केवल 2024 में 4,000 से अधिक ADA वेब मुकदमे दायर किए गए)। यूरोपीय अभिगम्यता अधिनियम (EAA, जून 2025 में लागू) पूरे EU में अधिकांश उपभोक्ता-सामना वाली वेबसाइटों के लिए WCAG-समतुल्य अभिगम्यता को कानूनी आवश्यकता बनाता है। विफल हेडिंग संरचना वादीयों के लिए पहचानने और दस्तावेज़ करने के लिए सबसे आसान मुद्दों में से एक है, जो बुनियादी हेडिंग जाँचों को उच्च-लाभ अनुपालन कदम बनाता है।

व्यावहारिक वर्कफ़्लो

नए पृष्ठों और टेम्पलेट्स पर प्री-लॉन्च जाँच

किसी भी नए पृष्ठ या टेम्पलेट के शिप होने से पहले, इस चेकर के माध्यम से HTML चलाएँ। हेडिंग-संरचना मुद्दे पेश करने के लिए सबसे आसान अभिगम्यता बग हैं (विशेष रूप से CMS-संचालित सामग्री में जहाँ संपादक दृश्य आकार के आधार पर हेडिंग स्तर चुनते हैं) और ठीक करने के लिए सबसे आसान। लॉन्च से पहले उन्हें पकड़ना बाद में बहुत सस्ता है, जब फिक्स को सामग्री मालिकों के साथ समन्वय की आवश्यकता होती है। एजेंसियों के लिए, इस जाँच को QA चेकलिस्ट में बनाएँ; इन-हाउस टीमों के लिए, इसे कोड समीक्षा के हिस्से के रूप में या main में विलय से पहले चलाएँ।

अभिगम्यता अनुपालन के लिए मौजूदा साइट का ऑडिट करना

अभिगम्यता ऑडिट (पूर्व-मुकदमा, EAA अनुपालन, अनुबंध आवश्यकता) के लिए, सबसे अधिक ट्रैफ़िक वाले पृष्ठों के माध्यम से चलें और प्रत्येक के HTML को इस चेकर के माध्यम से चलाएँ। निष्कर्षों का दस्तावेज़ीकरण करें: किन पृष्ठों में हेडिंग मुद्दे हैं, किस प्रकार, कैसे ठीक करें। अन्य WCAG मानदंडों के लिए axe DevTools या Lighthouse के साथ जोड़ें। हेडिंग-संरचना निष्कर्ष आमतौर पर सुधारने में सबसे आसान होते हैं और ऑडिट रिपोर्ट का एक ठोस त्वरित-जीत अनुभाग बनाते हैं।

CMS संपादक प्रशिक्षण और टेम्पलेटिंग

CMS-संचालित सामग्री (WordPress, Drupal, Contentful, Sanity) अक्सर संपादकों को H1 से H6 विकल्पों के साथ एक हेडिंग ड्रॉपडाउन देती है। संपादक जो नियमों को नहीं जानते वे दृश्य आकार से स्तर चुनते हैं। संपादकों को इस चेकर का प्रदर्शन करें ताकि वे देख सकें कि उनकी हेडिंग पसंद क्या उत्पन्न करती है। टेम्पलेट्स के लिए, प्रत्येक डिज़ाइन परिवर्तन के बाद रेंडर किए गए आउटपुट को चेकर के माध्यम से चलाएँ ताकि पुष्टि हो सके कि संपादक की हेडिंग पसंद अभी भी मान्य पदानुक्रम उत्पन्न करती है। कई CMS प्लगइन मौजूद हैं जो लिखने के समय संपादकों को चेतावनी देते हैं; यह टूल सत्यापन कदम की सेवा करता है।

ईमेल टेम्पलेट्स और HTML न्यूज़लेटर्स को मान्य करना

स्क्रीन रीडर द्वारा पढ़े गए HTML ईमेल को वेब पृष्ठों के समान हेडिंग पदानुक्रम का पालन करना चाहिए। बड़ी सूची को भेजने से पहले इस चेकर के माध्यम से अपने ईमेल टेम्पलेट का HTML चलाएँ। सामान्य ईमेल-टेम्पलेट मुद्दे: कई h1 (जब प्रत्येक अनुभाग का अपना शीर्षक होता है), गुम h1 (जब लेआउट सीधे h2 से शुरू होता है), और केवल छोटे हेडिंग के लिए उपयोग किए जाने वाले सजावटी h4। भेजने से पहले इन्हें ठीक करें; आपकी सूची पर सहायक तकनीक उपयोगकर्ता ध्यान देंगे।

PDF-से-HTML रूपांतरणों को मान्य करना

जब आप अभिगम्यता के लिए PDFs को HTML में परिवर्तित करते हैं (ताकि उन्हें हेडिंग नेविगेशन के साथ स्क्रीन रीडर द्वारा पढ़ा जा सके), तो कन्वर्टर को PDF संरचना टैग को HTML हेडिंग स्तरों में मैप करना होता है। परिणाम अक्सर टूटा हुआ होता है: उचित टैगिंग के बिना PDFs बिना किसी हेडिंग के सपाट HTML उत्पन्न करते हैं, और यहाँ तक कि टैग किए गए PDFs कभी-कभी all-h1 या all-h2 आउटपुट उत्पन्न करते हैं। परिवर्तित पृष्ठ को प्रकाशित करने से पहले समस्या को खोजने के लिए इस चेकर के माध्यम से परिवर्तित HTML चलाएँ।

नए डेवलपर्स और डिज़ाइनर का ऑनबोर्डिंग

जूनियर फ्रंट-एंड डेवलपर्स और डिज़ाइनरों को टूटी हुई हेडिंग पदानुक्रम और परिणामी स्क्रीन रीडर अनुभव के ठोस उदाहरण देखने से लाभ होता है। यह दिखाने के लिए कि हेडिंग कैसे स्क्रीन रीडर नेविगेशन को चलाते हैं, इस टूल को स्क्रीन रीडर डेमो के साथ जोड़ें (Windows पर NVDA मुफ्त है, Mac पर VoiceOver इन-बिल्ट है)। अमूर्त हेडिंग नियमों और ठोस उपयोगकर्ता अनुभव के बीच का संबंध अक्सर वही होता है जो पाठ को चिपकाता है।

सामान्य त्रुटियाँ

दृश्य आकार द्वारा हेडिंग स्तर चुनना

सबसे आम गलती: h4 का उपयोग करना क्योंकि आप छोटा टेक्स्ट चाहते हैं, या h2 से h4 पर कूदना क्योंकि डिज़ाइन में सही आकार का h3 नहीं है। हेडिंग स्तर संरचनात्मक हैं, दृश्य नहीं; आकार को नियंत्रित करने के लिए CSS का उपयोग करें और उस स्तर का उपयोग करें जो दस्तावेज़ पदानुक्रम से मेल खाता है। यदि आपके डिज़ाइन सिस्टम में हर आवश्यक स्तर के लिए दृश्य शैली नहीं है, तो गलत स्तर चुनने के बजाय एक जोड़ें (या क्लास नामों के साथ ओवरराइड करें)।

प्रति पृष्ठ कई h1

एक पृष्ठ में पृष्ठ शीर्षक का प्रतिनिधित्व करने वाला ठीक एक h1 होना चाहिए। सामान्य बग: h1 में लिपटा साइट लोगो प्लस एक लेख शीर्षक भी h1 में (दो h1), प्रत्येक हीरो अनुभाग h1 का उपयोग करते हुए मुखपृष्ठ (कई h1), या बिल्कुल भी h1 नहीं क्योंकि लेआउट h2 से शुरू होता है। फिक्स संरचनात्मक है: पृष्ठ पर सबसे महत्वपूर्ण सामग्री को एकल h1 के रूप में चुनें और बाकी सब कुछ को h2 या उससे नीचे डिमोट करें। axe और Lighthouse जैसे टूल इस कारण से कई h1 पर चेतावनी देते हैं।

छोड़े गए हेडिंग स्तर

h2 से सीधे h4 जाना दस्तावेज़ रूपरेखा को तोड़ता है। हेडिंग-से-हेडिंग चलने वाले स्क्रीन रीडर उपयोगकर्ता प्रत्येक h4 को h3 के नीचे नेस्ट होने की उम्मीद करते हैं, और गुम h3 संरचना को भ्रमित करता है। फिक्स गुम मध्यवर्ती स्तर डालना या h4 को h3 में डिमोट करना है। सबसे आम कारण एक मॉकअप से डिज़ाइन कॉपी करना है जहाँ दृश्य पदानुक्रम तीन आकारों का उपयोग करता है लेकिन डिज़ाइन सिस्टम चार हेडिंग स्तरों का उपयोग करता है; प्रत्येक घटक अद्यतन के बाद फिर से जाँच करें।

खाली हेडिंग

बिना टेक्स्ट सामग्री के एक h2 (अक्सर क्योंकि एक JavaScript विजेट ने टेक्स्ट हटा दिया लेकिन तत्व रखा) स्क्रीन रीडर की हेडिंग सूची में एक बिना लेबल वाली हेडिंग के रूप में दिखाई देती है, जो भ्रमित और बेकार है। या तो हेडिंग को टेक्स्ट से भरें, या हेडिंग तत्व को पूरी तरह से हटा दें। यह सिंगल-पेज ऐप्स में आम है जहाँ डेटा लोड होने से पहले प्लेसहोल्डर तत्व रेंडर किए जाते हैं; केवल तभी हेडिंग रेंडर करें जब इसमें डालने के लिए सामग्री हो।

गैर-अर्थपूर्ण रैपरों के अंदर हेडिंग

role="presentation" या aria-hidden="true" के साथ div में लिपटी हेडिंग अभिगम्यता ट्री से हटा दी जाती है, जो अन्यथा सही हेडिंग को स्क्रीन रीडर से छुपा सकती है। प्रत्येक हेडिंग के पैरेंट तत्वों का ऑडिट करें ताकि सुनिश्चित हो सके कि वे अभिगम्यता ट्री से हेडिंग को नहीं हटाते हैं। CSS display:none और visibility:hidden भी हेडिंग को हटाते हैं; केवल जानबूझकर उपयोग करें और कभी भी ऐसी सामग्री पर नहीं जो स्क्रीन-रीडर-दृश्य होनी चाहिए।

जब मूल HTML काम करेगा तब ARIA का उपयोग करना

h2 तत्व का उपयोग करने के बजाय div में role="heading" aria-level="2" जोड़ना अभिगम्यता के लिए काम करता है लेकिन अनावश्यक जटिलता है। मूल h1-h6 तत्वों को हेडिंग अर्थशास्त्र मुफ्त में मिलता है, डिफ़ॉल्ट ब्राउज़र शैलियों में सही ढंग से रेंडर होते हैं, और ARIA ओवरराइड्स से बेहतर स्क्रीन रीडर बग का सामना करते हैं। ARIA का पहला नियम (WAI-ARIA ऑथरिंग प्रथाओं के अनुसार) है: जब मूल HTML समान अर्थशास्त्र प्रदान करता है तो ARIA का उपयोग न करें। मूल हेडिंग तत्वों का उपयोग करें जब तक कि फ्रेमवर्क बाधा वास्तव में ARIA को मजबूर न करे।

गोपनीयता और डेटा हैंडलिंग

आपके द्वारा चिपकाया गया HTML पूरी जाँच के दौरान आपके ब्राउज़र में रहता है। हेडिंग निकालने वाला DOMParser आपकी मशीन पर JavaScript में चलता है; परिणाम टेक्स्टएरिया के नीचे पृष्ठ में रेंडर किए जाते हैं। कोई अपलोड चरण नहीं है, कोई दूरस्थ प्रसंस्करण नहीं है, और आपने कौन सा HTML चिपकाया उसके बारे में कोई टेलीमेट्री नहीं है। यह मायने रखता है क्योंकि वह HTML जिसे आप सबसे अधिक जाँचना चाहते हैं (प्री-लॉन्च टेम्पलेट्स, NDA के तहत क्लाइंट साइट्स, आंतरिक एडमिन पृष्ठ) वही है जिसे आपको तीसरे पक्ष के SaaS वैलिडेटर में नहीं चिपकाना चाहिए।

एक बार पृष्ठ लोड हो जाने के बाद, टूल ऑफ़लाइन काम करता है। आप इंटरनेट से डिस्कनेक्ट कर सकते हैं, HTML चिपका सकते हैं, जाँच चला सकते हैं, और परिणामों की समीक्षा कर सकते हैं बिना आपके मार्कअप के किसी अन्य मशीन को छुए। अधिकांश क्लाउड अभिगम्यता चेकर (PowerMapper, Tenon, Site Improve) पृष्ठ URL या HTML अपलोड करने की मांग करते हैं; गोपनीय पृष्ठों के लिए यह ठीक वह विफलता मोड है जिससे बचना है।

इस टूल का उपयोग कब न करें

पूर्ण WCAG ऑडिट के लिए (व्यापक टूल का उपयोग करें)

हेडिंग संरचना दर्जनों WCAG मानदंडों में से एक है। पूर्ण ऑडिट के लिए, axe DevTools (Deque से मुफ्त Chrome/Firefox एक्सटेंशन), Lighthouse (Chrome में निर्मित), WAVE (WebAIM का मुफ्त टूल), या Tenon या PowerMapper जैसे भुगतान समाधान का उपयोग करें। ये रंग कंट्रास्ट, alt टेक्स्ट, ARIA उपयोग, फॉर्म लेबल, फ़ोकस ऑर्डर, और कई और चीज़ों की जाँच करते हैं। व्यापक के बजाय, इसके साथ इस टूल को चलाएँ।

गतिशील सामग्री के लिए (रेंडर किए गए DOM का परीक्षण करें)

यदि आपके हेडिंग JavaScript (React, Vue, Svelte, Angular) द्वारा उत्पन्न होते हैं, तो स्थिर HTML स्रोत में अंतिम हेडिंग नहीं होते हैं। आपको JavaScript चलने के बाद रेंडर किए गए DOM को चिपकाना होगा। ब्राउज़र DevTools का उपयोग करें: पृष्ठ खोलें, DevTools खोलें, Elements टैब, body या main पर राइट-क्लिक करें, Copy outerHTML, फिर इस चेकर में चिपकाएँ। या एक ब्राउज़र एक्सटेंशन का उपयोग करें जो लाइव DOM को सीधे चलाता है।

स्वचालित CI/CD पाइपलाइनों के लिए (Node लाइब्रेरी का उपयोग करें)

यदि आप चाहते हैं कि हेडिंग जाँच हर कमिट या पुल अनुरोध पर स्वचालित रूप से चले, तो axe-core, Pa11y, या jest-axe को अपने टेस्ट सूट में एकीकृत करें। वे CI में हेडलेस रूप से हेडिंग जाँच (और कई अन्य WCAG जाँच) चलाते हैं। यह ब्राउज़र टूल विकास और समीक्षा के दौरान इंटरैक्टिव उपयोग के लिए है, स्वचालन के लिए नहीं। दोनों का अपना स्थान है; एक बार के ऑडिट के लिए ब्राउज़र टूल का उपयोग करें और निरंतर सत्यापन के लिए CI लाइब्रेरी।

PDF या Word दस्तावेज़ अभिगम्यता के लिए

PDFs और Word दस्तावेज़ों के अपने अभिगम्यता टैगिंग सिस्टम (PDF/UA, Word हेडिंग शैलियाँ) हैं। वे HTML हेडिंग का उपयोग नहीं करते हैं, इसलिए यह टूल लागू नहीं होता है। PDF अभिगम्यता के लिए, Adobe Acrobat Pro के Accessibility Checker या PAC 2024 (मुफ्त, PDF/UA-केंद्रित) का उपयोग करें। Word के लिए, इन-बिल्ट Accessibility Checker (समीक्षा टैब) का उपयोग करें। यदि आप इस टूल का उपयोग करना चाहते हैं तो पहले HTML में परिवर्तित करें, लेकिन रूपांतरण स्वयं हेडिंग समस्याओं को पेश कर सकता है।

अधिक प्रश्न

क्या एक हेडिंग स्तर को छोड़ना कभी ठीक है?

सीधे दस्तावेज़ सामग्री में नहीं। WCAG 2.2 SC 1.3.1 का तात्पर्य है कि हेडिंग को पदानुक्रमिक अनुक्रम बनाना चाहिए। एक सामान्य मामला जहाँ यह छोड़ने जैसा दिखता है वह पृष्ठ रूपरेखा h1 से शुरू होकर मुख्य सामग्री क्षेत्र के अंदर h2, जबकि एक साइडबार या नेविगेशन में भी h2 हैं; यह ठीक है क्योंकि दोनों पृष्ठ के h1 के तहत भाई-बहन हैं। वास्तविक नियम है: सन्निहित सामग्री प्रवाह के भीतर स्तर न छोड़ें। चेकर केवल वास्तविक छोड़ने को चिह्नित करता है।

क्या होगा यदि मेरा फ्रेमवर्क केवल एक हेडिंग स्तर का समर्थन करता है?

कुछ घटक पुस्तकालय हेडिंग को निश्चित स्तर पर रेंडर करते हैं (हमेशा h2, नेस्टिंग की परवाह किए बिना)। फिक्स हेडिंग घटक पर एक स्तर प्रॉप उजागर करना है (h2, h3, आदि) और पैरेंट्स को उपयुक्त मान पारित करने देना है। React जैसे फ्रेमवर्क आमतौर पर ऐसा करते हैं; यदि आपका नहीं करता है, तो घटक पर aria-level जोड़ें और जब तक आप रिफैक्टर नहीं कर सकते तब तक एक अस्थायी समाधान के रूप में role="heading" का उपयोग करें। दीर्घावधि में, हर पुन: प्रयोज्य हेडिंग घटक को एक स्तर प्रॉप स्वीकार करना चाहिए।

क्या टूल role="heading" जैसी ARIA भूमिकाओं की जाँच करता है?

हाँ। role="heading" और एक मान्य aria-level विशेषता (1 से 6) वाला कोई भी तत्व संकेतित स्तर पर एक हेडिंग के रूप में माना जाता है। मूल h1-h6 तत्व हमेशा पसंदीदा होते हैं, लेकिन ARIA-चिह्नित हेडिंग स्क्रीन रीडर के लिए समान रूप से मान्य हैं और मूल के साथ-साथ जाँच की जाती है।

अन्य WCAG मानदंडों की तुलना में हेडिंग पदानुक्रम कितना महत्वपूर्ण है?

बहुत। WebAIM का वार्षिक स्क्रीन रीडर उपयोगकर्ता सर्वेक्षण लगातार पाता है कि 67-70% स्क्रीन रीडर उपयोगकर्ता पृष्ठ को समझने के अपने प्राथमिक तरीके के रूप में हेडिंग द्वारा नेविगेट करते हैं। खराब हेडिंग प्रभावी रूप से मुख्य अभिगम्यता नेविगेशन विधियों में से एक को ब्लॉक करते हैं। WebAIM के WebAIM Million वार्षिक विश्लेषण में, हेडिंग मुद्दे वेब पर सबसे आम पाँच अभिगम्यता विफलताओं में से हैं। उच्च उपयोगकर्ता प्रभाव और आसान पहचान का संयोजन उन्हें शीर्ष प्राथमिकता बनाता है।

क्या हर पृष्ठ में एक h1 होना चाहिए?

हाँ, दुर्लभ अपवादों के साथ। हर पूर्ण HTML दस्तावेज़ में पृष्ठ शीर्षक का प्रतिनिधित्व करने वाला ठीक एक h1 होना चाहिए। अपवाद वे टुकड़े हैं जो स्पष्ट रूप से एक बड़े पृष्ठ में डाले गए हैं (एक ईमेल हस्ताक्षर, एक अन्य पृष्ठ में एम्बेड किया गया विजेट); मेजबान पृष्ठ h1 प्रदान करता है और टुकड़ा h2 या उससे कम पर शुरू होता है। स्टैंडअलोन पृष्ठों के लिए, गुम h1 एक स्पष्ट अभिगम्यता विफलता है।

क्या मैं कानूनी अनुपालन ऑडिट के लिए इस टूल पर भरोसा कर सकता हूँ?

विशेष रूप से हेडिंग संरचना के लिए, हाँ: नियम सटीक हैं और टूल उन्हें सटीक रूप से लागू करता है। समग्र WCAG अनुपालन के लिए, कोई भी एकल स्वचालित टूल पर्याप्त नहीं है; कानूनी-ग्रेड ऑडिट के लिए सहायक तकनीक के साथ मैनुअल परीक्षण, विशेषज्ञ समीक्षा, और विकलांग उपयोगकर्ताओं के साथ उपयोगकर्ता परीक्षण आवश्यक है। इस टूल का उपयोग अपने ऑडिट के कई इनपुटों में से एक के रूप में करें, अनुपालन के लिए सत्य के एकमात्र स्रोत के रूप में नहीं।