5.3 एक्सेसिबिलिटी

अवलोकन और प्रेरणा

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

बड़ी टीमों के लिए, एक्सेसिबिलिटी को सिस्टम में बनाया जाना चाहिए, व्यक्तिगत अच्छे इरादों पर नहीं छोड़ा जाना चाहिए। जब कई टीमें एक उत्पाद में शिप करती हैं, तो एक अकेला अनएक्सेसिबल कॉम्पोनेंट (एक बिना लेबल वाला फ़ॉर्म फ़ील्ड, केवल-रंग वाला स्थिति संकेतक, एक मोडल में एक कीबोर्ड ट्रैप) विकलांग उपयोगकर्ताओं को एक पूरी यात्रा से बाहर लॉक कर सकता है। साझा कॉम्पोनेंट, डिज़ाइन टोकन, टेस्टिंग पाइपलाइन, और डेफ़िनिशन ऑफ़ डन में एक्सेसिबिलिटी बनाना ही इसे स्केल पर विश्वसनीय बनाने का एकमात्र तरीका है। बाद में इसे रेट्रोफ़िट करना महंगा और त्रुटि-प्रवण है। इसे शुरू से डिज़ाइन करना सस्ता और टिकाऊ है।

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

यह भी देखें: अध्याय 5.2 (UI डिज़ाइन और डिज़ाइन सिस्टम), अध्याय 5.6 (फ़्रंटएंड इंजीनियरिंग), और अध्याय 5.1 (UX फ़ाउंडेशन)।

मुख्य सिद्धांत

• एक्सेसिबिलिटी एक आधाररेखा गुणवत्ता विशेषता है, सुरक्षा और परफ़ॉर्मेंस की तरह, कोई वैकल्पिक फ़ीचर नहीं।
• POUR सिद्धांत: इंटरफ़ेस अवश्य Perceivable (अनुभवगम्य), Operable (संचालन योग्य), Understandable (समझने योग्य), और Robust (मज़बूत) होने चाहिए।
• पहले Semantic HTML; ARIA का उपयोग केवल वास्तविक अंतरालों को भरने के लिए करें, कभी नेटिव एलिमेंट के विकल्प के रूप में नहीं।
• माउस से उपयोग करने योग्य हर चीज़ अकेले कीबोर्ड से भी उपयोग करने योग्य होनी चाहिए।
• केवल रंग, आकार, या स्थिति से जानकारी न दें।
• स्वचालित टूल केवल समस्याओं के एक अंश को पकड़ते हैं; मैनुअल और assistive-technology टेस्टिंग आवश्यक हैं।
• सुलभ डिज़ाइन हर किसी के लिए बेहतर डिज़ाइन है (“curb-cut effect,” जहाँ विकलांग लोगों के लिए बनाए गए फ़ीचर सभी उपयोगकर्ताओं को लाभान्वित करते हैं)।
• विकलांग लोगों के साथ डिज़ाइन और टेस्ट करें, केवल उनके लिए नहीं।

अनुशंसाएँ

WCAG के अनुसार डिज़ाइन करें और बनाएँ, वर्तमान मानक को लक्ष्य बनाते हुए

Web Content Accessibility Guidelines (WCAG) अंतरराष्ट्रीय संदर्भ है। WCAG 2.1 और 2.2 चार POUR सिद्धांतों के तहत संगठित हैं, जिनमें अनुरूपता स्तर A, AA, और AAA पर परीक्षण योग्य सफलता मानदंड हैं। अपनी आधाररेखा के रूप में लेवल AA को लक्ष्य बनाएँ; यही वह है जिसे अधिकांश कानून संदर्भित करते हैं। WCAG 2.2 फ़ोकस दृश्यता, लक्ष्य आकार, और संज्ञानात्मक भार घटाने के लिए मानदंड जोड़ता है। WCAG 3.0 एक उभरता हुआ उत्तराधिकारी है, जो अलग ढंग से संरचित है और अभी विकास में है। इस पर नज़र रखें, लेकिन आज 2.2 AA के अनुसार बनाएँ। दिशानिर्देशों को एक फ़र्श मानें, छत नहीं: हर मानदंड पास करना वास्तव में उपयोग योग्य अनुभव की गारंटी नहीं देता।

सिमैंटिक HTML और सही ARIA का उपयोग करें

नेटिव HTML एलिमेंट (बटन, लिंक, फ़ॉर्म कंट्रोल, हेडिंग, सूचियाँ, लैंडमार्क) अंतर्निहित एक्सेसिबिलिटी सिमैंटिक्स, कीबोर्ड व्यवहार, और assistive-technology समर्थन के साथ आते हैं। इन्हें पहले उपयोग करें। ARIA (Accessible Rich Internet Applications) भूमिकाओं, स्थितियों, और गुणों तक तभी पहुँचें जब कस्टम विजेट का वर्णन करना हो जिसे HTML व्यक्त नहीं कर सकता, और ARIA Authoring Practices का पालन करें। ARIA का पहला नियम सरल है: यदि एक नेटिव एलिमेंट काम करेगा तो ARIA का उपयोग न करें। गलत ARIA बिना किसी ARIA से बदतर है: यह सक्रिय रूप से screen readers को गुमराह करता है। पेज को एक तार्किक हेडिंग संरचना, सार्थक लेबल, इमेज के लिए वैकल्पिक टेक्स्ट, मीडिया के लिए कैप्शन और ट्रांस्क्रिप्ट, और हर लेबल तथा उसके कंट्रोल के बीच एक प्रोग्रामैटिक लिंक दें।

कीबोर्ड और assistive-technology संचालन क्षमता की गारंटी दें

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

स्वचालित टूल, मैनुअल समीक्षा, और वास्तविक उपयोगकर्ताओं के साथ टेस्ट करें

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

एक्सेसिबिलिटी को संगठनात्मक बनाएँ, वीरतापूर्ण नहीं

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

ट्रेड-ऑफ़: पक्ष और विपक्ष

दृष्टिकोण	पक्ष	विपक्ष
शुरुआत से एक्सेसिबिलिटी बनाना	सबसे सस्ता, टिकाऊ, हर किसी के लिए बेहतर	अग्रिम प्रशिक्षण और अनुशासन की आवश्यकता
बाद में रेट्रोफ़िट / उपचार	प्रयास टालता है, त्वरित लॉन्च को अनब्लॉक करता है	कहीं अधिक महंगा, नाज़ुक, बीच में कानूनी जोखिम
केवल स्वचालित टेस्टिंग	तेज़, सस्ता, CI में रिग्रेशन पकड़ता है	~दो-तिहाई समस्याएँ छूट जाती हैं; झूठा आत्मविश्वास
मैनुअल + assistive-tech टेस्टिंग	वास्तविक यूज़ेबिलिटी बाधाएँ पकड़ता है	धीमा, कुशल टेस्टर और डिवाइस चाहिए
विकलांग उपयोगकर्ताओं के साथ टेस्टिंग	वास्तविक अनुभव पर ज़मीनी सच्चाई	भर्ती प्रयास और लागत, सम्मानपूर्वक किया जाना चाहिए

केंद्रीय ट्रेड-ऑफ़ अग्रिम अनुशासन बनाम टाली गई लागत है। शुरू से बनाई गई एक्सेसिबिलिटी सस्ती है और हर किसी के लिए गुणवत्ता सुधारती है; कानूनी दबाव में रेट्रोफ़िट की गई एक्सेसिबिलिटी महंगी, अधूरी, और तनावपूर्ण है। लंबी अवधि में “गति” के विरुद्ध कोई वास्तविक ट्रेड-ऑफ़ नहीं है: अनएक्सेसिबल सॉफ़्टवेयर बस आपके पाँचवें उपयोगकर्ताओं के लिए काम नहीं करता। यह एक बचत नहीं, एक दोष है।

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

1. क्या एक्सेसिबिलिटी रिग्रेशन हमारे बिल्ड को उसी तरह विफल करते हैं जैसे एक टूटा हुआ टेस्ट करता है, और यदि नहीं, तो क्यों नहीं? स्वचालित स्कैनर केवल लगभग एक-तिहाई समस्याएँ पकड़ते हैं, लेकिन जो वे पकड़ते हैं (गुम लेबल, कंट्रास्ट विफलताएँ, बिना लेबल वाले कंट्रोल) CI में पकड़ना सस्ता है और लॉन्च-पूर्व ऑडिट में खोजना महंगा है। एक रिग्रेशन को बिल्ड विफलता मानना ही वह चीज़ है जो एक्सेसिबिलिटी को वीरतापूर्ण व्यक्तिगत प्रयास से एक विश्वसनीय सिस्टम गुण में बदलती है, जो एकमात्र चीज़ है जो तब काम करती है जब कई टीमें एक उत्पाद में शिप करती हैं। तय करें कि कौन सी जाँचें ब्लॉक करने वाली हैं, कौन सी सलाहकार हैं, और कौन एक विफलता को ओवरराइड कर सकता है। मीटिंग में अपने वर्तमान स्कैनर परिणाम और अपनी डेफ़िनिशन ऑफ़ डन लाएँ। यदि एक्सेसिबिलिटी मानदंड प्रति स्टोरी डेफ़िनिशन ऑफ़ डन में नहीं लिखे गए हैं, तो जिस क्षण एक डेडलाइन कसती है, उन्हें कम प्राथमिकता दी जाएगी।

2. कस्टम विजेट के लिए हमारा नियम क्या है, और शिप होने से पहले ARIA की समीक्षा कौन करता है? नेटिव HTML एलिमेंट मुफ़्त में कीबोर्ड व्यवहार और assistive-technology समर्थन के साथ आते हैं, और गलत ARIA बिना किसी ARIA से बदतर है क्योंकि यह सक्रिय रूप से स्क्रीन रीडर को गुमराह करता है। इस पर सहमत हों कि सिमैंटिक HTML डिफ़ॉल्ट है और किसी भी कस्टम विजेट (एक बनावटी ड्रॉपडाउन, डेट पिकर, या मोडल) को मर्ज से पहले ARIA Authoring Practices का पालन करते हुए एक कीबोर्ड और स्क्रीन-रीडर वॉकथ्रू की आवश्यकता है। यह उन इंटरैक्टिव कॉम्पोनेंट के लिए सबसे अधिक मायने रखता है जिन्हें कई टीमें पुन: उपयोग करती हैं, क्योंकि एक कीबोर्ड ट्रैप वाला एक टूटा हुआ मोडल विकलांग उपयोगकर्ताओं को एक पूरी यात्रा से बाहर लॉक कर सकता है। अपने कस्टम विजेट की एक सूची लाएँ और पूछें कि किनका वास्तविक स्क्रीन रीडर से टेस्ट किया गया है। जो नहीं किए गए हैं वे साझा कोड में छिपी देयताएँ हैं।

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

4. क्या विकलांग लोग हमारे डिज़ाइन और टेस्टिंग का हिस्सा हैं, या हम अभी भी एक काल्पनिक उपयोगकर्ता के लिए डिज़ाइन कर रहे हैं जिसे हमने खुद गढ़ा? स्वचालित स्कैनर और यहाँ तक कि विशेषज्ञ ऑडिट भी आपको बताते हैं कि मार्कअप अनुरूप है या नहीं; वे आपको यह नहीं बताते कि क्या एक अंधा उपयोगकर्ता वास्तव में आपका चेकआउट पूरा कर सकता है या एक संज्ञानात्मक विकलांगता वाला व्यक्ति आपके एरर संदेश समझ सकता है। विकलांग प्रतिभागियों को शामिल करना ज़मीनी सच्चाई का एकमात्र स्रोत है, और यह बदलता है कि आप क्या बनाते हैं, लेकिन यह वास्तविक प्रश्न उठाता है कि आप निष्पक्ष रूप से कैसे भर्ती करते हैं, आप लोगों को उनके समय के लिए कैसे मुआवज़ा देते हैं, और आप एक प्रतिभागी को हर विकलांगता के प्रवक्ता के रूप में मानने से कैसे बचते हैं। अपनी वर्तमान शोध सूची, अपनी भर्ती और भुगतान प्रथाएँ, और पिछले वर्ष कितने अध्ययनों में विकलांग प्रतिभागी शामिल थे इसकी एक ईमानदार गिनती लाएँ। एक बड़े संगठन के लिए, दृष्टि, सुनने, मोटर, और संज्ञानात्मक आवश्यकताओं में निष्पक्ष मुआवज़े और कवरेज के साथ एक आवर्ती पैनल वह है जो इसे एक बार के इशारे से एक भरोसेमंद इनपुट में बदल देता है; सरकार में, आप जिस जनता की सेवा करते हैं उसे शामिल करना अक्सर कानूनी और नागरिक दायित्व का हिस्सा है, कोई वैकल्पिक सुविधा नहीं।

