फॉर्म सत्यापन

docs.scrimba.com

एक फॉर्म लोगों से इनपुट एकत्र करता है, और लोग फ़ील्ड खाली छोड़ देते हैं, ईमेल में गलती करते हैं, या जहाँ संख्या होनी चाहिए वहाँ अक्षर डालते हैं। आप नहीं चाहते कि वह डेटा आपके कोड तक अछूता रहे। कुछ भी जमा करने से पहले, ब्राउज़र बहुत कुछ आपके लिए जांच सकता है, लेकिन केवल तभी जब आप बताएँ कि प्रत्येक फ़ील्ड क्या उम्मीद करता है। वह विवरण सीधे आपके HTML में लिखा जाता है, और यह अध्याय इसे कैसे लिखें इसके बारे में है।

आवश्यक फ़ील्ड और इनपुट प्रकार

दो सबसे सस्ते चेक जो आप जोड़ सकते हैं वह कह रहे हैं कि एक फ़ील्ड बिल्कुल भरा होना चाहिए, और कह रहे हैं कि किस प्रकार का मान इसमें संबंधित है।

एक इनपुट में शब्द required जोड़ें और ब्राउज़र उस फ़ील्ड में कुछ न होने तक फॉर्म जमा करने से इनकार करता है। इसे होने के लिए आपको कोई कोड नहीं लिखना है। विशेषता ही निर्देश है।

<input type="text" name="full_name" required>

दूसरी आधी type विशेषता है। यह ब्राउज़र को बताता है कि मान किस रूप का होना चाहिए, और ब्राउज़र इसे आपके लिए जांचता है। type="email" का उपयोग करें और ब्राउज़र सुनिश्चित करता है कि मान ईमेल पते जैसा दिखता है। type="number" का उपयोग करें और यह केवल संख्याएँ स्वीकार करता है। तारीखों के लिए एक प्रकार है, वेब पतों के लिए एक, और अधिक हैं।

इसे डॉक्टर के कार्यालय में एक फॉर्म की तरह सोचें जहाँ कुछ बॉक्स "अवश्य भरें" के रूप में चिह्नित हैं और दिनांक बॉक्स में पहले से ही दिन, महीने और वर्ष के लिए छोटे स्लॉट हैं। कागज आपको बता रहा है कि आप कहीं भी कुछ न लिखने से पहले कहाँ क्या जाता है।

required एक बूलियन विशेषता है: इसकी मौजूदगी अकेली नियम को चालू करती है, और इसका कोई मान नहीं लेता। required के रूप में चिह्नित एक नियंत्रण खाली होते हुए फॉर्म जमा करने को अवरुद्ध करता है।

type विशेषता दोहरी कर्तव्य करती है। यह ब्राउज़र द्वारा प्रस्तुत किए जाने वाले नियंत्रण (एक दिनांक चुनने वाला, एक संख्या स्पिनर) को चुनता है और यह मान पर एक अंतर्निहित बाधा सेट करता है:

• type="email" एक @ और एक डोमेन-आकार की पूँछ की आवश्यकता है।
• type="url" कुछ ऐसा आवश्यक है जो एक निरपेक्ष वेब पते के रूप में पार्स हो।
• type="number" केवल संख्यात्मक इनपुट स्वीकार करता है और min, max, और step को अनलॉक करता है।
• type="tel" मान को बाधित नहीं करता है, लेकिन यह मोबाइल पर एक फोन कीपैड लाता है।

किसी अन्य चीज़ से पहले विशिष्ट प्रकार की ओर झुकें। यह सबसे अधिक जाँच के लिए कम से कम कोड है, और यह स्पर्श उपकरणों पर लोगों को मिलने वाले ऑन-स्क्रीन कीबोर्ड में सुधार करता है।

required और type वह हैं जो प्लेटफॉर्म बाधा सत्यापन कहता है उसकी पहली दो परतें: आपके द्वारा घोषित किए गए नियमों के विरुद्ध एक नियंत्रण के मान की जाँच करने की ब्राउज़र की अंतर्निहित प्रणाली। required "मान लुप्त" नियम सेट करता है। type उस प्रकार से जुड़ा एक प्रारूप नियम सेट करता है।

