वेब एक्सेसिबिलिटी के लिए जोर से पढ़ें (Read Aloud) TTS: एक WCAG 2.2 कार्यान्वयन गाइड

विश्व स्वास्थ्य संगठन का अनुमान है कि दुनिया भर में लगभग 1.3 अरब लोग किसी न किसी गंभीर दिव्यांगता के साथ जीते हैं। बहुत से लोगों के लिए, "ज़ोर से पढ़ना" (रीड अलाउड) टेक्स्ट कोई अतिरिक्त सुविधा नहीं है; यह वह माध्यम है जिसके ज़रिए वे समाचार, दस्तावेज़, फ़ॉर्म और वेब पर मौजूद अन्य सभी चीज़ों को समझते हैं। इसके बावजूद, कई साइटें अभी भी सुगमता (एक्सेसिबिलिटी) को बाद में जोड़े जाने वाले पैच की तरह मानती हैं: चेकलिस्ट पर एक साधारण आइटम, न कि एक ऐसा उत्पाद फीचर जिसे पहले दिन से ही डिज़ाइन किया गया हो।

यह लेख उन डेवलपर्स, प्रोडक्ट प्रबंधकों और एक्सेसिबिलिटी लीड्स के लिए है जो WCAG 2.2 के मानकों पर खरा उतरने वाले रीड अलाउड फीचर को पेश करने के लिए एक आधुनिक एआई वॉयस एपीआई का उपयोग करना चाहते हैं। इसका उद्देश्य व्यावहारिक स्पष्टता प्रदान करना है: टीटीएस (TTS) किन सफलता मानदंडों का सार्थक रूप से समर्थन करता है, शुरू से अंत तक एक अनुपालनशील कार्यान्वयन कैसा दिखता है, और टीमें ऐसी कौन सी गलतियाँ दोहराती रहती हैं, भले ही वे मानती हों कि एक्सेसिबिलिटी का काम "पूरा" हो गया है।

WCAG 2.2 वास्तव में क्या मांग करता है (और इसमें TTS कहाँ फिट बैठता है)

WCAG 2.2 को 5 अक्टूबर 2023 को W3C की सिफ़ारिश का दर्जा मिला, जिससे मौजूदा ढांचे में नौ नए सफलता मानदंड जुड़ गए। यह अभी भी चार परिचित सिद्धांतों (POUR: Perceivable - बोधगम्य, Operable - संचालित करने योग्य, Understandable - समझने योग्य, और Robust - सुदृढ़) के इर्द-गिर्द व्यवस्थित है, जैसा कि W3C ने अपनी परिचयात्मक सामग्रियों (W3C, 2024) में संक्षेप में बताया है। ज़ोर से पढ़ा जाने वाला टेक्स्ट इन चारों के साथ जुड़ सकता है, लेकिन यह सबसे स्पष्ट रूप से 'बोधगम्य' (Perceivable) के तहत अपनी उपयोगिता साबित करता है: उन उपयोगकर्ताओं तक समान जानकारी पहुँचाना जो इसे दृश्य रूप से आसानी से नहीं पढ़ सकते।

'बोधगम्य' के अंतर्गत, सफलता मानदंड 1.1.1 गैर-पाठ्य सामग्री के लिए पाठ्य विकल्पों की मांग करता है। SC 1.3.1 की आवश्यकता है कि जानकारी और संरचना प्रोग्रामेटिक रूप से निर्धारित की जा सके। SC 1.4.5 आपको टेक्स्ट की छवियों के बजाय वास्तविक टेक्स्ट का उपयोग करने के लिए प्रेरित करता है जब वास्तविक टेक्स्ट काम कर सकता हो। इनमें से कोई भी पंक्ति यह नहीं कहती कि "आपको TTS प्रदान करना ही होगा।" वे जो करते हैं वह आपको ऐसी सामग्री बनाने के लिए बाध्य करना है जिसे मशीनें समझ सकें, और एक सटीक, नेविगेट करने योग्य ऑडियो बनाने के लिए रीड अलाउड लेयर ठीक इसी पर निर्भर करती है। सबसे आम गलती जो मैं अक्सर देखता हूँ वह वैचारिक है: WCAG के लिए एक अंतर्निहित ऑडियो प्लेयर की आवश्यकता नहीं है; इसके लिए सुलभ सामग्री की आवश्यकता होती है। एक भरोसेमंद रीड अलाउड एपीआई उन लोगों के लिए पहुंच प्रदान करने का सबसे आसान तरीका है जो सिस्टम स्क्रीन रीडर पर भरोसा नहीं कर सकते, या बस नहीं करना चाहते।