5. जब हम एक तृतीय-पक्ष कॉम्पोनेंट खरीदते या एम्बेड करते हैं, तो क्या हम एक्सेसिबिलिटी का प्रमाण माँगते हैं, और इसे कौन जाँचता है? एक बड़े उत्पाद में जो कुछ शिप होता है उसका अधिकांश हिस्सा इन-हाउस नहीं लिखा गया होता: एक लाइब्रेरी से एक डेट पिकर, एक iframe में एक पेमेंट विजेट, एक चार्टिंग पैकेज, एक पूरा SaaS मॉड्यूल। एक अकेला अनएक्सेसिबल एम्बेडेड कॉम्पोनेंट पूरी यात्रा को विफल कर सकता है चाहे आपका अपना कोड कितना ही साफ़ क्यों न हो, और एक बार इसे जोड़ दिया जाए, इसे बदलना महंगा है। तय करें कि एक्सेसिबिलिटी एक प्रोक्योरमेंट आवश्यकता है, कि विक्रेताओं को एक एक्सेसिबिलिटी अनुरूपता रिपोर्ट (एक दस्तावेज़ जैसे VPAT जो बताता है कि एक उत्पाद WCAG के विरुद्ध कैसे मापता है) आपूर्ति करनी चाहिए, और कि कोई तकनीकी व्यक्ति दावे को केवल फ़ाइल करने के बजाय मान्य करता है। अपने तृतीय-पक्ष कॉम्पोनेंट की एक सूची लाएँ और पूछें कि किनके पास वर्तमान, विश्वसनीय अनुरूपता प्रमाण है। एंटरप्राइज़ और सरकारी खरीद में, अनुबंध में WCAG 2.2 AA अनुरूपता और उपचार का अधिकार लिखें, क्योंकि हस्ताक्षर से पहले किया गया वादा गो-लाइव के बाद खोजी गई बाधा से लागू करने में कहीं अधिक सस्ता है।

6. हमारा लक्ष्य अनुरूपता स्तर क्या है, इसका मालिक कौन है, और मानक बदलने पर हम इसे कैसे वर्तमान रखते हैं? WCAG 2.2 AA आज की फ़र्श है और अधिकांश कानून इसे संदर्भित करते हैं, लेकिन 2.2 ने ऐसे मानदंड जोड़े जिन्हें कई टीमों ने नहीं अपनाया है, और WCAG 3.0 एक अलग संरचना के साथ आ रहा है। बिना किसी नामित मालिक के, मानक भटक जाता है: अलग-अलग टीमें अलग-अलग वर्ज़न लक्ष्य बनाती हैं, कोई अंतर को ट्रैक नहीं करता, और अनुरूपता ऑडिट के बीच चुपचाप सड़ती है। वह सटीक वर्ज़न और स्तर तय करें जिसके अनुसार आप बनाते हैं, किसके पास इसे बढ़ाने का अधिकार है, और नए मानदंड डिज़ाइन सिस्टम और डेफ़िनिशन ऑफ़ डन तक कैसे पहुँचते हैं। अपना वर्तमान बताया गया लक्ष्य, इसका प्रमाण कि टीमें वास्तव में इसे कहाँ पूरा करती हैं, और उन 2.2 मानदंडों को अपनाने के लिए एक छोटा रोडमैप लाएँ जिन्हें आपने छोड़ दिया। एक बड़े या सार्वजनिक संगठन के लिए, एक एक्सेसिबिलिटी मालिक या उत्कृष्टता केंद्र, एक प्रकाशित एक्सेसिबिलिटी वक्तव्य, और अगले मानक वर्ज़न के लिए एक दस्तावेज़ीकृत योजना वह है जो आपको एक नियामक या अदालत को अच्छे इरादों के बजाय प्रमाण के साथ उत्तर देने देती है।