type पर दो उत्पादन नोट। पहला, type="email" पूर्ण ईमेल विनिर्देश के विरुद्ध सत्यापन नहीं करता है। ब्राउज़र जानबूझकर अनुमतिवादी पैटर्न का उपयोग करते हैं (वर्णों का एक रन, एक @, फिर एक डॉट-अलग डोमेन) क्योंकि सख्त जाँच उन पतों को अस्वीकार करेगी जो वास्तव में वितरण योग्य हैं। इसे आकार जाँच के रूप में व्यवहार करें, पते के अस्तित्व का प्रमाण नहीं। दूसरा, एक अज्ञात या असमर्थित type type="text" पर वापस आता है, इसलिए एक फ़ील्ड कभी पुराने ब्राउज़र पर अनुपयोगी नहीं बनता है, यह केवल अतिरिक्त जाँच खो देता है। वह सुंदर पतन है कि आप हाथ में संगतता तालिका के बिना नए प्रकारों को अपना सकते हैं।

यह प्रकार ऑन-स्क्रीन कीबोर्ड को भी चलाता है और, संबंधित inputmode विशेषता के माध्यम से (कौन सा कीबोर्ड लेआउट दिखाना है इसके लिए एक संकेत, सत्यापन बदले बिना), आप उस कीबोर्ड को स्वतंत्र रूप से ट्यून कर सकते हैं। प्रकार को सही तरीके से प्राप्त करना एक पहुँच क्षमता और एर्गोनोमिक्स निर्णय है जितना कि एक सत्यापन निर्णय।

यहाँ दोनों विशेषताओं का उपयोग करने वाला एक छोटा साइन-अप फॉर्म है:

<form>
  <label>
    ईमेल पता
    <input type="email" name="email" required>
  </label>
  <label>
    वेबसाइट
    <input type="url" name="website">
  </label>
  <button>साइन अप करें</button>
</form>

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

Junoआवश्यक फ़ील्ड और इनपुट प्रकार दो छोटे शब्द यहाँ बहुत काम करते हैं। एक फ़ील्ड पर required रखें और ब्राउज़र खाली को नहीं जाने देगा। type सेट करें, जैसे email या number, और यह जाँचता है कि मान सही आकार है। जो प्रकार फ़ील्ड से मेल खाता है उसे चुनें और आपको मुफ्त में जाँच मिलती है।

Junoआवश्यक फ़ील्ड और इनपुट प्रकारrequired एक बूलियन विशेषता है: यह या तो है या नहीं है, कोई मान आवश्यक नहीं है। type नियंत्रण को चुनता है और एक प्रारूप नियम सेट करता है, तो type="email" एक @ और एक डोमेन चाहता है। हमेशा सबसे विशिष्ट प्रकार के साथ शुरू करें; यह सबसे अधिक जाँच के लिए सबसे छोटा मार्कअप है, और मोबाइल कीबोर्ड भी बेहतर हो जाते हैं।

Junoआवश्यक फ़ील्ड और इनपुट प्रकार ये बाधा सत्यापन की पहली दो परतें हैं, ब्राउज़र की अंतर्निहित नियम जांचक। याद रखने योग्य: type="email" एक ढीली आकार जाँच है, यह प्रमाण नहीं है कि पता वास्तविक है, और एक असमर्थित प्रकार शांति से text पर वापस आता है टूटने के बजाय। प्रकार को चुनना एक पहुँच क्षमता कॉल भी है, क्योंकि यह लोगों को मिलने वाले ऑन-स्क्रीन कीबोर्ड को सेट करता है।

बाधा विशेषताएँ

"भरा हुआ" और "सही प्रकार" से परे, आप अक्सर सीमाएँ चाहते हैं: कम से कम इतना लंबा एक मान, इतनी बड़ी संख्या नहीं, एक सेट प्रारूप में एक कोड। एक मुट्ठी विशेषताएँ इसे कवर करती हैं।