रीड अलाउड टेक्स्ट से किसे लाभ होता है (स्क्रीन रीडर उपयोगकर्ताओं के अलावा)

रीड अलाउड को अक्सर "दृष्टिबाधित उपयोगकर्ताओं के लिए" के पर्याय के रूप में देखा जाता है, और यह सोच बहुत सीमित है। वेब सुगमता (एक्सेसिबिलिटी) में श्रवण, संज्ञानात्मक, न्यूरोलॉजिकल, शारीरिक, भाषण और दृश्य संबंधी अक्षमताएं शामिल हैं। एक अच्छी तरह से डिज़ाइन किया गया टीटीएस फीचर इनमें से कई ज़रूरतों का उस तरह से समर्थन कर सकता है जैसा कि पारंपरिक स्क्रीन रीडर अनुभव हमेशा नहीं कर पाता, खासकर जब आप पढ़ने के क्रम, गति और बोली जाने वाली सटीक सामग्री को नियंत्रित करते हैं।

डिस्लेक्सिया का उदाहरण लें: कई उपयोगकर्ताओं को टेक्स्ट देखने में कोई समस्या नहीं होती है, लेकिन इसे जल्दी और आराम से समझना एक अलग समस्या है। प्रिंट से जुड़ी अक्षमताओं पर शोध लगातार ऑडियो को एक ऐसे इनपुट माध्यम के रूप में इंगित करता है जो पढ़ने के प्रवाह से जुड़ी बाधाओं को कम करने में मदद करता है, जिससे टीटीएस एक व्यावहारिक एक्सेसिबिलिटी टूल बन जाता है न कि केवल एक अतिरिक्त फीचर। यही "पढ़ने के बजाय सुनने" का मोड कम साक्षरता वाले उपयोगकर्ताओं, गैर-मूल भाषा पाठकों, ध्यान से जुड़ी स्थितियों से जूझ रहे लोगों और सीमित इंटरनेट कनेक्शन वाले उपयोगकर्ताओं की भी मदद कर सकता है जो भारी मीडिया लोड करने के बजाय हल्के ऑडियो को स्ट्रीम करना पसंद करेंगे। एक बार जब आप एक्सेसिबिलिटी को वास्तविक दुनिया की पढ़ने की बाधाओं के रूप में देखना शुरू कर देते हैं, तो एक सक्षम वॉयस एपीआई में निवेश करना किसी विशेष फीचर जैसा नहीं, बल्कि बुनियादी उत्पाद स्वच्छता जैसा दिखने लगता है।

WCAG-अनुपालन वाले रीड अलाउड कार्यान्वयन की तकनीकी संरचना

एक एआई वॉयस एपीआई का उपयोग करके WCAG 2.2 अनुपालन वाले रीड अलाउड कार्यान्वयन का आर्किटेक्चर

किसी पेज को "बोलने योग्य" बनाना बेहद आसान है। लेकिन इसे इस तरह से बुलवाना जो WCAG 2.2 के मानकों पर खरा उतरे, इसका मतलब है रीड अलाउड को तीन परतों वाले सिस्टम के रूप में देखना: कंटेंट परत, एपीआई परत और प्लेयर परत।

परत 1: सिमेंटिक HTML और ARIA मार्कअप

एक टीटीएस एपीआई ईमानदारी से वही पढ़ेगा जो आप उसे देंगे, और यही सबसे बड़ी समस्या है। यदि आपका एक्सट्रैक्शन लॉजिक बिना किसी सिमेंटिक्स वाले डिव-भारी लेआउट से सीधे रॉ टेक्स्ट खींचता है, तो आवाज का मॉडल कितना भी स्वाभाविक क्यों न हो, ऑडियो वाक्यों के बेतरतीब मिश्रण जैसा सुनाई देगा। एक साफ हेडिंग पदानुक्रम (h1 से h6 तक), लैंडमार्क भूमिकाएं (main, nav, aside), और सटीक ARIA लेबल आपके एक्सट्रैक्शन कोड को वे आधार प्रदान करते हैं जिनकी उसे एक समझदार पठन क्रम बनाने के लिए आवश्यकता होती है। यहाँ SC 1.3.2 से समझौता नहीं किया जा सकता: पढ़ने का क्रम प्रोग्रामेटिक रूप से निर्धारित करने योग्य होना चाहिए। यह केवल तभी होता है जब DOM केवल पिक्सेल ही नहीं, बल्कि अर्थ को भी कोड करता है।

