अपनी वेबसाइट को सुलभ (accessible) कैसे बनाएं: WCAG 2.2 की शुरुआती गाइड
वेबसाइट को सुलभ बनाने के लिए उसे इस तरह बनाएं कि लोग उसे कीबोर्ड, स्क्रीन रीडर, ज़ूम या स्विच डिवाइस से भी इस्तेमाल कर सकें, सिर्फ़ माउस से नहीं: बटन, लिंक, हेडिंग और फ़ॉर्म लेबल के लिए असली HTML एलिमेंट इस्तेमाल करें, इमेज को सार्थक alt टेक्स्ट दें, टेक्स्ट का कंट्रास्ट ऊंचा रखें और फ़ोकस साफ़ दिखाएं। लक्ष्य मानक WCAG 2.2 लेवल AA है। ऑटोमेटिक चेकर समस्या का एक हिस्सा पकड़ते हैं; दस मिनट का कीबोर्ड और स्क्रीन रीडर टेस्ट बाकी का काफ़ी हिस्सा पकड़ लेता है।
व्यवहार में “सुलभ” का मतलब क्या है
सुलभता लोगों के बारे में है: कोई नेत्रहीन व्यक्ति जो स्क्रीन रीडर इस्तेमाल करता है, कोई जिसके हाथ कांपते हैं और जो कीबोर्ड से नेविगेट करता है, कोई कम दृष्टि वाला व्यक्ति जो 200% तक ज़ूम करता है, कोई तेज़ धूप में पढ़ता हुआ, या कोई जिसका हाथ कुछ हफ़्ते के लिए टूटा है। अच्छी सुलभता अक्सर सबके लिए साइट बेहतर बनाती है: साफ़ ढांचा, पढ़ने योग्य टेक्स्ट, और ऐसे फ़ॉर्म जो अपनी गलतियां समझाएं।
मुख्य संदर्भ मानक W3C के Web Content Accessibility Guidelines (WCAG) हैं। सितंबर 2026 तक, मौजूदा संस्करण WCAG 2.2 है (अक्टूबर 2023 में प्रकाशित, दिसंबर 2024 में अपडेट); WCAG 3 शुरुआती ड्राफ़्ट में है। WCAG चार सिद्धांतों के इर्द-गिर्द बना है — कंटेंट समझने योग्य (perceivable), संचालित होने योग्य (operable), समझ में आने योग्य (understandable) और मज़बूत (robust) होना चाहिए — और इसके तीन अनुपालन स्तर हैं:
| स्तर | इसका मतलब | इसे कौन लक्ष्य बनाता है |
|---|---|---|
| A | न्यूनतम; इसके बिना कुछ लोग साइट का इस्तेमाल बिल्कुल नहीं कर सकते | सभी |
| AA | आम लक्ष्य; कंट्रास्ट, फ़ोकस, आकार बदलना और त्रुटि संभालना शामिल | ज़्यादातर संगठन और कई कानून |
| AAA | सबसे सख्त; सभी कंटेंट के लिए संभव नहीं | कुछ खास सेवाएं और ऑडियंस |
कई जगहों के कानून WCAG का हवाला देते हैं — उदाहरण के लिए यूरोपीय एक्सेसिबिलिटी एक्ट, जो जून 2025 से EU में कई उपभोक्ता-उन्मुख डिजिटल सेवाओं पर लागू है। आप पर कौन से नियम लागू होते हैं, यह इस पर निर्भर है कि आप कहां काम करते हैं और क्या बेचते हैं; अगर पक्का न हो, तो किसी सलाहकार से पूछें। यह गाइड व्यावहारिक काम पर केंद्रित है।
विकल्प: वहां कैसे पहुंचें
| तरीका | किसके लिए अच्छा | ट्रेड-ऑफ़ |
|---|---|---|
| शुरू से ही बनाएं | नई साइट और ऐप | कुल मिलाकर सबसे कम मेहनत; शुरू में ही तय करना होगा |
| ऑडिट करें और ठीक करें | मौजूदा साइट | असली समस्याएं मिलती हैं; हर पेज पर केंद्रित जांच लगती है |
| पेशेवर ऑडिट | नियंत्रित क्षेत्र, बड़ी साइट, सार्वजनिक संस्थाएं | गहन और दस्तावेज़ीकृत; पैसे लगते हैं |
| ओवरले विजेट | सिफ़ारिश नहीं की जाती | अंदर के कोड को ठीक नहीं कर सकता |
ज़्यादातर छोटी साइट के लिए पहले दो तरीके काफ़ी हैं: AI से शुरू से ही सुलभ तरीके से बनाने को कहें, फिर लॉन्च से पहले ऑडिट करें।
वे सुधार जो सबसे ज़्यादा मायने रखते हैं
सही HTML एलिमेंट इस्तेमाल करें
ज़्यादातर सुलभता सही HTML से अपने आप मिल जाती है। <button> फ़ोकस किया जा सकता है, Enter और Space से काम करता है, और बटन के रूप में घोषित होता है। क्लिक हैंडलर वाला <div> इनमें से कुछ नहीं करता। AI से बना कोड कभी-कभी हर चीज़ के लिए स्टाइल किए गए div इस्तेमाल करता है; सिमैंटिक एलिमेंट मांगें:
- कार्रवाई के लिए
<button>, नेविगेशन के लिए<a href> - हर पेज पर एक
<h1>, फिर क्रम से<h2>,<h3>— स्क्रीन रीडर इस्तेमाल करने वाले हेडिंग के बीच कूदते हैं - लैंडमार्क:
<header>,<nav>,<main>,<footer> - हर फ़ॉर्म फ़ील्ड से जुड़ा
<label> <html lang="en">में पेज की भाषा
ARIA एट्रिब्यूट तभी इस्तेमाल करें जब कोई मूल एलिमेंट फ़िट न बैठे — जैसे कस्टम टैब सेट या combobox के लिए। गलत ARIA न होने से भी बुरा है।
कीबोर्ड पहुंच और दिखता फ़ोकस
माउस से जो कुछ भी कर सकते हैं, वह सिर्फ़ कीबोर्ड से भी होना चाहिए (WCAG 2.1.1)। पेज पर Tab दबाएं: हर लिंक, बटन और फ़ील्ड तार्किक क्रम में पहुंचने योग्य होना चाहिए, और आपको हमेशा दिखना चाहिए कि फ़ोकस कहां है (2.4.7 Focus Visible)। WCAG 2.2 ने जोड़ा है कि फ़ोकस किया गया एलिमेंट स्टिकी हेडर या कुकी बैनर के पीछे पूरी तरह छिपना नहीं चाहिए (2.4.11, लेवल AA)।
आम गड़बड़ियां: ऐसे मेन्यू जो सिर्फ़ होवर पर खुलें, ऐसे मोडल जो फ़ोकस को बांधे न रखें या Escape से बंद न हों, और CSS में outline: none जिसकी जगह कुछ और न हो।
टेक्स्ट विकल्प
हर सार्थक इमेज को ऐसा alt टेक्स्ट चाहिए जो संदर्भ में बताए कि वह क्या दिखाती है (“शेफ़ टेस्टिंग मेन्यू की प्लेटिंग करते हुए”, न कि “image1.jpg”)। सजावटी इमेज को खाली alt="" दें ताकि स्क्रीन रीडर उन्हें छोड़ दें। सिर्फ़ आइकन वाले बटन का सुलभ नाम होना चाहिए (“Close”, “Search”)। वीडियो को कैप्शन चाहिए; ऑडियो को ट्रांसक्रिप्ट।
रंग और कंट्रास्ट
WCAG 2.2 AA सामान्य टेक्स्ट के लिए कम से कम 4.5:1 और बड़े टेक्स्ट के लिए 3:1 कंट्रास्ट अनुपात मांगता है (1.4.3), और इनपुट बॉर्डर व अर्थपूर्ण आइकन जैसे इंटरफ़ेस के हिस्सों के लिए 3:1 (1.4.11)। हल्के भूरे प्लेसहोल्डर टेक्स्ट और फीके बटन आम तौर पर फ़ेल होते हैं। साथ ही, अर्थ देने के लिए सिर्फ़ रंग का इस्तेमाल कभी न करें — किसी गलत फ़ील्ड पर लाल बॉर्डर के साथ त्रुटि संदेश भी होना चाहिए।
आकार बदलना और रीफ़्लो
टेक्स्ट 200% ज़ूम पर भी उपयोगी रहना चाहिए (1.4.4), और कंटेंट 320 CSS पिक्सल की चौड़ाई पर बिना बगल में स्क्रॉल किए काम करना चाहिए (1.4.10)। ठीक से रिस्पॉन्सिव लेआउट इसका ज़्यादातर हिस्सा संभाल लेता है।
टारगेट का आकार, फ़ॉर्म और त्रुटियां
- टारगेट का आकार: WCAG 2.2 AA पॉइंटर टारगेट के लिए कम से कम 24 x 24 CSS पिक्सल, या छोटे टारगेट के आसपास पर्याप्त जगह मांगता है (2.5.8)। फ़ोन पर बड़ा टारगेट ज़्यादा आरामदेह होता है।
- फ़ॉर्म: दिखने वाले लेबल (सिर्फ़ प्लेसहोल्डर नहीं), साफ़ निर्देश, और ऐसे त्रुटि संदेश जो बताएं कि क्या गलत है और कैसे ठीक करें, फ़ील्ड के पास।
- लॉगिन: लोगों से बिना विकल्प के पहेली हल करवाना या कोड लिखवाना नहीं; पासवर्ड मैनेजर और पेस्ट करने की अनुमति दें (3.3.8 Accessible Authentication)।
जो प्रॉम्प्ट काम करते हैं
इस साइट को WCAG 2.2 लेवल AA के अनुसार बनाओ: सिमैंटिक HTML लैंडमार्क, हर पेज पर एक h1 और क्रम से हेडिंग, असली button और link एलिमेंट, हर फ़ॉर्म फ़ील्ड पर लेबल, दिखने वाले फ़ोकस स्टाइल, कम से कम 4.5:1 टेक्स्ट कंट्रास्ट, सार्थक इमेज पर alt टेक्स्ट और सजावटी पर alt="", और html lang सेट हो।
/signup और /checkout पेजों का सुलभता ऑडिट करो। सिर्फ़ कीबोर्ड से इस्तेमाल, फ़ोकस क्रम, दिखता फ़ोकस, लेबल, त्रुटि संदेश, कंट्रास्ट, और आइकन बटन के स्क्रीन रीडर नाम जांचो। हर समस्या को WCAG मानदंड के साथ सूचीबद्ध करो, फिर उन्हें ठीक करो, विज़ुअल डिज़ाइन को ज़रूरत से ज़्यादा बदले बिना।
मोबाइल मेन्यू कीबोर्ड से इस्तेमाल नहीं हो सकता। इसे aria-expanded वाला बटन बनाओ, खुलने पर फ़ोकस मेन्यू के अंदर ले जाओ, Escape से बंद करो और फ़ोकस वापस बटन पर लौटाओ।
चरण दर चरण
- एक ऑटोमेटिक जांच चलाएं। Chrome DevTools में Lighthouse का Accessibility सेक्शन, या axe ब्राउज़र एक्सटेंशन, हर मुख्य पेज पर। जो भी वह बताए, ठीक करें।
- माउस हटा दें। हर पेज पर Tab दबाते हुए हर मुख्य काम पूरा करें — साइन अप, खोज, चेकआउट। जो कुछ आप पहुंच नहीं पाते, जिस पर फ़ोकस नहीं दिखता, या जिससे बाहर नहीं निकल पाते, वह नोट करें।
- 200% ज़ूम करें और विंडो को फ़ोन की चौड़ाई तक सिकोड़ें। कुछ भी कटना या बगल में स्क्रॉल चाहिए नहीं।
- दस मिनट स्क्रीन रीडर आज़माएं: Mac और iPhone पर VoiceOver, Android पर TalkBack, या Windows पर NVDA (मुफ़्त)। हेडिंग, लिंक और फ़ॉर्म फ़ील्ड सुनें। बिना नाम वाला “button”, या “link, click here” का मतलब है कि अभी काम बाकी है।
- टेक्स्ट, बटन और इनपुट का कंट्रास्ट एक कंट्रास्ट चेकर से जांचें।
- ठीक करें, फिर वही काम दोबारा टेस्ट करें।
- एक सुलभता स्टेटमेंट प्रकाशित करें जिसमें लिखा हो कि आप किस मानक का लक्ष्य रखते हैं और समस्याएं कैसे रिपोर्ट करें — और उन रिपोर्ट का जवाब दें।
आम गलतियां
- कोड ठीक करने के बजाय ओवरले विजेट पर भरोसा करना।
- फ़ोकस आउटलाइन हटाना क्योंकि वे अव्यवस्थित लगते हैं, बिना किसी विकल्प के।
- सिर्फ़ प्लेसहोल्डर टेक्स्ट को लेबल बनाना। किसी के टाइप करते ही वह गायब हो जाता है, और अक्सर उसका कंट्रास्ट कम होता है।
- “Click here” और “Read more” लिंक। संदर्भ के बिना, स्क्रीन रीडर इस्तेमाल करने वाले एक जैसे लिंक की सूची सुनते हैं।
- कीवर्ड भरा alt टेक्स्ट। alt टेक्स्ट लोगों के लिए है; इमेज का वर्णन करें।
- एक बार टेस्ट करना। हर नया फ़ीचर कीबोर्ड पहुंच तोड़ सकता है। अपनी लॉन्च से पहले की टेस्टिंग में एक कीबोर्ड जांच जोड़ें।
सुलभता चेकलिस्ट
- मुख्य पेजों पर ऑटोमेटिक जांच (Lighthouse या axe) साफ़
- हर काम सिर्फ़ कीबोर्ड से पूरा हो सकता है
- फ़ोकस हमेशा दिखता है और स्टिकी एलिमेंट के पीछे नहीं छिपता
- सिमैंटिक हेडिंग, लैंडमार्क, बटन और लिंक;
langसेट है - सार्थक alt टेक्स्ट; सजावटी इमेज पर
alt=""; वीडियो पर कैप्शन - टेक्स्ट कंट्रास्ट ≥ 4.5:1 (बड़ा टेक्स्ट ≥ 3:1); UI के हिस्से ≥ 3:1
- 200% ज़ूम और 320 px चौड़ाई पर काम करता है
- हर फ़ॉर्म फ़ील्ड का दिखने वाला लेबल और साफ़ त्रुटि संदेश है
- सुलभता स्टेटमेंट, जिसमें समस्या रिपोर्ट करने का तरीका हो
इसके पीछे की अवधारणाओं के लिए वेब एक्सेसिबिलिटी क्या है पढ़ें। सुलभ डिज़ाइन और अच्छा डिज़ाइन काफ़ी हद तक एक-दूसरे में मिलते हैं; विज़ुअल पहलू के लिए AI से अच्छा दिखने वाला ऐप कैसे डिज़ाइन करें देखें।
Mythex पर सुलभता
Mythex वही मानक लेकर बनाता है जो आप मांगते हैं, इसलिए अपने पहले प्रॉम्प्ट में और आगे के संदेशों में “WCAG 2.2 AA” लिखें। आप प्रीव्यू के फ़ोन-आकार वाले फ़्रेम से छोटी स्क्रीन जांच सकते हैं (Preview और Code), लेकिन कीबोर्ड, ज़ूम और स्क्रीन रीडर टेस्ट प्रकाशित URL या अपने टैब में खुले प्रीव्यू पर सबसे अच्छे चलते हैं। एजेंट से किसी पेज का ऑडिट करवाएं, जो मिले उसे ठीक करवाएं, फिर ठीकियों को खुद टेस्ट करें — ऑटोमेटिक जांच एक शुरुआत है, अंतिम मंज़ूरी नहीं।
सवाल
वेबसाइट के लिए अभी का सुलभता मानक कौन सा है?
सितंबर 2026 तक, W3C का मौजूदा मानक WCAG 2.2 है, जो पहली बार अक्टूबर 2023 में प्रकाशित हुआ था। ज़्यादातर संगठन और कई कानून लेवल AA को लक्ष्य बनाते हैं। WCAG 3 अभी शुरुआती ड्राफ़्ट में है।
क्या कोई एक्सेसिबिलिटी ओवरले मेरी साइट को अनुपालन में ला सकता है?
किसी एक पर भरोसा न करें। ओवरले पेज के ऊपर एक टूलबार जोड़ते हैं, लेकिन अंदर के कोड में गायब लेबल, टूटी कीबोर्ड पहुंच या कमज़ोर ढांचे को ठीक नहीं कर सकते। साइट को खुद ठीक करना ही उसे उपयोगी बनाता है।
क्या ऑटोमेटिक चेकर हर समस्या पकड़ लेते हैं?
नहीं। Lighthouse और axe जैसे टूल alt टेक्स्ट की कमी, कम कंट्रास्ट और बिना लेबल वाले फ़ील्ड पकड़ते हैं, लेकिन कई समस्याएं, जैसे उलझा हुआ फ़ोकस क्रम, बेमतलब लिंक टेक्स्ट, या मौजूद पर गलत alt टेक्स्ट, को किसी व्यक्ति को कीबोर्ड और स्क्रीन रीडर से जांचना पड़ता है।
WCAG किस कंट्रास्ट अनुपात की मांग करता है?
WCAG 2.2 लेवल AA सामान्य टेक्स्ट के लिए कम से कम 4.5:1 और बड़े टेक्स्ट के लिए 3:1 मांगता है, और इनपुट बॉर्डर व अर्थपूर्ण आइकन जैसे यूज़र इंटरफ़ेस के हिस्सों के लिए 3:1।