आप सीमित कर सकते हैं कि एक फ़ील्ड क्या स्वीकार करता है। शुरू करने के लिए दो उपयोगी:

<input type="text" name="username" maxlength="20">
<input type="number" name="quantity" min="1" max="10">

maxlength="20" फ़ील्ड को बीस वर्णों पकड़ने के बाद रोक देता है। min और max अनुमत सबसे छोटी और सबसे बड़ी संख्याएँ सेट करते हैं। ब्राउज़र लोगों को इन सीमाओं के भीतर रखता है ताकि आपको उनकी जाँच स्वयं न करनी पड़े।

बाधा विशेषताओं का एक छोटा सेट है, और प्रत्येक एक नियम से मेल खाता है:

• minlength / maxlength टेक्स्ट मान में सबसे कम और सबसे अधिक वर्ण सेट करते हैं।
• min / max संख्या और तारीखों के लिए सबसे कम और सबसे अधिक मान सेट करते हैं।
• step एक संख्या के लिए अनुमत वृद्धि सेट करता है, इसलिए step="5" 0, 5, 10 स्वीकार करता है, और 3 अस्वीकार करता है।
• pattern एक नियमित अभिव्यक्ति (अनुमत पाठ के सटीक आकार का वर्णन करने के लिए एक कॉम्पैक्ट संकेतन) रखता है जिससे मान पूरी तरह मेल खाना चाहिए।

<input type="text" name="username" minlength="3" maxlength="20" required>
<input type="number" name="quantity" min="1" max="10" step="1">
<input type="text" name="pin" pattern="[0-9]{4}" title="चार अंक">

pattern को title के साथ जोड़ी: कुछ ब्राउज़र इसका पाठ त्रुटि संदेश में दिखाते हैं, और यह सचेत उपयोगकर्ताओं को बताता है कि फ़ील्ड क्या उम्मीद करता है। CSS में, :valid और :invalid आपको एक नियंत्रण को स्टाइल करने देते हैं कि क्या यह वर्तमान में अपनी बाधाओं को पारित करता है।

प्रत्येक बाधा विशेषता एक झंडे से मेल खाती है जो ब्राउज़र एक नियंत्रण के बारे में उठा सकता है, जो एक बार आप JavaScript से सत्यापन स्थिति पढ़ते हैं तो महत्वपूर्ण हो जाता है। min का उल्लंघन "रेंज अंडरफ्लो" उठाता है, maxlength पार करना "बहुत लंबा" उठाता है, pattern बेमेल "पैटर्न बेमेल" उठाता है, इत्यादि। विशेषता घोषणा है; झंडा यह है कि परिणाम की रिपोर्ट कैसे की जाती है।

दो विवरण जो लोगों को भ्रमित करते हैं। pattern निहित रूप से लंगर किया जाता है: अभिव्यक्ति को पूरे मान से मेल खाना चाहिए, जैसे कि यह शुरुआत से अंत तक कवर करने के लिए लपेटा गया हो, इसलिए pattern="[0-9]{4}" का अर्थ है ठीक चार अंक, "कहीं चार अंक युक्त" नहीं। और step को एक आधार (the min, या शून्य अगर कोई नहीं है) से फ़्लोटिंग-पॉइंट अंकगणित का उपयोग करके मापा जाता है, इसलिए step="0.1" एक मान को अस्वीकार कर सकता है जिसे आप पास करने की उम्मीद करते हैं क्योंकि बाइनरी दशमलव का प्रतिनिधित्व कैसे करता है; जब परिशुद्धता महत्वपूर्ण हो तो एक स्पष्ट min को आधार के रूप में सेट करें।

