पहुँच तर्फ

शुक्रबार काम गर्ने दिनको अन्त्य हो। खराब समाचार सधैं शुक्रबार कामको दिनको अन्त्यमा आउँछ।

तपाईं कार्यालय छोड्न लाग्दै हुनुहुन्छ, अर्को पुनर्संरचनाको बारेमा नयाँ पत्र भर्खरै मेलमा आएको छ।

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

धत्तेरिका! म किन यो योग्य थिए? के तिनीहरू मलाई छोड्न चाहन्छन्? कृतज्ञ कडा परिश्रमको लागि आफैलाई सेट अप गर्नुहोस् र अरू मानिसहरूका गल्तीहरू सुधार्ने प्रयास गर्नुहोस्। यो पक्कै पनि असफलता हो...

यो केही वर्ष पहिले उपलब्धता थियो। केही गरिब आत्माहरूलाई UI लाई "सफाई" गर्ने काम दिइयो र यसलाई अपाङ्गता भएका व्यक्तिहरूको लागि पहुँचयोग्य बनाउन प्रयास गरियो।

वास्तवमा यसको मतलब के हो त्यो एकदम अस्पष्ट थियो - सम्भवतः यदि तपाइँ फिल्डहरू मार्फत फोकस सूचक र ट्याब देख्न सक्नुहुन्छ, केहि Alt पाठ र केहि क्षेत्र विवरणहरू छन् भने, यो तपाइँको आवेदन पहुँचयोग्य छ भनेर विचार गरिनेछ ...

तर अचानक "बगहरू" हिमस्खलनको गतिमा गुणा गर्न थाले।

विभिन्न स्क्रिन रिडरहरू (Eng। स्क्रिन रिडरहरू) र ब्राउजरहरूले पूर्ण रूपमा फरक व्यवहार गरे।

एप प्रयोग गर्न नसकिने प्रयोगकर्ताले गुनासो गरेका छन् ।

एक ठाउँमा त्रुटि सच्याएपछि अर्को ठाउँमा त्रुटि देखा पर्‍यो।

र केवल प्रयोगकर्ता इन्टरफेस त्रुटिहरू परिवर्तन र सुधार गर्न हर्कुलियन प्रयासहरू आवश्यक पर्दछ।

म त्यहाँ थिए। म बाँचेँ, तर हामी "सफल" हुन सकेनौं - प्राविधिक रूपमा हामीले धेरै सफा गर्यौं, धेरै क्षेत्र विवरणहरू, भूमिकाहरू थप्यौं, र अनुपालनको केही स्तर हासिल गर्‍यौं, तर कोही पनि खुसी भएनन्। प्रयोगकर्ताहरूले अझै पनि अनुप्रयोग नेभिगेट गर्न नसकेको गुनासो गरे। प्रबन्धकले अझै पनि त्रुटिहरूको निरन्तर प्रवाहको बारेमा गुनासो गरे। ईन्जिनियरहरूले गुनासो गरे कि समस्या गलत रूपमा प्रस्तुत गरिएको थियो, स्पष्ट रूपमा परिभाषित "सही" समाधान बिना जुन सबै अवस्थामा काम गर्दछ।

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

म यो बारम्बार फर्केर आउनेछु, तर मानिसहरूले हाम्रो एप कसरी प्रयोग गरे भन्ने बारे हाम्रा सबै "धारणाहरू" गलत थिए।

किस्ट्रोकहरू प्रयोग गरेर जटिल प्रयोगकर्ता इन्टरफेस नेभिगेट गर्दै Tab/Shift+Tab - यो बेकार छ! हामीलाई केहि राम्रो चाहिन्छ। किबोर्ड सर्टकटहरू, हेडरहरू।

UI परिवर्तन गर्दा फोकस गुमाउनु ठूलो समस्या होइन, यो हो? फेरि सोचौं - यो अविश्वसनीय भ्रामक छ।

मैले जारी राखें, केही समयको लागि विभिन्न परियोजनाहरूमा काम गरें, र त्यसपछि हामीले नयाँ परियोजना सुरु गर्यौं, एक जटिल प्रयोगकर्ता इन्टरफेस र स्पष्ट स्थापनाको साथ, अन्ततः यस पटक पहुँच प्राप्त गर्न।

त्यसोभए, हामीले एक कदम फिर्ता लियौं र हामीले यसलाई कसरी फरक ढंगले कार्यान्वयन गर्न र सफल बनाउन सक्छौं, र प्रक्रियालाई कम बोरिंग बनाउन सक्छौं भनेर हेर्यौं!

चाँडै हामी केहि निष्कर्षमा पुग्यौं:

1. हामी प्रयोगकर्ता इन्टरफेस विकास गर्ने मानिसहरूलाई aria लेबल/भूमिकाहरू र पक्कै पनि, कम्पोनेन्टहरूको HTML संरचनासँग गडबड गर्न चाहँदैनौं। हामीले तिनीहरूलाई सही कम्पोनेन्टहरू प्रदान गर्न आवश्यक छ जसले पहुँचलाई बक्सबाट बाहिर नै निर्माण गर्यो।
2. पहुँच == प्रयोगको सहजता - अर्थात् यो प्राविधिक चुनौती मात्र होइन। हामीले सम्पूर्ण डिजाइन प्रक्रिया परिवर्तन गर्न र पहुँचयोग्यतालाई ध्यानमा राखी UI डिजाइन सुरु गर्नु अघि छलफल गरिएको सुनिश्चित गर्न आवश्यक छ। प्रयोगकर्ताहरूले कसरी कुनै प्रकार्यता पत्ता लगाउनेछन्, उनीहरूले कसरी नेभिगेट गर्नेछन्, र कुञ्जीपाटीबाट दायाँ-क्लिकले कसरी काम गर्नेछ भनेर तपाईंले चाँडै सोच्न आवश्यक छ। पहुँच डिजाइन प्रक्रियाको अभिन्न अंग हुनुपर्दछ - केहि प्रयोगकर्ताहरूको लागि यो अनुप्रयोगको उपस्थिति भन्दा धेरै हो।
3. सुरुदेखि नै, हामी अन्धा र अन्य अपाङ्गता भएका प्रयोगकर्ताहरूबाट अनुप्रयोगको प्रयोगको सहजताको बारेमा प्रतिक्रिया प्राप्त गर्न चाहन्थ्यौं।
4. हामीलाई पहुँच प्रतिगमनहरू समात्न साँच्चै राम्रो तरिकाहरू चाहिन्छ।

ठीक छ, ईन्जिनियरिङ्को दृष्टिकोणबाट, पहिलो भाग एकदमै रमाइलो लाग्थ्यो - वास्तुकलाको विकास गर्दै र कम्पोनेन्टहरूको पुस्तकालय लागू गर्दै। र वास्तवमा यो त्यस्तै थियो।

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

वास्तवमा, यहाँ भूमिकाहरू मात्र थपिएका छैनन्, तर किबोर्ड नेभिगेसनका लागि घटना ह्यान्डलरहरू पनि छन्।

यो थप सफा देखिन्छ। यदि हामीले तिनीहरूको बीचमा सफा पृथक्करण प्राप्त गर्न सक्छौं भने, यसले संरचना कसरी सिर्जना गरेको हो भन्ने कुराले फरक पार्दैन, हामी यसमा व्यवहारहरू लागू गर्न सक्छौं र पहुँच अधिकार प्राप्त गर्न सक्छौं।

तपाईले यसलाई कार्यमा देख्न सक्नुहुन्छ https://stardust-ui.github.io/react/ - UX पुस्तकालय प्रतिक्रिया, जुन सुरुदेखि नै पहुँचलाई ध्यानमा राखेर डिजाइन र कार्यान्वयन गरिएको हो।

दोस्रो भाग - डिजाइनको वरिपरि दृष्टिकोण र प्रक्रियाहरू परिवर्तन गर्दा सुरुमा मलाई डर लाग्यो: संगठनात्मक परिवर्तनको माध्यमबाट धकेल्न खोज्ने निम्न इन्जिनियरहरू सधैं राम्रोसँग समाप्त हुँदैन, तर यो सबैभन्दा रोचक क्षेत्रहरू मध्ये एक भयो जहाँ हामीले प्रक्रियामा महत्त्वपूर्ण योगदानहरू गर्यौं। । संक्षेपमा, हाम्रो प्रक्रिया निम्नानुसार थियो: नयाँ कार्यक्षमता एक टोलीद्वारा विकसित गरिनेछ, त्यसपछि हाम्रो नेतृत्व टोलीले प्रस्तावको समीक्षा/पुनरावलोकन गर्नेछ, र त्यसपछि, एक पटक स्वीकृत भएपछि, डिजाइन सामान्यतया इन्जिनियरिङ टोलीलाई हस्तान्तरण गरिनेछ। यस अवस्थामा, ईन्जिनियरिङ् टोलीले प्रभावकारी रूपमा पहुँच कार्यक्षमताको "स्वामित्व" गर्यो किनभने यो सम्बन्धित कुनै पनि समस्याहरू समाधान गर्ने जिम्मेवारी थियो।

