தயாரிப்பு குழுக்கள் அணுகல்தன்மையை (accessibility) ஒரு இறுதிப் பூச்சு போலக் கருதும் பழக்கம் கொண்டவர்கள். அவர்கள் அம்சங்களை உருவாக்குகிறார்கள், இடைமுகத்தை (interface) மெருகேற்றுகிறார்கள், பின்னர்—வெளியிடுவதற்கு இரண்டு நாட்களுக்கு முன்னால்—ஒரு ஸ்கேனரை இயக்குகிறார்கள். திடீரென்று டேஷ்போர்டு சிவப்பு நிறத்தில் மின்னுகிறது. விடுபட்ட படிவ லேபிள்கள் (form labels). அணுகல்தன்மை கொண்ட பெயர் இல்லாத பொத்தான்கள் (buttons). எச்சரிக்கையின்றி h1 இலிருந்து h4 க்குத் தாவும் தலைப்பு நிலைகள் (heading levels). உரையை பின்னணி இரைச்சலாக மாற்றும் வண்ணக் கலவைகள். இந்தப் பட்டியல் பார்ப்பதற்கு மலைப்பாகத் தோன்றுகிறது, ஏனெனில் இது காலதாமதமாக வந்த ஒன்று.
இந்த கடைசி நிமிடப் பதற்றம் ஏற்படுவதற்குக் காரணம், அணுகல்தன்மை சார்ந்த வேலைகள் கைமுறையாகவும் மெதுவாகவும் இருப்பது போன்ற உணர்வைத் தருவதே ஆகும். ஒரு டெஸ்டர் ஒவ்வொரு டெம்ப்ளேட்டையும் கையால் கிளிக் செய்து பார்ப்பதன் மூலம் ஒரு ஸ்பிரிண்டில் (sprint) குறிப்பிட்ட அளவு மட்டுமே சரிபார்க்க முடியும். ஆனால் இங்கே கவனிக்கப்படாமல் போகும் ஒரு விஷயம் உள்ளது: தாமதமாகக் கண்டறியப்படும் பெரும்பாலான தோல்விகள் நுணுக்கமான அல்லது ஒருமுறை மட்டும் நிகழும் கலைநயமிக்கத் தெரிவுகள் அல்ல. அவை டஜன் கணக்கான அல்லது நூற்றுக்கணக்கான பக்கங்களில் மீண்டும் மீண்டும் நிகழும் தொடர்ச்சியான, கட்டமைப்பு ரீதியான சிக்கல்கள். அந்தத் திரும்பத் திரும்ப நிகழும் தன்மையே ஆட்டோமேஷன் (automation) வேலை செய்வதற்கான சரியான காரணமாகும்.
இயந்திரங்கள் உண்மையில் எதில் சிறந்து விளங்குகின்றன
அணுகல்தன்மை குழுக்களுக்கு மந்திரம் தேவையில்லை. அவர்களுக்குப் பரவலான கவரேஜ் (coverage) தேவைப்படுகிறது. ஒரு திறமையான மனித ஆய்வாளர் பக்கங்களின் ஒரு மாதிரியை ஆய்வு செய்து, தனது தீர்ப்பைப் பயன்படுத்தி, சூழல் சார்ந்த நுணுக்கமான சிக்கல்களைக் கண்டறிய முடியும். அதே நேரத்தில், ஒரு இயந்திரம் எந்த ஒரு படிநிலையையும் தவிர்க்காமலும், சோர்வடையாமலும், ஒவ்வொரு இரவும் ஒவ்வொரு பக்கத்தையும் ஆய்வு செய்ய முடியும். இந்தச் சமன்பாட்டில் AI-ன் மதிப்பு அது WCAG தரநிலைகளை மாற்றுவது அல்ல. மாறாக, அது குழுக்கள் வேலை செய்யும் முறையை மாற்றுகிறது. ஒரு டெஸ்டர் மூலத் தரவுப் பதிவுகளில் (error logs) மூழ்கிப் போவதற்குப் பதிலாக அல்லது ஒவ்வொரு டெம்ப்ளேட்டையும் கிளிக் செய்வதற்குப் பதிலாக, AI ஒரே மாதிரியான சிக்கல்களைக் குழுவாக்கவும், அவற்றின் அதிர்வெண்ணின் அடிப்படையில் வரிசைப்படுத்தவும், எந்தத் தோல்விகள் பயனர் அனுபவத்தை (user experience) அதிகம் பாதிக்கின்றன என்பதைத் தெரிவிக்கவும் முடியும்.
அளவு (volume), வகைப்படுத்துதல் (triage) மற்றும் வடிவங்களைக் கண்டறிதல் (pattern recognition) ஆகியவற்றிற்கு AI-ஐப் பயன்படுத்தவும். உங்கள் குழு சிக்கல்களைச் சரிசெய்வதில் கவனம் செலுத்த, ஸ்கேனிங் சுமைகளை அது கையாளுவதாக இருக்கட்டும்.
பொதுவான தோல்விகளை வெளிப்படுத்தும் சமிக்ஞைகள்
பெரும்பாலான அணுகல்தன்மை தோல்விகள் தெளிவான, கண்டறியக்கூடிய சமிக்ஞைகளை வெளிப்படுத்துகின்றன. ஒரு ஸ்கேனரால் 'alt' பண்பு (attribute) விடுபட்ட ஒரு படத்தை அடையாளம் காண முடியும். DOM-இல் இருக்கும் ஆனால் எந்த உரையோ அல்லது aria-label-ஓ இல்லாத பொத்தான்களைக் கண்டறிய முடியும், இது ஸ்கிரீன் ரீடர் (screen reader) பயனர்களுக்கு அந்தப் பொத்தான் என்ன செய்கிறது என்பதைப் புரிய வைக்காது. "இங்கே கிளிக் செய்யவும்" அல்லது "மேலும் படிக்க" என்று கூறும் இணைப்புகளை (links) அது சுட்டிக்காட்ட முடியும், இது பக்கங்களின் வழியாகத் தாவும் பயனர்களுக்கு இலக்கு குறித்த சூழலைத் தராது. மாறுபட்ட நிறத் தேவைகளைப் (contrast requirements) பூர்த்தி செய்யாத வண்ணக் கலவைகளையும் அது கண்டறியும். பக்கத்தை வரைபடமாக்க தலைப்புகளைச் சார்ந்திருக்கும் மக்களுக்குத் தலைப்பு வரிசையைத் (heading hierarchies) தாண்டிச் செல்லும் நிலைகளையும் அது குறிக்கும்.
இவை வடிவ அடிப்படையிலான (pattern-based) சிக்கல்கள். இவை கணிக்கக்கூடிய குறியீடு குறிகாட்டிகளாக (code markers) வெளிப்படுகின்றன, அதாவது ஆட்டோமேஷன் கண்டறிவதில் சிறந்து விளங்கும் அதே வகையான வேலை இவை.
உண்மையான சிக்கல்களைக் கண்டறியும் ஒரு செயல்முறைத் தொடரை (Pipeline) உருவாக்குதல்
ஒரு சிறந்த அமைப்பு என்பது ஒருமுறை இயங்கும் ஒற்றைக் கருவியைச் சார்ந்து இருக்காது. அது பல அடுக்குகளைக் கொண்டது. முதல் அடுக்கு என்பது குறியீட்டைத் தானே ஸ்கேன் செய்யும் ஒரு விதி இயந்திரம் (rule engine) ஆகும். டெவலப்பர்கள் கூறுகளை (components) உருவாக்கும்போதே, இந்த இயந்திரங்கள் மார்க்கப் (markup) குறியீட்டை WCAG வழிகாட்டுதல்களுடன் ஒப்பிட்டுச் சரிபார்க்கின்றன, லேபிள்கள் இல்லாத உள்ளீடுகள் அல்லது செல்லாத பண்புகளை (invalid attributes) உலாவியில் (browser) தோன்றுவதற்கு முன்பே சுட்டிக்காட்டுகின்றன.
இரண்டாவது அடுக்கு பிரவுசர் ஆட்டோமேஷன் (browser automation) ஆகும். ஒரு மாடல் (modal) திறந்த பிறகு, ஒரு டிராப்டவுன் (dropdown) விரிவடைந்த பிறகு அல்லது ஒரு படிவச் சரிபார்ப்புப் பிழை (form validation error) தோன்றிய பிறகு என்ன நடக்கிறது என்பதை நிலையான குறியீடு பகுப்பாய்வு (static code analysis) கண்டறிய முடியாது. உள்ளடக்கங்கள் பயனர் செயல்பாட்டின் அடிப்படையில் மாறும் — பதிவு செய்யும் செயல்முறைகள் (signup flows), பணம் செலுத்தும் முறைகள் (checkout processes), கணக்கு டேஷ்போர்டுகள் — போன்ற உண்மையான பயனர் பயணங்களின் வழியாக ஆட்டோமேட்டட் பிரவுசர்கள் செல்ல வேண்டும். உங்கள் கடவுச்சொல் தேவைகள் ஒரு புலத்திலிருந்து கவனம் (focus) விலகிய பின்னரே தோன்றினால், ஒரு குறியீடு ஸ்கேனரால் அந்த அறிவிப்புத் தோல்வியைக் (announcement failure) கண்டறிய முடியாமல் போகலாம்.
மூன்றாவது அடுக்கு, AI கண்டுபிடிப்புகளை விளக்கி, நகல் சிக்கல்களை ஒன்றிணைக்கும் இடமாகும். ஒரே மாதிரியான லேபிள் இல்லாத ஐகான் பொத்தான் எண்பது பக்கங்களில் பயன்படுத்தப்படும் ஒரு ஹெடர் (header) கூறில் இருந்தால், அந்த அமைப்பு அதை எண்பது தனித்தனி பக்க அளவிலான பிழைகளாகக் காட்டாமல், ஒரு கூறு அளவிலான குறைபாடாக (component-level defect) ஒருமுறை மட்டுமே தெரிவிக்க வேண்டும். இது குழுக்கள் தேவையற்ற தகவல்களில் மூழ்கிப் போவதைத் தடுக்கிறது.
நான்காவது அடுக்கு மனித ஆய்வு (human review) ஆகும். ஒரு இயந்திரம் தொடர்ந்து ஆய்வு செய்ய வேண்டும், ஆனால் வெளியிடுவதற்கு முன் ஒரு நபர் விளிம்பு நிலைச் சூழல்களை (edge cases) ஆய்வு செய்ய வேண்டும். எந்தவொரு ஆட்டோமேட்டட் பைப்பைலைனும் (automated pipeline) அதன் சொந்த முடிவை மட்டும் இறுதித் தீர்ப்பாகக் கொண்டிருக்கக் கூடாது.
தொழில்நுட்பச் சொற்களைச் செயல்களாக மாற்றுதல்
ஸ்கேனரின் மூலத் தரவுப் பதிவுகள் பெரும்பாலும் பணிப் பட்டியலில் (backlogs) அப்படியே முடங்கிவிடுகின்றன, ஏனெனில் அவை டெவலப்பர்களுக்காக அல்லாமல் ஆய்வாளர்களுக்காக உருவாக்கப்பட்ட விவரக்குறிப்பு போலத் தோன்றுகின்றன. "போதிய வண்ண மாறுபாடு விகிதம் இல்லை" (insufficient color contrast ratio) என்று கூறும் ஒரு அறிக்கை, அது ஒரு பொதுவான மற்றும் குறைந்த முன்னுரிமை கொண்ட விஷயமாகத் தெரிவதால் புறக்கணிக்கப்படுகிறது. "வெள்ளை பின்னணியில் சாம்பல் நிற உதவி உரை (help text) படிக்க கடினமாக உள்ளது" என்று கூறுவது, ஒரு டெவலப்பர் எதைச் சரிசெய்ய வேண்டும், எங்கு பார்க்க வேண்டும் மற்றும் அது உண்மையான பயனர்களுக்கு ஏன் முக்கியம் என்பதைத் துல்லியமாகத் தெரிவிக்கும். தொழில்நுட்ப WCAG தோல்விகளைத் தயாரிப்பு குழுக்கள் உண்மையில் வாசித்துச் செயல்படும் எளிய மொழியாக மொழிபெயர்ப்பதன் மூலம் AI இந்த இடைவெளியைக் குறைக்க உதவும்.
நீங்கள் ஒவ்வொரு எச்சரிக்கையையும் ஒரே மாதிரியாகக் கருதாமல், உங்கள் கண்டுபிடிப்புகளுக்குத் தன்னம்பிக்கை நிலைகளை (confidence levels) ஒதுக்கீடு செய்ய வேண்டும். லேபிள்கள் இல்லாத படிவ உள்ளீடுகள் (unlabeled form inputs) போன்ற அதிகத் தன்னம்பிக்கை கொண்ட சிக்கல்களுக்குத் தானாகவே டிக்கெட்டுகளை உருவாக்கலாம், ஏனெனில் இதற்கான தீர்வு எப்போதும் WCAG விதிகளின்படி அவசியமானது மற்றும் எளிதானது. விவரிப்பிற்குப் பதிலாக வெறும் முக்கியச் சொற்களை (keywords) மட்டுமே கொண்ட சந்தேகத்திற்குரிய alt text போன்ற நடுத்தரத் தன்னம்பிக்கை கொண்ட கண்டுபிடிப்புகள், அந்த விவரிப்பு பயனுள்ளதா என்பதைத் தீர்மானிக்க மனித ஆய்வுக்குத் தேவைப்படுகின்றன. குறைந்த தன்னம்பிக்கை கொண்ட விஷயங்கள் கைமுறைச் சோதனைக்காக (manual testing) அறிக்கைகளிலேயே இருக்க வேண்டும். ஒரு ஸ்கேனர் (scanner) விடுபட்ட alt attribute-ஐக் கண்டறியும், ஆனால் ஒரு படம் அலங்காரத்திற்காகவா அல்லது உள்ளடக்கத்தைப் புரிந்துகொள்வதற்கு அவசியமானதா என்பதை அது அறியாது. அந்தச் சூழலைப் புரிந்துகொள்ள இன்னும் ஒரு மனிதன் தேவைப்படுகிறான்.
ஒருமுறை சரிசெய்தால், எல்லா இடங்களிலும் சரிசெய்யலாம்
சிக்கல்கள் எங்கு குவிகின்றன என்பதைக் கண்டறிய AI குழுக்களுக்கு உதவுகிறது. சரியாக வடிவமைக்கப்படாத ஒரு பட்டன் காம்போனென்ட் (button component) ஐம்பது திரைகளில் இருந்தால், அந்த காம்போனென்ட்டை ஒருமுறை சரிசெய்வதன் மூலம் சிக்கல்களின் எண்ணிக்கையை உடனடியாகக் குறைக்கலாம். இது வேலையை ஒவ்வொரு பக்கமாகச் சரிசெய்யும் முறையிலிருந்து, முறையான காம்போனென்ட் லைப்ரரி பராமரிப்பு (systematic component library maintenance) முறைக்கு மாற்றுகிறது. பேட்டர்ன் ரெக்னகிஷன் (Pattern recognition) மூலம் AI பெரும் பலனைத் தருகிறது. இது நூற்றுக்கணக்கான பக்கங்களுக்கு இடையே உள்ள தொடர்புகளை இணைக்கிறது, இதனால் குழுக்கள் நாற்பது வெவ்வேறு Jira டிக்கெட்டுகளில் ஒரே பிழையைத் திரும்பத் திரும்பச் சரிசெய்வதைத் தவிர்க்கலாம்.
ஸ்கேனர்களை புல் ரிக்வெஸ்ட்களுடன் (pull requests) இணைப்பது இந்தத் பின்னூட்டத்தை (feedback) துல்லியமாக வைத்திருக்கும். ஒரு டெவலப்பர் தனது புதிய மார்க்கப் (markup) மூலம் ஒரு தலைப்பு நிலை (heading level) விடுபட்டுள்ளது என்ற எச்சரிக்கையை மெர்ஜ் (merge) செய்வதற்கு முன்பே பெற்றால், அதைச் சரிசெய்ய சில நிமிடங்கள் மட்டுமே ஆகும். அதே சிக்கல் ப்ரொடக்ஷனுக்கு (production) அனுப்பப்பட்டு, வெளியீட்டிற்கு இரண்டு நாட்களுக்கு முன்பு கண்டறியப்பட்டால், அதைச் சரிசெய்ய ஒரு ஹாட்ஃபிக்ஸ் (hotfix), ரிக்ரஷன் டெஸ்டிங் (regression testing) மற்றும் பங்குதாரர்களுடனான (stakeholder) தகவல் தொடர்பு தேவைப்படும். துல்லியமான சுழற்சிகள் நேரத்தைச் சேமிப்பதோடு, அணுகல்தன்மை கடனையும் (accessibility debt) குறைக்கின்றன.
வேலைப் பகிர்வு
ஆட்டோமேஷன் (Automation) தானாகவே உங்கள் தயாரிப்பை அணுகல்தன்மை கொண்டதாக மாற்றாது. இருப்பினும், உங்கள் குழு மீண்டும் மீண்டும் அதே தெளிவான தோல்விகளை வெளியிடுவதைத் தடுக்கும். உங்கள் CI பைப்லைனில் (CI pipeline) தானியங்கிச் சோதனைகளைச் செய்யுங்கள். உள்ளடக்கத் தொகுப்பாளர்கள் (content editors) அல்லது புதிய அம்சங்களால் ஏற்படும் பின்னடைவுகளைக் (regressions) கண்டறிய ஒவ்வொரு இரவும் ஸ்டேஜிங் தளங்களை (staging sites) ஸ்கேன் செய்யுங்கள். பேக்லாக்ஸை (backlogs) நிர்வகிக்கக்கூடியதாக வைத்திருக்க சிக்கல்களை காம்போனென்ட் வாரியாகப் பிரிக்கவும். சூழல் மிகவும் முக்கியமான தளத்தின் பகுதிகளுக்கு மனித கவனத்தை ஒதுக்குங்கள்: ஒரு படத்திற்கு alt text தேவையா என்று தீர்மானித்தல், சிக்கலான தனிப்பயன் காம்போனென்ட்களை (custom components) மதிப்பீடு செய்தல் மற்றும் பயனரின் நோக்கத்தைப் புரிந்துகொள்ள வேண்டிய செயல்பாடுகளைச் (flows) சோதித்தல் போன்றவற்றுக்கு மனிதத் தலையீடு அவசியம்.
அதிகப்படியான தரவுகள், வகைப்படுத்துதல் (triage) மற்றும் பேட்டர்ன் ரெக்னகிஷன் ஆகியவற்றிற்கு AI-ஐப் பயன்படுத்துங்கள். ஒவ்வொரு இரவும் ஒவ்வொரு பக்கத்திலும் செய்யப்படும் மீண்டும் மீண்டும் நிகழும் ஸ்கேனிங் பணிகளை இயந்திரங்களிடம் விட்டுவிடுங்கள். முடிவெடுக்கும் பணிகளை மனிதர்களிடம் விட்டுவிடுங்கள். அந்த வேலைப் பகிர்வுதான் அணுகல்தன்மையை (accessibility) வெளியீட்டிற்கு முந்தைய பதற்றத்திலிருந்து ஒரு சாதாரண பொறியியல் பழக்கமாக மாற்றுகிறது.
Source: https://dev.to/henryv/automating-wcag-compliance-with-ai-4ogp
Join the discussion: https://t.me/GyaanSetuAi