:valid और :invalid pseudo-classes (CSS चयनकर्ता जो किसी तत्व के स्थान के बजाय इसकी स्थिति के आधार पर इसे मेल खाते हैं) उपयोगी लेकिन कुंद हैं: एक खाली required फ़ील्ड पहली पेंट से :invalid से मेल खाता है, इसलिए इसे लाल रंग से स्टाइल करना उपयोगकर्ता को कुछ भी टाइप करने से पहले त्रुटियों के साथ अभिनंदित करता है। सुधार :user-invalid है, जो केवल व्यक्ति के फ़ील्ड के साथ इंटरैक्ट करने के बाद से मेल खाता है, इसलिए प्रतिक्रिया तब आती है जब यह उपयोगी हो ना कि आगमन पर।

वह नियम जो सबसे अधिक भ्रम को बचाता है: एक pattern को पूरे मान से मेल खाना चाहिए, केवल इसके एक हिस्से से नहीं।

<input
  type="text"
  name="product_code"
  pattern="[A-Z]{2}-[0-9]{3}"
  title="दो अक्षर, एक हाइफन, तीन अंक, उदा. AB-123"
  required
>

Junoबाधा विशेषताएँ एक बार जब कोई फ़ील्ड आवश्यक और टाइप किया जाता है, तो आप सीमाएँ जोड़ सकते हैं। maxlength कितने वर्ण जाते हैं इसे कैप करता है, और min और max एक संख्या को घेरते हैं। ब्राउज़र लोगों को उन सीमाओं के भीतर स्वचालित रूप से रखता है, जो बहुत सी जाँच है जो आपको कभी लिखना नहीं पड़ता।

Junoबाधा विशेषताएँ सेट छोटा है: टेक्स्ट के लिए minlength/maxlength, संख्या और तारीखों के लिए min/max, वृद्धि के लिए step, और सटीक आकार के लिए pattern। pattern को title दें ताकि संदेश कुछ मायने रखता हो। और pattern पूरे मान से मेल खाता है, इसलिए [0-9]{4} कुल चार अंक है, कहीं चार अंक नहीं।

Junoबाधा विशेषताएँ प्रत्येक विशेषता एक वैधता झंडे से मेल खाती है जिसे आप बाद में पढ़ सकते हैं, इसलिए मार्कअप और रिपोर्टिंग एक दूसरे से मेल खाते हैं। दो समस्याएँ: pattern अंत से अंत तक लंगर किया जाता है, और step एक आधार से फ्लोटिंग-पॉइंट गणित का उपयोग करता है, इसलिए जब परिशुद्धता गिनती हो तो स्पष्ट min सेट करें। :invalid नहीं :user-invalid से स्टाइल करें, या आप किसी को कुछ भी टाइप करने से पहले एक अछूते फ़ील्ड को लाल रंग से पेंट करेंगे।

मूल सत्यापन प्रतिक्रिया

नियमों को घोषित करना कहानी का आधा हिस्सा है। दूसरा आधा वह है जो व्यक्ति को एक मान तोड़ने पर दिखता है।

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

तो एक required ईमेल फ़ील्ड खाली छोड़ दिया गया "कृपया इस फ़ील्ड को भरें" जैसा कुछ उत्पन्न करता है, और फॉर्म तब तक भेजा नहीं जाता जब तक इसे ठीक न किया जाए।

सबमिट पर सत्यापन होता है। ब्राउज़र नियंत्रणों के माध्यम से चलता है, पहला अमान्य खोजता है, इसे ध्यान केंद्रित करता है, और समस्या का वर्णन करने वाला एक छोटा संदेश बुलबुला दिखाता है। यदि सब कुछ पास हो जाता है, तो फॉर्म सामान्य रूप से जमा हो जाता है।

आपको CSS के माध्यम से कुछ स्टाइलिंग नियंत्रण मिलता है। :required, :valid, :invalid, और :in-range आपको फ़ील्ड को दृष्टि से चिह्नित करने देते हैं। जो आप आसानी से रीस्टाइल नहीं कर सकते वह संदेश बुलबुला ही है, इसका रूप ब्राउज़र का है, आपका नहीं। आप novalidate विशेषता के साथ एक फॉर्म के लिए पूरी प्रणाली को भी बंद कर सकते हैं, जो तब उपयोगी होता है जब आप पूरी तरह से JavaScript में सत्यापन करने का इरादा रखते हैं।

