प्रवेशयोग्यता चाचणी: सर्वसमावेशक सॉफ्टवेअर तयार करण्याचे शक्तिशाली मार्ग

चाचणीमुळे लोकांना उत्पादन वापरण्यापासून थांबवणाऱ्या समस्या शोधण्यात संघांना मदत होते. हे सॉफ्टवेअर स्थिर आणि वापरण्यास सुलभ बनवते. स्क्रीन रीडर हे एक महत्त्वाचे क्षेत्र आहे. कार्यसंघांनी पृष्ठे कशी वाचली जातात, लेबले कशी हाताळली जातात आणि शीर्षके आणि दुवे अर्थपूर्ण आहेत की नाही हे तपासले पाहिजे. कीबोर्ड तपासणे देखील महत्त्वाचे आहे. परीक्षकांनी पुष्टी करणे आवश्यक आहे, वापरून प्रवेशयोग्यता चाचणीजे वापरकर्ते क्रमाने नियंत्रणांमधून पुढे जाऊ शकतात, फोकस कुठे आहे ते पाहू शकतात आणि माउसशिवाय प्रत्येक क्रियेपर्यंत पोहोचू शकतात.

कलर कॉन्ट्रास्ट हे आणखी एक सामान्य अंतर आहे. कॉन्ट्रास्ट चेकमध्ये मजकूर, बटणे आणि मुख्य UI स्थिती समाविष्ट केल्या पाहिजेत जेणेकरून कमी दृष्टी किंवा रंगाचा गोंधळ असलेल्या लोकांसाठी सामग्री गमावली जाणार नाही. टीम टूल्ससह ऑडिट देखील करू शकतात. या तपासण्यांमध्ये वारंवार समस्या येतात, परंतु ते मानवी पुनरावलोकनाची जागा घेत नाहीत. वास्तविक वापरकर्ता अभिप्राय अजूनही महत्त्वाचा आहे.

प्रवेशयोग्यता एकूण सॉफ्टवेअर गुणवत्तेशी जोडते. इंटरफेस वापरणे कठीण असल्यास, वैशिष्ट्ये सिद्धांतानुसार कार्य करत असली तरीही लोक कार्ये पूर्ण करू शकत नाहीत. सहसा लवकर चाचणी घेणे चांगले. बिल्ड टाइम दरम्यान समस्या सोडवणे रिलीझ नंतर सोडवण्यापेक्षा कमी खर्च करते. समावेशक UX एकापेक्षा जास्त गटांना मदत करते. हे केवळ कायमस्वरूपी अपंग असलेल्यांनाच नव्हे तर तात्पुरत्या मर्यादा असलेल्या किंवा विचित्र परिस्थितीचा सामना करणाऱ्या लोकांना समर्थन देते.

प्रवेशयोग्यता चाचणी म्हणजे काय?

प्रवेशयोग्यता चाचणी म्हणजे अडथळे शोधण्यासाठी सॉफ्टवेअर तपासणे. हे अडथळे अपंग असलेल्या लोकांवर परिणाम करू शकतात. चेकमध्ये वैशिष्ट्ये कशी कार्य करतात आणि सामग्री कशी दर्शविली जाते हे समाविष्ट आहे.

सामान्य क्षेत्रांमध्ये हे समाविष्ट आहे:

• फक्त कीबोर्ड वापरणे
• स्क्रीन वाचक पृष्ठे कशी वाचतात
• मजकूर आणि पार्श्वभूमी यांच्यातील रंगाचा फरक
• झूम आणि मजकूर आकार बदलण्याचे वर्तन
• फॉर्म आणि फॉर्म फील्ड
• प्रतिमा आणि त्यांचा पर्यायी मजकूर
• शीर्षलेख आणि पृष्ठ विभागाचा क्रम
• जिथे फोकस स्क्रीनवर हलतो
• बटणे, दुवे आणि इतर परस्पर भाग
• त्रुटी संदेश कसे सादर केले जातात
• ऑडिओ आणि व्हिडिओ सामग्री

हे काम वेगवेगळ्या प्रकारे करता येते. काही चाचण्या ऑटोमेशन वापरतात. इतर हाताने केले जातात. आपण वास्तविक लोकांसह देखील चाचणी घेऊ शकता. एकापेक्षा जास्त पद्धती वापरणे मदत करते. ऑटोमेशन स्पॉट्स समस्या ज्या टूल्स शोधू शकतात. हँड चेकमुळे परीक्षकाला प्रत्यक्ष संवादाद्वारे इंटरफेस जाणवण्यास मदत होते. वास्तविक वापरकर्त्यांना अनेकदा अशा समस्या लक्षात येतात ज्या विकसकांना अपेक्षित नसतात. केवळ उच्च प्रवेशयोग्यता स्कोअर हे उद्दिष्ट नाही. लोक अडकून न पडता महत्त्वाची कामे पूर्ण करू शकतात का हे पाहण्याचा उद्देश आहे.

प्रवेशयोग्यता खरोखर सॉफ्टवेअर गुणवत्तेचा भाग आहे.

काही संघ प्रवेशयोग्यतेला साईड टास्क प्रमाणे हाताळतात.

ते सामान्य विकासापासून वेगळे बसल्यासारखे कार्य करतात. व्यवहारात जे घडते त्याच्याशी ते दृश्य जुळत नाही. जेव्हा ॲपमध्ये प्रवेशयोग्यता अंतर असते, तेव्हा ते सहसा इतर समस्येकडे देखील निर्देश करते. उदाहरणार्थ, खराब लेआउट स्क्रीन-रीडर वापरकर्त्याला ट्रिप करू शकते. हे कोडसह नंतर काम करणे देखील कठीण करू शकते.

अस्पष्ट त्रुटी सहाय्यक साधने वापरणाऱ्या लोकांना त्रास देऊ शकतात. ते दृश्यदृष्टीवर अवलंबून असल्या लोकांनाही अस्वस्थ करतात. फोकस समस्या समान आहेत.

ते कीबोर्ड वापरकर्त्यांना दुखवू शकतात आणि ते इतरांना दुखवू शकतात जे माऊस वापरत नाहीत. चांगली प्रवेशयोग्यता सामान्यत: चांगल्या प्रकारे केलेल्या मूलभूत गोष्टींमधून येते. स्पष्ट रचना मदत करते. स्थिर वर्तन महत्त्वाचे. इंटरफेस आणि वापरकर्ता यांच्यातील संवाद महत्त्वाचा आहे. त्यामुळे प्रवेशयोग्यता ठोस अभियांत्रिकीमध्ये बसते, नंतरचा विचार नाही.

स्क्रीन रीडर तपासतो: ॲप चांगला संवाद साधतो का?

स्क्रीन रीडर हे एक सहाय्यक साधन आहे.

हे ऑन-स्क्रीन सामग्रीला भाषणात किंवा अन्य प्रकारच्या आउटपुटमध्ये बदलते. NVDA, JAWS, VoiceOver आणि TalkBack ही सामान्य उदाहरणे आहेत. चांगले कार्य करण्यासाठी, सॉफ्टवेअरने उपयुक्त तपशील प्रकट करणे आवश्यक आहे. प्रत्येक नियंत्रण कशासाठी आहे आणि पृष्ठ कसे सेट केले आहे हे दर्शविणे आवश्यक आहे.

स्क्रीन रीडर वापरणारी व्यक्ती हे सांगण्यास सक्षम असावी:

• एक बटण काय करते
• जिथे एक दुवा जातो
• शेताला काय हवे आहे

• ते कोणत्या हेडिंगवर आहेत
• जर एखादा संवाद दिसला असेल
• काहीतरी चूक झाली आणि एरर उठवली तर

हे किती चांगले कार्य करते हे HTML आणि अंगभूत प्रवेशयोग्यतेच्या अर्थावर बरेच अवलंबून असते. त्यामुळे पॉलिश दिसणारा कस्टम इंटरफेस सहाय्यक तंत्रज्ञानापासून संरचनेला लपवून ठेवल्यास तो अयशस्वी होऊ शकतो. म्हणूनच स्क्रीन-रीडर चाचणी खूप मौल्यवान आहे. हे एक अनुभव दर्शविते की सामान्य दृश्य तपासणी चुकते.

कीबोर्ड ऍक्सेस चेक: माउसशिवाय वापरून पहा

चांगली चाचणी देखील मूलभूत आहे. फक्त कीबोर्डसह ॲप वापरा. कीबोर्ड वापरकर्ते की नियंत्रणे मिळवण्यास आणि त्यांचा वापर करण्यास सक्षम असावे.

