एक्सेसिबिलिटी टेस्टिंग क्या है?
एक्सेसिबिलिटी टेस्टिंग यह जाँचती है कि दिव्यांग लोग किसी प्रोडक्ट को समझ, नेविगेट और ऑपरेट कर पाते हैं या नहीं — कीबोर्ड, स्क्रीन रीडर, मैग्निफ़िकेशन, कैप्शन या वॉइस कंट्रोल से। इसमें ऑटोमेटेड rule checks, मैनुअल कीबोर्ड और स्क्रीन रीडर पास, और WCAG 2.2 success criteria के विरुद्ध संरचित मूल्यांकन शामिल हैं, क्योंकि सिर्फ़ टूल यह तय नहीं कर सकते कि प्रोडक्ट accessible है या नहीं।
गाइड पढ़ें: एक्सेसिबिलिटी टेस्टिंग
HTML एक्सेसिबिलिटी चेकर कैसे इस्तेमाल करें
- पेज का HTML कॉपी करें: server-rendered पेज के लिए View source, या JavaScript से बने पेज के लिए DevTools → Elements → <html> पर right-click → Copy outerHTML। किसी component का markup भी चलेगा।
- उसे पेस्ट करें (या सेव की गई .html फ़ाइल चुनें) और contrast का लक्ष्य, AA या AAA, चुनें।
- एक्सेसिबिलिटी जाँचें दबाएँ। "मिली समस्याएँ" की FAIL पंक्तियों से शुरू करें; हर एक बताती है कि उसे कैसे ठीक करें।
- "अब भी हाथ से जाँचना है" सूची को keyboard और screen reader के साथ पूरा करें — ये बाधाएँ markup में नहीं दिखतीं।
- ठीक करने के बाद फिर से चलाएँ, और Markdown या JSON रिपोर्ट को टेस्ट के सबूत के साथ रखें।
HTML एक्सेसिबिलिटी चेकर की खूबियाँ
- WCAG 2.2 और W3C ACT rules से 30 ऑटोमेटेड rules, हर एक अपने success criterion से जुड़ा या best practice के रूप में चिह्नित
- Accessible names markup से उसी तरह निकाले जाते हैं जैसे assistive technology निकालती है: aria-labelledby, aria-label, <label>, alt, legend, content, फिर title और placeholder
- Text alternatives, form labels, button और link नाम, अस्पष्ट link text ("click here", "read more" — अरबी और हिंदी में भी), headings, IDs और references, ARIA roles और focusable content पर aria-hidden
- पूरे documents के लिए page-level जाँच: language, अरबी और दूसरी right-to-left भाषाओं के लिए dir="rtl", title, main landmark, h1, zoom और timed refresh
- Inline रंगों वाले text का contrast ratio, AA (4.5:1 / 3:1) या AAA (7:1 / 4.5:1) के विरुद्ध, बड़े text के नियमों के साथ
- हर rule का नतीजा (PASS, FAIL, WARN, N/A), हर समस्या उसके element, विवरण और fix के साथ, वे जाँचें जिनके लिए इंसान चाहिए, और Markdown व JSON रिपोर्ट
HTML एक्सेसिबिलिटी चेकर का उदाहरण
आम ग़लतियों वाला एक अरबी landing पेज
इनपुट:
उदाहरण पेज: dir के बिना <html lang="ar">, viewport में maximum-scale=1, home link के अंदर बिना alt का logo image, सिर्फ़ icon वाला menu button, सिर्फ़ placeholder से label किया email field, id="phone" की ओर इशारा करता label for="phone-number", बिना fieldset के दो radio buttons, क्लिक होने वाला <div>, बिना title का iframe और सफ़ेद पर स्लेटी text #9aa0a6आउटपुट:
10 failures, 6 warnings। FAIL: zoom सीमित (1.4.4) · बिना alt की image (1.1.1) · बिना नाम का link (2.4.4) · बिना नाम का button (4.1.2) · बिना label के 3 fields (1.3.1, 4.1.2) · label for="phone-number" — इस id का कोई element नहीं · बिना title का iframe · contrast 2.64:1, चाहिए 4.5:1 (1.4.3)। WARN: dir="rtl" के बिना lang="ar" · सिर्फ़ placeholder वाला label (3.3.2) · "Read more" link text (2.4.4) · h1 के बाद h3 · radio group समूह में नहीं · keyboard से न चलने वाला clickable div (2.1.1)HTML एक्सेसिबिलिटी चेकर कब इस्तेमाल करें
- Code review से पहले किसी component या template को बिना browser extension इंस्टॉल किए जाँचना
- Accessibility bug report की triage: दिए गए HTML में ग़ायब label या टूटे aria-labelledby reference की पुष्टि
- यह सिखाना कि आम WCAG failures markup में कैसी दिखती हैं, हर एक के साथ criterion और fix
- अरबी पेजों में language और direction attributes जाँचना, जिन पर screen reader और layout निर्भर हैं
HTML एक्सेसिबिलिटी चेकर के बारे में अक्सर पूछे जाने वाले सवाल
क्या ये जाँचें पास होने का मतलब है कि मेरा पेज WCAG के अनुरूप है?
नहीं। ऑटोमेटेड rules सिर्फ़ कुछ बाधाएँ खोजते हैं — ग़ायब label, ख़ाली button, अमान्य role। Alt text सार्थक है या नहीं, सब कुछ keyboard और screen reader से चलता है या नहीं, और stylesheets से तय contrast — इनके लिए इंसान चाहिए। रिपोर्ट नतीजों के बाद ये manual जाँचें सूचीबद्ध करती है।
चेकर कौन-से rules चलाता है?
30 rules: text alternatives, form labels और सिर्फ़ placeholder वाले labels, button और link नाम, link का उद्देश्य, page language और अरबी के लिए dir="rtl", page title, headings, duplicate IDs और टूटे references, ARIA roles, focusable content पर aria-hidden, positive tabindex, frame titles, table headers, list संरचना, radio groups, zoom, timed refresh, अपने-आप चलने वाला audio, सिर्फ़ mouse वाले click handlers, चमकता text और inline रंगों का contrast। हर एक अपने WCAG 2.2 success criterion से जुड़ा है या best practice के रूप में चिह्नित है।
रंगों का contrast कैसे जाँचा जाता है?
जब किसी element के text और background दोनों के रंग inline style attributes में (उसी element या किसी ancestor पर) तय हों, तो चेकर WCAG contrast ratio निकालता है और उसकी तुलना 4.5:1 (बड़े text के लिए 3:1), या AAA के लिए 7:1 और 4.5:1 से करता है। Stylesheets के रंग सिर्फ़ HTML में नहीं दिखते, इसलिए ऐसे elements को "मापा नहीं गया" गिना जाता है, पास नहीं।
क्या मैं JavaScript से बना पेज जाँच सकता हूँ?
हाँ: पेज खोलें, render होने तक रुकें, फिर ब्राउज़र के developer tools में Elements पैनल के <html> element पर right-click करके Copy → Copy outerHTML चुनें और उसे पेस्ट करें। View source सिर्फ़ scripts चलने से पहले का HTML दिखाता है।
क्या मेरा HTML कहीं भेजा जाता है?
नहीं। इसे आपके ब्राउज़र का अपना HTML parser एक inert document में पढ़ता है — उसमें scripts नहीं चलतीं और images लोड नहीं होतीं — और कुछ भी अपलोड नहीं होता।
तकनीकी नोट्स
HTML को ब्राउज़र का अपना HTML parser (DOMParser) एक inert document में पढ़ता है: बिना quotes के attributes, implied end tags और असली दुनिया का बाक़ी markup ठीक वैसे ही पढ़ा जाता है जैसे ब्राउज़र पढ़ता है, scripts कभी नहीं चलतीं और images कभी लोड नहीं होतीं। hidden, aria-hidden="true", या inline styles में display:none या visibility:hidden से छिपे elements दिखने वाले content के rules से बाहर रहते हैं।
Accessible names W3C Accessible Name computation के क्रम का सरल रूप अपनाते हैं: aria-labelledby, aria-label, native label (<label for>, लपेटने वाला <label>, alt, legend, value), buttons, links और headings के लिए element का content, फिर title और fields के लिए placeholder — जिसकी सूचना दी जाती है, क्योंकि visitor के टाइप करते ही वह ग़ायब हो जाता है।
Contrast के लिए WCAG relative-luminance formula इस्तेमाल होता है। यह सिर्फ़ तब निकाला जाता है जब text का रंग और background दोनों element या किसी ancestor की inline styles में तय हों और background एक ठोस रंग हो; text 24 px पर बड़ा माना जाता है, या bold होने पर 18.66 px पर। बाक़ी सब "मापा नहीं गया" गिना जाता है, पास कभी नहीं।
सीमाएँ और कार्यप्रणाली
ऑटोमेटेड rules यह तय नहीं कर सकते कि पेज accessible है या WCAG के अनुरूप। वे alt text के अर्थ को नहीं परख सकते, keyboard व्यवहार और focus नहीं जाँच सकते, और यह नहीं सुन सकते कि screen reader क्या बोलता है।
Stylesheets, computed layout और scripts सिर्फ़ HTML से उपलब्ध नहीं हैं, इसलिए CSS से तय contrast, focus visibility, 320 px पर reflow, target sizes और dynamic बदलाव manual जाँचों में रखे गए हैं।
Accessible-name computation specification का भरोसेमंद सरल रूप है, उसके हर edge case का नहीं (उदाहरण के लिए, CSS से बना content और नामों के अंदर embedded controls नहीं गिने जाते)।
सुरक्षा और गोपनीयता
HTML आपके ब्राउज़र में parse और जाँचा जाता है; कुछ भी अपलोड नहीं होता। इससे बना document inert है: उसकी कोई script नहीं चलती और वह जिन resources का ज़िक्र करता है उनमें से कोई request नहीं होता।
संदर्भ
- Web Content Accessibility Guidelines (WCAG) 2.2W3C की Recommendation जो सुलभ वेब कंटेंट के लिए टेस्ट करने योग्य success criteria तय करती है — चार सिद्धांतों और तीन conformance स्तरों (A, AA, AAA) में व्यवस्थित।
- Evaluating Web Accessibility Overviewएक्सेसिबिलिटी मूल्यांकन के लिए W3C का प्रवेश-पृष्ठ: शुरू से और पूरे विकास में मूल्यांकन क्यों, और मैनुअल जाँच, टूल व यूज़र भागीदारी कैसे साथ काम करते हैं।
- WCAG Evaluation Methodology (WCAG-EM) 2.0पूरी वेबसाइट को WCAG के सामने जाँचने की W3C पद्धति: दायरा तय करना, खोजबीन, प्रतिनिधि सैंपल चुनना, ऑडिट और रिपोर्ट।