input:user-invalid {
  border-color: #c0392b;
}
input:user-valid {
  border-color: #2d7a3f;
}

मूल प्रतिक्रिया सुविधाजनक है और लगभग मुफ्त है, और यह उन सीमाओं के साथ आती है जो योजना के योग्य हैं इससे पहले कि आप इसे एक शिप किए गए उत्पाद में पर ऐतबार करें।

संदेश बुलबुला एक क्षणभंगुर तत्व है: यह सबमिट पर दिखाई देता है, अगली इंटरैक्शन पर गायब हो जाता है, और दस्तावेज़ का हिस्सा नहीं है जिसे आप चुन या स्टाइल कर सकते हैं। स्क्रीन रीडर ब्राउज़र में इसके लिए समर्थन असमान है, इसलिए एक बुलबुला अकेले उस किसी को त्रुटि की घोषणा करने का एक विश्वसनीय तरीका नहीं है जो इसे नहीं देख सकता। इसका पाठ आपके पृष्ठ के lang के लिए नहीं, ब्राउज़र की भाषा में भी स्थानीयकृत है, तो अंग्रेजी में लिखा गया फॉर्म उस आगंतुक को फ्रेंच त्रुटि संदेश दिखा सकता है जिसका ब्राउज़र फ्रेंच पर सेट है। वह उपयोगकर्ता के लिए सही है और विकास कर्ता के लिए आश्चर्य की बात है।

आप जमा किए बिना समान प्रवाह को स्वयं चला सकते हैं: reportValidity() जाँच चलाता है और माँग पर बुलबुले दिखाता है। लेकिन त्वरित प्रोटोटाइप से परे कुछ के लिए, सुलभ पैटर्न मूल बुलबुले को दबाना है (novalidate के साथ) और पृष्ठ में अपना स्वयं की त्रुटि पाठ प्रस्तुत करना है, फ़ील्ड से जुड़ा, तो यह दृश्यमान, शैली योग्य, और विश्वसनीय रूप से घोषित है। अगला अनुभाग कैसे कवर करता है।

Junoमूल सत्यापन प्रतिक्रिया सभी उन विशेषताओं के लिए यह वह भुगतान है: एक बुरी फ़ील्ड के साथ सबमिट दबाएँ और ब्राउज़र एक छोटा संदेश पॉप करता है, आपको फ़ील्ड की ओर संकेत करता है, और भेजने से इनकार करता है। आपने उस पाठ में से कोई नहीं लिखा; ब्राउज़र ने किया, आगंतुक की भाषा में। बहुत से फॉर्मों के लिए, यह सभी प्रतिक्रिया है जो आपको चाहिए।

Junoमूल सत्यापन प्रतिक्रिया जाँच सबमिट पर चलती है: पहली बुरी फ़ील्ड को ध्यान केंद्रित करना और संदेश बुलबुला मिलता है, और फॉर्म इसे पास करने तक रोका जाता है। आप :user-valid और :user-invalid के साथ फ़ील्ड को स्टाइल कर सकते हैं, लेकिन बुलबुला स्वयं ब्राउज़र को डिज़ाइन करने के लिए है। novalidate के साथ पूरी चीज़ को बंद करें जब आप JavaScript में इसे संभालने की योजना बनाते हैं।

Junoमूल सत्यापन प्रतिक्रिया बुलबुला क्षणभंगुर और अस्टाइल योग्य है, इसका स्क्रीन रीडर समर्थन पैची है, और इसका पाठ आपके पृष्ठ की भाषा के बजाय ब्राउज़र की भाषा का अनुसरण करता है। एक प्रोटोटाइप के लिए ठीक है, उत्पादन के लिए पतला है। जब पहुँच क्षमता महत्वपूर्ण हो, तो novalidate जोड़ें और अपना स्वयं की त्रुटि पाठ पृष्ठ में प्रस्तुत करें ताकि इसे देखा, स्टाइल किया जा सके, और सही ढंग से घोषित किया जा सके।

