ग्राहक कार्यों के आसपास कवरेज बनाएं
उन मार्गों और परिणामों की सूची बनाएं जो मूल्य पैदा करते हैं: सेवा ढूँढना, खोज, आइटम जोड़ना, बुकिंग, साइन-इन, मदद माँगना या भुगतान करना। प्रत्येक के लिए उन घटकों का नाम लें जो आकार बदल सकते हैं या विफल हो सकते हैं: नेविगेशन, फ़िल्टर, कार्ड्स, टेबल्स, इमेजेस, बैनर्स, फॉर्म्स, ड्रॉअर्स और एम्बेडेड विजेट्स। अपने कंटेंट के संकुचित होने वाली चौड़ाइयों पर परीक्षण करें—केवल वर्तमान फोन मॉडलों की सूची नहीं। प्रत्येक ब्रेकपॉइंट के ठीक नीचे, उस पर और ठीक ऊपर परीक्षण करें।
नैरो और मिड-विथ फोन, टैबलेट-जैसी चौड़ाई, लैपटॉप, वाइड डेस्कटॉप शामिल करें, और जब कार्य बदलता हो तब लैंडस्केप भी शामिल करें।
लंबे शीर्षक, खाली परिणाम, वैलिडेशन त्रुटियाँ, प्राइस बैज, पूर्ण पते, और जहाँ लागू हों लंबे लेबल्स का उपयोग करें।
रीफ़्लो, पढ़ने और ज़ूम का प्रमाणित परीक्षण
पृष्ठ में उपयुक्त viewport सेटिंग है यह सुनिश्चित करें, फिर पेज-स्तरीय क्षैतिज स्क्रोलिंग की तलाश करें। फिक्स्ड इमेजेस, चौड़े फील्ड, नेगेटिव मार्जिन्स, ऑफ-कैनवास पैनल्स और बैनर्स सामान्य कारण हैं। W3C का WCAG 2.1 Reflow मानदंड 320 CSS पिक्सल के समकक्ष चौड़ाई पर ऊर्ध्वाधर-स्क्रोलिंग सामग्री का वर्णन करता है, जिसमें 400% ज़ूम पर 1280-पिक्सल viewport शामिल है। अगर यह मानदंड दायरे में है तो वास्तविक ज़ूम परिदृश्य का परीक्षण करें। मैप, वीडियो या डेटा टेबल को दो-आयामी लेआउट की आवश्यकता हो सकती है—पर वह स्क्रोल कम्पोनेंट के भीतर रखें और आस-पास का पेज रीफ़्लो होने दें।
प्रत्येक परीक्षण सीमा पर हेडर, मुख्य कंटेंट, फुटर, स्टिकी बार, डायलॉग और त्रुटि सारांश की जाँच करें।
संकुचित स्क्रीन के लिए जानकारी पुन: व्यवस्थित करें; किसी आवश्यकता, मूल्य विवरण, या मदद पाथ को बिना सूचित किए हटाएँ नहीं।
कंटेंट और फॉर्म्स पर तनाव परीक्षण
कंटेंट ऑपरेशन्स बिना किसी CSS रिलीज़ के रेस्पॉन्सिव विफलताएँ पैदा कर सकते हैं। सबसे लंबे अनुमोदित हेडिंग, कई बैज, गायब इमेज, चयनित फ़िल्टर, बड़ी कानूनी सूचना, और ब्राउज़र-भरा फ़ील्ड टेस्ट करें। जब कॉलम स्टैक होते हैं तो पढ़ने और कीबोर्ड ऑर्डर अब भी तर्कसंगत है यह पुष्टि करें। छोटे डिवाइस पर वास्तविक फॉर्म पूरा करें: कंट्रोल खोलें, त्रुटि सुधारें, और सबमिट करें। थर्ड-पार्टी विजेट्स को प्रोडक्शन-जैसी पेज स्थिति में टेस्ट करें क्योंकि उनका कंटेनर, कंसेंट स्थिति, फ़ॉन्ट्स और स्टाइल्स परिणाम बदल सकते हैं।
संभावित अधिकतम लंबाई और संयोजनों को प्रतिबिंबित करें, पर QA साक्ष्य में ग्राहक या भुगतान डेटा शामिल न करें।
नोटिस, चैट, प्रोमोशन्स और वैलिडेशन संदेशों को साथ में खोलें; किसी को भी प्राथमिक क्रिया या फोकस्ड फील्ड को ढकना नहीं चाहिए।
हर इनपुट पथ का अभ्यास करें
एक बड़ी स्क्रीन होने का मतलब माउस होना नहीं है, और एक छोटी स्क्रीन का मतलब केवल टच होना भी नहीं है। hover मीडिया फीचर यह जाँचता है कि प्राथमिक इनपुट सुविधाजनक रूप से होवर कर सकता है—इसलिए होवर को बढ़ावा देना चाहिए, न कि केवल होवर के आधार पर किसी क्रिया या स्पष्टीकरण का एकमात्र मार्ग होना चाहिए। डेस्कटॉप पर कीबोर्ड और पॉइंटर उपयोग, टच डिवाइस पर टैप और स्क्रोल, और जहाँ प्रासंगिक हो मिश्रित-इनपुट उपकरणों का परीक्षण करें। कॉम्पैक्ट क्लोज़ बटन्स, स्टीपर, चिप्स, कैलेंडर और आइकन क्रियाओं की समीक्षा करें। WCAG 2.2 Target Size (Minimum) 24 बाय 24 CSS-पिक्सल लक्ष्य आकार के साथ परिभाषित अपवादों सहित एक मापदंड निर्दिष्ट करता है; यह एक मानदंड है जिसके दायरे और अपवाद हैं, न कि यह वादा कि हर 24-पिक्सल कंट्रोल हर किसी के लिए समान रूप से आसान है।
पेज पर टैब करें। फ़ोकस दिखाई देना चाहिए, समझदारी से क्रम में होना चाहिए, और मेन्यू तथा डायलॉग में प्रवेश और निकास पूर्वानुमानित होना चाहिए।
एक आवश्यक होवर-रिवील को फ़ोकस, टैप, या दिखाई देने वाले नियंत्रक से उपलब्ध कराएँ, और भ्रमित करने वाले पहले-टैप व्यवहार को रोकें।
सीमित परिस्थितियों में एसेट्स और प्रदर्शन सत्यापित करें
एक इमेज अपने कंटेनर में फिट हो सकती है और फिर भी डिवाइस के लिए गलत फ़ाइल हो सकती है। जाँचें कि मीडिया कंटेंड रहे, जहाँ लागू हो लेआउट स्पेस आरक्षित करे, उपयोगी क्रॉप को बनाए रखे, और उपयुक्त candidates रिक्वेस्ट करे। srcset और sizes ब्राउज़र को उपलब्ध इमेज स्रोतों में से चुनने की जानकारी देते हैं; वे किसी विशेष अनुरोध की गारंटी नहीं देते। DevTools थ्रॉटलिंग समस्याएँ जल्दी उजागर करने के लिए उपयोगी है, पर इसके CPU और नेटवर्क नियंत्रण विकास मशीन के सापेक्ष परिस्थितियों का अनुकरण करते हैं। प्रमुख यात्राओं को वास्तविक डिवाइस और कनेक्शन पर फिर से जाँचें। फ़ॉन्ट्स, हीरो मीडिया, कैरोज़ल, क्लाइंट-साइड वर्क और थर्ड-पार्टी स्क्रिप्ट्स को देर, शिफ्ट या ब्लॉक किए गए टैप्स के लिए निरीक्षित करें।
मार्ग, viewport, वास्तविक या सिम्युलेटेड कनेक्शन, और क्या धीमा या अस्थिर हुआ—यह सब कैप्चर करें; सामान स्थितियों की तुलना करें।
जहाँ सुरक्षित हो, टेस्ट बिल्ड में गैर-आवश्यक एम्बेड्स को देरी से लोड करके जानें कि क्या कोर कार्य उपयोगयोग्य रहता है।
प्रोएक्टिव अपटाइम कार्य के रूप में सुधार करें
Status Is UP के संदर्भ में रेस्पॉन्सिव रेडीनेस प्रोएक्टिव अपटाइम ऑप्टिमाइज़ेशन है: एक यूज़र-ब्लॉकिंग डिवाइस पाथ की पहचान करें, उसके कारण को ठीक करें, मरम्मत का प्रमाण दें, और पुनरावृत्ति रोकें। यह दावा नहीं है कि मॉनिटरिंग अलर्ट हर लेआउट या इंटरैक्शन दोष का निर्णय कर सकता है। कार्य प्रभाव और पहुँच के द्वारा प्राथमिकता तय करें। डिप्लॉयमेंट से पहले, पास-पास की चौड़ाइयों और बदले हुए जर्नी को वास्तविक हार्डवेयर पर परीक्षण करें। साझा नेविगेशन, स्टाइल्स, स्क्रिप्ट्स, पेमेंट्स, या इंटीग्रेशन्स में बदलाव के लिए रोलबैक योजना बनाएं। रिलीज़ के बाद, प्रमाण के चरणों को फिर से दोहराएँ और साक्ष्य को परिवर्तन रिकॉर्ड से जोड़ें।
मार्ग, डिवाइस या viewport, ओरिएंटेशन, इनपुट, स्थिति, अपेक्षित परिणाम, वास्तविक परिणाम, और एक गोपनीयता-निरपेक्षित (redacted) कैप्चर बताएं।
रूट-ओवरराइड के बजाय कम्पोनेंट, लेआउट नियम, टोकन, या इमेज-डिलिवरी फिक्स को प्राथमिकता दें; अपवादों को एक मालिक और हटाने की योजना दें।