लॉन्च से पहले लैंडिंग पेज को सिर्फ कीबोर्ड से जाँचें
माउस अलग रखकर लैंडिंग पेज का एक जरूरी काम पूरा करें। फोकस, बटन, मेनू और डायलॉग जाँचें और दिक्कतों को ऐसे लिखें कि उन्हें दोबारा देखा जा सके।
इस लेख में
इस गाइड की जानकारी और सीमाएँ
गाइड 31 अक्टूबर 2026 को चेक की गई। यह डॉक्यूमेंटेशन पर आधारित है, खुद इस्तेमाल करके किया गया टेस्ट नहीं। कवर AI से बना चित्र है।
कई लोग कीबोर्ड या ऐसी सहायक तकनीक इस्तेमाल करते हैं जो कीबोर्ड कमांड से चलती है। W3C की एक्सेसिबिलिटी गाइड कहती है कि फॉर्म और दूसरे कंट्रोल समेत पेज के काम कीबोर्ड से किए जा सकने चाहिए। यह बात हर पेज पर लागू होती है, चाहे उसकी शुरुआत किसी टेम्पलेट, AI से बने लेआउट या जरूरत के हिसाब से लिखे गए कोड से हुई हो। W3C — एक्सेसिबिलिटी के बुनियादी सिद्धांत
पहले कोई असली काम चुनें
हिस्सा 1 में से 4एक ऐसा काम चुनें जो विजिटर सच में कर सकता है, जैसे सेवाओं का मेनू खोलना, कोई पैकेज ढूँढ़ना और पूछताछ के फॉर्म तक पहुँचना। प्रीव्यू या स्टेजिंग कॉपी पर काम करें, ताकि टेस्ट करते समय गलती से कोई असली पूछताछ न भेज दी जाए या खरीदारी पूरी न हो जाए।
देखें कि फोकस कहाँ जाता है
हिस्सा 2 में से 4कीबोर्ड फोकस बताता है कि आपकी अगली कार्रवाई किस चीज पर होगी। आगे बढ़ते समय यह साफ दिखना चाहिए कि अभी कौन-सा लिंक, बटन या फील्ड सक्रिय है। बॉर्डर, आउटलाइन या कोई दूसरा साफ दिखने वाला निशान यह जानकारी दे सकता है।
चीजें खोलें, फिर बंद भी करें
हिस्सा 3 में से 4चुना हुआ काम पूरा करते समय खुलने-बंद होने वाले मेनू, FAQ यानी आम सवालों के कंट्रोल और डायलॉग भी जाँचें। किसी कंट्रोल तक पहुँच जाना सिर्फ शुरुआत है; उसका असली काम करके देखें और वापस पेज पर आएँ।
जो दिक्कत दिखे, उसे ठीक करने लायक लिखें
हिस्सा 4 में से 4हर नोट में एक ही दिक्कत लिखें: आपने कहाँ से शुरू किया, कौन-सी कुंजियाँ दबाईं, क्या होना चाहिए था और असल में क्या हुआ। “Tab से पूछताछ वाले बटन तक पहुँच जाते हैं, लेकिन फोकस का कोई निशान नहीं दिखता” लिखना, “एक्सेसिबिलिटी खराब लग रही है” लिखने से ज्यादा काम का है।
पहले कोई असली काम चुनें
एक ऐसा काम चुनें जो विजिटर सच में कर सकता है, जैसे सेवाओं का मेनू खोलना, कोई पैकेज ढूँढ़ना और पूछताछ के फॉर्म तक पहुँचना। प्रीव्यू या स्टेजिंग कॉपी पर काम करें, ताकि टेस्ट करते समय गलती से कोई असली पूछताछ न भेज दी जाए या खरीदारी पूरी न हो जाए।
माउस अलग रख दें। आगे जाने के लिए Tab और पीछे जाने के लिए Shift+Tab इस्तेमाल करें। अगर कुछ कंट्रोल छूटते दिखें, तो अपने ब्राउज़र और ऑपरेटिंग सिस्टम की कीबोर्ड नेविगेशन सेटिंग देखें। अलग-अलग कंट्रोल अलग कुंजियों से चलते हैं: लिंक आम तौर पर Enter से खुलते हैं, जबकि विकल्पों की लिस्ट में ऐरो कीज़ की जरूरत पड़ सकती है। W3C — कीबोर्ड से शुरुआती जाँच
शुरू करने से पहले ब्राउज़र, पेज का पता और चुना हुआ काम लिख लें। इससे बाद में बग रिपोर्ट देखकर उसी दिक्कत को दोहराना आसान होगा।
देखें कि फोकस कहाँ जाता है
कीबोर्ड फोकस बताता है कि आपकी अगली कार्रवाई किस चीज पर होगी। आगे बढ़ते समय यह साफ दिखना चाहिए कि अभी कौन-सा लिंक, बटन या फील्ड सक्रिय है। बॉर्डर, आउटलाइन या कोई दूसरा साफ दिखने वाला निशान यह जानकारी दे सकता है।
मुख्य call-to-action, यानी वह बटन या लिंक जिससे आप विजिटर को अगला काम करने को कहते हैं, पर रुकें। क्या आप बिना अंदाजा लगाए उसे पहचान सकते हैं? हल्के हिस्सों, गहरे हिस्सों और बैकग्राउंड इमेज पर भी यही जाँचें। जब तक किसी चीज पर फोकस है, उसका निशान दिखना चाहिए। थोड़ी देर चलकर गायब हो जाने वाला ऐनिमेशन काफी नहीं है। W3C — फोकस दिखाई देना चाहिए
यह भी देखें कि स्क्रॉल करते समय ऊपर टिके रहने वाले हेडर, कुकी बैनर या पेज के ऊपर आने वाली दूसरी चीजें फोकस वाले कंट्रोल को पूरी तरह न ढक दें। W3C — फोकस वाला कंट्रोल छिपना नहीं चाहिए
अब क्रम पर ध्यान दें। क्या फोकस समझ में आने वाले रास्ते से चलता है या बिना वजह अलग-अलग हिस्सों में उछलता है? इसका क्रम हर चीज की स्क्रीन पर दिखने वाली जगह से हूबहू मिलना जरूरी नहीं है, लेकिन अर्थ और इस्तेमाल का तरीका सही रहना चाहिए। अगर संपर्क फॉर्म में फोकस बार-बार ऐसे फील्ड समूहों के बीच जा रहा है जिनका आपस में संबंध नहीं है, तो उसकी जाँच करनी चाहिए। W3C — फोकस का क्रम
चीजें खोलें, फिर बंद भी करें
चुना हुआ काम पूरा करते समय खुलने-बंद होने वाले मेनू, FAQ यानी आम सवालों के कंट्रोल और डायलॉग भी जाँचें। किसी कंट्रोल तक पहुँच जाना सिर्फ शुरुआत है; उसका असली काम करके देखें और वापस पेज पर आएँ।
मोडल डायलॉग खुलने पर फोकस आम तौर पर उसके अंदर जाता है। Tab और Shift+Tab से उसके कंट्रोल के बीच आगे-पीछे जाना चाहिए, Escape से वह बंद होना चाहिए और फोकस आम तौर पर उसी कंट्रोल पर लौटना चाहिए जिससे वह खुला था। यह भी देखें कि बंद करने या रद्द करने वाला बटन साफ दिखाई दे रहा हो। W3C — मोडल डायलॉग का पैटर्न
खुले हुए मोडल के अंदर फोकस बनाए रखना जानबूझकर किया गया व्यवहार हो सकता है। समस्या तब है जब कीबोर्ड से किसी हिस्से से बाहर निकलना या उसे बंद करना मुमकिन न हो। अगर बाहर निकलने के लिए कोई अलग तरीका जरूरी है, तो यूज़र को बताया जाना चाहिए कि वह कैसे काम करता है। W3C — कीबोर्ड इस्तेमाल करने वाला फँसना नहीं चाहिए
जो दिक्कत दिखे, उसे ठीक करने लायक लिखें
हर नोट में एक ही दिक्कत लिखें: आपने कहाँ से शुरू किया, कौन-सी कुंजियाँ दबाईं, क्या होना चाहिए था और असल में क्या हुआ। “Tab से पूछताछ वाले बटन तक पहुँच जाते हैं, लेकिन फोकस का कोई निशान नहीं दिखता” लिखना, “एक्सेसिबिलिटी खराब लग रही है” लिखने से ज्यादा काम का है।
सुधार के बाद वही काम दोबारा करें और पास के कंट्रोल भी जाँचें। नतीजे को उसकी सीमा में रखें: यह कीबोर्ड से की गई शुरुआती जाँच है। इससे पूरी एक्सेसिबिलिटी या WCAG के मानकों पर खरा उतरना साबित नहीं होता। W3C साफ चेतावनी देता है कि उसकी आसान जाँचों में पास होने वाले पेजों में भी इस्तेमाल की बड़ी बाधाएँ रह सकती हैं। जो मिला है, उसके आधार पर आगे ज्यादा व्यापक जाँच करें। W3C — इस जाँच की सीमा
यह तरीका डॉक्यूमेंटेशन पर आधारित है; किसी खास वेबसाइट को खुद टेस्ट करने का दावा नहीं किया गया है।
जानकारी के स्रोत
ये मूल लेख के official sources हैं। इनमें से कई पेज English में हैं।