तुम्ही दुवे, बटणे, फील्ड आणि इतर परस्पर भाग यासारख्या गोष्टींपर्यंत पोहोचण्यास सक्षम असावे.

या की वापरून पहा:

• पुढील फोकस आयटमवर जाण्यासाठी टॅब.
• मागे जाण्यासाठी Shift + Tab.
• फोकस केलेले नियंत्रण चालू करण्यासाठी Enter किंवा Space.

तुम्ही चाचणी करत असताना, तुम्ही टॅबसह मेनू आणि साइटमधून फिरू शकता हे तपासा. तुम्ही फॉर्म भरू शकता, डायलॉग बॉक्स उघडू शकता आणि माहिती पाठवू किंवा पुष्टी करू शकता का ते देखील पहा. आपण महत्त्वाचे असलेल्या मुख्य क्रियांपर्यंत पोहोचू शकता याची खात्री करा. WCAG सारखी मानके कीबोर्ड प्रवेश कव्हर करतात.

ते कीबोर्ड ट्रॅप्स देखील कव्हर करतात. जेव्हा पृष्ठाच्या एका भागावर फोकस येतो तेव्हा कीबोर्ड ट्रॅप होतो आणि नंतर आपण ते कीबोर्डसह सोडू शकत नाही. ही चाचणी दुसरी समस्या देखील दर्शवू शकते: फोकस दृश्यमानता. फोकस कुठे आहे हे पृष्ठ स्पष्टपणे दर्शवत नसल्यास, संपूर्ण इंटरफेस वापरण्यास कठीण वाटते. व्यस्त पडद्यावर, ते आणखी गोंधळात टाकणारे होते.

आजच्या ॲप स्क्रीन्समध्ये हाताळणीवर लक्ष केंद्रित करा

जेव्हा इंटरफेस JavaScript द्वारे चालविला जातो तेव्हा फोकस खूप महत्वाचे आहे. पॉप अप होणाऱ्या संवादाबद्दल विचार करा.

त्या क्षणी, लोकांना पृष्ठ बदलले आहे हे समजले पाहिजे. कीबोर्ड कर्सर योग्य ठिकाणी जावे. ते समस्या न करता संवाद नियंत्रणे वापरण्यास सक्षम असावे. ते बंद करण्यासाठी त्यांना एक सोपा, अपेक्षित मार्ग देखील आवश्यक आहे. बंद केल्यानंतर, कर्सर पृष्ठावर जिथे होता तिथे परत गेला पाहिजे.

हीच समस्या इतर अनेक UI भागांमध्ये दिसून येते, जसे की:

• ड्रॉप डाउन मेनू
• स्वयंपूर्ण इनपुट
• खरेदी गाड्या
• मल्टी स्टेज फॉर्म
• सूचना आणि संदेश
• ॲप्स जे पृष्ठ रीलोड करत नाहीत

जेव्हा लोकांच्या अपेक्षेप्रमाणे लक्ष केंद्रित केले जाते तेव्हा ते गोंधळात टाकणारे वाटू शकते. जर फोकस जेव्हा पाहिजे तेव्हा बदलत नसेल, तर ते प्रगती देखील रोखू शकते. त्यामुळे प्रवेशयोग्यता तपासण्यांनी “या घटकावर लक्ष केंद्रित केले जाऊ शकते का” या पलीकडे दिसले पाहिजे. त्यांनी प्रत्यक्ष वापरात फोकस कसे कार्य करते याची देखील चाचणी केली पाहिजे. वापरकर्त्याच्या दृष्टिकोनातून, वर्तन अर्थपूर्ण आणि सुसंगत असले पाहिजे.

फॉर्म भरण्यासाठी लोकांच्या अपेक्षेपेक्षा जास्त वेळ लागू शकतो

स्पष्ट कार्यासाठी एक फॉर्म लक्ष वेधून घेतो.

हे एका क्षेत्रातील चरणांची सूची देते.

मूलभूत गोष्टी करण्यासाठी संघ सहसा फॉर्मवर अवलंबून असतात:

• खाते सेट करा
• काहीतरी खरेदी करा
• मदतीसाठी विचारा
• बिल भरा
• समर्थनाशी संपर्क साधा
• भेटीची वेळ बुक करा

