पैटर्न, कॉम्पोनेंट, और डिज़ाइन सिस्टम

कई लोग अपने डेवलपमेंट वर्कफ़्लो की प्रक्रिया में पैटर्न स्टाइल गाइड, कॉम्पोनेंट लाइब्रेरी या पूरे डिज़ाइन सिस्टम का इस्तेमाल करके कॉम्पोनेंट-ड्रिवन डेवलपमेंट का इस्तेमाल करते हैं. अगर आपने इन टूल का आधिकारिक तौर पर इस्तेमाल नहीं किया है, तब भी इसी तरह की प्रोसेस का इस्तेमाल करके किसी वेबसाइट, ऐप्लिकेशन या अन्य डिजिटल प्रॉडक्ट के बड़े डिज़ाइन को छोटे-छोटे हिस्सों में बांटा जा सकता है.

किसी इमारत की बनावट की तरह, एक बार में एक टुकड़ा बनाना भी ज़रूरी है. पहला, नींव, स्ट्रक्चर, दीवारें, खिड़कियां, छत वगैरह. कॉम्पोनेंट-ड्रिवन डेवलपमेंट टूल की मदद से, हम वेबसाइटों, ऐप्लिकेशन, और अन्य डिजिटल प्रॉडक्ट के लिए ऐसा कर सकते हैं.

कॉम्पोनेंट-ड्रिवन कंपोनेंट के कुछ फ़ायदे हैं, जैसे कि चीज़ों को छोटे-छोटे हिस्सों में बांटना. इससे, फिर से इस्तेमाल किए जा सकने वाले इन कॉम्पोनेंट को बनाने में कम समय लगता है. इसकी मदद से डिज़ाइनर, फ़्रंटएंड और बैकएंड डेवलपर, और QA एक साथ काम कर सकते हैं. क्लाइंट, डिज़ाइनर, पीएम वगैरह इस तरह के होते हैं, क्योंकि वे बिल्ड प्रोसेस की झलक देख सकते हैं और वेबसाइट लॉन्च होने के बाद, रेफ़रंस के तौर पर लिविंग स्टाइल गाइड का इस्तेमाल कर सकते हैं.

हालांकि, जब सुलभता को ध्यान में रखकर पैटर्न, कॉम्पोनेंट, और डिज़ाइन सिस्टम पर काम किया जाता है, तो हमारे मन में कुछ सवाल उठते हैं. आपको कैसे पता चलेगा कि सुलभता के मामले में सबसे बेहतर पैटर्न क्या है? क्या आपको पहले से मौजूद पैटर्न/लाइब्रेरी का इस्तेमाल करना चाहिए या नया पैटर्न/लाइब्रेरी बनानी चाहिए? आपको कैसे पता चलेगा कि इन पैटर्न से आपके उपयोगकर्ताओं को वाकई मदद मिलेगी या नहीं?

इस विषय के लिए बड़ी संख्या में विकल्प मौजूद हैं. इसलिए, इस विषय को लेकर भ्रम की स्थिति पैदा होना आसान है. इस मॉड्यूल का मकसद आपको इस बारे में सामान्य जानकारी देना है कि सुलभता के लिए पैटर्न, कॉम्पोनेंट, और डिज़ाइन सिस्टम का आकलन कैसे किया जाए. साथ ही, यह आपको शुरुआत करने की जानकारी देता है. इससे, सुलभ विकल्प चुनने में आसानी होती है.

गंभीरता से सोचें

ऐक्सेस किया जा सकने वाला पैटर्न, कॉम्पोनेंट या डिज़ाइन सिस्टम चुनना, रॉकेट विज्ञान नहीं है. हालांकि, इसमें समय और तर्क के साथ सोचने की ज़रूरत पड़ती है. असल में, "एक परफ़ेक्ट पैटर्न" जैसी कोई चीज़ नहीं है. हालांकि, ऐसे कई विकल्प हो सकते हैं जो सही तरीके से काम करें. इसका मतलब है कि आप अपनी स्थिति के हिसाब से सबसे अच्छा विकल्प चुन लें.

