# SaaS प्रोडक्ट और वेब ऐप के लिए WCAG 2.2 AA चेकलिस्ट

<https://www.fixreports.com/hi/blog/wcag-2-2-checklist-saas-web-apps>

अपडेट: 2026-10-26

किसी SaaS प्रोडक्ट में एक्सेसिबिलिटी के दो हिस्से होते हैं: मार्केटिंग साइट जो उसे बेचती है, और वह ऐप्लिकेशन जिसे लोग हर दिन इस्तेमाल करते हैं। मार्केटिंग साइट उन्हीं तरीक़ों से फ़ेल होती है जैसे कोई भी वेबसाइट: कम कंट्रास्ट, गायब alt टेक्स्ट और बिना लेबल के फ़ॉर्म। ऐप्लिकेशन अपनी समस्याएँ जोड़ता है: ऐसे लॉगिन फ़्लो जो पासवर्ड मैनेजर को रोकते हैं, ऐसे डायलॉग जो कीबोर्ड फ़ोकस को फँसा लेते हैं, ऐसा सिंगल-पेज नेविगेशन जिस पर स्क्रीन रीडर का ध्यान नहीं जाता, बिना टेक्स्ट वाली डेटा टेबल और चार्ट, बिना विकल्प वाला ड्रैग-एंड-ड्रॉप, और बिना चेतावनी के ख़त्म होने वाले सेशन। यह चेकलिस्ट एक आम SaaS प्रोडक्ट के हिस्सों के हिसाब से WCAG 2.2 Level AA को कवर करती है।

**मुख्य बातें**

- WCAG 2.2 अक्टूबर 2023 में W3C Recommendation बना और उसने नौ सफलता मानदंड जोड़े, जिनमें से छह Level A या AA के हैं ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/))।
- Accessible Authentication (3.3.8, AA) का मतलब है कि लॉगिन पासवर्ड याद रखने या उसे देखकर दोबारा टाइप करने पर निर्भर नहीं हो सकता, जब तक लोग उसे पेस्ट न कर सकें या पासवर्ड मैनेजर इस्तेमाल न कर सकें ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum))।
- इंटरैक्टिव टारगेट कम से कम 24 × 24 CSS पिक्सेल के होने चाहिए, या उनके चारों ओर पर्याप्त जगह होनी चाहिए (2.5.8, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum))।
- “सेव हो गया” या “3 नतीजे” जैसे मैसेज फ़ोकस हिलाए बिना स्क्रीन रीडर तक पहुँचने चाहिए (4.1.3, AA) ([W3C](https://www.w3.org/WAI/WCAG22/Understanding/status-messages))।
- बिज़नेस और सरकारी ख़रीदार अक्सर Accessibility Conformance Report माँगते हैं, जो आमतौर पर Information Technology Industry Council के VPAT टेम्पलेट पर लिखी जाती है ([ITI](https://www.itic.org/policy/accessibility/vpat))।

## ब्रोशर साइट के मुकाबले SaaS के लिए एक्सेसिबिलिटी ज़्यादा अहम क्यों है?

लोग SaaS प्रोडक्ट को घंटों इस्तेमाल करते हैं, अक्सर इसलिए कि उनकी कंपनी ने उसे चुना है। मार्केटिंग पेज पर कोई बाधा एक विज़िटर को खोती है; प्रोडक्ट में कोई बाधा किसी को अपना काम करने से रोक सकती है। इसीलिए बड़े ग्राहक, यूनिवर्सिटी और सरकारी संस्थाएँ ख़रीदने से पहले एक्सेसिबिलिटी के बारे में ज़्यादा से ज़्यादा पूछने लगे हैं, और इसीलिए जवाब में सिर्फ़ वेबसाइट नहीं, ऐप्लिकेशन भी शामिल होना चाहिए।

यह इसलिए भी अहम है कि ऑटोमेटेड टेस्ट समस्या का सिर्फ़ एक हिस्सा पकड़ते हैं। axe-core जैसे टूल मार्कअप की कमियाँ ढूँढते हैं, जैसे गायब लेबल और कम कंट्रास्ट। वे यह नहीं बता सकते कि कोई डायलॉग फ़ोकस को सही जगह लौटाता है या नहीं, किसी चार्ट का डेटा टेक्स्ट के रूप में उपलब्ध है या नहीं, या कोई वर्कफ़्लो कीबोर्ड से पूरा किया जा सकता है या नहीं। किसी ऐप्लिकेशन को ऑटोमेटेड जाँच और मैन्युअल टेस्टिंग, दोनों की ज़रूरत होती है।

## साइन-अप और लॉगिन को एक्सेसिबल कैसे बनाएँ?

ऑथेंटिकेशन वह जगह है जहाँ WCAG 2.2 ने SaaS के लिए सबसे अहम नई शर्त जोड़ी।

- **पेस्ट और पासवर्ड मैनेजर की अनुमति दें (3.3.8, AA)।** पासवर्ड या कोड फ़ील्ड में पेस्ट करना ब्लॉक न करें, और `autocomplete="username"`, `autocomplete="current-password"` और `autocomplete="one-time-code"` इस्तेमाल करें, ताकि ब्राउज़र और पासवर्ड मैनेजर इन्हें भर सकें।
- **पहेलियों को अंदर आने का इकलौता रास्ता न बनाएँ।** जो CAPTCHA लोगों से बिगड़ा हुआ टेक्स्ट देखकर लिखने या कोई पहेली सुलझाने को कहता है, वह एक संज्ञानात्मक (cognitive) टेस्ट है। कोई विकल्प दें, और ऐसी जाँचों को प्राथमिकता दें जिनमें यूज़र को कुछ करना न पड़े ([W3C](https://www.w3.org/TR/turingtest/))।
- **हर फ़ील्ड को लेबल दें (1.3.1 और 3.3.2, A)।** अपने इनपुट से जुड़ा एक दिखने वाला `<label>` इस्तेमाल करें; प्लेसहोल्डर टेक्स्ट टाइप करते ही ग़ायब हो जाता है और वह लेबल नहीं है।
- **एरर को टेक्स्ट में बताएँ (3.3.1, A) और सुधार सुझाएँ (3.3.3, AA)।** “पासवर्ड में कम से कम 12 कैरेक्टर होने चाहिए” मदद करता है; सिर्फ़ लाल बॉर्डर नहीं।
- **दो बार न पूछें (3.3.7, A)।** अगर कई स्टेप वाले साइन-अप में कंपनी का नाम या पता पहले ही पूछा जा चुका है, तो उसे अपने आप भरें या लोगों को उसे चुनने दें, दोबारा टाइप न कराएँ।
- **मदद को एक ही जगह रखें (3.2.6, A)।** अगर आप चैट, हेल्प लिंक या संपर्क जानकारी देते हैं, तो उन्हें फ़्लो के हर पेज पर एक ही सापेक्ष जगह पर रखें।

## कौन-से फ़ॉर्म और एरर पैटर्न सबसे ज़्यादा फ़ेल्योर पैदा करते हैं?

ऐप्लिकेशन की ज़्यादातर कमियाँ फ़ॉर्म में होती हैं। WebAIM के 2026 के सर्वे में 10 लाख होम पेजों में से 51% पर फ़ॉर्म लेबल गायब मिले ([WebAIM](https://webaim.org/projects/million/)), और ऐप्लिकेशन में होम पेजों से कहीं ज़्यादा फ़ॉर्म होते हैं।

- हर इनपुट को प्रोग्राम के ज़रिए पढ़ा जा सकने वाला नाम दें, और रेडियो बटन जैसे आपस में जुड़े कंट्रोल को `<fieldset>` और `<legend>` से ग्रुप करें।
- लोगों को एरर वहाँ बताएँ जहाँ उनका ध्यान जाए: फ़ोकस को फ़ॉर्म के ऊपर एरर सारांश पर, या पहले ग़लत फ़ील्ड पर ले जाएँ, और सारांश के हर आइटम को उसके फ़ील्ड से लिंक करें।
- ज़रूरी फ़ील्ड को टेक्स्ट में चिह्नित करें, सिर्फ़ रंग से नहीं (1.4.1, A)।
- जब कोई सिर्फ़ कोई विकल्प चुनता है, तो फ़ॉर्म सबमिट न करें या संदर्भ न बदलें (3.2.2, A); किसी साफ़ एक्शन का इंतज़ार करें।

## डायलॉग, मेन्यू और पॉपओवर को कैसे व्यवहार करना चाहिए?

कस्टम कंपोनेंट वह जगह है जहाँ कीबोर्ड और स्क्रीन रीडर सपोर्ट सबसे ज़्यादा टूटता है। WAI-ARIA Authoring Practices Guide हर पैटर्न के लिए अपेक्षित व्यवहार बताती है ([W3C](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/))।

- **डायलॉग**: खुलने पर फ़ोकस को डायलॉग के अंदर ले जाएँ, खुले रहने तक Tab को उसके अंदर रखें, Escape से उसे बंद करें, और फ़ोकस को उस कंट्रोल पर लौटाएँ जिसने उसे खोला था। नेटिव `<dialog>` एलिमेंट, या `aria-modal="true"` और एक नाम के साथ `role="dialog"` इस्तेमाल करें।
- **कोई कीबोर्ड ट्रैप नहीं (2.1.2, A)**: हर कंपोनेंट से कीबोर्ड के ज़रिए बाहर निकला जा सके।
- **दिखने वाला फ़ोकस (2.4.7, AA)**, जो स्टिकी हेडर, कुकी बैनर या चैट विजेट के पीछे न छिपे (2.4.11, AA, 2.2 में नया)।
- **टूलटिप और पॉपओवर (1.4.13, AA)**, जिन्हें लोग Escape से हटा सकें, जिन पर hover करने से वे ग़ायब न हों, और जो हटाए जाने तक बने रहें।
- **सिंगल-की शॉर्टकट (2.1.4, A)**: अगर किसी अक्षर की की दबाने से कोई एक्शन होता है, तो लोगों को शॉर्टकट बंद करने या दूसरी की पर सेट करने दें, या उन्हें तभी सक्रिय करें जब संबंधित कंपोनेंट पर फ़ोकस हो।

## सिंगल-पेज ऐप में नेविगेशन को कैसे संभालें?

सिंगल-पेज ऐप में पेज लोड हुए बिना URL बदल जाता है, इसलिए हो सकता है स्क्रीन रीडर यह न बताए कि कुछ हुआ है।

- हर रूट बदलने पर डॉक्यूमेंट टाइटल अपडेट करें, ताकि हर व्यू का एक वर्णनात्मक टाइटल हो (2.4.2, A)।
- फ़ोकस को नए व्यू की मुख्य हेडिंग पर ले जाएँ, या बदलाव को किसी polite live region में अनाउंस करें; Next.js जैसे फ़्रेमवर्क में इसके लिए route announcer शामिल होता है।
- फ़ोकस का क्रम तार्किक रखें (2.4.3, A): कोई आइटम डिलीट होने के बाद फ़ोकस किसी समझदारी भरे पड़ोसी एलिमेंट पर जाना चाहिए, पेज के सबसे ऊपर नहीं।
- बार-बार आने वाले नेविगेशन को छोड़ने का कोई तरीक़ा दें (2.4.1, A), जैसे स्किप लिंक या लैंडमार्क।

## डैशबोर्ड, डेटा टेबल और चार्ट को एक्सेसिबल कैसे बनाएँ?

- **टेबल**: हेडर के लिए `<th>` और `scope` के साथ असली `<table>` मार्कअप, और एक कैप्शन इस्तेमाल करें (1.3.1, A)। `<div>` एलिमेंट से बने ग्रिड को पूरे ARIA grid पैटर्न की ज़रूरत होती है, जिसे सही बनाना कहीं ज़्यादा मुश्किल है।
- **चार्ट**: हर चार्ट को ऐसा टेक्स्ट विकल्प दें जो मुख्य बात बताए, और डेटा को टेबल के रूप में भी दें (1.1.1, A)। सीरीज़ में फ़र्क़ बताने के लिए सिर्फ़ रंग पर निर्भर न रहें (1.4.1, A); लेबल या पैटर्न जोड़ें।
- **कंट्रास्ट**: टेक्स्ट को 4.5:1 चाहिए (1.4.3, AA), और चार्ट की लाइनों, आइकन और इनपुट बॉर्डर को अपने बैकग्राउंड के मुकाबले 3:1 (1.4.11, AA)। डार्क मोड को अलग से जाँचें। हमारा [कलर कंट्रास्ट चेकर](/hi/color-contrast-checker) किसी भी रंग-जोड़े को टेस्ट करता है।
- **स्टेटस मैसेज (4.1.3, AA)**: “सेव हो गया”, “अपलोड पूरा हुआ” और नतीजों की गिनती के लिए `role="status"` या कोई live region इस्तेमाल करें, ताकि स्क्रीन रीडर इस्तेमाल करने वाले अपनी जगह खोए बिना उन्हें सुन सकें।

## WCAG 2.2 के नए मानदंड वेब ऐप के लिए क्या बदलते हैं?

| मानदंड | लेवल | ऐप में इसका मतलब |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | स्टिकी टूलबार, बैनर और चैट विजेट फ़ोकस किए गए एलिमेंट को पूरी तरह न ढकें |
| 2.5.7 Dragging Movements | AA | ड्रैग करके किए जाने वाले हर काम, जैसे kanban बोर्ड का क्रम बदलना, के लिए एक सिंगल-पॉइंटर विकल्प चाहिए, जैसे मेन्यू या ऊपर-नीचे के बटन |
| 2.5.8 Target Size (Minimum) | AA | बटन और लिंक कम से कम 24 × 24 CSS पिक्सेल के हों, या इतनी दूरी पर हों कि हर एक के चारों ओर 24 पिक्सेल का घेरा किसी दूसरे पर न चढ़े |
| 3.2.6 Consistent Help | A | हेल्प लिंक, चैट और संपर्क जानकारी हर पेज पर एक ही सापेक्ष जगह पर हों |
| 3.3.7 Redundant Entry | A | उसी प्रक्रिया में पहले से डाली गई जानकारी अपने आप भरी हो या चुनी जा सके |
| 3.3.8 Accessible Authentication (Minimum) | AA | याद रखे या देखकर दोबारा टाइप किए बिना लॉगिन, जब तक पेस्ट, पासवर्ड मैनेजर या कोई दूसरा तरीक़ा उपलब्ध न हो |

WCAG 2.2 ने 4.1.1 Parsing को भी हटा दिया, जिसका अब एक्सेसिबिलिटी पर कोई व्यावहारिक असर नहीं है ([W3C](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/))।

## टाइमआउट, लेआउट और ज़ूम का क्या?

- **सेशन टाइमआउट (2.2.1, A)**: सेशन ख़त्म होने से पहले लोगों को चेतावनी दें और उन्हें किसी आसान एक्शन से समय बढ़ाने दें, जब तक समय सीमा अनिवार्य न हो या 20 घंटे से ज़्यादा न हो। चल रहे काम को सेव करते रहने से सबसे बुरा नतीजा टल जाता है।
- **Reflow (1.4.10, AA)**: कंटेंट 320 CSS पिक्सेल की चौड़ाई पर (1280 पिक्सेल की स्क्रीन पर 400% ज़ूम के बराबर) दो दिशाओं में स्क्रॉल किए बिना काम करना चाहिए; डेटा टेबल और ऐसे ही कंटेंट को छूट है।
- **टेक्स्ट स्पेसिंग (1.4.12, AA)**: लाइन की ऊँचाई और अक्षरों के बीच की दूरी बढ़ाने पर टेक्स्ट कटना नहीं चाहिए, जो फ़िक्स्ड ऊँचाई वाले कंटेनर में अक्सर होता है।
- **ओरिएंटेशन (1.3.4, AA)**: ऐप को पोर्ट्रेट या लैंडस्केप पर लॉक न करें, जब तक यह अनिवार्य न हो।

## ACR क्या है, और क्या आपको इसकी ज़रूरत है?

Accessibility Conformance Report (ACR) दर्ज करती है कि कोई प्रोडक्ट हर एक्सेसिबिलिटी मानदंड को कैसे पूरा करता है: supports, partially supports या does not support, टिप्पणियों के साथ। ज़्यादातर ACR, Information Technology Industry Council के प्रकाशित VPAT टेम्पलेट पर लिखी जाती हैं, जिसके WCAG, अमेरिकी Section 508 मानकों और यूरोपीय मानक EN 301 549 के लिए अलग-अलग संस्करण हैं ([ITI](https://www.itic.org/policy/accessibility/vpat))।

अमेरिका की संघीय एजेंसियों को Section 508 के तहत एक्सेसिबल टेक्नोलॉजी ख़रीदनी होती है ([Section508.gov](https://www.section508.gov/)), और EU की सरकारी संस्थाएँ EN 301 549 का हवाला देती हैं, इसलिए इन ग्राहकों को बेचने वाले B2B प्रोडक्ट से ख़रीद प्रक्रिया के दौरान अक्सर ACR माँगी जाती है। ऐसी ईमानदार ACR, जिसमें ज्ञात कमियाँ लिखी हों, ख़रीदारों के लिए पूरे सपोर्ट का दावा करने वाली ACR से ज़्यादा काम की होती है। यह प्रोडक्ट की टेस्टिंग पर आधारित होनी चाहिए, जिसमें मैन्युअल टेस्टिंग भी शामिल हो; सिर्फ़ ऑटोमेटेड स्कैन से इसे नहीं भरा जा सकता।

अगर आप EU में उपभोक्ताओं को बेचते हैं, तो आपके ऑनलाइन बेचने के तरीक़े पर European Accessibility Act भी लागू हो सकता है; हमारी [EAA गाइड](/hi/blog/european-accessibility-act-online-stores) इसका दायरा समझाती है। यह क़ानूनी सलाह नहीं है।

## SaaS टीम को एक्सेसिबिलिटी कैसे टेस्ट करनी चाहिए?

1. **बुनियादी जाँचें ऑटोमेट करें।** अपने end-to-end टेस्ट में और मार्केटिंग साइट पर axe-core या कोई मिलता-जुलता इंजन चलाएँ, और नए उल्लंघन मिलने पर बिल्ड फ़ेल करें। हमारा [मुफ़्त एक्सेसिबिलिटी चेकर](/hi/website-accessibility-checker) किसी भी सार्वजनिक पेज पर यही इंजन चलाता है।
2. **कीबोर्ड से टेस्ट करें।** अपने मुख्य वर्कफ़्लो, जैसे साइन-अप, कोई रिकॉर्ड बनाना और सेटिंग बदलना, सिर्फ़ Tab, Shift+Tab, Enter, Space, Escape और ऐरो की से पूरे करें।
3. **स्क्रीन रीडर से टेस्ट करें।** Windows पर NVDA और macOS व iOS पर VoiceOver मुफ़्त हैं। जाँचें कि नाम, रोल, स्टेट और मैसेज अनाउंस होते हैं।
4. **ज़ूम करें और साइज़ बदलें।** 200% टेक्स्ट ज़ूम और 320 पिक्सेल चौड़ी विंडो जाँचें।
5. **डिज़ाइन सिस्टम में ठीक करें।** ज़्यादातर कमियाँ साझा कंपोनेंट से आती हैं; किसी बटन या डायलॉग को एक बार ठीक करने से वह हर जगह ठीक हो जाता है।

## अक्सर पूछे जाने वाले प्रश्न

### क्या WCAG वेब ऐप के लॉगिन के बाद वाले हिस्सों पर लागू होता है?

WCAG किसी भी वेब कंटेंट पर लागू होता है, जिसमें लॉगिन के पीछे के पेज भी शामिल हैं। किसी ख़ास प्रोडक्ट को इसे पूरा करना क़ानूनन ज़रूरी है या नहीं, यह अधिकार-क्षेत्र और ग्राहक पर निर्भर करता है, लेकिन जो ख़रीदार एक्सेसिबिलिटी के बारे में पूछते हैं, उनका मतलब आमतौर पर पूरा प्रोडक्ट होता है।

### क्या कोई ओवरले किसी SaaS प्रोडक्ट को एक्सेसिबल बना सकता है?

नहीं। ओवरले कस्टम कंपोनेंट के मूल कोड को नहीं बदलते, और ऐप्लिकेशन की कमियाँ वहीं होती हैं। [एक्सेसिबिलिटी ओवरले](/hi/blog/accessibility-overlays-ftc-order) पर हमारी गाइड एक प्रमुख ओवरले विक्रेता के ख़िलाफ़ FTC की कार्रवाई के बारे में बताती है।

### ऑटोमेटेड टूल WCAG का कितना हिस्सा जाँच सकते हैं?

सिर्फ़ एक हिस्सा। ऑटोमेटेड नियम गायब नाम, लेबल और कंट्रास्ट की कमियाँ भरोसेमंद तरीक़े से ढूँढते हैं, लेकिन कई मानदंडों, जैसे अर्थपूर्ण फ़ोकस क्रम, काम का alt टेक्स्ट और समझ में आने वाले एरर मैसेज, का आकलन किसी व्यक्ति को करना होता है।

### हमें WCAG के किस वर्ज़न को लक्ष्य बनाना चाहिए?

WCAG 2.2 Level AA मौजूदा वर्ज़न है। कई क़ानून और ख़रीद नियम अब भी WCAG 2.1 AA का हवाला देते हैं; 2.2 AA पूरा करने से 2.1 AA भी पूरा हो जाता है, सिवाय हटाए गए Parsing मानदंड के।

### क्या हमें Level AAA पूरा करना होगा?

W3C पूरे प्रोडक्ट के लिए AAA की शर्त रखने की सलाह नहीं देता, क्योंकि कुछ कंटेंट हर AAA मानदंड पूरा नहीं कर सकता। आम लक्ष्य Level AA होता है।

## स्रोत

- W3C: [What's new in WCAG 2.2](https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/)
- W3C: [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/)
- W3C: [Understanding 3.3.8 Accessible Authentication (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum)
- W3C: [Understanding 2.5.8 Target Size (Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum)
- W3C: [Understanding 4.1.3 Status Messages](https://www.w3.org/WAI/WCAG22/Understanding/status-messages)
- W3C: [ARIA Authoring Practices Guide: Dialog (modal) pattern](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)
- W3C: [Inaccessibility of CAPTCHA](https://www.w3.org/TR/turingtest/)
- ITI: [Voluntary Product Accessibility Template (VPAT)](https://www.itic.org/policy/accessibility/vpat)
- GSA: [Section508.gov](https://www.section508.gov/)
- WebAIM: [The WebAIM Million (2026)](https://webaim.org/projects/million/)