फील्ड लेबल चुकणे सोपे असते तेव्हा फॉर्म समस्या निर्माण करू शकतात. एरर जेव्हा कोणतीही खरी मदत दर्शवत नाहीत तेव्हा हे देखील चुकीचे होते. जर कोणी फील्डमधून फिरण्यासाठी कीबोर्ड वापरू शकत नसेल तर ते अडकू शकतात. त्यानंतर, संपूर्ण मार्ग तुटतो. वापरकर्ता थांबतो.

चांगले फॉर्म वेगळे दिसणारे लेबल वापरतात. ते स्कॅन करणे सोपे असावे. पृष्ठास त्रुटी मजकूर आवश्यक आहे जो सामान्य वाटतो, धक्कादायक नाही. जेव्हा एखादी चूक होते तेव्हा संदेश लहान आणि साधा असावा. इशारे व्यक्ती ज्या पायरीवर आहे त्या अचूकपणे जुळले पाहिजेत. प्रत्येक वेळी पूर्ण प्रवासाची चाचणी घ्या. फक्त एक बॉक्स चेक करू नका आणि थांबा. पहिल्या स्क्रीनपासून अंतिम सबमिटपर्यंत संपूर्ण क्रम चालवा.

हे केवळ तांत्रिक तपासणी उत्तीर्ण करण्याबद्दल नाही.

मुख्य प्रश्न सोपा आहे: नवीन व्यक्ती स्वतःहून फॉर्म पूर्ण करू शकते का?

उत्तम प्रवेशासाठी प्रथम साधे HTML वापरा

नोकरीशी जुळणारे टॅग निवडा.

जर मजकूर हेडिंग असेल तर त्याला हेडिंग टॅगमध्ये ठेवा.

क्रिया क्लिक असल्यास, एक बटण वापरा.

तुम्हाला दुसऱ्या पेजवर जाण्याची गरज असल्यास, लिंक वापरा.

मेनू आयटमसाठी, नेव्हिगेशन नीट आणि स्पष्ट ठेवा. इनपुटसाठी, फिट होईल असे लेबल जोडा.

या लेआउटसह, ब्राउझर आणि सहाय्यक साधने प्रत्येक भाग आणि त्याची भूमिका शोधू शकतात.

तुम्ही नंतर कोडवर परत आल्यावरही हेच सेटअप मदत करते. साध्या HTML सह तयार केलेला घटक इतरांना वाचणे सोपे असते. हे जेनेरिक ब्लॉक्सचे मिश्रण आणि बरेच स्क्रिप्ट वर्क यांना हरवू शकते.

वास्तविक प्रकल्पांमध्ये, चांगले प्रवेश कार्य आणि चांगले फ्रंटएंड कार्य सहसा एकत्र जातात.

प्रवेशयोग्यतेसाठी स्वयंचलित तपासणी

स्वयंचलित चाचणी आता सॉफ्टवेअरच्या कामाचा एक सामान्य भाग आहे. योग्य साधनांसह, एक कार्यसंघ पृष्ठे स्कॅन करू शकतो आणि यासारख्या समस्या शोधू शकतो:

• गहाळ असलेली लेबले
• कमी रंगाचा कॉन्ट्रास्ट
• तुटलेली किंवा अवैध विशेषता
• मार्कअपमध्ये स्ट्रक्चरल समस्या
• काही कीबोर्ड ट्रॅप किंवा फोकस समस्या
• पर्यायी मजकूर जो प्रतिमांवर अनुपस्थित आहे

हे धनादेश सतत एकत्रीकरणासाठी उपयुक्त आहेत. जेव्हा नवीन कोड येतो तेव्हा टीम ब्रेकेज लवकर पकडू शकते. तरीही, स्वयंचलित चाचणी पुरेसे नाही. एक स्कॅनर इमेज ऑल्ट मजकूर अस्तित्वात असल्याचा अहवाल देऊ शकतो. परंतु मजकूर वाचकाला मदत करतो की नाही हे सांगता येणार नाही. हे असेही म्हणू शकते की बटणाला प्रवेश करण्यायोग्य नाव आहे. तरीही ते नाव लोकांच्या अपेक्षांशी जुळते की नाही हे सांगता येत नाही.

हे तांत्रिक नियमांची पुष्टी देखील करू शकते. परंतु इंटरफेस वास्तविक वापरात स्पष्ट वाटत असल्यास ते ठरवू शकत नाही. W3C मार्गदर्शनाने मानवीय पुनरावलोकनांसह ऑटोमेशन जोडण्यास सांगितले आहे. हे ब्राउझर आणि सहाय्यक तंत्रज्ञानावर चाचणी देखील सुचवते.