परत 2: SSML और एपीआई अनुरोध

SSML वह जगह है जहाँ "टेक्स्ट" एक उद्देश्य के साथ "भाषण" बनता है। एक बेहतरीन वॉयस एपीआई को SSML स्वीकार करना चाहिए जो आपको ठहराव, ज़ोर देने, संक्षेपों के उच्चारण और बोलने की गति को नियंत्रित करने की अनुमति देता है, वे छोटी चीज़ें जो ऑडियो को केवल सुनने योग्य बनाने के बजाय वास्तव में उपयोगी बनाती हैं। अनुपालन के दृष्टिकोण से, SSML में भाषा मेटाडेटा भी शामिल होता है। SC 3.1.1 के लिए आवश्यक है कि पेज की भाषा प्रोग्रामेटिक रूप से निर्धारित की जा सके; SSML में सही भाषा सेट करना इंजन को सही फोनेम (ध्वनि) सेट की ओर ले जाता है। SC 3.1.2 उस आवश्यकता को उन अंशों तक विस्तारित करता है जो भाषाएँ बदलते हैं। यदि आपका पेज अंग्रेजी और हिंदी के बीच बदलता है, तो आपके सिंथेसिस अनुरोध को एक भाषा मॉडल को अनुमान लगाने के लिए मजबूर करने के बजाय उन सीमाओं को चिह्नित करना होगा।

परत 3: ऑडियो प्लेयर और कीबोर्ड नियंत्रण

प्लेयर वह जगह है जहाँ व्यावहारिक रूप से एक्सेसिबिलिटी की जीत या हार होती है। SC 2.1.1 के लिए आवश्यक है कि प्रत्येक नियंत्रण कीबोर्ड से काम करे, इसलिए प्ले, पॉज़, स्टॉप और गति समायोजन केवल माउस से किए जाने वाले काम नहीं होने चाहिए। फोकस स्टाइलिंग भी मायने रखती है: दिखाई देने वाले फोकस संकेतक SC 2.4.7 के अंतर्गत आते हैं, जबकि WCAG 2.2 फोकस किए गए तत्वों को छिपाने से बचाने के लिए SC 2.4.11 जोड़ता है। यदि आप और आगे जाना चाहते हैं, तो SC 2.4.13 AAA स्तर पर फोकस उपस्थिति को कवर करता है। ऑडियो व्यवहार भी विशिष्टता का हिस्सा है। SC 1.4.2 के लिए तीन सेकंड से अधिक समय तक स्वचालित रूप से चलने वाले किसी भी ऑडियो को रोकने या बंद करने के तरीके की आवश्यकता होती है, जो ऑटोप्ले रीड अलाउड को तब तक जोखिम भरा बनाता है जब तक कि स्टॉप कंट्रोल तुरंत उपलब्ध और आसानी से सुलभ न हो। यदि आपका कार्यान्वयन ब्राउज़र-डिफ़ॉल्ट आउटलाइन और "जैसे-तैसे" कीबोर्ड हैंडलिंग पर निर्भर करता है, तो WCAG 2.2 के आने पर यह दृष्टिकोण विफल होने लगता है।

टीटीएस और एक्सेसिबिलिटी के बारे में अधिकांश टीमें क्या गलती करती हैं

सबसे आम गलती किसी तीसरे पक्ष के ब्राउज़र एक्सटेंशन (या पेज पर डाले गए एक सामान्य विजेट) को ही एक्सेसिबिलिटी प्लान मान लेना है। TTSReader जैसे उपकरण इस बात के उपयोगी उदाहरण हैं कि एक स्टैंडअलोन रीड अलाउड ऐप कैसा दिख सकता है, लेकिन वे इस अनुभव को आपके उत्पाद में एकीकृत करने का विकल्प नहीं हैं। नेटिव एकीकरण आपको यह नियंत्रित करने की अनुमति देता है कि क्या पढ़ा जाए, उसे कैसे व्यवस्थित किया जाए, वह कैसा सुनाई दे और कीबोर्ड से उसे कैसे संचालित किया जाए। उपयोगकर्ताओं से अपनी स्वयं की सहायक तकनीक लाने के लिए कहना आपको पहली जगह में सुलभ सामग्री बनाने की जिम्मेदारी से मुक्त नहीं करता है।

