🙄 👌🏿 🌮 सुलभता की ओर 💃🏻 🔩 💿

Microsoft टीम की पहुँच टीम का लॉगोटाइप। संक्षिप्त अंग्रेजी शब्द पहुँच के साथ Microsoft लोगो चश्मा - a11y

शुक्रवार दिन का अंत है। बुरी खबर हमेशा दिन के अंत में शुक्रवार को आती है।

आप कार्यालय छोड़ने वाले हैं, "जिन" अगले पुनर्गठन के बारे में एक नया पत्र अभी मेल में आया है।

धन्यवाद xxxx, आज से आप zzzz को रिपोर्ट करेंगे
...
और ह्यूग टीम हमारे उत्पादों को विकलांग लोगों के लिए सुलभ बनाएगी।

अरे नहीं! मैं इसके लायक क्यों था? क्या वे मुझे छोड़ना चाहते हैं? एक कृतघ्न कड़ी मेहनत में ट्यून करें और दूसरे लोगों की गलतियों को ठीक करने का प्रयास करें। यह शायद एक विफलता है ...

यह कुछ साल पहले सुलभता थी। कुछ गरीब लोगों को विकलांग लोगों के लिए इसे सुलभ बनाने की कोशिश करने के लिए यूजर इंटरफेस "सफाई" का काम मिला।

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

लेकिन अचानक, "बग" एक हिमस्खलन की गति से गुणा करना शुरू कर दिया।

विभिन्न स्क्रीन रीडर और ब्राउज़र पूरी तरह से अलग तरह से व्यवहार करते हैं।

उपयोगकर्ताओं ने शिकायत की कि आवेदन उपयोग के लिए उपयुक्त नहीं है।

जैसे ही एक स्थान पर त्रुटि को ठीक किया गया, दूसरा दूसरे में दिखाई दिया।

और, उपयोगकर्ता इंटरफ़ेस त्रुटियों को बदलने और ठीक करने के लिए एक टाइटैनिक प्रयास की आवश्यकता थी।

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

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

मैं बार-बार इस पर वापस आऊंगा, लेकिन हमारी "मान्यताओं" के बारे में लगभग सभी लोगों ने बताया कि हमारे आवेदन का उपयोग कैसे गलत था।

Tab/Shift+Tab कुंजियों के उपयोग से जटिल उपयोगकर्ता इंटरफ़ेस के माध्यम से नेविगेट करना! कुछ बेहतर चाहिए। कीबोर्ड शॉर्टकट, हेडर।

यूआई बदलते समय ध्यान केंद्रित करने की हानि यह एक बड़ी समस्या नहीं है? फिर से सोचें - यह पागलपन भरी बात है।

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

इसलिए, हमने एक कदम पीछे लिया और देखा कि कैसे हम इसे अलग तरीके से लागू कर सकते हैं और सफल हो सकते हैं, और इसलिए कि कार्य प्रक्रिया स्वयं उबाऊ नहीं है!

बहुत जल्दी हम कुछ निष्कर्षों पर आए:

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

खैर, इंजीनियरिंग के दृष्टिकोण से, पहला भाग बहुत मजेदार लग रहा था - वास्तुकला का विकास और घटकों के एक पुस्तकालय के कार्यान्वयन। और वास्तव में यह था।

ARIA के उदाहरणों को देखते हुए और इसे "अनुकूलन" समस्या के बजाय एक डिजाइन समस्या के रूप में देखते हुए, एक कदम पीछे लेते हुए, हमने कुछ अंशों को पेश किया। घटक में एक 'संरचना' (HTML तत्व शामिल हैं) और एक 'व्यवहार' (यह उपयोगकर्ता के साथ कैसे बातचीत करता है)। उदाहरण के लिए, नीचे दिए गए स्निपेट्स में, हमारे पास एक सरल अनऑर्डर की गई सूची है। सूची में "व्यवहार" जोड़ते समय, उपयुक्त भूमिकाएँ जोड़ी जाती हैं ताकि यह सूची की तरह काम करे। इसी तरह, हम मेनू के लिए करते हैं।

सुगमता के लिए गुण और व्यवहार के साथ सूची घटकों और मेनू में एक साधारण सूची के परिवर्तन को दिखाने वाली छवि।

सुगमता के लिए गुण और व्यवहार के साथ सूची घटकों और मेनू में एक साधारण सूची के परिवर्तन को दिखाने वाली छवि।

वास्तव में, न केवल भूमिकाओं को यहां जोड़ा जाता है, बल्कि कीबोर्ड नेविगेशन के लिए घटना संचालकों को भी जोड़ा जाता है।

यह पहले से अधिक साफ-सुथरा दिखता है। यदि हम उनके बीच एक स्वच्छ अलगाव प्राप्त कर सकते हैं, तो इससे कोई फर्क नहीं पड़ता कि संरचना कैसे बनाई गई थी, हम इसके लिए व्यवहार लागू कर सकते हैं और सही पहुंच प्राप्त कर सकते हैं।

कार्रवाई में, यह https://stardust-ui.imtqy.com/react/ पर देखा जा सकता है - रिएक्ट UX लाइब्रेरी, जिसे शुरू से ही खाते की पहुंच को ध्यान में रखते हुए बनाया और कार्यान्वित किया जाता है।

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

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

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

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

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

विज़ुअल रिग्रेशन की परिभाषा एक निश्चित कार्य है, इस प्रक्रिया में बहुत कम जोड़ा जा सकता है, सिवाय इसके कि शायद कीबोर्ड की मदद से नेविगेट करते समय फोकस दिखाई दे रहा है या नहीं। अधिक दिलचस्प पहुंच के साथ काम करने के लिए दो अपेक्षाकृत नई प्रौद्योगिकियां हैं।

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

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

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

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

पी एस लेख मूल से कुछ विचलन के साथ अनुवाद किया गया था। इस लेख के सह-लेखक के रूप में, मैं ह्यूज के साथ इन पचड़ों पर सहमत हुआ।

सुलभता की ओर

More articles: