सुलभ फ़ॉर्म की टेस्टिंग

फ़ॉर्म पर कौन-से WCAG 2.2 criteria लागू होते हैं

“फ़ॉर्म” नाम का कोई एक success criterion नहीं है। आवश्यकताएँ चारों सिद्धांतों में फैली हैं, इसलिए फ़ॉर्म review असल में criteria के एक तय सेट पर से गुज़रना है। नीचे मुख्य सेट है; स्तर वही हैं जो WCAG 2.2 में प्रकाशित हैं।

• 1.3.1 Info and Relationships (A) — labels, groups और required स्थिति programmatically उपलब्ध हों, केवल दृश्य रूप से नहीं।
• 1.3.5 Identify Input Purpose (AA) — यूज़र के बारे में जानकारी लेने वाले फ़ील्ड अपना उद्देश्य बताएँ (HTML में autocomplete attribute से)।
• 1.4.1 Use of Color (A) — required फ़ील्ड और errors केवल रंग से न दर्शाए जाएँ।
• 2.5.3 Label in Name (A) — control के accessible name में उसका दिखने वाला label टेक्स्ट शामिल हो।
• 3.2.2 On Input (A) — फ़ील्ड बदलने से संदर्भ में अप्रत्याशित बदलाव न हो, जैसे फ़ॉर्म का submit हो जाना।
• 3.3.1 Error Identification (A) — input error पकड़ी जाए तो फ़ील्ड पहचाना जाए और error टेक्स्ट में बताई जाए।
• 3.3.2 Labels or Instructions (A) — जहाँ यूज़र input चाहिए, वहाँ labels या निर्देश दिए जाएँ।
• 3.3.3 Error Suggestion (AA) — सुधार ज्ञात हो तो सुझाया जाए, जब तक इससे सुरक्षा या उद्देश्य ख़तरे में न पड़े।
• 3.3.4 Error Prevention (Legal, Financial, Data) (AA) — कानूनी, वित्तीय या डेटा असर वाले submission reversible, checked या confirmed हों।
• 3.3.7 Redundant Entry (A) — उसी प्रक्रिया में पहले दी गई जानकारी auto-populate हो या चुनने के लिए उपलब्ध हो।
• 3.3.8 Accessible Authentication (Minimum) (AA) — लॉगिन का कोई चरण cognitive function test न माँगे, जब तक अनुमत विकल्प या mechanism न हो।
• 4.1.2 Name, Role, Value (A) और 4.1.3 Status Messages (AA) — कस्टम controls नाम, role और state बताएँ; status और error संदेश focus हटाए बिना assistive technology तक पहुँचें।

Labels, निर्देश और required फ़ील्ड

हर input को ऐसा accessible name चाहिए जो उसके पास दिखने वाले टेक्स्ट से मेल खाए। HTML में मज़बूत तरीका है <label> element जो for/id से input से जुड़ा हो, या input को घेरे हो। खाली फ़ील्ड के अंदर दिखने वाला hint टेक्स्ट label नहीं है: टाइप करते ही ग़ायब हो जाता है, अक्सर contrast में फ़ेल होता है, और accessible name के रूप में उसका समर्थन असंगत है। जहाँ दिखने वाला label element नहीं है वहाँ aria-label और aria-labelledby सही हैं, पर तब Label in Name जाँचें — जो बटन “भेजें” दिखाता है और जिसका नाम “Submit form” है, वह voice-control यूज़र को तोड़ देता है जो वही बोलते हैं जो दिखता है।

निर्देश और format hints (“DD/MM/YYYY”, “कम से कम 8 अक्षर, एक अंक”) फ़ील्ड से पहले हों या उससे जुड़े हों, आम तौर पर aria-describedby से, ताकि फ़ील्ड पर focus आते ही पढ़े जाएँ। जो निर्देश केवल hover पर tooltip में दिखते हैं, वे कीबोर्ड और टच यूज़र तक नहीं पहुँचते।

Required फ़ील्ड को दृश्य और programmatic दोनों संकेत चाहिए। अकेला लाल तारांकन रंग पर और यूज़र के परंपरा जानने पर निर्भर है; फ़ॉर्म के ऊपर एक बार समझाएँ (“* वाले फ़ील्ड अनिवार्य हैं”) या label में “(अनिवार्य)” लिखें, और required attribute या aria-required="true" सेट करें ताकि screen reader उसे बोले।

• हर फ़ील्ड का accessible name ब्राउज़र devtools के accessibility pane में देखें — markup से अनुमान न लगाएँ।
• दिखने वाले label पर क्लिक करें: focus फ़ील्ड पर जाना चाहिए (label सच में जुड़ा है, इसकी तेज़ जाँच)।

आज़माएँ: वैलिडेशन टेस्ट जनरेटर आज़माएँ: HTML एक्सेसिबिलिटी चेकर

fieldset और legend से संबंधित फ़ील्ड का grouping

Radio buttons या checkboxes के समूह में अर्थ के दो स्तर होते हैं: प्रश्न और हर उत्तर। अगर केवल उत्तरों के labels हों, तो screen reader यूज़र सुनता है “हाँ, radio button, 1 of 2” और उसे पता नहीं चलता कि पूछा क्या जा रहा है। समूह को <fieldset> और <legend> में रखें, या कस्टम विजेट के लिए aria-labelledby के साथ role="group"/role="radiogroup" इस्तेमाल करें। यही बात दिन, महीना और साल में बँटी जन्म-तिथि और दोहराए गए पते के ब्लॉक पर भी लागू होती है।

<!-- Defect: the question is plain text, not associated with the radios -->
<p>क्या आपके पास residence permit है?</p>
<input type="radio" id="p-yes" name="permit"><label for="p-yes">हाँ</label>
<input type="radio" id="p-no" name="permit"><label for="p-no">नहीं</label>

<!-- Fixed: the legend names the group; each option keeps its own label -->
<fieldset>
  <legend>क्या आपके पास residence permit है? (अनिवार्य)</legend>
  <input type="radio" id="p-yes" name="permit" required><label for="p-yes">हाँ</label>
  <input type="radio" id="p-no" name="permit"><label for="p-no">नहीं</label>
</fieldset>

Error पहचान, सुझाव और announcement

Validation फ़ेल होने पर तीन बातें सही होनी चाहिए। Error वाला फ़ील्ड पहचाना जाए; error टेक्स्ट में बताई जाए (3.3.1); और जहाँ सुधार ज्ञात हो, सुझाया जाए (3.3.3) — “तारीख़ DD/MM/YYYY में लिखें, जैसे 05/03/2026”, न कि “Invalid input”। अकेला लाल border 1.4.1 में फ़ेल है; अकेले icon को text alternative चाहिए; और संदेश फ़ील्ड से programmatically जुड़ा हो (aria-describedby या aria-errormessage के साथ aria-invalid="true") ताकि यूज़र फ़ील्ड पर लौटे तो पढ़ा जाए।

<label भाग 1:1for="dob">भाग 2:2Date of birth (required)</label>
<p id="dob-hint">भाग 3:3DD/MM/YYYY</p>
<input भाग 1:1id="dob" भाग 4:4required
  भाग 5:5autocomplete="bday"
  भाग 6:6aria-invalid="true"
  भाग 7:7aria-describedby="dob-hint dob-error">
<p id="dob-error">भाग 8:8Enter the date as DD/MM/YYYY, for example 05/03/2026</p>

यूज़र को यह भी पता चलना चाहिए कि error हुई है। दो आम, व्यावहारिक पैटर्न: submit पर फ़ॉर्म के ऊपर error summary दिखाएँ, focus उस पर ले जाएँ और हर प्रविष्टि को उसके फ़ील्ड से link करें; या focus सीधे पहले invalid फ़ील्ड पर ले जाएँ। जो संदेश focus हटाए बिना आते हैं — “सेव हो गया”, “3 परिणाम”, asynchronous “username पहले से लिया गया” — उनके लिए live region इस्तेमाल करें (जानकारी के लिए role="status" या aria-live="polite"; ज़रूरी errors के लिए role="alert") ताकि 4.1.3 Status Messages पूरा हो। Live region का container टेक्स्ट डालने से पहले पेज में मौजूद होना चाहिए, वरना कई screen readers उसे नहीं बोलते।

Inline validation की टाइमिंग पर ध्यान दें। हर keystroke पर, या जब यूज़र अभी ईमेल टाइप कर रहा हो, error बोलना शोरगुल और उलझन पैदा करता है; blur या submit पर validate करना आम तौर पर शांत रहता है। और किसी फ़ील्ड का बदलना अपने आप फ़ॉर्म submit या पेज navigate नहीं करना चाहिए (3.2.2 On Input), जब तक यूज़र को पहले न बताया गया हो।

• खाली फ़ॉर्म submit करें: हर required फ़ील्ड टेक्स्ट में रिपोर्ट हो, संदेश में फ़ील्ड का नाम हो।
• ग़लत format डालें: संदेश अपेक्षित format उदाहरण सहित बताए।
• Screen reader के साथ invalid फ़ॉर्म submit करें: बिना खोजे सुनाई दे कि errors हैं।
• Server-side errors (जैसे “card declined”) भी client-side errors की तरह ही announce हों।

आज़माएँ: नेगेटिव टेस्ट जनरेटर आज़माएँ: Mock एरर पेलोड जनरेटर

Error prevention और redundant entry

3.3.4 Error Prevention (Legal, Financial, Data) उन पेजों पर लागू है जो कानूनी प्रतिबद्धता या वित्तीय ट्रांज़ैक्शन बनाते हैं, यूज़र-नियंत्रित डेटा बदलते या हटाते हैं, या टेस्ट उत्तर जमा करते हैं। तीन में से कम से कम एक विकल्प सही होना चाहिए: submission reversible हो; डेटा जाँचा जाए और यूज़र सुधार सके; या अंतिम रूप देने से पहले review, confirm और सुधार की व्यवस्था हो। व्यवहार में टेस्टर पेमेंट से पहले review चरण, undo या cancellation की अवधि, या अकाउंट हटाने से पहले confirmation dialog जाँचते हैं — और यह कि review स्क्रीन ख़ुद सुलभ है (headings, पढ़ने योग्य values, हर सेक्शन के लिए साफ़ नाम वाला “Edit” link)।

3.3.7 Redundant Entry (A) WCAG 2.2 में नया है। अगर कोई multi-step प्रक्रिया वह जानकारी फिर माँगती है जो यूज़र पहले दे चुका है — billing चरण में shipping पता, confirmation चरण में national ID — तो उसे auto-populate करना या चुनने के लिए देना होगा (जैसे “shipping पते जैसा ही” checkbox)। अपवाद तब हैं जब दोबारा डालना आवश्यक हो, सुरक्षा के लिए ज़रूरी हो (जैसे नया password confirm करना), या पहले की जानकारी अब मान्य न हो।

Input purpose, autocomplete और सुलभ authentication

1.3.5 Identify Input Purpose चाहता है कि यूज़र की जानकारी लेने वाले फ़ील्ड अपना उद्देश्य programmatically बताएँ, जब वह उद्देश्य WCAG के “Input Purposes for User Interface Components” सेक्शन में सूचीबद्ध हो। HTML में इसका मतलब है सही token वाला autocomplete attribute: name, given-name, family-name, email, tel, street-address, postal-code, bday, username, current-password, new-password, cc-number आदि। Conformance से आगे, सही tokens ब्राउज़र और password managers को फ़ॉर्म भरने देते हैं, जो मोटर और संज्ञानात्मक विकलांगता वाले लोगों की सीधी मदद है। हर फ़ील्ड पर token जाँचें; व्यक्तिगत-डेटा फ़ील्ड पर autocomplete="off" उठाने लायक finding है।

3.3.8 Accessible Authentication (Minimum) कहता है कि authentication प्रक्रिया का कोई चरण cognitive function test — password याद रखना, puzzle हल करना, code हाथ से उतारना — न माँगे, जब तक वह चरण बिना ऐसे test का वैकल्पिक तरीका, मदद करने वाला mechanism (WCAG के अपने उदाहरण: password manager समर्थन और copy-paste), या वस्तु पहचानने या यूज़र द्वारा दी गई व्यक्तिगत सामग्री पहचानने वाला test न दे। Understanding दस्तावेज़ one-time code को हाथ से उतारने को cognitive function test मानता है, इसलिए यूज़र को कम से कम code paste करने में सक्षम होना चाहिए।

• Username और password फ़ील्ड paste स्वीकार करें और password managers उन्हें भर सकें (कोई script paste या autofill को न रोके)।
• One-time code पूरा paste हो सके। “हर अंक के लिए एक बॉक्स” वाले inputs अक्सर इसमें फ़ेल होते हैं: paste सिर्फ़ पहला बॉक्स भरता है — इसे स्पष्ट रूप से टेस्ट करें। HTML token autocomplete="one-time-code" ब्राउज़र को code सुझाने में मदद करता है; यह WCAG की input-purpose सूची में नहीं है, इसलिए इसे 1.3.5 की आवश्यकता नहीं, अच्छी practice मानें।
• CAPTCHA: टेक्स्ट या puzzle CAPTCHA cognitive function test है और उसे विकल्प चाहिए; object-recognition CAPTCHA AA पर अपवाद है (AAA यानी 3.3.9 Accessible Authentication (Enhanced) पर नहीं)। किसी भी CAPTCHA image को 1.1.1 के तहत उसका उद्देश्य बताने वाला text alternative, और दूसरी इंद्रिय वाला वैकल्पिक रूप फिर भी चाहिए।
• Passwordless विकल्प (ईमेल link, passkeys/WebAuthn) cognitive function test से बचने वाले विकल्प हैं — जाँचें कि वे कीबोर्ड और screen reader से पहुँचने और चलाने योग्य हैं।

आज़माएँ: फ़ेक यूज़र जनरेटर

एक व्यावहारिक टेस्ट प्रक्रिया

• Structure pass (devtools): हर फ़ील्ड के लिए accessibility tree में computed accessible name, role, description, required और invalid स्थिति पढ़ें। Autocomplete tokens की पुष्टि करें।
• Keyboard pass: फ़ॉर्म केवल Tab, Shift+Tab, arrow keys, Space और Enter से पूरा करें — focus order दृश्य क्रम का पालन करे, focus हमेशा दिखे, कस्टम select और date picker चलें (कीबोर्ड एक्सेसिबिलिटी गाइड देखें)।
• Screen-reader pass: Windows पर NVDA या JAWS, macOS/iOS पर VoiceOver, या Android पर TalkBack से पूरा करें — हर फ़ील्ड, group, hint और error सार्थक रूप से बोला जाए (screen reader टेस्टिंग गाइड देखें)।
• Error pass: खाली submit, हर ग़लत format, server-side errors और timeout ट्रिगर करें। Focus की गति और announcements देखें।
• Visual pass: 200% zoom करें और 320 CSS px चौड़ाई पर reflow जाँचें; labels और errors अपने फ़ील्ड के पास रहें; errors रंग पर निर्भर न हों; फ़ील्ड borders और focus indicators non-text contrast पूरा करें।

आज़माएँ: वैलिडेशन टेस्ट जनरेटर आज़माएँ: फ़ेक नाम जनरेटर

Checklist: सुलभ फ़ॉर्म test cases

इसे अपने test management टूल में हर फ़ॉर्म के लिए एक checklist के रूप में कॉपी करें, या हर पंक्ति को फ़ॉर्म के असली फ़ील्ड और डेटा के साथ test case में बदलें। नीचे की checklist अंग्रेज़ी में है ताकि सीधे कॉपी हो सके; उसके बिंदु ये हैं:

• Labels और निर्देश — हर फ़ील्ड का दिखने वाला label और उससे मेल खाता accessible name हो (1.3.1, 3.3.2, 2.5.3); placeholder कभी अकेला label न हो; format hints फ़ील्ड से जुड़े हों (aria-describedby) और फ़ोकस पर पढ़े जाएँ; required फ़ील्ड दिखने वाले टेक्स्ट या समझाए गए चिह्न के साथ required/aria-required से चिह्नित हों (1.3.1, 1.4.1)।
• Grouping — radio/checkbox groups और बँटे हुए फ़ील्ड (तारीख़, फ़ोन) में fieldset+legend हो, या नाम वाला role=group।
• Errors — ख़ाली submit पर हर error फ़ील्ड का नाम ले और टेक्स्ट में हो (3.3.1); ग़लत format पर संदेश उदाहरण के साथ सही format सुझाए (3.3.3); error फ़ील्ड से जुड़ा हो और invalid फ़ील्ड पर aria-invalid लगा हो; errors announce हों — फ़ोकस summary या पहले error पर जाए, या live region इस्तेमाल हो (4.1.3); errors सिर्फ़ रंग से न दिखें (1.4.1); फ़ील्ड बदलने से अचानक submit या navigation न हो (3.2.2)।
• Prevention और redundant entry — कानूनी, वित्तीय या डेटा बदलने वाले submit में review, undo या check-and-correct हो (3.3.4); पिछले चरणों का डेटा पहले से भरा या चुनने योग्य हो (3.3.7); session timeout डेटा खोए बिना बढ़ाया जा सके (2.2.1)।
• Purpose और authentication — personal-data फ़ील्ड पर autocomplete tokens सही हों (1.3.5); username/password/OTP फ़ील्ड में paste और password managers काम करें (3.3.8); पूरा OTP paste करने पर सभी बँटे boxes भर जाएँ; CAPTCHA का विकल्प और टेक्स्ट विकल्प हो (3.3.8, 1.1.1)।
• Operation — पूरा फ़ॉर्म सिर्फ़ कीबोर्ड से, दिखने वाले फ़ोकस के साथ, और स्क्रीन रीडर से पूरा हो सके; 200% ज़ूम और 320 CSS px चौड़ाई पर कोई label या error न खोए; RTL फ़ॉर्म में lang="ar" dir="rtl" हो और LTR डेटा फ़ील्ड dir="ltr" या dir="auto" इस्तेमाल करें।

FORM A11Y CHECKLIST — <form name / URL / build>

Labels & instructions
[ ] Every field has a visible label and a matching accessible name (1.3.1, 3.3.2, 2.5.3)
[ ] Placeholder is never the only label
[ ] Format hints are associated with the field (aria-describedby) and read on focus
[ ] Required fields: visible text or explained marker + required/aria-required (1.3.1, 1.4.1)

Grouping
[ ] Radio/checkbox groups and split fields (date, phone) have fieldset+legend or role=group with a name

Errors
[ ] Empty submit: each error names the field and is in text (3.3.1)
[ ] Wrong format: message suggests the correct format with an example (3.3.3)
[ ] Error is associated with the field; aria-invalid set on invalid fields
[ ] Errors are announced: focus moves to summary/first error, or live region used (4.1.3)
[ ] Errors are not shown by colour alone (1.4.1)
[ ] Changing a field does not submit or navigate unexpectedly (3.2.2)

Prevention & redundant entry
[ ] Legal/financial/data-changing submit: review, undo or check-and-correct exists (3.3.4)
[ ] Data from earlier steps is pre-filled or selectable (3.3.7)
[ ] Session timeout can be extended without data loss (2.2.1)

Purpose & authentication
[ ] autocomplete tokens correct on personal-data fields (1.3.5)
[ ] Paste and password managers work on username/password/OTP fields (3.3.8)
[ ] Pasting a full OTP into split boxes fills all boxes
[ ] CAPTCHA has an alternative and a text alternative (3.3.8, 1.1.1)

Operation
[ ] Whole form completable by keyboard only; focus visible
[ ] Whole form completable with a screen reader
[ ] 200% zoom and 320 CSS px width: no lost labels or errors
[ ] RTL forms: lang="ar" dir="rtl"; LTR data fields use dir="ltr"/"auto"

आज़माएँ: AI QA चेकलिस्ट जनरेटर

आम defects, bug titles के रूप में

एक्सेसिबिलिटी bugs तेज़ी से ठीक होते हैं जब title control, दिखने वाली विफलता और प्रभावित यूज़र्स का नाम ले, और body success criterion का हवाला दे। पूरी रिपोर्ट की बनावट bug-report गाइड में है; ये यथार्थवादी titles हैं जिनके अनुसार आप अपने लिख सकते हैं।