जब आपको अभी भी JavaScript की आवश्यकता है

मूल सत्यापन एक फ़ील्ड को अपने स्वयं के नियमों के विरुद्ध जाँचता है। बहुत सी वास्तविक जाँचें उस आकार में फिट नहीं होती हैं, और वह है जहाँ JavaScript आते हैं।

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

यह HTML की विफलता नहीं है। अंतर्निहित जाँचें कोई कोड के साथ सामान्य मामलों को संभालती हैं, और JavaScript बाकी को संभालती है।

अंतराल एक से अधिक फ़ील्ड पर निर्भर कुछ भी है, या पृष्ठ के पास अभी तक की जानकारी पर। एक सामान्य उदाहरण दो पासवर्डों के मेल की पुष्टि कर रहा है। आप उनकी तुलना JavaScript में करते हैं और setCustomValidity के साथ परिणाम को मूल प्रणाली में वापस खिलाते हैं, जो एक नियंत्रण पर एक कस्टम त्रुटि संदेश सेट करता है (एक खाली स्ट्रिंग का अर्थ है "यह मान्य है"):

<input type="password" id="password" name="password" required>
<input type="password" id="confirm" name="confirm" required>

तुलना स्वयं एक <script> में चलती है:

const password = document.querySelector("#password")
const confirm = document.querySelector("#confirm")

confirm.addEventListener("input", () => {
  // खाली स्ट्रिंग त्रुटि को साफ करती है और फ़ील्ड को वैध चिह्नित करती है
  const message = confirm.value === password.value ? "" : "पासवर्ड मेल नहीं खाते"
  confirm.setCustomValidity(message)
})

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

JavaScript बाधा सत्यापन API के माध्यम से मूल सत्यापन तक पहुँचता है (फॉर्म नियंत्रणों पर ब्राउज़र उजागर करने वाले संपत्तियों और विधियों का सेट वैधता पढ़ने और सेट करने के लिए)। टुकड़े जो आप सबसे अधिक उपयोग करते हैं:

• setCustomValidity(message) एक नियंत्रण पर एक कस्टम त्रुटि स्ट्रिंग सेट करता है। एक गैर-खाली स्ट्रिंग इसे अमान्य चिह्नित करती है और इसका संदेश बन जाती है; एक खाली स्ट्रिंग कस्टम त्रुटि को साफ करती है।
• validity एक पढ़ने के लिए ValidityState वस्तु है: एक प्रत्येक संभावित विफलता के लिए बूलियन (valueMissing, typeMismatch, patternMismatch, rangeOverflow, tooLong, customError, और इसी तरह), साथ ही समग्र परिणाम के लिए valid। इसे पढ़ें यह पता लगाने के लिए कि एक फ़ील्ड क्यों विफल हुआ, केवल कि यह विफल हुआ नहीं।
• checkValidity() सच या गलत लौटाता है कुछ भी दिखाए बिना; reportValidity() वही करता है और मूल बुलबुले प्रदर्शित करता है।

सुलभ त्रुटियों के लिए, रंग अपने आप कभी पर्याप्त नहीं है: एक लाल सीमा एक स्क्रीन रीडर को कुछ भी नहीं कहती है या जो लाल को हरे से अलग नहीं कर सकते। त्रुटि पाठ को अपनी फ़ील्ड के साथ जोड़ें ताकि सहायक तकनीक उन्हें एक साथ पढ़े। इनपुट पर aria-describedby को त्रुटि तत्व के id पर सेट करें (यह एक स्क्रीन रीडर को बताता है "इस पाठ को फ़ील्ड के विवरण के रूप में पढ़ें"), और aria-invalid="true" सेट करें जबकि फ़ील्ड विफल हो रहा है (यह फ़ील्ड को त्रुटि स्थिति में होने की घोषणा करता है):

<input
  type="text"
  id="username"
  name="username"
  aria-describedby="username-error"
  aria-invalid="true"
  required
>
<p id="username-error" role="alert">वह उपयोगकर्ता नाम पहले से ले लिया गया है।</p>

role="alert" एक स्क्रीन रीडर को संदेश की घोषणा करने के लिए बनाता है जैसे ही यह दिखाई देता है। पहुँच क्षमता अध्याय नियंत्रणों को उनके विवरणों के साथ जोड़ने पर गहराई से जाता है।

यह ट्रेड-ऑफ को छोड़ देता है। मूल सत्यापन कम कोड है, प्लेटफॉर्म के साथ सुसंगत है, और आपकी स्क्रिप्ट लोड होने से पहले काम करता है, लेकिन इसकी प्रतिक्रिया को स्टाइल और घोषित करना कठिन है। कस्टम सत्यापन अधिक कोड है और अधिक दायित्व है, लेकिन शब्दावली, समय और पहुँच क्षमता पर पूर्ण नियंत्रण देता है। अधिकांश उत्पादन फॉर्म दोनों का उपयोग करते हैं: अंतर्निहित विशेषताएँ आधार के रूप में, JavaScript स्तरित उन जाँचों और मेसेजिंग विशेषताओं तक नहीं पहुँच सकते।

कोई फर्क नहीं पड़ता कि आप क्या चुनते हैं, एक नियम नहीं झुकता है। ग्राहक सत्यापन एक सुविधा है, कभी एक गारंटी नहीं। इस अध्याय में वर्णित सब कुछ आगंतुक के ब्राउज़र में चलता है, जहाँ कोई भी इसे बंद कर सकता है, पृष्ठ को संपादित कर सकता है, या फॉर्म को छूए बिना सीधे आपके सर्वर को अनुरोध भेज सकता है। सर्वर को हर मान को फिर से सत्यापन करना चाहिए जो यह प्राप्त करता है जैसे कि कोई ब्राउज़र जाँच कभी नहीं हुई। ब्राउज़र की जाँचों को एक तेज़, अनुकूल पहला पास के रूप में व्यवहार करें जो आपके उपयोगकर्ताओं को एक गोल ट्रिप बचाता है, और सर्वर को उस जाँच के रूप में व्यवहार करें जो वास्तव में आपके डेटा की रक्षा करता है।

Junoजब आपको अभी भी JavaScript की आवश्यकता है अंतर्निहित जाँचें एक बार में एक फ़ील्ड को कवर करती हैं, इसलिए फ़ील्ड की तुलना, जैसे "क्या ये दो पासवर्ड मेल खाते हैं", या सर्वर के साथ जाँच, जैसे "क्या यह उपयोगकर्ता नाम मुफ्त है", को JavaScript की आवश्यकता है। वह सामान्य है। HTML हर रोज़ के मामलों को मुफ्त में संभालता है, और JavaScript जो अपने आप नहीं देख सकता उसे उठाता है।

Junoजब आपको अभी भी JavaScript की आवश्यकता है जब कोई जाँच दो फ़ील्ड पर फैली हो या सर्वर की आवश्यकता हो, तो इसे JavaScript में परिकलित करें और setCustomValidity के साथ परिणाम को वापस भेजें: विफल करने के लिए संदेश स्ट्रिंग, इसे साफ करने के लिए खाली स्ट्रिंग। फ़ील्ड तब किसी अन्य की तरह मूल सत्यापन में शामिल हो जाता है। पासवर्ड मेल और उपयोगकर्ता नाम उपलब्धता क्लासिक दो हैं।

Junoजब आपको अभी भी JavaScript की आवश्यकता है बाधा सत्यापन API आपका हुक है: setCustomValidity एक संदेश सेट करने के लिए, validity यह पढ़ने के लिए कि एक फ़ील्ड क्यों विफल हुआ, checkValidity और reportValidity जाँच चलाने के लिए। सुलभ त्रुटियों के लिए, पाठ को aria-describedby और aria-invalid के साथ फ़ील्ड से जोड़ें, कभी अकेले रंग नहीं। और जो वैकल्पिक नहीं है: यहाँ हर जाँच ब्राउज़र में चलती है, तो सर्वर को सभी का फिर से सत्यापन करना है।