क्षेत्र लेंस

स्टार्टअप। यहाँ गति आपके पक्ष में है, क्योंकि जब कोडबेस छोटा होता है तो एक्सेसिबिलिटी सबसे सस्ती होती है। पहले स्प्रिंट से CI में एक स्वचालित स्कैनर और अपनी पुल-रिक्वेस्ट चेकलिस्ट में एक कीबोर्ड वॉकथ्रू जोड़ें, और सिमैंटिक HTML पर निर्भर रहें ताकि आपको मुफ़्त में कीबोर्ड और स्क्रीन-रीडर समर्थन मिले। ओवरले और भारी टूलिंग छोड़ें; भुगतान यह है कि जब बीच बिक्री में एक ग्राहक की प्रोक्योरमेंट टीम एक अनुरूपता रिपोर्ट माँगती है, तो आप दौड़भाग करने के बजाय दिनों में उत्तर दे सकते हैं।

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

एंटरप्राइज़। स्केल पर काम एक्सेसिबिलिटी को कई टीमों में एक सिस्टम गुण बनाना है। डिज़ाइन सिस्टम में डिफ़ॉल्ट रूप से एक्सेसिबल कॉम्पोनेंट शिप करें, CI में रिग्रेशन गेट करें, और डिज़ाइनरों, इंजीनियरों, और कंटेंट लेखकों के लिए एक उपचार प्रक्रिया और प्रशिक्षण के साथ एक मालिक या उत्कृष्टता केंद्र खड़ा करें। एक मीट्रिक के रूप में समय के साथ अनुरूपता ट्रैक करें, प्रोक्योरमेंट में WCAG अनुरूपता लिखें, और तृतीय-पक्ष कॉम्पोनेंट को एक पोर्टफ़ोलियो के रूप में प्रबंधित करें ताकि एक एम्बेडेड विजेट चुपचाप एक साझा यात्रा को विफल न कर सके।

सरकार। एक्सेसिबिलिटी एक कानूनी जनादेश और एक नागरिक कर्तव्य है, क्योंकि विकलांग नागरिकों के पास अक्सर एक लाभ, लाइसेंस, या वोट के लिए कोई वैकल्पिक प्रदाता नहीं होता। उस मानक के अनुसार बनाएँ जिसे आपका क्षेत्राधिकार उद्धृत करता है (उदाहरण के लिए Section 508, EN 301 549, या यूरोपीय एक्सेसिबिलिटी अधिनियम को WCAG 2.2 AA से मैप किया गया), बाधाओं की रिपोर्ट करने के मार्ग के साथ एक एक्सेसिबिलिटी वक्तव्य प्रकाशित करें, और उस विकलांग जनता के साथ टेस्ट करें जिसकी आप सेवा करते हैं। वास्तविक अनुरूपता के विकल्प के रूप में ओवरले को अस्वीकार करें, और विक्रेताओं को अनुबंध में विश्वसनीय प्रमाण और उपचार का अधिकार आपूर्ति करने की आवश्यकता बताएँ।

उदाहरण

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

एंटरप्राइज़। एक बड़े खुदरा विक्रेता को एक क्लास-एक्शन मुकदमे का सामना करना पड़ा क्योंकि अंधे ग्राहक स्क्रीन रीडर के साथ चेकआउट पूरा नहीं कर पा रहे थे। समझौते और कानूनी फ़ीस से परे, कंपनी को एक अदालत-पर्यवेक्षित समयसीमा के तहत उपचार करना पड़ा। इसके बाद इसने अपने डिज़ाइन सिस्टम और CI पाइपलाइन में एक्सेसिबिलिटी को दोबारा बनाया, डेफ़िनिशन ऑफ़ डन में स्क्रीन-रीडर टेस्टिंग जोड़ी, और अपनी टीमों को प्रशिक्षित किया। दोबारा बना, एक्सेसिबल चेकआउट ने कन्वर्ज़न भी सुधारा और सबके लिए सहायता संपर्क घटाए: जिन सुधारों ने स्क्रीन-रीडर उपयोगकर्ताओं की मदद की (स्पष्ट लेबल, एरर संदेश, तार्किक क्रम) उन्होंने सभी उपयोगकर्ताओं की मदद की।