दूसरी विफलता मोड यह मान लेना है कि पेज स्थिर है। आधुनिक वेब ऐप्स DOM को लगातार बदलते रहते हैं, और रीड अलाउड को इसके साथ तालमेल रखना पड़ता है। यहीं पर ARIA लाइव रीजन (aria-live, aria-atomic) काम आते हैं: वे वह तंत्र हैं जो आपके टीटीएस अनुभव को बिना पूरा रीलोड किए परिवर्तनों को दर्शाने में मदद करते हैं। WCAG SC 4.1.3, जिसे 2.1 में पेश किया गया था और 2.2 में आगे बढ़ाया गया, इसके लिए स्थिति संदेशों (status messages) को प्रोग्रामेटिक रूप से निर्धारित करने की आवश्यकता होती है। यदि आपका रीड अलाउड फीचर लाइव रीजन्स को अनदेखा करता है, तो उपयोगकर्ता महत्वपूर्ण चीज़ों को याद कर देंगे: जैसे फॉर्म एरर, लोडिंग स्टेटस और इन-ऐप नोटिफिकेशन।

एक्सेसिबिलिटी के लिए एआई वॉयस एपीआई चुनना: विशिष्टताओं की क्या मांग है

वॉयस एपीआई एक जैसे नहीं होते हैं, और एक्सेसिबिलिटी ही वह जगह है जहाँ इनके बीच का अंतर स्पष्ट हो जाता है। WCAG विक्रेताओं के नाम नहीं लेता है, लेकिन यह उन क्षमताओं के एक समूह की ओर इशारा करता है जिनकी आपके टीटीएस बैकएंड को आवश्यकता होती है यदि आप चाहते हैं कि आपका कार्यान्वयन मजबूत और उपयोग में सुखद हो।

WCAG 2.2 अनुपालन से प्रेरित एपीआई आवश्यकताएं:

• SSML समर्थन: पूर्ण SSML समर्थन आपको भाषा, ज़ोर देने और ठहराव के व्यवहार को इस तरह से कोड करने की अनुमति देता है जो SC 3.1.1 और 3.1.2 के अनुकूल हो।

• कम विलंबता (लो लेटेंसी): SC 2.2.1 समय सीमा के बारे में है, लेकिन एक धीमा टीटीएस पाइपलाइन अभी भी उन लोगों को परेशान करता है जो ऑडियो को अपने मुख्य एक्सेस पाथ के रूप में उपयोग करते हैं। एक इंजीनियरिंग लक्ष्य के रूप में, पहले ऑडियो के लिए 300ms से कम का समय एक व्यावहारिक मानक है।

• स्ट्रीमिंग ऑडियो आउटपुट: स्ट्रीमिंग के ज़रिए सिंथेसिस समाप्त होने से पहले ही प्लेबैक शुरू हो जाता है, जो लंबे पेजों के लिए और उन उपयोगकर्ताओं के लिए महत्वपूर्ण है जो सुनने से पहले पूरा रेंडर होने का इंतज़ार नहीं करना चाहते हैं।

• विभिन्न आवाज विकल्प और बोलने की गति: WCAG सीधे तौर पर ऑडियो गति नियंत्रण की मांग नहीं करता है, लेकिन गति पर उपयोगकर्ता का नियंत्रण एक मजबूत एक्सेसिबिलिटी और उपयोगिता की सर्वोत्तम प्रथा है। कई उपयोगकर्ताओं को बोलने की धीमी गति से लाभ होता है, इसलिए गति समायोजन का समर्थन करना आवश्यक है।

• विश्वसनीय अपटाइम और SLA: एक्सेसिबिलिटी ऐसा फीचर नहीं हो सकता जो "अस्थायी रूप से अनुपलब्ध" हो। मजबूत अपटाइम गारंटी अनुपालन जोखिम प्रबंधन का हिस्सा हैं, न कि केवल एक प्रदर्शन प्राथमिकता।

