फ़ॉर्म एक ऐसा एलिमेंट है जिसकी मदद से उपयोगकर्ता, किसी फ़ील्ड या फ़ील्ड के ग्रुप में डेटा डाल सकता है. फ़ॉर्म एक फ़ील्ड के तौर पर आसान हो सकते हैं या कई चरणों वाले फ़ॉर्म एलिमेंट के तौर पर मुश्किल हो सकते हैं. इनमें हर पेज पर कई फ़ील्ड, इनपुट की पुष्टि, और कभी-कभी कैप्चा भी शामिल होता है.
फ़ॉर्म को ऐक्सेस करने के लिहाज़ से सही बनाने के लिए, सबसे ज़्यादा मेहनत करनी पड़ती है. इसकी वजह यह है कि इसके लिए, उन सभी एलिमेंट के बारे में जानकारी होनी चाहिए जिन्हें हमने पहले ही कवर कर लिया है. साथ ही, फ़ॉर्म के लिए खास तौर पर बने नियमों के बारे में भी जानकारी होनी चाहिए. थोड़ी समझ और समय की मदद से, अपने और अपने उपयोगकर्ताओं के हिसाब से, ऐक्सेस किया जा सकने वाला फ़ॉर्म बनाया जा सकता है.
फ़ॉर्म, इस कोर्स में कॉम्पोनेंट से जुड़ा आखिरी मॉड्यूल है. इस मॉड्यूल में, फ़ॉर्म के लिए बने दिशा-निर्देशों पर फ़ोकस किया जाएगा. हालांकि, कॉन्टेंट का स्ट्रक्चर, कीबोर्ड फ़ोकस, और रंग का कंट्रास्ट जैसे अन्य सभी दिशा-निर्देश भी फ़ॉर्म के एलिमेंट पर लागू होते हैं. इन दिशा-निर्देशों के बारे में आपको पिछले मॉड्यूल में बताया गया था.
फ़ील्ड
फ़ॉर्म में फ़ील्ड सबसे ज़रूरी होते हैं. फ़ील्ड, छोटे इंटरैक्टिव पैटर्न होते हैं. जैसे, इनपुट या रेडियो बटन एलिमेंट. इनकी मदद से, उपयोगकर्ता कॉन्टेंट डाल सकते हैं या कोई विकल्प चुन सकते हैं. इसमें अलग-अलग तरह के फ़ॉर्म फ़ील्ड उपलब्ध हैं.
डिफ़ॉल्ट तौर पर, हमारा सुझाव है कि ARIA की मदद से कोई कस्टम एलिमेंट बनाने के बजाय, पहले से मौजूद एचटीएमएल पैटर्न का इस्तेमाल करें. ऐसा इसलिए, क्योंकि फ़ील्ड की स्थितियां, प्रॉपर्टी, और वैल्यू जैसी कुछ सुविधाएं और फ़ंक्शन, एचटीएमएल एलिमेंट में पहले से मौजूद होते हैं. कस्टम फ़ील्ड के लिए, आपको एरिया को मैन्युअल तरीके से जोड़ना होगा.
इसका सुझाव नहीं दिया जाता — ARIA के साथ कस्टम एचटीएमएल
<div role="form" id="sundae-order-form">
<!-- form content -->
</div>
सुझाया गया — स्टैंडर्ड एचटीएमएल
<form id="sundae-order-form">
<!-- form content -->
</form>
जहां लागू हो वहां सबसे ज़्यादा ऐक्सेस किए जा सकने वाले फ़ॉर्म फ़ील्ड पैटर्न चुनने के अलावा, आपको अपने फ़ील्ड में एचटीएमएल ऑटोकंप्लीट एट्रिब्यूट भी जोड़ने चाहिए. अपने-आप भरने की सुविधा वाले एट्रिब्यूट जोड़ने से, उपयोगकर्ता एजेंट और सहायक टेक्नोलॉजी (एटी) को मकसद की जानकारी या पहचान के बारे में ज़्यादा जानकारी मिलती है.
ऑटोकंप्लीट एट्रिब्यूट की मदद से, उपयोगकर्ता अपने हिसाब से विज़ुअल प्रज़ेंटेशन बना सकते हैं. उदाहरण के लिए, जन्मदिन के ऑटोकंप्लीट एट्रिब्यूट (bday
) को असाइन करके, किसी फ़ील्ड में जन्मदिन का केक आइकॉन दिखाना. आम तौर पर, अपने-आप जानकारी भरने की सुविधा वाले एट्रिब्यूट से, फ़ॉर्म भरना आसान और तेज़ हो जाता है. यह सुविधा खास तौर पर उन लोगों के लिए बहुत फ़ायदेमंद है जिनमें सीखने और पढ़ने से जुड़ी समस्याएं हैं. साथ ही, यह उन लोगों के लिए भी मददगार है जो स्क्रीन रीडर जैसे एटी का इस्तेमाल करते हैं.
<form id="sundae-order-form">
<p>Name: <input type="name" autocomplete="name"></p>
<p>Telephone: <input type="tel" autocomplete="tel"></p>
<p>Email address: <input type="email" autocomplete="email"></p>
</form>
आखिर में, फ़ॉर्म फ़ील्ड पर फ़ोकस या उपयोगकर्ता का इनपुट मिलने पर, उनमें कॉन्टेक्स्ट के हिसाब से बदलाव नहीं होने चाहिए. ऐसा तब तक नहीं होना चाहिए, जब तक कि कॉम्पोनेंट का इस्तेमाल करने से पहले, उपयोगकर्ता को इस व्यवहार के बारे में चेतावनी न दी गई हो. उदाहरण के लिए, जब किसी फ़ील्ड पर फ़ोकस किया जाता है या उपयोगकर्ता उसमें कॉन्टेंट जोड़ता है, तो फ़ॉर्म अपने-आप सबमिट नहीं होना चाहिए.
लेबल
लेबल से उपयोगकर्ता को यह पता चलता है कि फ़ील्ड का मकसद क्या है. अगर फ़ील्ड की वैल्यू सबमिट करना ज़रूरी है, तो लेबल से फ़ील्ड की ज़रूरी शर्तों के बारे में भी जानकारी मिल सकती है. जैसे, इनपुट फ़ॉर्मैट. लेबल हर समय दिखने चाहिए और उपयोगकर्ताओं को फ़ॉर्म फ़ील्ड के बारे में सटीक जानकारी देनी चाहिए.
ऐक्सेस किए जा सकने वाले फ़ॉर्म के बुनियादी सिद्धांतों में से एक, फ़ील्ड और उसके लेबल के बीच साफ़ और सटीक कनेक्शन बनाना है. यह विज़ुअल और प्रोग्राम के हिसाब से, दोनों तरह से सही है. इस संदर्भ के बिना, हो सकता है कि उपयोगकर्ता को फ़ॉर्म में मौजूद फ़ील्ड भरने का तरीका न समझ आए.
<form id="sundae-order-form">
<p><label>Name (required): <input type="name" autocomplete="name" required></label></p>
<p><label>Telephone (required): <input type="tel" autocomplete="tel" required></label></p>
<p><label>Email address: <input type="email" autocomplete="email"></label></p>
</form>
साथ ही, मेलिंग पते जैसे मिलते-जुलते फ़ॉर्म फ़ील्ड को प्रोग्राम के हिसाब से और विज़ुअल तौर पर ग्रुप किया जाना चाहिए. एक तरीका यह है कि मिलते-जुलते एलिमेंट को ग्रुप करने के लिए, फ़ील्डसेट और लेजेंड पैटर्न का इस्तेमाल करें.
ब्यौरा
फ़ील्ड के ब्यौरे, लेबल की तरह ही काम करते हैं. इनका इस्तेमाल, फ़ील्ड और ज़रूरी शर्तों के बारे में ज़्यादा जानकारी देने के लिए किया जाता है. अगर लेबल या फ़ॉर्म के निर्देशों में ज़रूरत के मुताबिक जानकारी दी गई है, तो सुलभता के लिए फ़ील्ड की जानकारी देना ज़रूरी नहीं है.
हालांकि, कुछ मामलों में फ़ॉर्म में गड़बड़ियों से बचने के लिए, ज़्यादा जानकारी देना फ़ायदेमंद होता है. जैसे, पासवर्ड फ़ील्ड के लिए, इनपुट की कम से कम लंबाई के बारे में जानकारी देना या उपयोगकर्ता को बताना कि कैलेंडर के किस फ़ॉर्मैट का इस्तेमाल करना है (जैसे, MM-DD-YYYY).
फ़ॉर्म में फ़ील्ड की जानकारी जोड़ने के कई तरीके हैं. सबसे अच्छा तरीका यह है कि <label>
एलिमेंट के अलावा, फ़ॉर्म एलिमेंट में aria-describedby एट्रिब्यूट जोड़ा जाए. स्क्रीन रीडर, ब्यौरा और लेबल, दोनों को पढ़ेगा.
अगर आपने अपने एलिमेंट में
aria-labelledby एट्रिब्यूट जोड़ा है, तो एट्रिब्यूट की वैल्यू, आपके
<label>
में मौजूद टेक्स्ट को बदल देती है. हमेशा की तरह, फ़ाइनल कोड को उन सभी एटी के साथ टेस्ट करना न भूलें जिनके साथ आपको इसे इस्तेमाल करना है.
गड़बड़ियां
ऐक्सेस किए जा सकने वाले फ़ॉर्म बनाते समय, उपयोगकर्ताओं को फ़ॉर्म में गड़बड़ियां करने से रोकने के लिए कई काम किए जा सकते हैं. इस मॉड्यूल में, हमने फ़ील्ड को साफ़ तौर पर मार्क-अप करने, पहचान करने वाले लेबल बनाने, और जब भी संभव हो, ज़्यादा जानकारी जोड़ने के बारे में बताया है. भले ही, आपको लगता हो कि आपका फ़ॉर्म कितना भी साफ़ है, फिर भी कोई उपयोगकर्ता गलती कर सकता है.
जब किसी उपयोगकर्ता को फ़ॉर्म में कोई गड़बड़ी मिलती है, तो सबसे पहले उसे गड़बड़ी के बारे में बताएं. जिस फ़ील्ड में गड़बड़ी हुई है उसकी जानकारी साफ़ तौर पर दी जानी चाहिए. साथ ही, उपयोगकर्ता को गड़बड़ी के बारे में टेक्स्ट में जानकारी दी जानी चाहिए.
गड़बड़ी के मैसेज दिखाने के लिए अलग-अलग तरीके हैं. जैसे:
- गड़बड़ी होने की जगह के आस-पास मौजूद, इनलाइन मोडल
- पेज पर सबसे ऊपर, एक बड़े मैसेज में गड़बड़ियों का कलेक्शन
गड़बड़ियों की जानकारी देते समय, कीबोर्ड फ़ोकस और एआरआई लाइव रीजन के विकल्पों पर ध्यान दें.
जब भी हो सके, उपयोगकर्ता को गड़बड़ी को ठीक करने का सुझाव दें. उपयोगकर्ताओं को गड़बड़ियों की सूचना देने के लिए, दो एट्रिब्यूट उपलब्ध हैं.
- इसके लिए, एचटीएमएल ज़रूरी एट्रिब्यूट का इस्तेमाल किया जा सकता है. ब्राउज़र, पुष्टि करने के लिए सबमिट किए गए पैरामीटर के आधार पर, गड़बड़ी का सामान्य मैसेज दिखाएगा.
- इसके अलावा, एटी के साथ गड़बड़ी का कस्टमाइज़ किया गया मैसेज शेयर करने के लिए, aria-required एट्रिब्यूट का इस्तेमाल किया जा सकता है. जब तक सभी उपयोगकर्ताओं को मैसेज दिखाने के लिए अतिरिक्त कोड नहीं जोड़ा जाता, तब तक सिर्फ़ एटी को मैसेज मिलेगा.
जब उपयोगकर्ता को लगता है कि सभी गड़बड़ियां ठीक हो गई हैं, तो उसे फ़ॉर्म फिर से सबमिट करने की अनुमति दें. साथ ही, सबमिट करने के नतीजों के बारे में सुझाव या राय दें. गड़बड़ी का मैसेज, उपयोगकर्ता को बताता है कि उन्हें ज़्यादा अपडेट करने होंगे. वहीं, फ़ॉर्म सबमिट होने का मैसेज, इस बात की पुष्टि करता है कि उपयोगकर्ता ने सभी गड़बड़ियां ठीक कर ली हैं और फ़ॉर्म सबमिट कर दिया है.
सफलता की अन्य शर्तें
WCAG 2.2 में, सक्सेस क्राइटेरिया के तौर पर ये शर्तें शामिल की गई हैं. इनका मकसद, ऐक्सेस किए जा सकने वाले बेहतर फ़ॉर्म अनुभवों पर फ़ोकस करना है:
देखें कि आपको क्या समझ आया
ऐक्सेस किए जा सकने वाले फ़ॉर्म के बारे में अपनी जानकारी की जांच करें
इनमें से कौनसा फ़ॉर्म इनपुट सबसे ज़्यादा ऐक्सेस किया जा सकता है?
<label>Email address: <input type="email" required></label>
<label>Email address (required): <input type="email" required aria-describedby="email-validation"> <span id="email-validation" class="validation-message">Please provide a valid email address using the format name@place.com</span></label>
<label>Email address: <input type="email" required autocomplete="email"></label>
Email address: <input type="email" required>