संपूर्ण बिल्ड प्रक्रियेद्वारे प्रवेशयोग्यता चाचणी

तुम्ही लवकर सुरू केल्यावर प्रवेशयोग्यता उत्तम काम करते, शेवटच्या चाचणी टप्प्यावर नाही. डिझाईन टप्प्यात, संघ चांगला रंग कॉन्ट्रास्ट आणि स्पष्ट परस्पर नियम निवडू शकतो. विकासामध्ये, अभियंते सिमेंटिक HTML सह तयार करू शकतात आणि UI भाग वापरू शकतात जे आधीच प्रवेशास समर्थन देतात.

QA मध्ये, परीक्षक स्वयंचलित तपासणी करू शकतात आणि फक्त कीबोर्ड आणि स्क्रीन रीडरसह साइट वापरून पाहू शकतात. प्रक्षेपणानंतर, काम संपत नाही. टीम अहवाल पाहू शकतात आणि दिसणाऱ्या नवीन समस्यांचे निराकरण करू शकतात.

आपण याचा साखळीसारखा विचार करू शकता:

डिझाईन, नंतर डेव्हलपमेंट, नंतर ऑटोमेटेड चेक, नंतर मॅन्युअल चेक, नंतर वापरकर्त्यांसह टेस्टिंग, नंतर रिलीज, नंतर चालू निराकरणे

फायदा केवळ व्यावहारिक नाही. त्यातून पैशांचीही बचत होते. वैशिष्ट्य बनवले जात असताना प्रवेश समस्या दुरुस्त करणे सहसा सोपे असते.

अनेक वापरकर्ते त्यावर अवलंबून राहिल्यानंतर, नंतर त्याचे निराकरण करण्याचा प्रयत्न करणे, अधिक खर्च येतो आणि जास्त वेळ लागतो.

निष्कर्ष: सॉफ्टवेअर वापरण्यास सोपे बनवल्याने ते अवलंबून राहते.

प्रवेशयोग्यता तपासणी लाँच होण्यापूर्वी शेवटच्या आठवड्यासाठी कार्यसंघांनी जतन केलेली गोष्ट असू नये.

हे दैनंदिन विकासाशी संबंधित आहे, घाईघाईने केलेल्या विचाराप्रमाणे नाही. तुम्ही स्क्रीन-रीडर चाचण्या चालवता तेव्हा, मुख्य आशय जसा असावा तसा समजला आहे का ते तुम्ही पाहू शकता. कीबोर्ड तपासणी कोणीतरी साइटवरून जाऊ शकते की नाही हे दर्शविते आणि माउसवर अवलंबून न राहता ते वापरू शकते.

कॉन्ट्रास्ट तपासणे देखील महत्त्वाचे आहे, कारण मजकूर आणि नियंत्रणे स्क्रीनवर स्पष्टपणे दिसणे आवश्यक आहे.

स्वयंचलित स्कॅन अनेक पृष्ठांवर वारंवार येणारे बग आणि गहाळ निराकरणे त्वरित दर्शवू शकतात.

तरीही, मॅन्युअल चाचणी आणि वास्तविक लोकांकडील अभिप्राय सहसा अशा समस्या उघड करतात जे साधने पकडत नाहीत.

वेगवेगळ्या टप्प्यांवर प्रत्येक पद्धतीचा वापर केल्याने प्रत्यक्षात काय काम करत आहे याचे उत्तम दृश्य मिळते. डिजिटल साधने दैनंदिन कामांमध्ये मोठी भूमिका घेत असल्याने, प्रवेशयोग्यता आणि सॉफ्टवेअर गुणवत्ता जोडलेली आहे.

साइट किंवा ॲप केवळ तेव्हाच विश्वसनीय आहे जेव्हा वापरकर्ते त्यांना आवश्यक असलेल्या वैशिष्ट्यांपर्यंत पोहोचू शकतात आणि ते ज्यासाठी आले आहेत ते पूर्ण करू शकतात. सर्वसमावेशक सॉफ्टवेअर फक्त अधिक वापरकर्त्यांसाठी नाही. ते बांधले गेले पाहिजे जेणेकरून कमी लोक अवरोधित होतील.