WellSaid Labs जैसे एआई वॉयस जेनरेटर और Descript जैसे टूल कंटेंट प्रोडक्शन वर्कफ़्लो के इर्द-गिर्द बनाए गए हैं। यह एक वेब ऐप के भीतर रीड अलाउड को सक्षम करने से अलग काम है, जहाँ आपको स्ट्रीमिंग, सटीक SSML नियंत्रण और अनुमानित लेटेंसी की आवश्यकता होती है। एंटरप्राइज़ टीटीएस प्लेटफ़ॉर्म विकल्पों के रूप में मौजूद हैं, लेकिन टीमों को अपनाने से पहले बड़े पैमाने पर लेटेंसी और लागत का परीक्षण करना चाहिए, क्योंकि बड़ी-बड़ी क्षमताएं हमेशा वास्तविक रीड अलाउड वर्कलोड में उम्मीद के मुताबिक काम नहीं करती हैं।

Smallest.ai के Lightning API के साथ रीड अलाउड को लागू करना: एक व्यावहारिक गाइड

WCAG 2.2 अनुपालन वाले रीड अलाउड फीचर के लिए चार-चरणीय कार्यान्वयन प्रवाह

Smallest.ai का Lightning API इसी इंटीग्रेशन प्रोफाइल के लिए डिज़ाइन किया गया है: रीयल-टाइम वेब उपयोग के लिए स्ट्रीमिंग टीटीएस, उच्चारण और गति को नियंत्रित करने के लिए SSML समर्थन, और कई आवाजें व भाषाएं। नीचे एक सीधा क्रम दिया गया है जो WCAG की अपेक्षाओं पर सटीक बैठता है।

चरण 1: सिमेंटिक सामग्री को निकालना। एक ऐसा एक्सट्रैक्शन फ़ंक्शन बनाएं जो एक विशाल innerText ब्लॉक को पकड़ने के बजाय लैंडमार्क भूमिकाओं और हेडिंग पदानुक्रम का उपयोग करके DOM को पार करे। role='presentation' और aria-hidden='true' जैसे ARIA संकेतों का सम्मान करते हुए नेविगेशन, फुटर और सजावटी तत्वों को छोड़ दें।

चरण 2: अपना SSML पेलोड तैयार करना। निकाली गई सामग्री को SSML में लपेटें और xml:lang एट्रिब्यूट के ज़रिए पेज की भाषा पास करें। हेडिंग की सीमाओं पर `<break time='500ms'/>` जोड़ें ताकि ठहराव स्वाभाविक लगे। `<prosody>` एलिमेंट पर रेट एट्रिब्यूट के ज़रिए उपयोगकर्ता की पसंदीदा पठन गति को लागू करें।

चरण 3: स्ट्रीमिंग सक्षम के साथ Lightning API को कॉल करना। Smallest.ai का Waves API डेवलपर्स को Lightning और संबंधित स्पीच क्षमताओं तक पहुंच प्रदान करता है। स्ट्रीमिंग ऑडियो रिस्पॉन्स का अनुरोध करें, फिर इसे वेब ऑडियो एपीआई कॉन्टेक्स्ट या HTML5 ऑडियो एलिमेंट में पाइप करें ताकि पहले हिस्से के आते ही प्लेबैक शुरू हो सके।

चरण 4: कीबोर्ड-सुलभ प्लेयर बनाना। प्ले/पॉज, स्टॉप, स्पीड कंट्रोल और एक प्रोग्रेस इंडिकेटर प्रदान करें, जो सभी कीबोर्ड से सुलभ और उपयोग करने योग्य हों। फोकस स्टेट्स को स्पष्ट बनाएं और SC 2.4.11 की फोकस उपस्थिति आवश्यकताओं के अनुरूप रखें। एक aria-label जोड़ें जो यह बताता हो कि क्या पढ़ा जा रहा है, फिर बिना माउस को छुए केवल कीबोर्ड से पूरे फ्लो का परीक्षण करें।

WCAG 2.2 के विरुद्ध अपने रीड अलाउड फीचर का परीक्षण करना

