प्रोडक्ट टीमों की आदत होती है कि वे Accessibility को अंतिम परत की तरह मानती हैं। वे फीचर्स बनाती हैं, इंटरफ़ेस को पॉलिश करती हैं, और फिर—लॉन्च से दो दिन पहले—एक स्कैनर चलाती हैं। अचानक डैशबोर्ड लाल हो जाता है। मिसिंग फॉर्म लेबल्स। बिना किसी accessible name वाले बटन। हेडिंग लेवल्स जो बिना किसी चेतावनी के h1 से सीधे h4 पर कूद जाते हैं। कलर कॉम्बिनेशन जो टेक्स्ट को बैकग्राउंड शोर (noise) में बदल देते हैं। यह सूची भारी लग सकती है क्योंकि यह बहुत देर से आई है।
यह आखिरी समय की घबराहट इसलिए होती है क्योंकि Accessibility का काम मैन्युअल और धीमा महसूस होता है। एक टेस्टर जो हर टेम्पलेट को हाथ से चेक करता है, वह एक स्प्रिंट में बहुत कम चीज़ें कवर कर पाता है। लेकिन यहाँ वह हिस्सा है जिसे नज़रअंदाज़ कर दिया जाता है: देर से पाए जाने वाले अधिकांश फेलियर सूक्ष्म या एक बार की कलात्मक पसंद नहीं होते हैं। वे दोहराव वाले, संरचनात्मक (structural) मुद्दे होते हैं जो दर्जनों या सैकड़ों पेजों पर बार-बार आते हैं। यही दोहराव वह कारण है जिसकी वजह से ऑटोमेशन काम करता है।
मशीनें वास्तव में सबसे अच्छा क्या करती हैं
Accessibility टीमों को जादू की ज़रूरत नहीं है। उन्हें कवरेज की ज़रूरत है। एक कुशल मानव ऑडिटर पेजों के एक प्रतिनिधि नमूने (representative sample) का निरीक्षण कर सकता है, निर्णय ले सकता है, और उन सूक्ष्म मुद्दों को पकड़ सकता है जिनमें संदर्भ (context) की आवश्यकता होती है। वहीं दूसरी ओर, एक मशीन बिना किसी कदम को छोड़े या थके, हर रात हर पेज का निरीक्षण कर सकती है। इस समीकरण में AI का मूल्य यह नहीं है कि यह WCAG मानकों की जगह लेता है। यह टीमों के काम करने के तरीके को बदल देता है। कच्चे एरर लॉग्स (error logs) में डूबने या हर टेम्पलेट पर क्लिक करने के बजाय, AI डुप्लिकेट समस्याओं को ग्रुप कर सकता है, उन्हें आवृत्ति (frequency) के आधार पर रैंक कर सकता है, और आपको बता सकता है कि कौन से फेलियर यूजर एक्सपीरियंस को सबसे ज्यादा नुकसान पहुँचा रहे हैं।
वॉल्यूम, ट्राइएज (triage) और पैटर्न पहचान के लिए AI का उपयोग करें। इसे कच्चे स्कैनिंग लोड को संभालने दें ताकि आपकी टीम चीज़ों को ठीक करने पर ध्यान केंद्रित कर सके।
वे संकेत जो सामान्य विफलताओं को उजागर करते हैं
अधिकांश Accessibility फेलियर स्पष्ट और पता लगाने योग्य संकेत देते हैं। एक स्कैनर बिना alt attribute वाली इमेज को पहचान सकता है। यह उन बटनों को ढूंढ सकता है जो DOM में तो मौजूद हैं लेकिन उनमें कोई टेक्स्ट या aria-label नहीं है, जिससे स्क्रीन रीडर उपयोगकर्ताओं को यह पता नहीं चलता कि बटन क्या करता है। यह उन लिंक्स को फ्लैग कर सकता है जो "click here" या "read more" कहते हैं, जिससे पेजों पर टैब करने वाले उपयोगकर्ताओं को गंतव्य का कोई संदर्भ नहीं मिलता। यह उन कलर कॉम्बिनेशन को भी पकड़ता है जो कंट्रास्ट की आवश्यकताओं को पूरा नहीं करते हैं। यह उन हेडिंग पदानुक्रमों (hierarchies) को नोट करता है जो लेवल्स को छोड़ देते हैं, जिससे उन लोगों के लिए नेविगेशन टूट जाता है जो पेज को समझने के लिए हेडिंग्स पर भरोसा करते हैं।
ये पैटर्न-आधारित समस्याएँ हैं। वे अनुमानित कोड मार्कर्स के रूप में दिखाई देती हैं, जिसका अर्थ है कि वे ठीक उसी तरह का काम हैं जिसे खोजने में ऑटोमेशन माहिर है।
एक पाइपलाइन बनाना जो वास्तविक समस्याओं को पकड़े
एक अच्छा सेटअप केवल एक बार चलने वाले एकल टूल पर निर्भर नहीं करता है। यह कई परतों (layers) को जोड़ता है। पहली परत एक रूल इंजन है जो कोड का ही स्कैन करता है। ये इंजन डेवलपर्स द्वारा कंपोनेंट्स लिखते समय मार्कअप की WCAG दिशानिर्देशों के विरुद्ध जाँच करते हैं, और बिना लेबल वाले इनपुट या अमान्य एट्रिब्यूट्स को ब्राउज़र तक पहुँचने से पहले ही फ्लैग कर देते हैं।
दूसरी परत ब्राउज़र ऑटोमेशन है। स्टैटिक कोड एनालिसिस उस चीज़ को नहीं पकड़ सकता जो मोडल खुलने, ड्रॉपडाउन विस्तार करने, या फॉर्म वैलिडेशन एरर आने के बाद होती है। ऑटोमेटेड ब्राउज़र्स को वास्तविक यूजर जर्नी—साइनअप फ्लो, चेकआउट प्रक्रिया, अकाउंट डैशबोर्ड—के माध्यम से चलना होगा, जहाँ यूजर की क्रिया के आधार पर कंटेंट डायनामिक रूप से बदलता है। यदि आपकी पासवर्ड आवश्यकताएँ केवल फ़ील्ड से फोकस हटने के बाद दिखाई देती हैं, तो केवल एक कोड स्कैनर उस अनाउंसमेंट फेलियर को कभी नहीं देख पाएगा।
तीसरी परत वह है जहाँ AI निष्कर्षों की व्याख्या करता है और डुप्लिकेट्स को मर्ज करता है। यदि एक ही बिना लेबल वाला आइकन बटन अस्सी पेजों में उपयोग किए जाने वाले हेडर कंपोनेंट में मौजूद है, तो सिस्टम को इसे एक कंपोनेंट-लेवल दोष के रूप में एक बार रिपोर्ट करना चाहिए, न कि अस्सी अलग-अलग पेज-लेवल बग के रूप में। यह टीमों को शोर (noise) में डूबने से बचाता है।
चौथी परत मानव समीक्षा (human review) है। मशीन को लगातार निरीक्षण करना चाहिए, लेकिन रिलीज़ से पहले एक व्यक्ति को एज केसेस (edge cases) की समीक्षा करनी चाहिए। किसी भी ऑटोमेटेड पाइपलाइन को अपने आप अंतिम फैसला नहीं सुनाना चाहिए।
तकनीकी शब्दावली को कार्रवाई में बदलना
कच्चे स्कैनर आउटपुट अक्सर बैकलॉग में ही रह जाते हैं क्योंकि वे डेवलपर्स के बजाय ऑडिटर्स के लिए बनाए गए स्पेसिफिकेशन की तरह लगते हैं। "अपर्याप्त कलर कंट्रास्ट रेशियो" कहने वाली रिपोर्ट को नज़रअंदाज़ कर दिया जाता है क्योंकि यह अमूर्त (abstract) और कम प्राथमिकता वाली लगती है। "सफेद बैकग्राउंड पर ग्रे हेल्प टेक्स्ट पढ़ना मुश्किल है" कहना एक डेवलपर को ठीक बताता है कि क्या ठीक करना है, कहाँ देखना है, और वास्तविक उपयोगकर्ताओं के लिए यह क्यों मायने रखता है। AI तकनीकी WCAG विफलताओं को सरल भाषा में अनुवाद करके इस अंतर को पाटने में मदद कर सकता है जिसे प्रोडक्ट टीमें वास्तव में पढ़ती हैं और उस पर कार्रवाई करती हैं।
आपको अपने निष्कर्षों को केवल अलर्ट मानने के बजाय उन्हें कॉन्फिडेंस लेवल (confidence levels) भी देने की आवश्यकता है। हाई कॉन्फिडेंस वाली समस्याएँ, जैसे कि बिना लेबल वाले फॉर्म इनपुट, ऑटो-टिकट बना सकती हैं क्योंकि WCAG द्वारा इनका समाधान लगभग हमेशा आवश्यक होता है और इसका समाधान सीधा होता है। मीडियम कॉन्फिडेंस वाले निष्कर्ष, जैसे कि संदिग्ध alt text जो वर्णनात्मक होने के बजाय कीवर्ड-स्टफ्ड (keyword-stuffed) हो सकता है, उन्हें यह तय करने के लिए मानवीय समीक्षा की आवश्यकता होती है कि विवरण उपयोगी है या नहीं। लो कॉन्फिडेंस वाली वस्तुओं को मैन्युअल टेस्टिंग के लिए रिपोर्ट में ही रहना चाहिए। एक स्कैनर एक गायब alt attribute को देख सकता है, लेकिन वह यह नहीं जान सकता कि कोई इमेज सजावटी है या सामग्री को समझने के लिए आवश्यक है। उस संदर्भ (context) के लिए अभी भी एक इंसान की आवश्यकता होती है।
एक बार ठीक करें, हर जगह ठीक करें
AI टीमों को यह खोजने में मदद करता है कि समस्याएँ कहाँ केंद्रित हैं। यदि पचास स्क्रीन पर एक खराब तरीके से बनाया गया बटन कंपोनेंट (button component) भेजा जाता है, तो कंपोनेंट को एक बार ठीक करने से समस्याओं की संख्या तुरंत कम हो जाती है। यह काम को पेज-दर-पेज समस्याओं को सुलझाने के बजाय व्यवस्थित कंपोनेंट लाइब्रेरी रखरखाव (component library maintenance) में बदल देता है। पैटर्न पहचान (Pattern recognition) वह जगह है जहाँ AI वास्तव में फायदेमंद साबित होता है। यह सैकड़ों पेजों के बीच संबंध जोड़ता है ताकि टीमें चालीस अलग-अलग Jira टिकटों में एक ही बग को ठीक करने से बच सकें।
स्कैनर को pull requests से जोड़ने से यह फीडबैक सटीक बना रहता है। जब एक डेवलपर को मर्ज करने से पहले ही यह अलर्ट मिलता है कि उनके नए मार्कअप (markup) ने हेडिंग लेवल को छोड़ दिया है, तो उसे ठीक करने में कुछ ही मिनट लगते हैं। जब वही समस्या प्रोडक्शन में पहुँच जाती है और लॉन्च से दो दिन पहले पाई जाती है, तो उसे ठीक करने के लिए हॉटफिक्स (hotfix), रिग्रेशन टेस्टिंग और स्टेकहोल्डर कम्युनिकेशन की आवश्यकता होती है। छोटे और तेज़ लूप समय बचाते हैं और एक्सेसिबिलिटी डेब्ट (accessibility debt) को कम करते हैं।
श्रम का विभाजन
ऑटोमेशन अपने आप में आपके प्रोडक्ट को एक्सेसिबल नहीं बना देगा। हालाँकि, यह आपकी टीम को बार-बार एक ही तरह की स्पष्ट विफलताओं को भेजने से ज़रूर रोक देगा। अपने CI पाइपलाइन में ऑटोमेटेड चेक चलाएँ। कंटेंट एडिटर्स या नई सुविधाओं द्वारा पेश किए गए रिग्रेशन को पकड़ने के लिए हर रात स्टेजिंग साइट्स को क्रॉल करें। बैकलॉग को प्रबंधनीय रखने के लिए समस्याओं को कंपोनेंट के आधार पर समूहित करें। मानवीय ध्यान उन साइट के हिस्सों के लिए सुरक्षित रखें जहाँ संदर्भ (context) सबसे अधिक मायने रखता है: यह तय करना कि क्या किसी इमेज को alt text की आवश्यकता है, जटिल कस्टम कंपोनेंट्स का मूल्यांकन करना, और उन फ्लो (flows) का परीक्षण करना जिनमें उपयोगकर्ता के इरादे (user intent) को समझना आवश्यक है।
वॉल्यूम, ट्राइएज (triage) और पैटर्न पहचान के लिए AI का उपयोग करें। मशीनों को हर रात हर पेज पर दोहराव वाले स्कैनिंग का काम करने दें। इंसानों को निर्णय लेने (judgment calls) का काम करने दें। श्रम का यही विभाजन है जिससे एक्सेसिबिलिटी प्री-लॉन्च घबराहट से बदलकर एक सामान्य इंजीनियरिंग आदत बन जाती है।
Source: https://dev.to/henryv/automating-wcag-compliance-with-ai-4ogp
Join the discussion: https://t.me/GyaanSetuAi