कम माँगें, और अनुरोध समझाएँ
उपयोगकर्ता के तत्काल कार्य से शुरू करें, फिर केवल वही डेटा माँगें जो उसे पूरा करने के लिए जरूरी हो। न्यूज़लेटर के लिए ईमेल का पर्याप्त होना आम है; शिपिंग के लिए पता चाहिए। इन्हें स्वत: ही जन्मतिथि, नौकरी का शीर्षक, या बंडल मार्केटिंग सहमति की आवश्यकता नहीं है। पहले परिणाम के लिए अतिरिक्त प्रश्नों को टालें जब तक वे आवश्यक न हों।
फॉर्म पर बताएं कि डेटा किसे प्राप्त होगा और प्रयोजन क्या है, साथ में पूर्ण प्राइवेसी नोटिस का आसान लिंक दें। UK GDPR के दायरे में आने वाली संस्थाओं पर पारदर्शिता कर्तव्य होते हैं जिनमें प्रयोजन और रिटेंशन सहित संदर्भ-निर्भर जानकारी शामिल है। यह सार्वभौमिक कानूनी सलाह नहीं है: अपने बाजारों के लिए संग्रह और नोटिस कॉपी को उपयुक्त समीक्षकों से अनुमोदन कराएँ।
सबमिशन से पहले आवश्यक फ़ील्ड और असामान्य फॉर्मैट घोषित करें; सिर्फ़ स्टार (*) या रंग पर्याप्त नहीं है।
ऑप्शनल मार्केटिंग सहमति को उस क्रिया से अलग रखें जो ऑर्डर, अनुरोध, या अकाउंट टास्क सबमिट करने के लिए आवश्यक है।
लेबल और मूल कंट्रोल काम करने दें
हर फ़ील्ड, चेकबॉक्स, रेडियो ग्रुप, सिलेक्ट और बटन को उसका उद्देश्य बताए ऐसा नाम चाहिए। कंट्रोल से जुड़े एक दृश्य लेबल का प्रयोग करें, आमतौर पर एक label एलिमेंट के माध्यम से जिसकी for वैल्यू input id से मेल खाती है। इससे लेबल का सक्रिय क्षेत्र बड़ा होता है और सहायक तकनीक सही कंट्रोल की पहचान कर पाती है। लेबल को इनपुट के पास रखें।
Hint टेक्स्ट फ़ील्ड का नाम नहीं है। इसे एकमात्र निर्देश न बनाएं जो टाइप करते ही गायब हो जाए। यदि दृश्य संदर्भ लेबल को अनावश्यक बनाता है, तो कोड में एक एक्सेसिबल नाम रखें और उसे टेस्ट करें। W3C नोट करता है कि title टेक्स्ट प्राथमिक लेबल के रूप में कम भरोसेमंद है।
जब अनुकूल हो तो generic टेक्स्ट फ़ील्ड की नकल करने के बजाय email, tel, date, radio, checkbox, या select का उपयोग करें।
Submit की जगह Create account या Place order जैसे एक्शन लेबल का उपयोग करें जब वह स्पष्ट हो।
सुधार के लिए सत्यापित करें, फिर सर्वर पर नियम लागू करें
स्थिर चेक्स के लिए मूल (native) constraints का उपयोग करें: सही input type, required, length, range, और उपयुक्त pattern। एक उपयोगी फॉर्मैट उदाहरण त्रुटि बनने से पहले दें। क्लाइंट चेक्स रिकवरी में सुधार करते हैं पर वे सुरक्षा सीमा नहीं हैं। अनुरोध इन्हें बायपास कर सकते हैं, इसलिए सर्वर पर प्रासंगिक सिंटैक्स और व्यवसाय नियम प्रोसेसिंग से पहले सत्यापित करें।
जब सबमिशन असफल हो, तो स्वीकृत मान बनाए रखें। फॉर्म से पहले एक एरर समरी रखें, हर फ़ील्ड की पहचान करें, समस्या और सुधार समझाएँ, और उस पर लिंक दें। फ़ील्ड के बगल में संक्षिप्त संदेश दोहराएँ। इसे कंट्रोल से संबद्ध करें, जहाँ उपयुक्त हो invalid state बताएं, और पहले त्रुटि या समरी पर फोकस को पूर्वानुमेय तरीके से ले जाएँ। सफलता की स्पष्ट पुष्टि करें।
टाइप करते समय केवल तब वैधता जाँचें जब फ़ीडबैक स्थिर और उपयोगी हो—जैसे username availability जैसी स्थितियाँ। मध्य-एंट्री में अनिवार्य रूप से होने वाली फॉर्मैट विफलताओं को अक्सर फील्ड से फोकस हटने पर या सबमिट पर दिखाना बेहतर होता है। स्क्रीन रीडरों के साथ डायनामिक संदेशों का परीक्षण करें; लाइव अपडेट मददगार हो सकते हैं लेकिन लगातार व्यवधान घर्षण है।
सर्वर पर स्वीकार्य तिथियाँ, विकल्प, लंबाइयां, और फॉर्मैट परिभाषित करें। संदिग्ध वर्णों की denylist प्राथमिक नियंत्रण के रूप में भरोसेमंद नहीं है।
टाइमआउट या डुप्लिकेट सबमिट के लिए बताएं कि अनुरोध प्राप्त हुआ था या नहीं और सुरक्षित अगला कदम क्या है।
ब्राउज़र ऑटोफ़िल और मोबाइल एंट्री का समर्थन करें
डाटा का वर्णन करने वाले विशिष्ट autocomplete टोकन जोड़ें: given-name, family-name, email, tel, shipping street-address, billing postal-code, username, और new-password सामान्य उदाहरण हैं। ये टोकन ब्राउज़र और पासवर्ड मैनेजर को समान फ़ील्ड्स अलग करने में मदद करते हैं। ऑटोफ़िल सहायता है, वादा नहीं; व्यवहार भिन्न होता है और यह एक उपयोगी फॉर्म, name या id, और एक सबमिट कंट्रोल पर निर्भर कर सकता है।
ऐसा input type उपयोग करें जो उपयुक्त मोबाइल कीबोर्ड और बेसिक ब्राउज़र वैलिडेशन दे सके। पासवर्ड फ़ील्ड में पेस्ट ब्लॉक न करें और पासवर्ड मैनेजर obstruct न करें। आधुनिक ब्राउज़र लॉगिन फ़ॉर्म पर autocomplete off होने पर भी क्रेडेंशियल भरने का विकल्प दे सकते हैं, इसलिए अपने दर्शकों वाले ब्राउज़रों में वास्तविक जर्नीज़ का परीक्षण करें।
एक ही पेज पर बिलिंग और शिपिंग के लिए corresponding grouping टोकन का उपयोग करें ताकि समान फ़ील्ड्स भ्रमित न हों।
सुनिश्चित करें कि लेबल दिखाई देते रहें और स्क्रिप्ट ब्राउज़र-भरे मानों को खाली मान न समझें।
कीबोर्ड से पूरा होने योग्य पथ बनाएं
एक व्यक्ति को पॉइन्टर के बिना फॉर्म पूरा करने में सक्षम होना चाहिए। कीबोर्ड ऑपरेशन स्पीच इनपुट और अन्य सहायक तकनीकों का भी समर्थन करता है जो कीस्ट्रोक उत्पन्न करते हैं। फॉर्म से पहले से लेकर बाद तक Tab करें: क्रम कार्य का पालन करें, फोकस दिखाई देना चाहिए, और कोई भी कंट्रोल, डायलॉग, डेट पिकर, त्रुटि लिंक, या हेल्प पैनल फोकस को ट्रैप नहीं कर सकता।
मूल कंट्रोल इसका बहुत कुछ प्रदान करते हैं। कस्टम ड्रॉपडाउन, मास्क्ड डेट्स, पता लुकअप, CAPTCHA वैकल्पिक, और मॉडलों को जानबूझकर कीबोर्ड व्यवहार, फोकस मैनेजमेंट और एक्सेसिबल नामों की आवश्यकता होती है। यदि कोई कस्टम कम्पोनेंट उपयोगी नेटीव विकल्प के बराबर नहीं कर पा रहा, तो उसे सरल बनाएं। संकरे चौड़ाई और अधिक ज़ूम पर परीक्षण करें।
सामान्य, त्रुटि, और कंडीशनल फ्लोज़ को पूरा करने के लिए Tab, Shift+Tab, Enter, Space, Escape, और संबंधित एरो कीज़ का उपयोग करें।
गार्डरेल और रोलबैक के साथ सुधार रिलीज़ करें
किसी मूल्यवान फॉर्म को बदलने से पहले कन्फर्म्ड सबमिशन्स, फ़ील्ड-श्रेणी के अनुसार त्रुटियाँ, तकनीकी विफलताएँ, और पूरा होने का समय का बेसलाइन रिकॉर्ड करें। मेट्रिक सुधारने के लिए केवल कच्चे मान इकट्ठा या रीक प्ले न करें—सेंसेटिव डेटा की सुरक्षा बनाए रखें। एग्रीगेट सिग्नल्स को एक्सेसिबिलिटी और कीबोर्ड जांच के साथ पेयर करें, क्योंकि एक ही दर अक्सर यह नहीं बताती कि लोग क्यों संघर्ष कर रहे थे।
जहाँ व्यावहारिक हो एक समय में एक ही महत्वपूर्ण बदलाव रिलीज़ करें—जैसे लेबल शब्दावली, हटाया गया ऑप्शनल फ़ील्ड, या बेहतर रिकवरी। परीक्षण से पहले गार्डरेल परिभाषित करें: भुगतान प्राधिकरण त्रुटियाँ, सपोर्ट संपर्क, या एक्सेसिबिलिटी रिग्रेशन प्रासंगिक हो सकते हैं। प्रोडक्शन कॉन्फ़िगरेशन का सुरक्षित अकाउंट्स और भुगतान टेस्ट वातावरण के साथ परीक्षण करें। भुगतान स्क्रिप्ट, डेटा हैंडलिंग, और अनुपालन के लिए योग्य सुरक्षा, पेमेंट्स, और कानूनी समीक्षक आवश्यक हैं; यह लेख अनुपालन प्रमाणित नहीं करता।
SIU इस प्रक्रिया को लॉन्च प्रीफ्लाइट के माध्यम से सुरक्षित बनाता है: निर्भरताएँ, क्लाइंट व्यवहार, सर्वर प्रतिक्रियाएँ, पुष्टिकरण, और रोलबैक की पुष्टि करें। यह प्रैक्टिक्टिव रीमेडिएशन है, टीम के लाइव-स्टेटस या आउटेज मॉनिटरिंग प्रोसेस का विकल्प नहीं।
मिसिंग और मॉलफॉर्म्ड मान, एक्सपायर्ड सेशन, धीमे जवाब, असफल लुकअप, और अंतिम क्रिया पर डबल क्लिक का उपयोग करें।
पहले कॉन्फ़िगरेशन, एक ओनर, और एक्सपोज़र बढ़ने से पहले एक उल्टनीय डिप्लॉयमेंट स्टेप तैयार रखें।