अपने उत्पादों की गैर-दृश्य उपलब्धता (समस्या के तकनीकी पहलुओं) को सुनिश्चित करने के मुद्दे पर ऑल-रूसी सोसायटी ऑफ द ब्लाइंड से 1 सी कंपनी की अपील

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

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

प्रारंभिक शैक्षिक कार्यक्रम

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

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

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

सभी के लिए समस्या की प्रासंगिकता

प्रोग्राम इंटरफेस और विशेष रूप से 1 सी वातावरण की गैर-दृश्य उपलब्धता की समस्या दूर नहीं होती है।

दुर्भाग्य से, दृष्टि की समस्याओं वाले लोगों की संख्या, दवा के विकास के बावजूद, इसके विपरीत बढ़ जाती है, क्योंकि आधुनिक दुनिया में शरीर के दृश्य समारोह पर भार कई गुना बढ़ गया है। इससे दृष्टि की कमी या पूर्ण हानि के कारण हर साल पुनर्वास की आवश्यकता वाले लोगों की संख्या में वृद्धि होती है। इसके अलावा, पेशेवर पुनर्वास सहित, और न केवल घरेलू।

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

अंधे के लिए पेशेवर सॉफ्टवेयर की अनुपलब्धता उन कारकों में से एक है जो इस समस्या के समाधान को तीनों पक्षों के लाभ के लिए बाधित करते हैं:

1. विकलांग लोग जो नौकरी पाने की इच्छा रखते हैं;
2. एक राज्य जो अपने सामाजिक कार्यों को पूरा करना चाहता है;
3. एक सक्षम और प्रभावी कर्मचारी प्राप्त करने के इच्छुक संगठन।

कई क्षेत्रों में रूस और व्यक्तिगत सीआईएस देशों के लिए 1 सी सॉफ़्टवेयर पैकेज व्यावहारिक रूप से वास्तविक मानक है, इसलिए पहचानी गई समस्या के संदर्भ में, इसकी उपलब्धता का सवाल बेहद गंभीर है।

तकनीकी दृष्टिकोण

OSI के अध्यक्ष द्वारा उपरोक्त अपील में, निम्नलिखित वाक्यांश है:

... गैर-दृश्य स्क्रीन एक्सेस कार्यक्रमों (जॉज़ और एनव्हिडिए) के साथ 1 सी कार्यक्रम (संस्करण 8) की संगतता सुनिश्चित करने की समस्या को हल करने की आवश्यकता है। प्रारंभिक अनुमानों के अनुसार, इस संशोधन में महत्वपूर्ण समय और सामग्री की लागत की आवश्यकता नहीं होगी और हम संयुक्त रूप से इस समस्या को हल करने के लिए नेत्रहीन प्रोग्रामर को आकर्षित करने के लिए तैयार हैं। "

आपको इस तथ्य पर छूट देनी चाहिए कि यह सिर्फ एक प्रेस विज्ञप्ति है, और इस जानकारी को कार्रवाई के मार्गदर्शक के रूप में न लें।

सबसे पहले, JAWS और NVDA सॉफ्टवेयर के विशेष मामले हैं, हालांकि सबसे आम हैं। हालांकि, उनके अलावा, अब भी रूसी बाजार में दो और समाधान हैं (COBRA और SuperNova), और निकट भविष्य में, एक तीसरा (विंडो-आइज़) भी दिखाई देना चाहिए।

दूसरे, कुछ मामलों में केवल सहायक सॉफ़्टवेयर के स्तर तक बढ़ते हुए, निचले स्तर पर एप्लिकेशन एक्सेस को लागू करना अधिक सही है।

वास्तव में दो स्तर हैं:

1. ऑपरेटिंग सिस्टम में लागू पहुंच एपीआई का स्तर;
2. स्क्रीन एक्सेस प्रोग्राम स्तर (प्रत्येक प्रोग्राम का अपना कार्यान्वयन है)।

बदले में, स्क्रीन एक्सेस प्रोग्राम स्तर को भी विभाजित किया जा सकता है:

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

इस प्रकार, आवेदन की उपलब्धता को लागू करने के लिए तीन दृष्टिकोण हैं। सच है, वे अक्सर एक दूसरे में बहते हैं।

समस्या को हल करने के लिए विकल्प

पूर्वगामी के आधार पर, हम आवेदन की उपलब्धता को लागू करने के लिए निम्नलिखित रणनीतियों को अलग कर सकते हैं।

I. प्रोग्राम को सामान्य सिस्टम एक्सेसिबिलिटी एपीआई में अपनाना

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

