तुमची वेबसाइट प्रवेशयोग्य (accessible) कशी बनवायची: WCAG 2.2 नवशिक्या मार्गदर्शक
वेबसाइट प्रवेशयोग्य बनवण्यासाठी ती अशी बांधा की लोक माऊससोबतच कीबोर्ड, स्क्रीन रीडर, झूम किंवा स्विच डिव्हाइसने देखील तिचा वापर करू शकतील: बटणे, लिंक्स, हेडिंग्ज आणि फॉर्म लेबल्ससाठी खरे HTML घटक वापरा, इमेजेसना अर्थपूर्ण alt text द्या, मजकुराचा कॉन्ट्रास्ट उच्च ठेवा आणि फोकस दिसेल याची खात्री करा. ध्येय WCAG 2.2 Level 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 चा संदर्भ देतात — उदाहरणार्थ युरोपियन Accessibility Act, जो जून 2025 पासून EU मधील अनेक ग्राहकाभिमुख डिजिटल सेवांना लागू आहे. तुम्हाला कोणते नियम लागू होतात हे तुम्ही कुठे काम करता आणि काय विकता यावर अवलंबून आहे; शंका असल्यास सल्लागाराशी बोला. हे मार्गदर्शक व्यावहारिक कामावर लक्ष केंद्रित करते.
पर्याय: तिथे कसे पोहोचायचे
| दृष्टिकोन | कशासाठी चांगला | तडजोड |
|---|---|---|
| सुरुवातीपासूनच अंगभूत बांधा | नवीन साइट्स आणि ॲप्स | एकूण सर्वात कमी प्रयत्न; सुरुवातीलाच सांगावे लागते |
| तपासा आणि दुरुस्त करा | विद्यमान साइट्स | खऱ्या समस्या सापडतात; प्रति पान केंद्रित पास लागतो |
| व्यावसायिक ऑडिट | नियमित क्षेत्रे, मोठ्या साइट्स, सार्वजनिक संस्था | सखोल आणि दस्तऐवजीकृत; खर्च येतो |
| Overlay विजेट | शिफारस केलेले नाही | मूळ कोड दुरुस्त करू शकत नाही |
बहुतेक छोट्या साइट्ससाठी पहिले दोन पुरेसे आहेत: AI ला सुरुवातीपासून प्रवेशयोग्य बनवायला सांगा, नंतर लाँचपूर्वी ऑडिट करा.
सर्वात महत्त्वाच्या दुरुस्त्या
योग्य HTML घटक वापरा
बहुतेक प्रवेशयोग्यता योग्य HTML मुळेच मोफत मिळते. <button> फोकस करता येते, Enter आणि Space ने चालते आणि बटण म्हणून घोषित होते. क्लिक हँडलर असलेला <div> यापैकी काहीच नाही. AI-बनवलेला कोड कधीकधी सर्वकाही स्टाईल केलेल्या divs ने बनवतो; सिमॅंटिक घटक मागा:
- कृतींसाठी
<button>, नेव्हिगेशनसाठी<a href> - प्रति पान एक
<h1>, मग<h2>,<h3>क्रमाने — स्क्रीन रीडर वापरणारे हेडिंग्जमध्ये उड्या मारतात - Landmarks:
<header>,<nav>,<main>,<footer> - प्रत्येक फॉर्म फील्डशी जोडलेला
<label> <html lang="en">मध्ये पानाची भाषा
नैसर्गिक घटक बसत नसेल तेव्हाच ARIA attributes वापरा — उदाहरणार्थ सानुकूल टॅब सेट किंवा combobox. चुकीचा ARIA नसण्यापेक्षाही वाईट आहे.
कीबोर्ड प्रवेश आणि दिसणारा फोकस
माऊसने जे काही करता येते ते फक्त कीबोर्डने करता आले पाहिजे (WCAG 2.1.1). पानावर Tab दाबा: प्रत्येक लिंक, बटण आणि फील्ड तार्किक क्रमाने पोहोचण्याजोगी असावी, आणि फोकस कुठे आहे ते नेहमी दिसले पाहिजे (2.4.7 Focus Visible). WCAG 2.2 ने जोडले की फोकस केलेला घटक स्टिकी हेडर किंवा कुकी बॅनरच्या मागे पूर्णपणे लपलेला नसावा (2.4.11, Level AA).
सामान्य अपयश: फक्त hover केल्यावर उघडणारे मेनू, फोकस न अडकवणारे किंवा Escape ने बंद न होणारे modals, आणि CSS मध्ये outline: none जो बदलाशिवाय ठेवलेला असतो.
मजकूर पर्याय
प्रत्येक अर्थपूर्ण इमेजला तिच्या संदर्भात काय दाखवते ते सांगणारा alt text हवा ("शेफ टेस्टिंग मेन्यू सजवतो आहे", "image1.jpg" नव्हे). सजावटीच्या इमेजेसना रिकामा alt="" द्या म्हणजे स्क्रीन रीडर त्या वगळतात. फक्त आयकॉन असलेल्या बटणांना सुलभ नाव हवे ("बंद करा", "शोधा"). व्हिडिओंना कॅप्शन्स आणि ऑडिओला ट्रान्स्क्रिप्ट हवी.
रंग आणि कॉन्ट्रास्ट
WCAG 2.2 AA ला सामान्य मजकुरासाठी किमान 4.5:1 आणि मोठ्या मजकुरासाठी 3:1 कॉन्ट्रास्ट गुणोत्तर लागते (1.4.3), आणि इनपुट बॉर्डर्स व अर्थपूर्ण आयकॉन्ससारख्या इंटरफेस भागांसाठी 3:1 (1.4.11). फिकट राखाडी placeholder मजकूर आणि फिकट बटणे ही नेहमीची अपयश आहेत. तसेच, अर्थ सांगण्यासाठी फक्त रंग कधीही वापरू नका — अवैध फील्डवरची लाल बॉर्डर सोबत त्रुटी संदेश हवा.
आकार बदलणे आणि reflow
200% झूम केल्यावरही मजकूर वापरण्यायोग्य राहिला पाहिजे (1.4.4), आणि कंटेंट 320 CSS pixels रुंदीवर बाजूला स्क्रोल न करता चालला पाहिजे (1.4.10). प्रतिसादक्षम मांडणी बहुतेक हे हाताळते.
लक्ष्य आकार, फॉर्म आणि त्रुटी
- लक्ष्य आकार: WCAG 2.2 AA पॉइंटर लक्ष्यांसाठी किमान 24 बाय 24 CSS pixels किंवा लहान लक्ष्यांभोवती पुरेसे अंतर मागते (2.5.8). फोनवर मोठे लक्ष्य अधिक सोयीचे असते.
- फॉर्म: दिसणारे लेबल्स (फक्त placeholder नव्हे), स्पष्ट सूचना, आणि त्रुटी संदेश जे काय चुकले आणि ते कसे दुरुस्त करायचे ते सांगतात, फील्डच्या शेजारी.
- लॉगिन: लोकांना कोडे सोडवायला किंवा पर्यायाशिवाय कोड लिहायला लावू नका; पासवर्ड मॅनेजर आणि पेस्ट करण्याची परवानगी द्या (3.3.8 Accessible Authentication).
उपयुक्त प्रॉम्प्ट्स
ही साइट WCAG 2.2 Level AA नुसार बनवा: सिमॅंटिक HTML landmarks, प्रति पान एक h1 आणि क्रमाने हेडिंग्ज, खरे button आणि link घटक, प्रत्येक फॉर्म फील्डवर लेबल्स, दिसणारे फोकस स्टाईल्स, किमान 4.5:1 मजकूर कॉन्ट्रास्ट, अर्थपूर्ण इमेजेसवर alt text आणि सजावटीच्या इमेजेसवर 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" म्हणजे दुरुस्तीचे काम आहे.
- मजकूर, बटणे आणि इनपुट्सचा कॉन्ट्रास्ट कॉन्ट्रास्ट तपासक साधनाने तपासा.
- दुरुस्त करा, मग त्याच कामांची पुन्हा चाचणी करा.
- प्रवेशयोग्यता विधान प्रकाशित करा, ज्यात तुम्ही कोणते मानक ठेवता आणि समस्या कशा नोंदवायच्या ते सांगितलेले असेल — आणि आलेल्या अहवालांना उत्तर द्या.
सामान्य चुका
- Overlay विजेटवर अवलंबून राहणे कोड दुरुस्त करण्याऐवजी.
- फोकस आउटलाइन काढून टाकणे कारण त्या नीटनेटक्या दिसत नाहीत, बदलाशिवाय.
- Placeholder मजकूर हाच एकमेव लेबल असणे. कोणी टाइप करू लागताच तो नाहीसा होतो आणि अनेकदा कमी कॉन्ट्रास्टचा असतो.
- "येथे क्लिक करा" आणि "अधिक वाचा" लिंक्स. संदर्भाशिवाय, स्क्रीन रीडर वापरणारे एकसारख्या लिंक्सची यादी ऐकतात.
- Alt text मध्ये कीवर्ड भरणे. Alt text लोकांसाठी आहे; इमेजचे वर्णन करा.
- एकदाच चाचणी करणे. प्रत्येक नवीन वैशिष्ट्य कीबोर्ड प्रवेश तोडू शकते. तुमच्या लाँचपूर्वीच्या चाचणीत कीबोर्ड पास जोडा.
प्रवेशयोग्यता चेकलिस्ट
- मुख्य पानांवर स्वयंचलित तपासणी (Lighthouse किंवा axe) स्वच्छ
- प्रत्येक काम फक्त कीबोर्डने पूर्ण करता येते
- फोकस नेहमी दिसतो आणि स्टिकी घटकांमागे कधीच लपत नाही
- सिमॅंटिक हेडिंग्ज, landmarks, बटणे आणि लिंक्स;
langसेट - अर्थपूर्ण alt text; सजावटीच्या इमेजेस
alt=""; व्हिडिओवर कॅप्शन्स - मजकूर कॉन्ट्रास्ट ≥ 4.5:1 (मोठा मजकूर ≥ 3:1); UI भाग ≥ 3:1
- 200% झूम आणि 320 px रुंदीवर चालते
- प्रत्येक फॉर्म फील्डला दिसणारे लेबल आणि स्पष्ट त्रुटी संदेश
- प्रवेशयोग्यता विधान, समस्या नोंदवण्याच्या मार्गासह
यामामागच्या संकल्पनांसाठी वेब प्रवेशयोग्यता म्हणजे काय वाचा. प्रवेशयोग्य डिझाइन आणि चांगले डिझाइन यात खूप साम्य आहे; दृश्य बाजूसाठी AI सह चांगले दिसणारे ॲप कसे डिझाइन करायचे पहा.
Mythex वर प्रवेशयोग्यता
Mythex तुम्ही मागितलेल्या मानकानुसार बांधते, त्यामुळे तुमच्या पहिल्या प्रॉम्प्टमध्ये आणि पुढच्या संदेशांत "WCAG 2.2 AA" लिहा. Preview च्या फोन-आकाराच्या फ्रेमने तुम्ही लहान स्क्रीन तपासू शकता (Preview आणि Code), पण कीबोर्ड, झूम आणि स्क्रीन रीडर चाचण्या प्रकाशित URL वर किंवा स्वतःच्या टॅबमध्ये उघडलेल्या preview वर सर्वोत्तम चालतात. एजंटला एखादे पान ऑडिट करायला सांगा, त्याला सापडलेल्या गोष्टी दुरुस्त करायला सांगा, आणि मग दुरुस्त्यांची स्वतः चाचणी करा — स्वयंचलित पास ही सुरुवात आहे, अंतिम मंजुरी नव्हे.
प्रश्न
वेबसाइटसाठी सध्याचे प्रवेशयोग्यता मानक कोणते आहे?
सप्टेंबर 2026 पर्यंत, W3C चे सध्याचे मानक WCAG 2.2 आहे, जे ऑक्टोबर 2023 मध्ये प्रथम प्रकाशित झाले. बहुतेक संस्था आणि अनेक कायदे Level AA चे ध्येय ठेवतात. WCAG 3 अजून सुरुवातीच्या मसुद्यात आहे.
प्रवेशयोग्यता overlay माझी साइट अनुपालनात आणू शकते का?
त्यावर अवलंबून राहू नका. Overlay पानाच्या वर एक टूलबार जोडतो, पण मूळ कोडमधील गहाळ लेबल्स, तुटलेला कीबोर्ड प्रवेश किंवा कमकुवत रचना दुरुस्त करू शकत नाही. साइट स्वतः दुरुस्त करणे हेच ती वापरण्यायोग्य बनवते.
स्वयंचलित तपासणी साधने सर्व समस्या शोधतात का?
नाही. Lighthouse आणि axe सारखी साधने alt text नसणे, कमी कॉन्ट्रास्ट आणि लेबल नसलेली फील्ड्स पकडतात, पण अनेक समस्या — गोंधळात टाकणारा फोकस क्रम, अर्थहीन लिंक मजकूर, उपस्थित पण चुकीचा alt text — यासाठी व्यक्तीने कीबोर्ड आणि स्क्रीन रीडरने तपासणी करणे आवश्यक आहे.
WCAG कोणता कॉन्ट्रास्ट गुणोत्तर मागते?
WCAG 2.2 Level AA किमान सामान्य मजकुरासाठी 4.5:1 आणि मोठ्या मजकुरासाठी 3:1, तसेच इनपुट बॉर्डर्स आणि अर्थ सांगणाऱ्या आयकॉन्ससारख्या वापरकर्ता इंटरफेस घटकांसाठी 3:1 मागते.