🥇पहुंच की ओर | प्रोहोस्टर

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

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

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

अरे नहीं! मैं इसके लायक क्यों था? क्या वे चाहते हैं कि मैं चला जाऊं? अपने आप को कृतघ्न परिश्रम और अन्य लोगों की गलतियों को सुधारने का प्रयास करने के लिए तैयार करें। यह निश्चित रूप से एक विफलता है...

यह उपलब्धता कुछ वर्ष पहले थी। कुछ गरीब आत्माओं को यूआई को "साफ करने" का काम दिया गया ताकि इसे विकलांग लोगों के लिए सुलभ बनाया जा सके।

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

लेकिन अचानक "कीड़े" हिमस्खलन की गति से बढ़ने लगे।

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

उपयोगकर्ताओं ने शिकायत की है कि ऐप अनुपयोगी है।

जैसे ही एक जगह एक त्रुटि सुधारी गई, दूसरी जगह दूसरी त्रुटि सामने आ गई।

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

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

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

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

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

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

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

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

हम बहुत जल्दी कुछ निष्कर्ष पर पहुंचे:

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

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

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

दरअसल, यहां न केवल भूमिकाएं जोड़ी गई हैं, बल्कि कीबोर्ड नेविगेशन के लिए इवेंट हैंडलर भी जोड़े गए हैं।

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

आप इसे क्रियान्वित रूप में यहाँ देख सकते हैं https://stardust-ui.github.io/react/ - यूएक्स लाइब्रेरी प्रतिक्रिया, जिसे शुरू से ही पहुंच को ध्यान में रखकर डिज़ाइन और कार्यान्वित किया गया है।

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

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

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

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

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

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

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

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

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

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

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

केवल पंजीकृत उपयोगकर्ता ही सर्वेक्षण में भाग ले सकते हैं। साइन इन करेंकृपया।

क्या आप अपने एप्लिकेशन की पहुंच पर ध्यान देते हैं?

Да
नहीं
यह पहली बार है जब मैंने ऐप एक्सेसिबिलिटी के बारे में सुना है।

17 उपयोगकर्ताओं ने मतदान किया। 5 उपयोगकर्ता अनुपस्थित रहे।

स्रोत: www.habr.com

पहुंच की ओर

क्या आप अपने एप्लिकेशन की पहुंच पर ध्यान देते हैं?

एक टिप्पणी जोड़ें उत्तर रद्द