• “Sign-up: Email फ़ील्ड का कोई accessible name नहीं — screen reader केवल ‘edit text’ बोलता है (1.3.1, 4.1.2)”
• “Checkout: card errors केवल लाल border से दिखती हैं; कोई टेक्स्ट संदेश नहीं (1.4.1, 3.3.1)”
• “Payment: submit के बाद error summary दिखता है पर focus बटन पर ही रहता है और कुछ announce नहीं होता (4.1.3)”
• “Login: password फ़ील्ड में paste ब्लॉक, password managers भर नहीं पाते (3.3.8)”
• “OTP स्क्रीन: 6 अंकों का code paste करने पर छह में से केवल पहला बॉक्स भरता है (3.3.8)”
• “Visa आवेदन चरण 3: passport नंबर दोबारा टाइप करना पड़ता है जबकि चरण 1 में डाला गया था (3.3.7)”

आज़माएँ: AI बग टाइटल जनरेटर

अरबी और right-to-left फ़ॉर्म

अरबी फ़ॉर्म ऊपर की सूची के अलावा अपनी जाँचें जोड़ते हैं। पेज या फ़ॉर्म में lang="ar" और dir="rtl" होना चाहिए ताकि screen reader आवाज़ बदले और सही क्रम में पढ़े; labels, hints और error summaries right-to-left पढ़ने के क्रम का पालन करें, और focus order उससे मेल खाए। Left-to-right डेटा वाले फ़ील्ड — ईमेल, URL, IBAN, कई फ़ोन formats — को आम तौर पर input पर ही dir="ltr" (या dir="auto") चाहिए ताकि टाइप करते समय अक्षरों का क्रम न बदले, और ऐसे values उद्धृत करने वाले error संदेश उन्हें उलझाएँ नहीं।

Validation को वही स्वीकार करना चाहिए जो लोग अरबी में सच में टाइप करते हैं: फ़ोन और ID नंबर में Arabic-Indic अंक (अगर सिस्टम उन्हें बदलता है), अरबी लिपि में नाम, और जहाँ बिज़नेस स्वीकार करे वहाँ हिजरी तारीख़ें। सही अरबी नाम पर “मान्य नाम डालें” जैसी error functional और एक्सेसिबिलिटी दोनों तरह का defect है। RTL टेस्टिंग गाइड bidirectional टेक्स्ट, mirroring और mixed-direction input को विस्तार से कवर करती है।

आज़माएँ: फ़ेक नाम जनरेटर

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

संदर्भ

• Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024W3C की Recommendation जो सुलभ वेब कंटेंट के लिए टेस्ट करने योग्य success criteria तय करती है — चार सिद्धांतों और तीन conformance स्तरों (A, AA, AAA) में व्यवस्थित।
• Understanding WCAG 2.2W3C Web Accessibility Initiative (WAI)WCAG 2.2 की हर guideline और success criterion की व्याख्या: उद्देश्य, किसे लाभ, उदाहरण और तकनीकें (नॉर्मेटिव नहीं)।
• How to Meet WCAG (Quick Reference)W3C Web Accessibility Initiative (WAI)WCAG 2.2 के हर success criterion की फ़िल्टर करने योग्य सूची, पर्याप्त तकनीकों और आम विफलताओं के साथ।
• Accessible Rich Internet Applications (WAI-ARIA) 1.2W3C · 2023W3C Recommendation जो ARIA roles, states और properties परिभाषित करती है — कस्टम विजेट अपना अर्थ सहायक तकनीक को कैसे बताते हैं।
• ARIA Authoring Practices Guide (APG)W3C Web Accessibility Initiative (WAI)आम विजेट (tabs, menus, dialogs, comboboxes) के पैटर्न, अपेक्षित कीबोर्ड इंटरैक्शन और ARIA उपयोग के साथ — वह संदर्भ जिससे टेस्टर कस्टम कंपोनेंट की तुलना करते हैं।
• Accessibility — MDNMDN Web Docs (Mozilla)सुलभ वेब पेज बनाने और जाँचने की व्यावहारिक गाइड: सिमैंटिक HTML, ARIA, कीबोर्ड सपोर्ट और टेस्टिंग।
• Evaluating Web Accessibility OverviewW3C Web Accessibility Initiative (WAI)एक्सेसिबिलिटी मूल्यांकन के लिए W3C का प्रवेश-पृष्ठ: शुरू से और पूरे विकास में मूल्यांकन क्यों, और मैनुअल जाँच, टूल व यूज़र भागीदारी कैसे साथ काम करते हैं।