यदि एप्लिकेशन इंटरफ़ेस को एक अलग वातावरण या ढांचे का उपयोग करके डिज़ाइन किया गया है, तो उनके पास आमतौर पर अपनी प्रौद्योगिकियां होती हैं, उदाहरण के लिए, जावा के लिए जावा एक्सेस ब्रिज या क्यूटी के लिए QAccessibleInterface।

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

यह एक अच्छी रणनीति है, क्योंकि यह सभी स्क्रीन एक्सेस कार्यक्रमों के लिए सार्वभौमिक पहुँच प्रदान करता है, अर्थात।

द्वितीय। एक विशिष्ट स्क्रीन एक्सेस प्रोग्राम के लिए एक एप्लिकेशन को अपनाना

इस क्षेत्र में, डेवलपर इस तथ्य पर ध्यान केंद्रित करता है कि वह एक विशिष्ट स्क्रीन-एक्सेस प्रोग्राम के एपीआई के माध्यम से प्रासंगिक जानकारी के हस्तांतरण को लागू करता है। यह या तो स्क्रीन एक्सेस प्रोग्राम के निर्माता द्वारा प्रदान किए गए dll का उपयोग कर सकता है, या OLE स्वचालन ऑब्जेक्ट्स को कॉल कर सकता है जो स्क्रीन एक्सेस प्रोग्राम से संबंधित हैं।

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

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

तृतीय। स्क्रीन एक्सेस प्रोग्राम के लिए एक मॉड्यूल का विकास

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

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

इसकी व्यापकता को केवल इस तथ्य से समझाया गया है कि संशोधन की आवश्यकता के अनुप्रयोग के डेवलपर को समझाने की तुलना में एक अलग स्क्रीन एक्सेस प्रोग्राम के लिए मॉड्यूल विकसित करना अक्सर आसान होता है। यही है, यह एकमात्र विकल्प है जो एप्लिकेशन डेवलपर के साथ सहयोग की आवश्यकता के बिना उपलब्ध है।

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

एक नियम के रूप में, मॉड्यूल या तो स्क्रीन-एक्सेस प्रोग्राम के डेवलपर्स द्वारा लिखे जाते हैं, जब यह एक बहुत व्यापक अनुप्रयोग की बात आती है, जिसकी उपलब्धता अत्यंत प्रासंगिक है, उदाहरण के लिए, Microsoft Office, स्वतंत्र प्रोग्रामर द्वारा, एक नियम के रूप में, जो स्क्रीन आधारित कार्यक्रम के सिर्फ उपयोगकर्ता हैं और अपने स्वयं के कार्यों को हल करते हैं। या ऐप डेवलपर द्वारा काम पर रखे गए प्रोग्रामर को आउटसोर्स किया जाता है।

इसे स्पष्ट करने के लिए, एक ग्राफिक बटन की पहुंच के कार्यान्वयन के साथ एक सरल उदाहरण पर विचार करें, जिसमें एक पाठ हस्ताक्षर नहीं है जिसके द्वारा यह एक अंधे उपयोगकर्ता द्वारा पहचाना जाता है:

• रणनीति I: एप्लिकेशन इंटरफ़ेस में बटन तत्व में एक पाठ लेबल जोड़ें और सभी स्क्रीन एक्सेस कार्यक्रमों के लिए पहुंच सुनिश्चित करें।
• रणनीति II: हम प्रोग्राम डेवलपर X से DLL को एप्लिकेशन के पैकेज में जोड़ते हैं, और जब सिस्टम फ़ोकस अहस्ताक्षरित बटन पर पड़ता है, तो DLL के माध्यम से हम टेक्स्ट लेबल का उच्चारण करने के लिए स्क्रीन एक्सेस प्रोग्राम को कमांड देते हैं। यदि स्क्रीन-एक्सेस प्रोग्राम का उपयोगकर्ता वाई को समर्थन के लिए कहता है, तो हम या तो इस कार्यक्रम के लिए एक समान योजना लागू करेंगे, या हम उसे प्रोग्राम एक्स पर स्विच करने की सलाह देंगे, और वह इससे खुश होने की संभावना नहीं है।
• रणनीति III: हम एक्स स्क्रीन एक्सेस प्रोग्राम के लिए मॉड्यूल लिखने में एक विशेषज्ञ सक्षम के साथ सहमत होंगे, या हम खुद ऐसे विशेषज्ञ का पोषण करेंगे, जो एक प्लग-इन का विकास करेगा यदि एक अहस्ताक्षरित बटन फ़ोकस में आता है। यदि प्रोग्राम Y का उपयोगकर्ता समर्थन करता है, तो रणनीति II के समान है।

ये तीन बुनियादी रणनीतियाँ हैं, हालाँकि इनके विभिन्न संयोजन हो सकते हैं, साथ ही साथ कुछ अधिक परिष्कृत तरीके भी हो सकते हैं।

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