सरकार। एक सार्वजनिक लाभ एजेंसी को अपने ऑनलाइन आवेदन के लिए कानूनी रूप से WCAG 2.1 AA पूरा करना आवश्यक था। अंधे और कम दृष्टि वाले उपयोगकर्ताओं, केवल-कीबोर्ड उपयोगकर्ताओं, और संज्ञानात्मक विकलांगता वाले उपयोगकर्ताओं के साथ प्रारंभिक टेस्टिंग ने उजागर किया कि एक केवल-रंग वाला “आवश्यक फ़ील्ड” संकेतक, एक अनएक्सेसिबल डेट पिकर, और अघोषित वैलिडेशन एरर लोगों को समाप्त करने से रोक रहे थे। इन्हें ठीक करना, सिमैंटिक मार्कअप, दृश्यमान फ़ोकस, लाइव-रीजन एरर घोषणाओं, और plain-language सहायता के माध्यम से, विकलांग नागरिकों को पहली बार अपने दम पर आवेदन करने दिया। इसने व्यक्तिगत सहायता पर निर्भरता घटाई और सेवा की लागत कम की, जबकि कानूनी जनादेश को पूरा किया।

व्यावसायिक मामला: प्रेरणाएँ, ROI, और TCO

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

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

नेतृत्व के सामने मामला बनाने के लिए, कानूनी दायित्व से शुरू करें जहाँ यह लागू होता है (यह सरकार के लिए और तेज़ी से निजी क्षेत्र के लिए अपरक्राम्य है)। फिर उस संबोधन योग्य आबादी को मात्रात्मक बनाएँ जिसे आप बाहर कर रहे हैं, उस बहिष्कार की सहायता-प्राप्त-चैनल लागत, और सभी उपयोगकर्ताओं के लिए “curb-cut” लाभों को। एक्सेसिबिलिटी को जोखिम प्रबंधन और गुणवत्ता के रूप में स्थापित करें, दान के रूप में नहीं।

एंटी-पैटर्न और नुकसान

• लॉन्च-पूर्व चेकबॉक्स के रूप में एक्सेसिबिलिटी: निरंतर अभ्यास के बजाय अंत में एक ऑडिट, महंगे अंतिम-क्षण के पुनर्कार्य की गारंटी देता है।
• “Div सूप”: सामान्य एलिमेंट पर क्लिक हैंडलर वाला गैर-सिमैंटिक मार्कअप, assistive technology के लिए अदृश्य।
• ARIA का दुरुपयोग: टूटे हुए मार्कअप पर ARIA बोल्ट करना, जो सादे मार्कअप से कहीं अधिक स्क्रीन रीडर को गुमराह करता है।
• केवल-रंग जानकारी: स्थिति केवल रंग से दिखाई जाती है, रंग-अंधे उपयोगकर्ताओं के लिए अदृश्य।
• अदृश्य फ़ोकस: सौंदर्य के लिए फ़ोकस आउटलाइन हटाना, कीबोर्ड उपयोगकर्ताओं को फँसा देना।
• कीबोर्ड ट्रैप: मोडल और विजेट जो फ़ोकस को फँसाते या खो देते हैं।
• स्वचालित-स्कैन आत्मसंतोष: एक स्कैनर पास करना और मान लेना कि उत्पाद एक्सेसिबल है।
• एक्सेसिबिलिटी ओवरले: तृतीय-पक्ष “एक-लाइन फ़िक्स” विजेट जो वास्तविक अनुरूपता नहीं देते और अनुभव बदतर बना सकते हैं।
• शोध से विकलांग उपयोगकर्ताओं को बाहर करना: वास्तविक लोगों के साथ टेस्ट करने के बजाय एक काल्पनिक विकलांग उपयोगकर्ता के लिए डिज़ाइन करना।

परिपक्वता मॉडल

