आपका बनाया गया फ़ॉर्म लोगों के लिए है. लोग अलग-अलग डिवाइस का इस्तेमाल करते हैं. कुछ लोग माउस, कुछ टच डिवाइस, कीबोर्ड का इस्तेमाल करते हैं. कुछ ऐसे डिवाइस होते हैं जिन्हें आंखों की मूवमेंट से कंट्रोल किया जाता है. कुछ स्क्रीन रीडर, कुछ छोटी स्क्रीन, और कुछ टेक्स्ट को बड़ा करने वाले सॉफ़्टवेयर का इस्तेमाल करते हैं. हर कोई आपके फ़ॉर्म का इस्तेमाल करना चाहता है. अपने फ़ॉर्म को सभी के लिए उपलब्ध और इस्तेमाल करने लायक बनाने का तरीका जानें.
पक्का करें कि उपयोगकर्ताओं को फ़ॉर्म फ़ील्ड का मकसद समझ में आए
आपके पास कई फ़ॉर्म कंट्रोल में से चुनने का विकल्प है.
उन सबमें क्या समानता है?
हर फ़ॉर्म कंट्रोल में, उससे जुड़ा <label> एलिमेंट होना चाहिए.
<label> एलिमेंट, फ़ॉर्म कंट्रोल का मकसद बताता है.
<label> टेक्स्ट, फ़ॉर्म कंट्रोल के साथ विज़ुअल तौर पर जुड़ा होता है और स्क्रीन रीडर से इसे पढ़ा जाता है.
इसके अलावा, <label> पर टैप या क्लिक करने से फ़ॉर्म कंट्रोल से जुड़ा फ़ोकस होता है, जिससे यह एक बड़ा टारगेट बन जाता है.
ब्राउज़र में पहले से मौजूद सुविधाओं को ऐक्सेस करने के लिए, काम के एचटीएमएल का इस्तेमाल करें
सैद्धांतिक तौर पर, सिर्फ़ <div> एलिमेंट का इस्तेमाल करके एक फ़ॉर्म बनाया जा सकता है.
आप इसे स्थानीय <form> जैसा भी बना सकते हैं.
नॉन-सिमैंटिक एलिमेंट इस्तेमाल करने में क्या समस्या है?
बिल्ट-इन फ़ॉर्म एलिमेंट में कई बिल्ट-इन सुविधाएं मौजूद होती हैं. आइए, एक उदाहरण देखें.
विज़ुअल तौर पर, <input> (उदाहरण में पहला वाला) और <div> एक जैसे दिखते हैं.
दोनों के लिए टेक्स्ट भी डाला जा सकता है, क्योंकि <div> में contenteditable एट्रिब्यूट मौजूद होता है.
हालांकि, सही <input> एलिमेंट और <input> की तरह दिखने वाले <div>
का इस्तेमाल करने के बीच कई अंतर हैं.
स्क्रीन रीडर का इस्तेमाल करने वाला व्यक्ति, <div> की पहचान इनपुट एलिमेंट के तौर पर नहीं कर सकता और वह फ़ॉर्म भर नहीं सकता.
स्क्रीन रीडर को सभी लोगों को 'नाम' सुनाई देता है.
इसमें इस बात का कोई संकेत नहीं होता कि एलिमेंट, टेक्स्ट जोड़ने के लिए फ़ॉर्म कंट्रोल के तौर पर काम करता है.
<div>Name</div> पर क्लिक करने से, उसके साथ इस्तेमाल होने वाले <div> पर फ़ोकस नहीं होता. वहीं, <label> और <input> को for और id एट्रिब्यूट का इस्तेमाल करके कनेक्ट किया जाता है.
फ़ॉर्म सबमिट करने के बाद, <div> में डाला गया डेटा, अनुरोध में शामिल नहीं किया जाता.
JavaScript के साथ डेटा अटैच करते समय,
<input> ऐसा डिफ़ॉल्ट रूप से करता है.
पहले से मौजूद फ़ॉर्म एलिमेंट में अन्य सुविधाएं भी होती हैं.
उदाहरण के लिए, सही फ़ॉर्म एलिमेंट और सही inputmode या type के साथ, ऑन-स्क्रीन कीबोर्ड सही वर्ण दिखाता है. <div> पर inputmode एट्रिब्यूट का इस्तेमाल करने पर, ऐसा नहीं किया जा सकता.
पक्का करें कि उपयोगकर्ताओं को सही डेटा फ़ॉर्मैट के बारे में पता हो
किसी फ़ॉर्म कंट्रोल के लिए, पुष्टि करने के अलग-अलग नियम तय किए जा सकते हैं.
उदाहरण के लिए, मान लें कि किसी फ़ॉर्म फ़ील्ड में कम से कम आठ वर्ण होने चाहिए.
आप minlength एट्रिब्यूट का इस्तेमाल करते हैं, जो ब्राउज़र को पुष्टि करने का नियम दिखाता है.
यह कैसे पक्का किया जा सकता है कि उपयोगकर्ताओं को पुष्टि करने के नियम के बारे में पता है? उन्हें बताएं.
फ़ॉर्म कंट्रोल के नीचे, सही फ़ॉर्मैट के बारे में जानकारी जोड़ें.
सहायक डिवाइसों के लिए, साफ़ तौर पर जानकारी देने के लिए, फ़ॉर्म कंट्रोल पर aria-describedby एट्रिब्यूट का इस्तेमाल करें. साथ ही, दोनों को कनेक्ट करने के लिए, गड़बड़ी के मैसेज पर id का इस्तेमाल करें.
किसी फ़ॉर्म कंट्रोल का गड़बड़ी का मैसेज ढूंढने में उपयोगकर्ताओं की मदद करें
पुष्टि करने के बारे में पिछले मॉड्यूल में, आपने यह सीखा कि अमान्य डेटा एंट्री के मामले में गड़बड़ी के मैसेज कैसे दिखाए जाते हैं.
<label for="name">Name</label>
<input type="text" name="name" id="name" required>
उदाहरण के लिए, अगर किसी फ़ील्ड में required एट्रिब्यूट है और अमान्य डेटा डाला गया है, तो फ़ॉर्म सबमिट करने पर ब्राउज़र, फ़ॉर्म कंट्रोल के बगल में गड़बड़ी का मैसेज दिखाता है. स्क्रीन रीडर भी गड़बड़ी के मैसेज के बारे में बताते हैं.
आप खुद भी गड़बड़ी का मैसेज तय कर सकते हैं:
इस उदाहरण में और बदलाव करने की ज़रूरत है, ताकि गड़बड़ी का मैसेज, फ़ॉर्म कंट्रोल से कनेक्ट हो सके.
आसान तरीका यह है कि फ़ॉर्म कंट्रोल में aria-describedby एट्रिब्यूट का इस्तेमाल किया जाए, जो गड़बड़ी के मैसेज एलिमेंट के id से मेल खाता हो.
इसके बाद, गड़बड़ी के मैसेज के लिए aria-live="assertive" का इस्तेमाल करें.
ARIA लाइव रीजन, गड़बड़ी दिखने के साथ ही स्क्रीन रीडर का इस्तेमाल करने वालों को एक गड़बड़ी की सूचना देता है.
इस तरीके में समस्या यह है कि कई फ़ील्ड वाले फ़ॉर्म के लिए, आम तौर पर एक से ज़्यादा गड़बड़ी होने पर aria-live सिर्फ़ पहली गड़बड़ी के बारे में सूचना देगा.
जैसा कि एक ही कार्रवाई पर, aria-live की कई सूचनाओं के बारे में इस लेख में बताया गया है, सभी गड़बड़ियों को मिलाकर एक मैसेज बनाया जा सकता है. दूसरा तरीका यह है कि गड़बड़ियां होने की जानकारी दी जाए. इसके बाद, फ़ील्ड पर फ़ोकस होने पर अलग-अलग गड़बड़ियों के बारे में बताया जाए.
पक्का करें कि उपयोगकर्ता गड़बड़ियों को पहचानते हों
कभी-कभी डिज़ाइनर :invalid स्यूडो-क्लास का इस्तेमाल करके,
अमान्य स्टेट को लाल रंग देते हैं.
हालांकि, किसी गड़बड़ी या सफलता के बारे में बताने के लिए,
आपको सिर्फ़ रंग के भरोसे नहीं रहना चाहिए.
लाल-हरे रंग के दिखाई न देने वाले लोगों को हरा और लाल रंग का बॉर्डर करीब-करीब एक जैसा दिखता है.
यह पता नहीं लगाया जा सकता कि मैसेज किसी गड़बड़ी से जुड़ा है या नहीं.
गड़बड़ी के मैसेज में रंग के अलावा, आइकॉन या गड़बड़ी के मैसेज से पहले एक आइकॉन इस्तेमाल करें.
<span class="error">
<strong>Error:</strong>Please use at least eight characters.
</span>
उपयोगकर्ताओं को आपके फ़ॉर्म पर नेविगेट करने में मदद करें
सीएसएस का इस्तेमाल करके, फ़ॉर्म कंट्रोल के विज़ुअल क्रम को बदला जा सकता है. विज़ुअल ऑर्डर और कीबोर्ड नेविगेशन (DOM ऑर्डर) के बीच डिसकनेक्ट होने से स्क्रीन रीडर और कीबोर्ड का इस्तेमाल करने वालों को समस्या होती है.
यह पक्का करने के तरीके के बारे में ज़्यादा जानें कि पेज पर विज़ुअल का क्रम, डीओएम क्रम के मुताबिक होता है.
उपयोगकर्ताओं को मौजूदा फ़ॉर्म कंट्रोल की पहचान करने में मदद करें
इस फ़ॉर्म में नेविगेट करने के लिए, अपने कीबोर्ड का इस्तेमाल करें.
क्या आपको पता है कि फ़ॉर्म कंट्रोल के चालू होने के बाद उनकी स्टाइल बदल गई थी?
यह डिफ़ॉल्ट फ़ोकस स्टाइल है.
इसे :focus सीएसएस स्यूडो-क्लास से बदला जा सकता है.
:focus के अंदर कोई भी स्टाइल इस्तेमाल की जाए,
हमेशा यह पक्का करता है कि डिफ़ॉल्ट स्टेट और फ़ोकस स्टेट के बीच के विज़ुअल अंतर आसानी से पहचाने जा सकें.
फ़ोकस इंडिकेटर डिज़ाइन करने के बारे में ज़्यादा जानें.
पक्का करें कि आपका फ़ॉर्म इस्तेमाल करने लायक हो
अलग-अलग डिवाइसों से अपना फ़ॉर्म भरकर, कई सामान्य समस्याओं का पता लगाया जा सकता है. सिर्फ़ अपने कीबोर्ड का इस्तेमाल करें, स्क्रीन रीडर का इस्तेमाल करें (जैसे कि Windows पर NVDA या Mac पर VoiceOver) या पेज को 200% तक ज़ूम करें. अपने फ़ॉर्म का हमेशा अलग-अलग प्लैटफ़ॉर्म पर, खास तौर पर ऐसे डिवाइसों या सेटिंग पर टेस्ट करें जिनका इस्तेमाल आप हर दिन नहीं करते. क्या आप स्क्रीन रीडर इस्तेमाल करने वाले किसी व्यक्ति या टेक्स्ट को बड़ा करने वाले सॉफ़्टवेयर का इस्तेमाल करने वाले किसी व्यक्ति को जानते हैं? उन्हें आपका फ़ॉर्म भरने के लिए कहें. सुलभता से जुड़ी समीक्षाएं बेहतरीन होती हैं. असली उपयोगकर्ताओं के साथ टेस्ट करना और भी बेहतर है.
सुलभता की समीक्षा करने और असल उपयोगकर्ताओं से टेस्ट करने के तरीके के बारे में ज़्यादा जानें.