स्वचालित एक्सेसिबिलिटी स्कैनर WCAG के केवल कुछ मुद्दों को ही पकड़ पाते हैं, इसलिए बाकी समस्याओं का पता तब चलता है जब कोई इंसान वास्तव में उत्पाद का उपयोग करने का प्रयास करता है। रीड अलाउड के लिए, इसका मतलब है कि प्रत्येक प्लेयर कंट्रोल तक केवल-कीबोर्ड पहुंच को सत्यापित करना, यह पुष्टि करना कि ARIA लाइव रीजन गतिशील परिवर्तनों की घोषणा करते हैं, और यह जांचना कि SSML भाषा टैग पेज की घोषित भाषा से मेल खाते हैं। इसका मतलब कम से कम एक ऐसे उपयोगकर्ता के साथ परीक्षण करना भी है जो मुख्य रूप से ऑडियो पर निर्भर करता है। कार्यान्वयन संदर्भों के लिए, एक्सेसिबिलिटी पर MDN Web Docs एक ठोस स्रोत है कि ब्राउज़र उस एक्सेसिबिलिटी ट्री को कैसे प्रदर्शित करते हैं जिस पर आपका एक्सट्रैक्शन लॉजिक निर्भर करता है। W3C वेब एक्सेसिबिलिटी इनिशिएटिव मूल्यांकन पद्धति गाइड प्रकाशित करता है जिन्हें QA के दौरान पास रखना उपयोगी होता है।

रीड अलाउड टीटीएस कार्यान्वयन के लिए एक व्यावहारिक WCAG 2.2 परीक्षण चेकलिस्ट

मुख्य निष्कर्ष और अगले कदम

एक्सेसिबिलिटी केवल टिक करने वाला कोई बॉक्स नहीं है; यह एक ऐसे उत्पाद के बीच का अंतर है जिसे 1.3 अरब लोग वास्तव में उपयोग कर सकते हैं और एक ऐसा उत्पाद जो उन्हें चुपचाप बाहर कर देता है। WCAG 2.2 यह निर्देश नहीं देता कि "TTS जोड़ें," लेकिन इसके सफलता मानदंड मिलकर एक स्पष्ट इंजीनियरिंग निर्देश देते हैं: अपनी सामग्री को व्यवस्थित करें, प्रोग्रामेटिक रूप से भाषा की पहचान करें, ऑडियो नियंत्रणों को मजबूत फोकस स्टेट्स के साथ कीबोर्ड-संचालित बनाएं, और गतिशील अपडेट को ध्यान में रखें। जब एक रीड अलाउड फीचर को ठीक से एकीकृत किया जाता है (ठोस SSML समर्थन के साथ कम लेटेंसी वाले, स्ट्रीमिंग वॉयस एपीआई द्वारा समर्थित), तो यह केवल-स्क्रीन-रीडर वाले मानसिक मॉडल की तुलना में कहीं अधिक लोगों के लिए उत्पाद को आसान बनाते हुए उन आवश्यकताओं को पूरा कर सकता है।

वॉयस एआई एप्लिकेशन इकोसिस्टम अब काफी परिपक्व हो चुका है जिससे टीमों को आवाज की गुणवत्ता और सुगमता की कठोरता के बीच चयन नहीं करना पड़ता है। यदि आप स्पीच स्टैक पर गहराई से काम कर रहे हैं, तो Smallest.ai ब्लॉग कार्यान्वयन पैटर्न, एपीआई तुलनाओं और उत्पाद अपडेट को ट्रैक करता है।

समस्या विशिष्ट है और इसे ठीक किया जा सकता है: रीड अलाउड फीचर्स WCAG 2.2 में इसलिए विफल नहीं होते कि टीमें परवाह नहीं करतीं, बल्कि इसलिए विफल होते हैं क्योंकि उनका स्टैक उन्हें लेटेंसी, SSML, स्ट्रीमिंग और बहुभाषी व्यवहार पर पर्याप्त नियंत्रण नहीं देता है। Smallest.ai का Lightning API इन कमियों को पूरा करने के लिए तैयार है, जिसमें 300ms से कम की स्ट्रीमिंग ऑडियो, पूर्ण SSML समर्थन और Waves API के माध्यम से डेवलपर पहुंच शामिल है। यदि आप एक्सेसिबिलिटी वर्क को वास्तविक रोडमैप में मैप कर रहे हैं, तो Lightning एक ऐसे रीड अलाउड अनुभव के लिए टीटीएस आधार के रूप में मूल्यांकन करने योग्य है जो WCAG की जांच और इस पर निर्भर लोगों के दैनिक उपयोग दोनों पर खरा उतरता है।