उत्पादन टीम्सना (Product teams) सहसा ॲक्सेसिबिलिटी (accessibility) म्हणजे केवळ शेवटचा एक 'पेंटचा थर' असल्यासारखे वाटते. ते फीचर्स तयार करतात, इंटरफेस पॉलिश करतात आणि मग—लाँचच्या दोन दिवस आधी—स्कॅनर चालवतात. अचानक डॅशबोर्डवर लाल दिवे चमकू लागतात. फॉर्म लेबल्स गहाळ आहेत. बटणांना कोणतेही ॲक्सेसिबल नाव नाही. हेडिंग लेव्हल्स कोणतीही सूचना न देता h1 वरून थेट h4 वर जातात. रंगांचे असे कॉम्बिनेशन जे मजकूर आणि बॅकग्राउंडमध्ये फरक करणे कठीण करतात. ही यादी खूप मोठी आणि थकवणारी वाटते कारण ती वेळेवर केलेली नसते.
ही शेवटच्या क्षणाची घबराट निर्माण होते कारण ॲक्सेसिबिलिटीचे काम मॅन्युअल आणि संथ वाटते. एका स्प्रिंटमध्ये प्रत्येक टेम्पलेट हाताने तपासून पाहणारा टेस्टर मर्यादितच काम करू शकतो. पण येथे एक महत्त्वाची गोष्ट दुर्लक्षित केली जाते: उशिरा आढळलेले बहुतेक दोष हे केवळ एखादा कलात्मक निर्णय नसून ते सूक्ष्म किंवा वैयक्तिक नसतात. ते पुनरावृत्ती होणारे, स्ट्रक्चरल (structural) प्रश्न असतात जे डझनभर किंवा शेकडो पेजेसवर पुन्हा पुन्हा येतात. हीच पुनरावृत्ती आहे, ज्यामुळे ऑटोमेशन प्रभावी ठरते.
मशीन नेमके काय उत्तम प्रकारे करू शकतात
ॲक्सेसिबिलिटी टीम्सना जादूची गरज नाही, तर त्यांना कव्हरेजची (coverage) गरज आहे. एक कुशल मानवी ऑडिटर पेजेसचा प्रतिनिधी नमुना तपासू शकतो, निर्णय घेऊ शकतो आणि संदर्भाची गरज असलेले सूक्ष्म प्रश्न पकडू शकतो. दुसरीकडे, मशीन कोणताही टप्पा न वगळता किंवा न थकता, दररोज प्रत्येक पेजची तपासणी करू शकते. या समीकरणात AI चे मूल्य हे WCAG मानकांची जागा घेणे नसून, ते टीम्सच्या कामाची पद्धत बदलणे आहे. रॅव एरर लॉग्समध्ये (raw error logs) बुडून जाण्याऐवजी किंवा प्रत्येक टेम्पलेटवर क्लिक करण्याऐवजी, AI डुप्लिकेट समस्यांचे गट करू शकते, त्यांच्या वारंवारतेनुसार त्यांना रँक करू शकते आणि कोणत्या त्रुटींमुळे युजर एक्सपिरियन्सवर (user experience) सर्वाधिक परिणाम होत आहे हे सांगू शकते.
मोठ्या प्रमाणावरील डेटा, ट्रायज (triage) आणि पॅटर्न रिकग्निशनसाठी AI चा वापर करा. स्कॅनिंगचा मोठा भार AI वर सोपवा जेणेकरून तुमची टीम गोष्टी सुधारण्यावर लक्ष केंद्रित करू शकेल.
सामान्य त्रुटी दर्शवणारे संकेत
बहुतेक ॲक्सेसिबिलिटी त्रुटी स्पष्ट आणि शोधण्यायोग्य संकेत देतात. स्कॅनर 'alt' ॲट्रिब्युट नसलेली इमेज शोधू शकतो. तो असे बटण शोधू शकतो जे DOM मध्ये आहे पण त्यात कोणताही मजकूर किंवा aria-label नाही, ज्यामुळे स्क्रीन रीडर वापरकर्त्यांना ते बटण काय करते हे समजत नाही. तो "click here" किंवा "read more" असे म्हणणारे लिंक्स देखील शोधू शकतो, ज्यामुळे पेजेसवर टॅब (tab) वापरणाऱ्या वापरकर्त्यांना त्या लिंकचे नेमके ठिकाण समजत नाही. तो रंगांचे असे कॉम्बिनेशन देखील शोधतो जे कॉन्ट्रास्टच्या (contrast) गरजा पूर्ण करत नाहीत. तो हेडिंग हायरार्कीमधील (heading hierarchies) त्रुटी देखील नोंदवतो, ज्यामुळे हेडिंग्सचा वापर करून पेज समजून घेणाऱ्या लोकांसाठी नेव्हिगेशनमध्ये अडथळा निर्माण होतो.
या पॅटर्नवर आधारित समस्या आहेत. त्या कोडमधील अंदाजित खुणा (markers) म्हणून दिसतात, याचा अर्थ ऑटोमेशन अशा प्रकारची कामे शोधण्यात अत्यंत उत्कृष्ट आहे.
वास्तविक समस्या शोधणारी पाइपलाइन तयार करणे
एक चांगली सेटअप ही केवळ एकदा चालणाऱ्या एका टूलवर अवलंबून नसते. ती विविध स्तरांचे (layers) मिश्रण असते. पहिला स्तर म्हणजे 'रूल इंजिन' (rule engine) जो कोडची स्वतः तपासणी करतो. डेव्हलपर्स घटक (components) तयार करत असतानाच हे इंजिन WCAG मार्गदर्शक तत्त्वांच्या आधारे मार्कअप तपासते आणि अनलेबल इनपुट्स किंवा अवैध ॲट्रिब्युट्स ब्राउझरपर्यंत पोहोचण्यापूर्वीच सूचित करते.
दुसरा स्तर म्हणजे ब्राउझर ऑटोमेशन. स्टॅटिक कोड अनालिसिस (Static code analysis) मॉडेल उघडल्यानंतर, ड्रॉपडाउन विस्तारल्यानंतर किंवा फॉर्म व्हॅलिडेशन एरर आल्यानंतर काय घडते हे शोधू शकत नाही. ऑटोमेटेड ब्राउझर्सना खऱ्या युजर जर्नी—साइनअप फ्लो, चेकआउट प्रक्रिया, अकाउंट डॅशबोर्ड—मधून जावे लागते, जिथे युजरच्या कृतीनुसार कंटेंट डायनॅमिकली बदलतो. जर तुमचे पासवर्डचे नियम केवळ फील्डमधून फोकस बाहेर गेल्यावर दिसत असतील, तर केवळ कोड स्कॅनरला ही त्रुटी कधीच दिसणार नाही.
तिसरा स्तर म्हणजे जिथे AI निष्कर्षांचा अर्थ लावते आणि डुप्लिकेट्स एकत्र करते. जर एखादे अनलेबल आयकॉन बटण ८० पेजेसवर वापरल्या जाणाऱ्या हेडर कंपोनंटमध्ये असेल, तर सिस्टमने त्याला ८० वेगवेगळ्या पेज-लेव्हल बग्स म्हणून न सांगता, एकदा कंपोनंट-लेव्हल दोष म्हणून रिपोर्ट केले पाहिजे. यामुळे टीम्सला अनावश्यक माहितीच्या (noise) ढिगाऱ्यात बुडून जाण्यापासून वाचवता येते.
चौथा स्तर म्हणजे मानवी पुनरावलोकन (human review). मशीनने सतत तपासणी केली पाहिजे, परंतु रिलीज करण्यापूर्वी एखाद्या व्यक्तीने 'एज केसेस' (edge cases) तपासाव्यात. कोणत्याही ऑटोमेटेड पाइपलाइनला स्वतःचा अंतिम निर्णय घेण्याचा अधिकार नसावा.
तांत्रिक शब्दरचना कृतीमध्ये रूपांतरित करणे
स्कॅनरचा कच्चा आउटपुट (raw output) अनेकदा बॅकलॉगमध्येच राहतो कारण तो डेव्हलपर्ससाठी नसून ऑडिटर्ससाठी असलेल्या स्पेसिफिकेशनसारखा वाचला जातो. "अपुरे कलर कॉन्ट्रास्ट रेशो" (insufficient color contrast ratio) असा रिपोर्ट दुर्लक्षित केला जातो कारण तो अमूर्त आणि कमी महत्त्वाचा वाटतो. त्याऐवजी "पांढऱ्या बॅकग्राउंडवर राखाडी रंगाचा हेल्प टेक्स्ट वाचणे कठीण आहे" असे म्हटल्यास डेव्हलपरला नक्की काय सुधारायचे आहे, कुठे पाहायचे आहे आणि ते खऱ्या वापरकर्त्यांसाठी का महत्त्वाचे आहे हे स्पष्ट समजते. तांत्रिक WCAG त्रुटींचे साध्या भाषेत रूपांतर करून, उत्पादन टीम्सना त्या वाचता येतील आणि त्यावर कृती करता येईल, यासाठी AI मदत करू शकते.
तुम्हाला प्रत्येक अलर्टला सारखे न मानता, तुमच्या निष्कर्षांना विश्वासाची पातळी (confidence levels) नियुक्त करणे देखील आवश्यक आहे. उच्च विश्वासार्हता असलेल्या समस्या, जसे की लेबल नसलेले फॉर्म इनपुट्स, आपोआप तिकीट तयार करू शकतात कारण WCAG नुसार त्यांचे निराकरण करणे नेहमीच आवश्यक असते आणि उपाय सोपा असतो. मध्यम विश्वासार्हता असलेले निष्कर्ष, जसे की संशयास्पद 'alt text' जे वर्णनात्मक असण्याऐवजी कीवर्ड-स्टफ्ड (keyword-stuffed) असू शकते, ते उपयुक्त आहे की नाही हे ठरवण्यासाठी मानवी पुनरावलोकनाची गरज असते. कमी विश्वासार्हता असलेल्या गोष्टी मॅन्युअल टेस्टिंगसाठी रिपोर्टमध्ये राहिल्या पाहिजेत. स्कॅनरला 'alt attribute' गहाळ असल्याचे दिसते, परंतु एखादे चित्र सजावटीचे आहे की मजकूर समजून घेण्यासाठी आवश्यक आहे, हे त्याला माहित नसते. त्यासाठी मानवी संदर्भाची गरज असतेच.
एकदा सुधारा, सर्वत्र सुधारा
AI टीम्सना समस्या कुठे केंद्रित आहेत हे शोधण्यात मदत करते. जर एखादा चुकीच्या पद्धतीने बनवलेला 'button component' पन्नास स्क्रीनवर वापरला गेला असेल, तर तो घटक एकदा सुधारल्यास समस्यांची संख्या लगेच कमी होते. यामुळे काम 'पेज-बाय-पेज' समस्या सोडवण्याऐवजी पद्धतशीर 'component library maintenance' कडे वळते. पॅटर्न रिकग्निशन (Pattern recognition) मध्ये AI चा खरा फायदा होतो. ते शेकडो पानांवरील दुवे जोडते जेणेकरून टीम्सना चाळीस वेगवेगळ्या Jira तिकीटमध्ये तोच बग पुन्हा पुन्हा सुधारावा लागणार नाही.
स्कॅनर्सना 'pull requests' शी जोडल्यामुळे हा फीडबॅक जलद आणि अचूक राहतो. जेव्हा एखादा डेव्हलपर मर्ज करण्यापूर्वीच त्याला अलर्ट मिळतो की त्याच्या नवीन मार्कअपमुळे 'heading level' सुटला आहे, तेव्हा तो सुधारण्यास काही मिनिटे लागतात. जेव्हा तीच समस्या प्रोडक्शनमध्ये जाते आणि लाँचच्या दोन दिवस आधी आढळते, तेव्हा ती सुधारण्यासाठी 'hotfix', 'regression testing' आणि स्टेकहोल्डरशी संवाद साधावा लागतो. जलद फीडबॅक लूपमुळे वेळ वाचतो आणि 'accessibility debt' कमी होतो.
कामाची विभागणी
ऑटोमेशनमुळे तुमचे उत्पादन आपोआप सुलभ (accessible) होणार नाही. तथापि, ते तुमच्या टीमला वारंवार त्याच स्पष्ट चुका पाठवण्यापासून रोखेल. तुमच्या CI पाइपलाइनमध्ये ऑटोमेटेड चेक चालवा. कंटेंट एडिटर्स किंवा नवीन फीचर्समुळे निर्माण होणारे रिग्रेशन्स (regressions) पकडण्यासाठी दर रात्री स्टेजिंग साइट्स क्रॉल करा. बॅकलॉग व्यवस्थापित करण्यायोग्य ठेवण्यासाठी समस्यांचे घटकानुसार (component) गट करा. ज्या ठिकाणी संदर्भ सर्वात महत्त्वाचा असतो, तिथे मानवी लक्ष केंद्रित करा: जसे की एखाद्या प्रतिमेला 'alt text' ची गरज आहे की नाही हे ठरवणे, जटिल कस्टम कंपोनंट्सचे मूल्यमापन करणे आणि वापरकर्त्याचा हेतू समजून घेण्याची आवश्यकता असलेल्या फ्लो (flows) तपासणे.
मोठ्या प्रमाणावरील कामे, ट्रायज (triage) आणि पॅटर्न रिकग्निशनसाठी AI चा वापर करा. दर रात्री प्रत्येक पानावर होणारे पुनरावृत्तीचे स्कॅनिंग मशीनला करू द्या. निर्णय घेण्याचे काम मानवांना सोपवा. कामाच्या या विभागणीमुळेच ॲक्सेसिबिलिटी ही लाँचपूर्वीची घबराट न राहता एक सामान्य इंजिनिअरिंग सवय बनते.
स्रोत: https://dev.to/henryv/automating-wcag-compliance-with-ai-4ogp
चर्चांमध्ये सामील व्हा: https://t.me/GyaanSetuAi