स्तर 1: आरंभ। कोई एक्सेसिबिलिटी अभ्यास नहीं। समस्याएँ तभी खोजी जाती हैं जब कोई उपयोगकर्ता शिकायत करता है या एक मुकदमा आता है, और प्रतिक्रिया प्रतिक्रियात्मक होती है। मार्कअप गैर-सिमैंटिक और अनटेस्टेड है, और इस समस्या का कोई मालिक नहीं है।

स्तर 2: विकसित। जागरूकता मौजूद है और कुछ टीमें इस पर कार्य करती हैं: यहाँ बिल्ड में एक स्वचालित स्कैनर, वहाँ एक कीबोर्ड वॉकथ्रू, एक बड़े रिलीज़ से पहले एक लॉन्च-पूर्व ऑडिट। अभ्यास टीमों में बुनियादी और असंगत है, एक्सेसिबिलिटी अभी भी एक देर-चरण की चेकलिस्ट है, और शेड्यूल दबाव में इसे अक्सर कम प्राथमिकता दी जाती है।

स्तर 3: मानकीकृत। WCAG 2.2 AA दस्तावेज़ीकृत मानक है, जो संगठन-व्यापी लागू है। एक्सेसिबिलिटी डिज़ाइन सिस्टम में बनाई गई है ताकि कॉम्पोनेंट डिफ़ॉल्ट रूप से एक्सेसिबल शिप हों, स्वचालित और मैनुअल रूप से टेस्ट किए गए हों, और डेफ़िनिशन ऑफ़ डन में लिखे गए हों। टीमों को प्रशिक्षित किया जाता है, एक मालिक या उत्कृष्टता केंद्र मौजूद है, और एक उपचार प्रक्रिया परिभाषित है।

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

स्तर 5: ऑर्केस्ट्रेट। एक्सेसिबिलिटी को लगातार सुधारा जाता है और पूरे संगठन में एकीकृत किया जाता है। विकलांग लोग नियमित आधार पर शोध और टेस्टिंग का हिस्सा हैं, और एक्सेसिबिलिटी प्रोक्योरमेंट, डिज़ाइन टोकन, और CI में एम्बेडेड है। संगठन मानक बदलने पर अनुकूल होता है (नए WCAG मानदंड अपनाना और WCAG 3.0 के लिए तैयारी करना), और यह विक्रेताओं और साझेदारों को प्रभावित करता है ताकि पूरी आपूर्ति श्रृंखला अनुरूप हो।

चर्चा के लिए विचार

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

मुख्य निष्कर्ष

• एक्सेसिबिलिटी एक आधाररेखा गुणवत्ता विशेषता है और, सरकार के लिए, एक कानूनी आवश्यकता है।
• WCAG 2.2 AA को एक फ़र्श के रूप में डिज़ाइन करें; POUR सिद्धांतों को एक मानसिक मॉडल के रूप में उपयोग करें।
• पहले सिमैंटिक HTML; ARIA केवल वास्तविक अंतरालों को भरने के लिए, सही ढंग से किया गया।
• स्वचालित टूल लगभग एक-तिहाई समस्याएँ पकड़ते हैं; मैनुअल और assistive-technology टेस्टिंग आवश्यक हैं।
• विकलांग लोगों के साथ टेस्ट करें, केवल उनके लिए नहीं।
• एक्सेसिबिलिटी को शुरू से बनाना सस्ता और टिकाऊ है; इसे रेट्रोफ़िट करना महंगा और नाज़ुक है।
• सुलभ डिज़ाइन हर किसी के लिए बेहतर डिज़ाइन है: curb-cut प्रभाव वास्तविक है।

संदर्भ और आगे पढ़ना

• W3C, Web Content Accessibility Guidelines (WCAG) 2.2 and supporting Understanding/Techniques documents
• W3C, WAI-ARIA Authoring Practices Guide
• W3C Web Accessibility Initiative (WAI), introductory and tutorial materials
• Laura Kalbag, Accessibility for Everyone
• Sarah Horton and Whitney Quesenbery, A Web for Everyone
• Regine Gilbert, Inclusive Design for a Digital World
• U.S. Section 508 standards and Section508.gov guidance
• European standard EN 301 549 and the European Accessibility Act
• Government accessibility guidance (e.g., UK GDS accessibility manual)
• WebAIM, research and articles including the annual accessibility analyses