प्रारम्भमा, पहुँच र उपयोगिता अभिन्न रूपमा जोडिएका छन् र यो डिजाइन चरणमा गर्नुपर्थ्यो भनेर व्याख्या गर्न एकदमै गाह्रो काम थियो, अन्यथा यसले ठूलो परिवर्तन र केही भूमिकाहरूको पुन: परिभाषा निम्त्याउने थियो। जे होस्, व्यवस्थापन र प्रमुख खेलाडीहरूको समर्थनमा, हामीले यो विचार लियौं र यसलाई गतिमा राख्यौं ताकि डिजाइनहरू व्यवस्थापनमा प्रस्तुत गर्नु अघि पहुँच र उपयोगिताको लागि परीक्षण गरियो।

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

हामीले यी (वा पछिल्ला) बैठकहरूमा अन्धा र असक्षम प्रयोगकर्ताहरू भएमा यो अझ राम्रो गर्न सक्थ्यौं - यो व्यवस्थित गर्न गाह्रो थियो, तर हामी अहिले स्थानीय दृष्टिविहीन संस्थाहरू र कम्पनीहरूसँग काम गर्छौं, जसले कार्यान्वयन प्रवाह प्रारम्भिक रूपमा प्रमाणित गर्न बाह्य परीक्षण प्रदान गर्दछ। विकास - दुबै घटक र कार्यान्वयन प्रवाह स्तरहरूमा।

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

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

1. पहुँच जानकारीहरू उपकरणहरूको सेट हो जुन ब्राउजरमा र समस्याहरू पहिचान गर्न निर्माण/परीक्षण चक्रको भागको रूपमा चलाउन सकिन्छ।
2. स्क्रिन रिडरहरूले सही रूपमा काम गर्छ भनी प्रमाणित गर्नु एक विशेष चुनौतीपूर्ण कार्य भएको छ। पहुँच को परिचय संग पहुँच DOM, हामी अन्ततः एपको पहुँच स्न्यापसटहरू लिन सक्षम छौं, जस्तै हामीले दृश्य परीक्षणहरूको लागि गर्छौं, र तिनीहरूलाई रिग्रेसनको लागि परीक्षण गर्छौं।

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

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

ML/AI ले अन्तरक्रिया र काम गर्ने पूर्णतया नयाँ तरिकाहरू सक्षम गर्दैछ, र हामी यस अत्याधुनिक यात्राको अर्को चरणहरूको हिस्सा हुन पाउँदा उत्साहित छौं। नवाचार सोचमा परिवर्तनद्वारा संचालित हुन्छ - मानवता सहस्राब्दीदेखि अवस्थित छ, सयौं वर्षदेखि मेसिनहरू, धेरै दशकहरूदेखि वेबसाइटहरू, र स्मार्टफोनहरू पनि कम छन्, प्रविधिले मानिसहरूलाई अनुकूलन गर्नुपर्छ, र यसको विपरीत होइन।

PS लेख मूलबाट सानो विचलन संग अनुवाद गरिएको छ। यस लेखको सह-लेखकको रूपमा, म हगसँग यी डिग्रेसनहरूमा सहमत छु।

दर्ता भएका प्रयोगकर्ताहरूले मात्र सर्वेक्षणमा भाग लिन सक्छन्। साइन इन गर्नुहोस्कृपया

के तपाइँ तपाइँको अनुप्रयोगहरूको पहुँचमा ध्यान दिनुहुन्छ?

• हो

• कुनै

• यो पहिलो पटक हो मैले एप पहुँचको बारेमा सुनेको छु।

17 प्रयोगकर्ताहरूले मतदान गरे। 5 प्रयोगकर्ताहरू रोकिए।

स्रोत: www.habr.com