डिज़ाइन/आर्किटेक्चर
वेब-27
वेब-27: सभी एजेंसियां कॉमनवेल्थ बैनर को बिना किसी बदलाव के और COV डिज़ाइन सिस्टम के अनुसार दिखाएँगी।
वेब को समझना-27
कॉमनवेल्थ ब्रांडिंग बार नागरिकों को वर्जीनिया के कॉमनवेल्थ में सरकारी संगठनों की आधिकारिक वेबसाइटों की पहचान करने में मदद करता है। यह विज़िटर को यह समझने में भी मदद करता है कि जिस साइट पर वे हैं वह आधिकारिक और सुरक्षित है। नया ब्रांडिंग बार वेबसाइट विज़िटर के लिए एक नेविगेशन पोर्टल के रूप में भी काम करता है, ताकि वे आसानी से सरकारी एजेंसियों के बीच नेविगेट कर सकें और राष्ट्रमंडल भर में जानकारी खोज सकें, बिना Virginia.gov पर वापस नेविगेट किए।
ब्रांडिंग बार इंस्टॉल करना आसान है, और एजेंसियों द्वारा गेट द कॉमनवेल्थ ब्रांडिंग बार के तहत अपनी वेबसाइट पर डालने के लिए निर्देश और कोड पाए जा सकते हैं। यह पेज किसी एजेंसी की वेबसाइट के हेड टैग में रखने के लिए कोड जनरेट करने के लिए चरण-दर-चरण निर्देश देता है। एजेंसियों के पास ग्रे और सफ़ेद ब्रांडिंग बार में से किसी एक को चुनने का विकल्प भी होता है, जो उनकी वेबसाइटों की कलर थीम के हिसाब से बेहतर है।
जेनरेट किए गए हर ब्रांडिंग बार में शामिल होता है:
- वर्जिनिया राज्य का लोगो
- एजेंसी या वर्जीनिया की सरकारी संस्था का नाम, जिसके जनरेटर को यह नाम पूरा बताना होगा
- एक बायलाइन जिसमें लिखा है, “वर्जीनिया कॉमनवेल्थ की आधिकारिक वेबसाइट” और ड्रॉप डाउन जिसमें लिखा है कि “आपको इस तरह पता है।”
- ड्रॉप डाउन में कॉमनवेल्थ ऑफ़ वर्जीनिया लोगो और HTTPS सर्टिफ़िकेट के बारे में जानकारी शामिल है।
- “फ़ाइंड अ कॉमनवेल्थ रिसोर्स” लेबल वाला एक सबमेनू, जिस पर क्लिक करने पर यूज़र वर्जीनिया एजेंसियों या सरकारी संस्थाओं में खोज कर सकते हैं, साथ ही आमतौर पर इस्तेमाल की जाने वाली कॉमनवेल्थ सेवाओं और संसाधनों को एजेंसी के सेवा क्षेत्र के अनुसार क्रमबद्ध किया जाता है।
जेनरेट किए गए कोड को वैसे ही इस्तेमाल किया जाना चाहिए और इसे किसी भी तरह से बदला नहीं जाना चाहिए। इंस्टॉलेशन से जुड़ी किसी भी समस्या को ईमेल करके वीटा की एंटरप्राइज़ वेब सेवा टीम को भेजा जाना चाहिए। जेनरेट किए गए कोड को वैसे ही इस्तेमाल किया जाना चाहिए और इसे किसी भी तरह से बदला नहीं जाना चाहिए। इंस्टॉलेशन से जुड़ी किसी भी समस्या को developer@vita.virginia.gov पर ईमेल करके वीटा की एंटरप्राइज़ वेब सेवा टीम को भेजा जाना चाहिए।
वेब-28
वेब-28: COV वेब सिस्टम में एजेंसी की साइट का खोज बॉक्स दिया जाएगा, जो हर पेज पर दिखेगा और उसे COV डिज़ाइन सिस्टम के निर्देशों के अनुसार दिखाया जाएगा।
वेब को समझना-28
एजेंसी की हर वेबसाइट और पेज पर एक एजेंसी-व्यापी साइट सर्च बॉक्स होने से यूज़र प्रासंगिक कीवर्ड और खोज शब्द टाइप करके जानकारी को तेज़ी से ऐक्सेस कर सकते हैं, जो उन्हें प्रासंगिक लिंक की सूची तक ले जाते हैं। यूज़र को ज़रूरी जानकारी देने के लिए कोई एजेंसी सिर्फ़ प्राथमिक या द्वितीयक नेविगेशन पर निर्भर नहीं हो सकती है।
चूँकि सर्च बॉक्स उन वेबसाइटों के लिए मुख्य केंद्र बन जाते हैं, जिनमें बड़ी मात्रा में सामग्री और जानकारी होती है, ख़ासकर नीतियां, प्रक्रियाएँ या नागरिक सेवाएँ शामिल होती हैं, इसलिए सर्च बॉक्स हर पेज पर प्रमुखता से प्रदर्शित होने चाहिए और उन्हें यूज़र आसानी से देख सकते हैं।
इसके अलावा, सर्च बॉक्स में इन सबसे अच्छे तरीकों का पालन करना चाहिए:
- खोज, जहाँ संभव हो, एक ओपन-टेक्स्ट क्वेरी फ़ील्ड में “खोज” लेबल वाला प्लेसहोल्डर टेक्स्ट हो या अधिक प्रासंगिक निर्देशों के साथ, कुछ शब्दों तक सीमित हो, जिसमें यूज़र प्रश्न टाइप कर सकते हैं।
- सर्च बॉक्स के साथ मैग्निफ़ाइंग ग्लास आइकन होना चाहिए, जिसमें कम से कम जानकारी होS संभव (सरल लीनियर)। यूज़र मैग्निफ़ाइंग ग्लास को पूरी तरह से खोज की कार्यक्षमता के प्रतीक के रूप में पहचानते हैं।
- जब भी संभव हो, इस आइकन से खोज की कार्यक्षमता को छिपाना नहीं चाहिए क्योंकि इससे इंटरैक्शन की लागत बढ़ जाती है (ज़्यादा क्लिक) और खोज की कार्यक्षमता कम अलग हो जाती है।
- जब संदेह हो, तो Google की तरह करें।
- एंटर दबाकर खोज से जुड़ी सवालों की पुष्टि की जानी चाहिए। अगर ज़रूरत हो, तो पुष्टि करने का बटन दबाकर भी खोज के सवालों की पुष्टि की जा सकती है, हालांकि खोज बॉक्स में एंटर दबाने का इंटरैक्शन बरकरार रखा जाना चाहिए।
- पुष्टि करने वाला बटन जोड़ने पर, उसे साइज़ दिया जाना चाहिए और उसे सही तरीके से रखा जाना चाहिए (आमतौर पर सर्च बॉक्स की ऊंचाई ही, ओपन-टेक्स्ट क्वेरी फ़ील्ड के दाईं ओर रखी जाती है)। ऐक्सेसिबिलिटी से जुड़े सबसे सही तरीकों को पूरा करने के लिए, यह सर्च बटन कम से कम 45 x 45 पिक्सल का होना चाहिए।
- इनपुट टेक्स्ट बॉक्स का आकार चौड़ा होना चाहिए, ताकि कम से कम 27 अक्षरों की लंबाई हो (ईएमएस का इस्तेमाल करके सेट किया गया)।
- जहाँ भी संभव हो, सर्च बॉक्स को एजेंसी की वेबसाइट के ऊपरी दाएं कोने में, कॉमनवेल्थ ब्रांडिंग बार के नीचे रखा जाना चाहिए।
- 10 से कम आइटम वाले ऑटो-सुझाव ड्रॉप डाउन फ़ील्ड से यूज़र को वे चीज़़ें तेज़ी से ढूंढने में मदद मिल सकती है, जिन्हें वे ढूंढ रहे हैं, हालांकि, इसका इस्तेमाल करने वाली एजेंसियों को यह पक्का करना चाहिए कि अपने-आप जनरेट होने वाले सुझाव इनपुट फ़ील्ड में टाइप किए गए खोज शब्दों के लिए प्रासंगिक हों।
- एक बार जब कोई यूज़र एंटर दबाता है, तो मूल खोज शब्द फ़ील्ड में ही रहना चाहिए, जब तक कि यूज़र द्वारा साफ़ नहीं किया जाता है और यूज़र को उनकी खोज क्वेरी के आधार पर परिणाम पेज दिया जाना चाहिए, जिसमें परिणाम दिखाए जाएंगे।
- अगर किसी खोज क्वेरी से कोई परिणाम नहीं मिलता है, तो यूज़र को ऐसी जानकारी दी जानी चाहिए जिसमें साफ़ लिखा हो कि मेल खाने वाले परिणाम नहीं हैं।
वेब-29
WEB-29: COV वेब सिस्टम में एक साइटमैप शामिल होगा, ताकि सर्च इंजन किसी वेबसाइट को और कुशलता से क्रॉल कर सकें। COV डिज़ाइन सिस्टम में उदाहरण दिए जाएंगे।
वेब को समझना-29
साइटमैप एक ऐसी फ़ाइल है, जिससे सर्च इंजन आपकी ज़्यादातर साइट के कॉन्टेंट को क्रॉल करके उसे खोज सकते हैं।
साइटमैप XML फ़ॉर्मेट में होने चाहिए, जिससे सर्च इंजन सिर्फ़ HTML फ़ाइलें ही नहीं, बल्कि छवियों, वीडियो, समाचार सामग्री और एजेंसी वेबपेजों के स्थानीय संस्करणों के डेटा को भी इंडेक्स कर सकते हैं।
XML फ़ॉर्मेट में साइटमैप बनाने के तरीके के बारे में और जानने के लिए, कृपया यहां जाएं sitemaps.org पर साइटमैप एक्सएमएल फ़ॉर्मेट के दस्तावेज़।
वीटा का सुझाव है कि डेवलपर्स.google.com पर दिए गए साइटमैप से जुड़े इन सबसे सही तरीकों का पालन करें:
- एक साइटमैप बिना कंप्रेस किए 50MB तक सीमित होना चाहिए। अगर आपकी एजेंसी की साइटमैप फ़ाइल बड़ी है, तो कृपया अपने साइटमैप को कई साइटमैप में बांट दें।
- साइटमैप फ़ाइलें UTF-8 एन्कोडेड होनी चाहिए।
- यह सुझाव दिया जाता है कि आपके साइटमैप साइट रूट पर ही होस्ट किए जाएं।
- उदाहरण के लिए, अपने साइटमैप में पूरी तरह से योग्य, संपूर्ण URL का इस्तेमाल करें, /agencypage.html के बजाय https://www.myvaagency.gov/agencypage.html का इस्तेमाल करें।
वेब-30
WEB-30: COV वेब सिस्टम यह सुनिश्चित करेगा कि प्रत्येक पेज पर एक फ़ूटर हो, जिसमें कम से कम, निम्नलिखित जानकारी हो:
- एजेंसी का नाम
- कॉपीराइट की जानकारी
- वेब एक्सेसिबिलिटी इनिशिएटिव (WAI) के अनुपालन के बारे में बताने वाला टेक्स्ट या आइकन का स्वीकृत लिंक।
- एजेंसी के इंटरनेट प्राइवेसी पॉलिसी स्टेटमेंट का लिंक।
- FOIA की जानकारी के लिए लिंक
- अनुवाद संबंधी अस्वीकरण
- हमसे संपर्क करें पेज
- COV डिज़ाइन सिस्टम द्वारा परिभाषित अन्य आइटम
वेब को समझना-30
वेबसाइट फ़ूटर एक स्टैटिक UI पैटर्न होता है, जो एजेंसी के साइट पेज के बिल्कुल नीचे दिखाया जाता है। WEB-30 बताता है कि हर पेज के फ़ूटर पर निम्नलिखित चीज़ें दिखाई देंगी:
- एजेंसी का नाम: एजेंसी का पूरा नाम दिखाया जाना चाहिए
- कॉपीराइट से जुड़ी जानकारी: कॉपीराइट के तौर पर दिखाया गया है © एजेंसी का पूरा नाम [वर्तमान वर्ष]
- वेब एक्सेसिबिलिटी इनिशिएटिव (WAI) से संबंधित टेक्स्ट या स्वीकृत आइकन लिंक: वेब एक्सेसिबिलिटी इनिशिएटिव के रूप में लिखा गया है और इससे लिंक किया गया है WCAG 2.0 AA अनुरूपता पेज। वैकल्पिक रूप से, एजेंसियां WAI लोगो का इस्तेमाल करके WAI से लिंक कर सकती हैं। लोगो के इस्तेमाल के लिए दिशा-निर्देश और कोड यहां देखे जा सकते हैं W3C का WCAG अनुरूपता जोड़ना लोगो पेज।
- यह ज़रूरी है कि एजेंसियां इस लिंक का इस्तेमाल करते समय WCAG 2.0 में बताई गई AA अनुरूपता को पूरा करने के लिए काम करें।
- एजेंसी के इंटरनेट प्राइवेसी पॉलिसी स्टेटमेंट का लिंक: गोपनीयता नीतियां एजेंसी के हिसाब से होती हैं, लेकिन कम से कम यह बताना चाहिए कि कोई एजेंसी साइट ऐक्सेस करते समय यूज़र की जानकारी का इस्तेमाल और संग्रह कैसे करती है, कौन सी जानकारी एकत्र की जाती है, यह वर्जीनिया कानून से कैसे संबंधित है, जहाँ कोई यूज़र ज़्यादा जानकारी, कुकी नीति, और यूज़र डेटा के इस्तेमाल से संबंधित अन्य जानकारी के लिए संपर्क कर सकता है। इस पर एक उदाहरण पाया जा सकता है वर्जिनिया.gov।
- FOIA की जानकारी के लिए लिंक: FOIA जानकारी एजेंसी के हिसाब से होती है और इसमें वर्जीनिया सूचना की स्वतंत्रता अधिनियम, यूज़र के FOIA अधिकारों, रिकॉर्ड का अनुरोध कैसे कर सकता है, अनुरोध कहाँ भेजना है, और अनुरोध प्राप्त करते समय एजेंसी की ज़िम्मेदारियों के बारे में सरल भाषा में जानकारी होनी चाहिए। FOIA के बारे में ज़्यादा जानकारी यहाँ पाई जा सकती है वर्जीनिया का कोड, अध्याय 37।
- अनुवाद अस्वीकरण: अनुवाद अस्वीकरण बताता है कि पेजों को स्थानीय बनाने के लिए कोई तृतीय पक्ष (आमतौर पर Google Translate) उपलब्ध होता है। इस अस्वीकरण में तीसरे पक्ष का नाम होना चाहिए, साथ ही यह बताना चाहिए कि यह विकल्प यूज़र को अंग्रेज़ी के अलावा अन्य भाषाओं में वेबसाइट उपलब्ध कराने में मदद करने के लिए दिया गया है, लेकिन इसका कोई स्वचालित अनुवाद सही नहीं है और तीसरे पक्ष की सेवा “जैसी है” प्रदान की जाती है। इस पर एक उदाहरण पाया जा सकता है वीटा का अनुवाद अस्वीकरण पेज।
- हमसे संपर्क करें पेज: फ़ूटर में हमसे संपर्क करें पेज शामिल होना चाहिए। ज़्यादा जानकारी के लिए, कृपया WEB-31 देखें।
इसके अलावा, COV डिज़ाइन सिस्टम सुझाव देता है कि सभी फ़ूटर्स
- मोबाइल पर काम करें
- फ़ुटर में दिए गए अतिरिक्त लिंक को मकसद से चुना जाना चाहिए (अक्सर इस्तेमाल किया जाता है, छोटा साइटमैप, आदि)
- इसमें सोशल मीडिया लिंक/आइकन शामिल हैं, लेकिन पूरे सोशल फ़ीड्स नहीं हैं
- साफ़ है और पढ़ने योग्य है, जिसमें बिल्कुल भी इमेजरी नहीं है
- अगर इस्तेमाल किया जाए, तो कॉल टू एक्शन को संक्षिप्त और स्पष्ट दिशा और उद्देश्य के साथ रखें।
वेब-31
WEB-31: COV वेब सिस्टम हमसे संपर्क करें पेज उपलब्ध कराएगा, जिसमें कम से कम, एजेंसी का:
- डाक का पता
- फ़ैक्स नंबर, अगर उपलब्ध हो
- फ़ोन नंबर, जिसमें टोल-फ़्री नंबर और/या TTY नंबर शामिल है
- किसी एजेंसी से संपर्क करने के लिए ईमेल लिंक या संपर्क फ़ॉर्म।
- हमसे संपर्क करें पेज को फ़ुटर पेज से ऐक्सेस किया जा सकता है।
वेब को समझना-31
ध्यान दें एजेंसियों को सामान्य ईमेल पते का इस्तेमाल करना चाहिए और किसी खास व्यक्ति के साथ एजेंसी के संपर्क लिंक जोड़ने से बचना चाहिए।
हमसे संपर्क करें पेज से यूज़र अलग-अलग यूज़र को समायोजित करने के लिए अलग-अलग तरीकों से किसी भी प्रश्न या समस्या के लिए एजेंसी से संपर्क कर सकते हैं।
- डाक पते एजेंसी का भौतिक पता होने चाहिए, न कि पीओ बॉक्स, उन्हें इस तरह फ़ॉर्मेट किया गया हो:
एजेंसी का पूरा नाम
123 स्ट्रीट एड्रेस रोड, सुइट नंबर 456
शहर, VA ज़िप कोड
- फ़ैक्स नंबर, अगर उपलब्ध हो, तो उसे इस तरह फ़ॉर्मेट किया गया है:
123-555-5555 (फ़ैक्स)
- फ़ोन नंबर, जिसमें टोल-फ़्री नंबर और/या TTY नंबर शामिल है, अगर उपलब्ध हो, तो इसे इस तरह फ़ॉर्मेट किया गया है:
1-123-555-5555 (फ़ोन)
1-800-555-5555 (टोल-फ़्री)
1-123-555-555 (TTY)
- ज़रूरत पड़ने पर टीटीवाई या रिले सेवाओं का इस्तेमाल करने के तरीके के बारे में और निर्देश दिए जा सकते हैं।
- किसी खास व्यक्ति के साथ सहयोगी एजेंसी के संपर्क से बचने के लिए एक सामान्य ईमेल लिंक का इस्तेमाल किया जाना चाहिए और इसे इस तरह फ़ॉर्मेट किया जाना चाहिए:
contact@agency.virginia.gov
किसी एजेंसी से संपर्क करने वाला संपर्क फ़ॉर्म, ईमेल पते का विकल्प होता है। किसी फ़ॉर्म का उपयोग करते समय, फ़ॉर्म में प्रतिक्रिया के लिए कम से कम निम्नलिखित फ़ील्ड होने चाहिए, उपयुक्त लेबलिंग के साथ: - पहला नाम
- कुल नाम(? क्या कुल नाम सच में ज़रूरी है? (कम से कम) के सिद्धांत पर जा रहे हैं
- ईमेल या फ़ोन नंबर
- संदेश या टिप्पणी के लिए फ़ील्ड
वेब-36
WEB-36: COV प्लेटफ़ॉर्म वेब सिस्टम, जिसमें कमर्शियल ऑफ़-द-शेल्फ (COTS) सिस्टम शामिल हैं, COV डिज़ाइन सिस्टम द्वारा परिभाषित कॉमनवेल्थ ब्रांडिंग के निर्बाध उपयोग के लिए व्हाइट-लेबलिंग का समर्थन करेंगे।
वेब को समझना-36
प्लैटफ़ॉर्म वेब सिस्टम को ईए द्वारा इस रूप में परिभाषित किया जाता है:
कोई भी वेब सिस्टम जो बड़े पैमाने पर या मल्टीटेनेंट इम्प्लीमेंटेशन के लिए एंटरप्राइज़-स्तर की क्षमताएं प्रदान करता है, जिसमें मानव संसाधन प्रबंधन प्रणाली (HRMS), फाइनेंशियल मैनेजमेंट सॉल्यूशंस (FMS), सप्लाई चैन मैनेजमेंट (SCM), ग्राहक संबंध प्रबंधन (CRM), एंटरप्राइज़ परफ़ॉर्मेंस मैनेजमेंट (EPM), और कॉन्टेंट मैनेजमेंट सिस्टम (CMS) शामिल हैं।
बाहरी रूप से या सार्वजनिक रूप से प्रस्तुत किए जाने पर इन सिस्टमों से COVA एजेंसियां ईए अपीयरेंस और डिज़ाइन सिस्टम मानकों (जिसे व्हाइट-लेबलिंग भी कहा जाता है) के अनुरूप अपनी उपस्थिति को फिर से ब्रांड बना सकती हैं। कम से कम, एक प्लैटफ़ॉर्म वेब सिस्टम जिसे सार्वजनिक यूज़र ऐक्सेस कर सकते हैं, पेज के सबसे ऊपर कॉमनवेल्थ ब्रांडिंग बार दिखाना चाहिए।
ऐक्सेसिबिलिटी
वेब-39
वेब-39: COV वेब सिस्टम, ऐक्सेसिबिलिटी की ज़रूरी जानकारी देगा, जो COV डिज़ाइन सिस्टम के निर्देशों के अनुसार दिखाई देगी, ताकि यूज़र को तुरंत पता चल जाए कि वेबसाइट को सबसे अच्छी तरह से कैसे नेविगेट किया जाए।
वेब को समझना-39
COV वेब सिस्टम साफ़ तौर पर वेबसाइटों के ऐक्सेसिबिलिटी अनुपालन को सूचीबद्ध WEB-30 के रूप में पोस्ट करेंगे, ताकि यूज़र को वेबसाइट नेविगेट करने के लिए ज़रूरी रणनीतियों के बारेमें सूचितकिया जा सके, भले ही क्षमता कुछ भी हो। बेशक, एजेंसियों को एक ऐक्सेसिबिलिटी स्टेटमेंट शामिल करना चाहिए, जिसमें एक ऐक्सेसिबिलिटी वेबसाइट विकसित करने की दिशा में एजेंसी द्वारा किए जा रहे प्रयास, वे ऐक्सेसिबिलिटी को कैसे ट्रैक करते हैं, और यूज़र ऐक्सेसिबिलिटी से संबंधित चिंताओं को किसे डायरेक्ट कर सकते हैं, शामिल होना चाहिए।
वेब-40 — वेब-43
विज़ुअल आवश्यकताएँ (वेब-40 — WEB-43)
वेब को समझना-40 — WEB-43
रंगों के लिए हाई-कंट्रास्ट मार्गदर्शन WCAG की सफलता के मापदंड 1.4 पर आधारित है। 3 कंट्रास्ट (न्यूनतम), जिसमें कहा गया है:
का विज़ुअल प्रेजेंटेशन टेक्स्ट और टेक्स्ट की छवियाँ एक है कंट्रास्ट रेशियो कम से कम 4.5:1 में से, इन को छोड़कर:
- बड़े पैमाने पर बड़े पैमाने के टेक्स्ट के टेक्स्ट और इमेज का कंट्रास्ट रेशियो कम से कम 3:1 होता है;
- टेक्स्ट या टेक्स्ट की छवियाँ जो किसी निष्क्रिय का हिस्सा हैं यूज़र इंटरफ़ेस का घटक, ये हैं पूरी सजावट, जो किसी को भी दिखाई नहीं देता है, या जो ऐसी तस्वीर का हिस्सा है जिसमें महत्वपूर्ण अन्य विज़ुअल कॉन्टेंट शामिल हैं, जिनके कंट्रास्ट की कोई ज़रूरत नहीं है।
- टेक्स्ट जो लोगो या ब्रैंड नाम का हिस्सा है, उसके कंट्रास्ट की कोई ज़रूरत नहीं है।
रंग कंट्रास्ट अनुपात का निर्धारण किसी ऑडिटिंग टूल जैसे कि SiteImprove या ऑनलाइन चेकर्स जैसे कि WebAIM।
ऑडियो संकेतों से मिलने वाला मार्गदर्शन WCAG की सफलता के मापदंड 1.2 पर आधारित है। 2 कैप्शन (पहले से रिकॉर्ड किया हुआ), जिसमें कहा गया है:
सिंक्रोनाइज़्ड मीडिया में पहले से रिकॉर्ड किए गए सभी ऑडियो कॉन्टेंट के लिए कैप्शन दिए जाते हैं, सिवाय इसके कि मीडिया टेक्स्ट का मीडिया विकल्प होता है और उस पर स्पष्ट रूप से लेबल किया जाता है।
कैप्शनिंग रेंडर करने के सबसे अच्छे तरीकों के बारे में मार्गदर्शन यहां पाया जा सकता है WCAG की सुझाई गई साइट, joeclark.org और मीडिया प्रोग्राम वेबसाइट का वर्णन और कैप्शन दिया गया है।
इसके अलावा, सभी यूज़र दृष्टिहीन यूज़र की दृष्टि को प्रभावित करने वाली अक्षमताओं जैसे अंधापन या कलर ब्लाइंडनेस के कारण होने वाले रंग, इमेजरी या अन्य विज़ुअल संकेतों को समझ नहीं पाते या देख नहीं पाते हैं। WEB-41 WCAG की सफलता के मापदंड 1.4 पर आधारित है। 1 रंग का उपयोग, जिसमें कहा गया है:
जानकारी देने, किसी क्रिया को इंगित करने, प्रतिक्रिया देने या किसी विज़ुअल एलिमेंट में अंतर करने के लिए रंग का इस्तेमाल सिर्फ़ दृश्य माध्यम के रूप में नहीं किया जाता है।
उदाहरण के लिए, अगर किसी संपर्क फ़ॉर्म में “सबमिट” के लिए हरा बटन और “फ़ॉर्म साफ़ करें” के लिए एक ग्रे बटन है,”, सबमिट करने के लिए बटन और निर्देश, दोनों पर साफ़ लेबल लगा होना चाहिए। इस उदाहरण में, हरे बटन पर “सबमिट करें” लेबल होना चाहिए और लाल बटन पर “क्लियर” लेबल होना चाहिए।”। निर्देशों से यूज़र को “फ़ॉर्म सबमिट करने की पुष्टि करने के लिए सबमिट बटन पर क्लिक करें या फ़ॉर्म साफ़ करने और फिर से शुरू करने के लिए फ़ॉर्म साफ़ करें” बटन पर क्लिक करें।
यूज़र को उलझन से बचाने के लिए लेबल लगाना स्पष्ट और वर्णनात्मक होना चाहिए, लेकिन इतना संक्षिप्त होना चाहिए कि यूज़र जल्दी से पढ़ सकें और पढ़ने या अन्य संज्ञानात्मक अक्षमताओं वाले यूज़र की मदद कर सकें।
एजेंसियों को अपनी वेबसाइट पर हाइपरलिंक दिखाने के लिए सिर्फ़ रंग का इस्तेमाल नहीं करना चाहिए। एजेंसियों को इस्तेमाल करना चाहिए एक जैसा, आसानी से पहचाने जाने वाले डिज़ाइन पैटर्न, जो अंदरूनी और बाहरी दोनों तरह के हाइपरलिंक को दर्शाते हैं, जैसे कि अंतर्निहित, CSS होवर स्टेट्स और आइकन के माध्यम से (ख़ासकर बाहरी हाइपरलिंक के मामले में)।
इसके अलावा, जिन फ़ील्ड को ज़रूरी के तौर पर मार्क किया गया है या जिन फ़ील्ड में इनपुट त्रुटियां हैं, उन्हें यह जानकारी ऐसे तरीके से पेश करनी होगी, जिन्हें सिर्फ़ रंग के इस्तेमाल से पहचाना नहीं जाता है। उदाहरण के लिए, किसी फ़ील्ड को सिर्फ़ लाल बॉर्डर में हाईलाइट नहीं किया जा सकता है या उसके बगल में लाल रंग का तारा चिह्न नहीं है। इसके बजाय, एजेंसियों को “पहला नाम ज़रूरी है” या “पहला नाम*” जैसे आइडेंटिफ़ायर और “* = ज़रूरी फ़ील्ड” कहने वाले नोटिफ़ायर पर विचार करना चाहिए।
फ़ील्ड की ज़रूरी सबसे अच्छी प्रथाओं के विज़ुअल और कोड उदाहरण यहां देखे जा सकते हैं डेक का ऐनाटॉमी ऑफ़ एक्सेसिबल फ़ॉर्म्स: आवश्यक फ़ॉर्म फ़ील्ड पेज।
यूज़र द्वारा दी गई त्रुटियों के लिए, त्रुटि के स्पष्ट, संक्षिप्त विवरण से त्रुटि को आसानी से पहचाना जा सकता है। हर गड़बड़ी का मैसेज इन मानदंडों को भी पूरा करना चाहिए:
- गलती से हर फ़ील्ड को पहचानें
- त्रुटियों को ठीक करने के लिए सुझाव दें (जब पता हो)
- इस जानकारी को सहायक तकनीक के रूप में ठीक से उजागर करें।
ऐक्सेसिबल फ़ॉर्म फ़ील्ड में त्रुटियों के साथ फ़ॉर्मेट करने के तरीके के बारे में अतिरिक्त जानकारी और उदाहरणों के लिए, कृपया देखें लेवल ऐक्सेस 'ऐक्सेस किया जा सकने वाला फ़ॉर्म, त्रुटि पहचान पेज कैसे दें।
ARIA से जुड़ी ज़रूरतें
वेब-44 — वेब-53
वेब-44 — वेब-53: ARIA से जुड़ी ज़रूरी शर्तें
वेब को समझना-44 — WEB-53
HTML 5 में विभिन्न प्रकार के और अधिक वर्णनात्मक HTML टैग होते हैं, ताकि डेवलपर और एक्सेस की जा सकने वाली तकनीक को वेब पेज की संरचना, सामग्री और संगठन को आसानी से समझने में मदद मिल सके। एजेंसियों को यह पक्का करना चाहिए कि उनकी वेबसाइटें सिमेंटिक एचटीएमएल का सही इस्तेमाल कर रही हैं, ताकि डेवलपर, यूज़र और ऐक्सेस की जा सकने वाली तकनीकें अपनी वेबसाइट की सामग्री को सही तरीके से ऐक्सेस कर सकें। इसके अलावा, HTML5 सिमेंटिक मार्कअप से HTML कोड में ARIA के इस्तेमाल को सीमित करने में मदद मिलती है। HTML 5 में सिमेंटिक मार्कअप और एक्सेसिबल में इसकी भूमिका के बारे में ज़्यादा जानकारी के लिए, कृपया देखें Mozilla का HTML: ऐक्सेसिबिलिटी वेबपेज के लिए एक अच्छा आधार।
एआरआईए, या ऐक्सेसिबल रिच इंटरनेट एप्लीकेशन, एचटीएमएल कोड में जोड़ी जाने वाली भूमिकाओं और विशेषताओं का एक सेट है, ताकि सहायक वेब तकनीकों का इस्तेमाल करने वाले यूज़र वेबसाइट को ज़्यादा ऐक्सेस किया जा सके। अगर आपके पास सिमेंटिक्स और व्यवहार वाला HTML एलिमेंट इस्तेमाल करने का विकल्प है, तो AIRA के बजाय उस HTML एलिमेंट का इस्तेमाल करें। एजेंसियों को एचटीएमएल एलिमेंट के साथ ARIA का इस्तेमाल करना चाहिए, अगर कोई ऐसा एचटीएमएल एलिमेंट नहीं है जो मूल रूप से शब्दार्थ या व्यवहारिक रूप से बताता हो या जो करता है उसे काम करता हो। जब एजेंसियां ARIA का इस्तेमाल करने का चुनाव करती हैं, तो उन्हें पता होना चाहिए कि सहायक वेब तकनीकों (जैसे कि कीबोर्ड टैब ऑर्डर) के लिए उपयुक्त और समान रूप से मूल अनुभव बनाने के लिए उनकी ज़िम्मेदारी है।
WEB-44 — WEB-53 खास तौर पर ARIA के इस्तेमाल की ज़रूरतों को दर्शाता है, अगर एजेंसियों को ऐसी स्थिति का पता चलता है जहाँ सिमेंटिक मार्कअप के बराबर कोई समस्या न हो। डेवलपर इसका संदर्भ दे सकते हैं W3C के एक्सेसिबल रिच इंटरनेट एप्लीकेशन (WAI-ARIA) 1.3 ARIA मानकों के बारे में ज़्यादा जानकारी के लिए, जबकि डिज़ाइनर इसका संदर्भ दे सकते हैं W3C की ARIA ऑथरिंग प्रैक्टिस गाइड (APG) सामान्य डिज़ाइन पैटर्न और ARIA के उपयोग के साथ सबसे अच्छा काम करने वाले इंटरैक्शन कैसे डिज़ाइन करें, इस बारे में जानकारी के लिए।
लेआउट के साथ यूज़र इंटरैक्शन
वेब-54 — वेब-102
वेब-54 — वेब-102: लेआउट के साथ यूज़र इंटरैक्शन
वेब को समझना-54 — WEB-102
जब एजेंसियां वेबसाइट बनाती हैं, तो उन्हें सिर्फ़ “सबसे सामान्य” यूज़र ही नहीं, बल्कि कई तरह के यूज़र प्रकारों और उनसे जुड़े अनुभवों के लिए डिज़ाइन पर भी विचार करना चाहिए। इन समूहों को आम तौर पर निम्नलिखित श्रेणियों में विभाजित किया जाता है:
- विज़ुअल
- ऑडिटरी
- मोटर
- संज्ञानात्मक
इस तरह, एजेंसियों को यह पक्का करना चाहिए कि उनकी वेबसाइट इन पाँच यूज़र समूहों तक पहुँचा जा सके और उनके साथ इंटरैक्शन किया जा सके और उनकी वेबसाइट के इंटरैक्शन के वैकल्पिक रूप उपलब्ध हों। उदाहरण के लिए, अगर किसी माउस पॉइंटर की मदद से कोई लिंक ऐक्सेस किया जा सकता है, तो वह कीबोर्ड के ज़रिए टैब ऑर्डर के ज़रिए, स्क्रीन रीडर के ज़रिए सिमेंटिक मार्कअप के ज़रिए भी उपलब्ध होना चाहिए, और सिर्फ़ रंग के ज़रिए ही नहीं, इसे विज़ुअल रूप से भी दर्शाया जाना चाहिए। इसके अलावा, एजेंसियों को ऑल्ट टेक्स्ट के ज़रिए विज़ुअल माध्यमों (जैसे चित्र) और सुनने के संकेतों के लिए वर्णनात्मक या अन्य समान टेक्स्ट का वर्णन करने पर विचार करना चाहिए।
एजेंसियों को यूज़र को वेब पेज पर पूरा नियंत्रण करने की अनुमति देनी चाहिए, अगर उसमें प्ले मीडिया (ऑडिटरी और/या विज़ुअल) है और जिन यूज़र को मिर्गी या माइग्रेन ट्रिगर हो सकते हैं, उनके लिए फ़्लैशिंग और स्क्रॉलिंग इमेजरी से बचना चाहिए।
जब संदेह हो, तो इसे आसान रखें!
डेवलपर और एजेंसियां इसका रेफ़रेंस कर सकते हैं WCAG वेब 2.1 मानक सबसे अद्यतित और स्वीकृत वेब मानकों के लिए, अगर वे और गहराई में गोता लगाना चाहते हैं। हालांकि, हार्वर्ड यूनिवर्सिटी ने टॉप 10 ज़रूरी चीज़ों के लिए एक सरल, आसानी से पढ़ी जाने वाली गाइड तैयार की है, जिस पर ऐक्सेसिबिलिटी के साथ डेवलपर को विचार करना चाहिए इसमें WEB-54 — WEB-71 में शामिल ज़्यादातर टॉपिक्स शामिल हैं।
WEB-72 — WEB-102 खास तौर पर वेबसाइट बनाने पर केंद्रित है बोधगम्य, ऑपरेट करने योग्य, और मज़बूत। इन चार सिद्धांतों में से तीन का दस्तावेजीकरण किया गया है WCAG के ऐक्सेसिबिलिटी के चार सिद्धांत।
WCAG के मुताबिक, ये चार सिद्धांत इस प्रकार हैं:
- बोधगम्य - जानकारी और यूज़र इंटरफ़ेस घटक यूज़र को उन तरीकों से पेश किए जाने चाहिए, जिन्हें वे देख सकते हैं। इसका मतलब है कि यूज़र को प्रस्तुत की जा रही जानकारी को महसूस करना चाहिए (यह उनके सभी होश में नहीं आ सकती)
- ऑपरेट किया जा सकता है - यूज़र इंटरफ़ेस के घटक और नेविगेशन काम करने योग्य होने चाहिए। इसका मतलब है कि यूज़र इंटरफ़ेस को ऑपरेट करने में सक्षम होना चाहिए (इंटरफ़ेस के लिए इंटरैक्शन की ज़रूरत नहीं है जिसे यूज़र नहीं कर सकता)
- समझा जा सकता है - जानकारी और यूज़र इंटरफ़ेस के संचालन को समझना चाहिए। इसका मतलब है कि यूज़र को जानकारी के साथ-साथ यूज़र इंटरफ़ेस के संचालन को भी समझना होगा (कॉन्टेंट या ऑपरेशन उनकी समझ से बाहर नहीं हो सकता)
- रोबस्ट - कॉन्टेंट इतना मज़बूत होना चाहिए कि कई तरह के यूज़र एजेंट उसकी भरोसेमंद व्याख्या कर सकें, जिसमें सहायक तकनीकें भी शामिल हैं। इसका मतलब है कि तकनीक के आगे बढ़ने पर यूज़र को सामग्री ऐक्सेस करनी होगी (जैसे-जैसे तकनीकें और यूज़र एजेंट विकसित होते हैं, सामग्री सुलभ रहनी चाहिए)
ये चार सिद्धांत वेब पर आज के आधुनिक एक्सेसिबिलिटी मानकों की रीढ़ हैं।
इसके अलावा, WEB-72 बताता है कि एजेंसी की वेबसाइटों में कम से कम यह होना चाहिए दो इन चीज़ों में से:
- संबंधित पेजों की सूची
- विषय-सूची
- साइट मैप
- सर्च करें
- सभी पेजों की सूची
संक्षिप्त और सरल तरीके से ज़्यादा जानकारी के लिए, एजेंसियां संदर्भ दे सकती हैं हार्वर्ड यूनिवर्सिटी के सिद्धांत उनकी डिजिटल एक्सेसिबिलिटी इनिशिएटिव वेबसाइट से।
यूज़र डिवाइस नेविगेशन
वेब-103 — वेब-120
वेब-103 — वेब-120: यूज़र डिवाइस नेविगेशन
वेब को समझना-103 — WEB-120
WEB-103 — WEB-120 खास तौर से किसी वेबसाइट को नेविगेट करने के वैकल्पिक तरीकों पर ध्यान देता है। यह जानना ज़रूरी है कि सभी यूज़र ऐसे इनपुट डिवाइस का इस्तेमाल नहीं करते हैं जो माउस पॉइंटर का इस्तेमाल करता हो। वैकल्पिक इनपुट डिवाइसों में स्क्रीन रीडर, वॉइस कमांड, माउथ स्टिक, सिप और पफ्स, और कंप्यूटर कीबोर्ड पर पाए जाने वाले टैब और एंटर कीज़ शामिल हो सकते हैं।
एजेंसियां इस पर सहायक तकनीकों के बारे में ज़्यादा जान सकती हैं यूनिवर्सिटी ऑफ़ बर्कले के सहायक टेक्नोलॉजीज के प्रकार का वेबपेज।
इसके अलावा, यह ईए सेक्शन मोबाइल डिवाइसों पर संभावित यूज़र के मोटर कंट्रोल फ़ंक्शन का भी संदर्भ देता है, जिसमें कहा गया है कि:
COV वेब सिस्टम को मल्टीपॉइंट या पथ-आधारित जेस्चर की ज़रूरत नहीं होगी, जैसे कि पिंचिंग, स्वाइप या ड्रैगिंग। कार्यक्षमता के लिए, जब तक कि संकेत कार्यक्षमता के लिए ज़रूरी न हो।
इसका मतलब है कि टच स्क्रीन डिवाइस पर, यूज़र जेस्चर कंट्रोल की ज़रूरत के बिना किसी वेबपेज पर ज़ूम कर सकते हैं, टेक्स्ट बड़ा कर सकते हैं या बेसिक इंटरैक्शन कर सकते हैं; और यह कि अलग-अलग स्क्रीन साइज़ और डिवाइस पर मूल रूप से प्रतिक्रिया देने के लिए वेबसाइट विकसित की जानी चाहिए।
एजेंसियां ऐक्सेसिबिलिटी की अतिरिक्त तकनीकों के बारे में जानकारी पा सकती हैं, जिनमें इस सेक्शन की तकनीकें भी शामिल हैं हार्वर्ड यूनिवर्सिटी के सहायक टेक्नोलॉजीज टेक्नीक्स वेबपेज।
एवी कॉन्टेंट
वेब-121 — वेब-128
एवी कंटेंट: वेब-121 — वेब-128
वेब को समझना-121 — WEB-128
सभी ऑडियो और विज़ुअल मीडिया को वेब पर यूज़र के लिए उचित रूप से एक्सेस किया जा सकता है और उन्हें फ़ॉर्मेट किया जाना चाहिए। ईए में यह सेक्शन खास तौर से किसके संदर्भ में है WCAG गाइडलाइन 1.2 - समय पर आधारित मीडिया, जिसमें बताया गया है कि वेबसाइटों पर AV कॉन्टेंट को कैसे ऐक्सेस किया जाना चाहिए। मानक 1.2। 1 और 1.2। 5 का रेफ़रंस दिया जाना चाहिए, जो नीचे दिया गया है:
- समय-आधारित मीडिया के लिए एक विकल्प प्रदान किया गया है, जो पहले से रिकॉर्ड किए गए ऑडियो-ओनली या केवल-वीडियो कॉन्टेंट के लिए समान जानकारी प्रदान करता है।
- सिंक्रोनाइज़्ड मीडिया में पहले से रिकॉर्ड किए गए सभी ऑडियो कॉन्टेंट के लिए कैप्शन दिए गए हैं।
- सिंक्रोनाइज़्ड मीडिया के लिए समय-आधारित मीडिया या पहले से रिकॉर्ड की गई वीडियो सामग्री के ऑडियो विवरण का एक विकल्प दिया गया है,
- सिंक्रोनाइज़्ड मीडिया में सभी लाइव ऑडियो कॉन्टेंट के लिए कैप्शन दिए गए हैं।
- सिंक्रोनाइज़्ड मीडिया में पहले से रिकॉर्ड की गई सभी वीडियो सामग्री के लिए ऑडियो विवरण दिया गया है।
इसके अलावा, सभी लाइव कॉन्टेंट, जैसे कि वेबिनार और एजेंसी की वेबसाइटों या ऐप्लिकेशन पर होस्ट किए गए वेबकास्ट में भी सटीक और समय पर कैप्शन दिए जाने चाहिए (जैसे कि रियल-टाइम कैप्शनिंग और/या कार्ट ट्रांसक्रिप्शन)।
यूज़र के पास किसी भी समय मीडिया को रोकने, चलाने और रोकने की क्षमता भी होनी चाहिए; और जब यूज़र पेज पर जाता है तो मीडिया अपने आप नहीं चलना चाहिए।