इसके बाद के टेस्टिंग मॉड्यूल में, आपको उन तकनीकों और तरीकों के बारे में ज़्यादा जानकारी मिलेगी जिनसे सुलभता के पैटर्न, कॉम्पोनेंट, और डिज़ाइन सिस्टम का आकलन किया जाता है. हालांकि, इससे पहले आपको कुछ बुनियादी बातें जाननी होंगी, जैसे कि:

  • क्या पहले से मौजूद ऐक्सेस किया जा सकने वाला कोई पैटर्न, कॉम्पोनेंट या डिज़ाइन सिस्टम पहले से मौजूद है?
  • मेरे ऐप्लिकेशन पर किन ब्राउज़र और सहायक टेक्नोलॉजी (AT) के साथ काम किया जा रहा है?
  • क्या मुझे किसी कोड/फ़्रेमवर्क की कोई सीमा या अन्य इंटिग्रेशन/फ़ैक्टर/उपयोगकर्ता की ज़रूरत है?

आपके डेवलपर प्लैटफ़ॉर्म और उपयोगकर्ता की ज़रूरतों के आधार पर, आपके पास इनसे दूसरे या अलग-अलग सवाल हो सकते हैं. सुलभता सुविधाओं के आकलन की शुरुआत, इन सवालों को ध्यान में रखकर करें.

भरोसेमंद संसाधन

कुछ भी नया बनाने से पहले, पूरी सावधानी बरतें. साथ ही, ऐक्सेस किए जा सकने वाले पैटर्न, कॉम्पोनेंट, और डिज़ाइन सिस्टम के मामले में पहले से मौजूद चीज़ों की समीक्षा करें. बस थोड़ी सी रिसर्च करके, आपको अपनी ज़रूरतों के हिसाब से एक या उससे ज़्यादा ऐसे समाधान मिल जाएंगे जो आपके काम के हों.

ऐक्सेस किए जा सकने वाले पैटर्न, कॉम्पोनेंट, और डिज़ाइन सिस्टम के लिए कुछ बेहतरीन संसाधन ये हैं:

JavaScript फ़्रेमवर्क के लिए इन संसाधनों को आसानी से ऐक्सेस किया जा सकता है या इन्हें आसानी से अपनी ज़रूरत के हिसाब से बनाया जा सकता है:

हालांकि—और इस पर ज़्यादा ध्यान नहीं दिया जाना चाहिए—आपको कभी भी कोड को कॉपी/पेस्ट नहीं करना चाहिए और यह मानकर चलना चाहिए कि वह आपके परिवेश में फ़िट हो जाएगा और आपके उपयोगकर्ताओं की ज़रूरतों को अपने आप पूरा कर लेगा. यह बात सभी पैटर्न, कॉम्पोनेंट, और डिज़ाइन सिस्टम पर लागू होती है, भले ही उन्हें 'पूरी तरह से ऐक्सेस किया जा सकने वाला' के तौर पर लेबल किया गया हो.

सभी संसाधनों को शुरुआत की जगह के तौर पर देखा जाना चाहिए. पक्का करें कि आपने हर चीज़ की जांच कर ली है!

ब्राउज़र और सहायक टेक्नोलॉजी (AT) सहायता

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

स्क्रीन रीडर खास ब्राउज़र को ध्यान में रखकर बनाए गए हैं और इन ब्राउज़र के साथ जोड़े जाने पर सबसे अच्छी तरह काम करेंगे. हम इस विषय के बारे में AT टेस्टिंग के मॉड्यूल में ज़्यादा जानकारी देंगे. हालांकि, पैटर्न का आकलन करने के मकसद से, इन कॉम्बिनेशन को समझना मददगार है. इससे आपको पता चल सकता है कि सहायता के लिए आपको क्या चाहिए.

स्क्रीन रीडर ओएस वेबसाइट का अलग-अलग ब्राउज़र पर चलना कीमत
Speech के साथ जॉब ऐक्सेस करना (JAWS) Windows Chrome, Firefox, Edge लाइसेंस ज़रूरी है (40 मिनट का मुफ़्त वर्शन मौजूद है)
नॉन-विज़ुअल डेस्कटॉप ऐक्सेस (NVDA) Windows Chrome और Firefox मुफ़्त (डाउनलोड करना ज़रूरी है)
Narrator Windows Edge मुफ़्त (Windows मशीन में पहले से मौजूद)
VoiceOver macOS Safari मुफ़्त (macOS मशीन में पहले से मौजूद)
ओर्का Linux Firefox मुफ़्त (Gnome-आधारित डिस्ट्रिब्यूशन में मौजूद)
TalkBack Android Chrome और Firefox मुफ़्त (Android OS के कुछ वर्शन में मौजूद)
VoiceOver iOS Safari मुफ़्त (iOS डिवाइसों में पहले से मौजूद है)

ब्राउज़र समर्थन आमतौर पर जटिल होता है और जब आप मिक्स में AT डिवाइस और ARIA विवरण जोड़ते हैं, तो चीज़ें और भी जटिल हो जाती हैं.

हालांकि, यह सभी बुरी खबरें नहीं हैं. अच्छी बात यह है कि HTML5 सुलभता, सुलभता सहायता, और डब्ल्यूसीएजी की कस्टम कंट्रोल ऐक्सेसबल डेवलपमेंट चेकलिस्ट जैसे बेहतरीन संसाधन, हमें मौजूदा ब्राउज़र और AT डिवाइस पर काम करने की सुविधा को बेहतर तरीके से समझने में मदद करते हैं. साथ ही, इससे हमें यह समझने में भी मदद मिलती है कि ARIA को सबसे पहले कब इस्तेमाल करना चाहिए.

ये रिसॉर्स, एचटीएमएल और ARIA पैटर्न के अलग-अलग सब-एलिमेंट के बारे में बताते हैं. इनमें ओपन-सोर्स कम्यूनिटी टेस्ट भी शामिल हैं. डेस्कटॉप और मोबाइल ब्राउज़र/AT डिवाइस, दोनों के लिए कुछ पैटर्न के उदाहरण भी देखे जा सकते हैं. इस तरह, इन संसाधनों से आपको उन पैटर्न, कॉम्पोनेंट, और डिज़ाइन सिस्टम के बारे में फ़ैसला लेने में आसानी होगी जिनका शायद आप इस्तेमाल करना चाहें.

दूसरी ज़रूरी बातें

जब आप ऐक्सेस किए जा सकने वाले कुछ बुनियादी पैटर्न या कॉम्पोनेंट चुन लें और ब्राउज़र और AT डिवाइस सपोर्ट में फैक्टर कर लें, तब आप पैटर्न, कॉम्पोनेंट, डिज़ाइन सिस्टम, और डेव एनवायरमेंट से जुड़े ज़्यादा खास प्रासंगिक सवालों पर जा सकते हैं.

उदाहरण के लिए, अगर आप मैनेजमेंट सिस्टम (सीएमएस) में काम कर रहे हैं या आपके पास लेगसी कोड है, तो हो सकता है कि आपको कुछ पैटर्न का इस्तेमाल करने की अनुमति मिले. समीक्षा करने के बाद, चुने गए कई पैटर्न को तुरंत एक या दो विकल्पों में से चुना जा सकता है.

कई JavaScript फ़्रेमवर्क की मदद से, डेवलपर अपने चुने हुए करीब-करीब हर पैटर्न का इस्तेमाल कर सकते हैं. ऐसे मामलों में, हो सकता है कि आपके पास कम पाबंदियां हों. साथ ही, आपके पास सबसे ज़्यादा ऐक्सेस किए जा सकने वाले पैटर्न का विकल्प चुनने का विकल्प भी होता है.

कुछ और चीज़ों को भी ध्यान में रखकर आपको कोई पैटर्न, कॉम्पोनेंट या डिज़ाइन सिस्टम चुनना होगा, जैसे कि:

  • परफ़ॉर्मेंस
  • सुरक्षा
  • खोज इंजन ऑप्टिमाइज़ेशन
  • भाषा का अनुवाद करने की सुविधा
  • तीसरे पक्ष के इंटिग्रेशन

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

आपने जो सीखा है उसकी जांच करें

पैटर्न के बारे में अपनी जानकारी को परखें

क्या ऐक्सेस किए जा सकने वाले कॉम्पोनेंट, उपयोगकर्ताओं के लिए हमेशा ऐक्सेस किए जा सकते हैं?

हां, इन कॉम्पोनेंट को इस्तेमाल करने के लिए अलग से कुछ नहीं करना होगा.
हालांकि, सुलभता के लिए बनाए गए संसाधन के दूसरे की तुलना में अपने-आप काम करने की संभावना ज़्यादा होती है, लेकिन यह ज़रूरी है कि आप सुलभता जांच करें, ताकि यह पक्का किया जा सके कि ये कॉम्पोनेंट आपके उपयोगकर्ताओं के लिए काम करें.
नहीं, आपको पहले अपने कॉम्पोनेंट की जांच करनी होगी.
यहां तक कि सुलभता के लिए डिज़ाइन किए गए कॉम्पोनेंट और पैटर्न की भी जांच की जानी चाहिए. ऐसा हो सकता है कि दूसरे मौजूदा कॉम्पोनेंट के साथ इसे इस्तेमाल न किया जा सके.