JavaScript ने स्थिर (static) दस्तऐवजांचे रूपांतर सॉफ्टवेअरमध्ये केले आहे. सिंगल-पेज ॲप्स (Single-page apps) अतिशय वेगवान वाटतात. पूर्ण पेज रीलोड होत नाही, स्क्रीन फ्लिकरिंग (flickering) होत नाही. पण या वेगाची एक किंमत चुकवावी लागते जी अनेक टीम्सकडे दुर्लक्षित राहते: वेबची मूलभूत यंत्रणा बिघडण्यास सुरुवात होते. नेव्हिगेशन नाजूक (brittle) होते. सर्च इंजिन्सना पाथ फॉलो करणे कठीण जाते. स्क्रीन रीडर्स गोंधळतात. आणि वापरकर्ते अशा इंटरफेसमध्ये अडकतात जे वेबसाइटसारखे दिसतात पण तुटलेल्या डेस्कटॉप ॲप्लिकेशन्ससारखे वागतात.
याचे मुख्य कारण सहसा onClick हँडलर असलेला एक div असतो.
Divs ला Links म्हणून वापरणे थांबवा
div ला कोणतेही सिमेंटिक (semantic) महत्त्व नसते. तो फक्त एक बॉक्स आहे. जेव्हा तुम्ही त्यावर क्लिक हँडलर लावता आणि वापरकर्त्याला नवीन व्ह्यूवर नेण्यासाठी त्याचा वापर करता, तेव्हा तुम्ही ब्राउझरला एका पुठ्ठ्याच्या बॉक्सला दरवाजाप्रमाणे वागवायला सांगत असता. ब्राउझर ते करण्यास नकार देतो. तसेच ब्राउझरभोवती तयार केलेली प्रत्येक टूल देखील नकार देते.
स्क्रीन रीडर्स div ला लिंक किंवा बटन म्हणून घोषित करत नाहीत. ते त्याकडे दुर्लक्ष करतात किंवा त्याला साध्या मजकुराप्रमाणे (plain text) वाचतात. आवाजाद्वारे (voice) नेव्हिगेशन करणारा वापरकर्ता त्याला टार्गेट करू शकत नाही. सर्च इंजिन क्रॉलर, जो तुमच्या पेजवर शोधण्यायोग्य URLs शोधत असतो, त्याला फॉलो करण्यासाठी काहीही दिसत नाही. तुमचा रूट (route) अस्तित्वात नाही असेच समजावे.
यापेक्षा वाईट म्हणजे, वापरकर्त्यांना आधीच माहित असलेल्या वैशिष्ट्यांचा (behaviors) तुम्ही अभाव निर्माण करता. एक खरी लिंक वापरकर्त्याला नवीन टॅबमध्ये उघडण्यासाठी राईट-क्लिक करणे, डेस्टिनेशन बुकमार्क करणे किंवा शेअर करण्यासाठी पत्ता कॉपी करणे यांसारख्या गोष्टी करण्याची परवानगी देते. कीबोर्ड वापरकर्ते टॅब (Tab) दाबून तिथे पोहोचण्याची आणि एंटर (Enter) दाबून ते उघडण्याची अपेक्षा करतात. div मध्ये यापैकी काहीही मिळत नाही. जरी तुम्ही tabIndex, role="link" आणि कीबोर्ड लिसनर्स जोडले, तरी ब्राउझर तुम्हाला मोफत देत असलेल्या गोष्टी तुम्ही पुन्हा (अपूर्णपणे) तयार करत असता. आणि तुम्ही एखादी 'edge case' विसरणारच; तुम्ही नेहमीच विसरता.
डेस्टिनेशनसाठी Anchors आणि ॲक्शन्ससाठी Buttons वापरा
HTML ने हे आधीच सोडवले आहे. गोंधळ तिथून सुरू होतो कारण दोन्ही घटक क्लिक करण्यायोग्य (clickable) दिसतात, त्यामुळे डेव्हलपर्स त्यांना एकमेकांऐवजी वापरतात. पण ते तसे नाहीत.
जेव्हा तुम्हाला वापरकर्त्याला नवीन URL वर नेायचे असेल, तेव्हा <a टॅग वापरा. कोणताही सिम्युलेटेड व्ह्यू स्वॅप (simulated view swap) किंवा स्टेट चेंज (state change) नाही, तर प्रत्यक्ष लोकेशनसाठी याचा वापर करा. href ॲट्रिब्युटमध्ये खरा पत्ता असला पाहिजे:
<a href="/docs">Documentation</a>
बस एवढेच. जर वापरकर्ता कुठे तरी जाणार असेल, तर लिंक वापरा.
जेव्हा सध्याच्या पेजवर काही घडते, तेव्हा <button> वापरा. बटन्स खालील प्रकारच्या ॲक्शन्ससाठी असतात:
- मॉडेल (modal) उघडणे
- फॉर्म सबमिट करणे
- सेटिंग्ज सेव्ह करणे
- मेनू टॉगल करणे
लिंक्स डेस्टिनेशनसाठी असतात. बटन्स ॲक्शन्ससाठी असतात. या दोघांचे मिश्रण केल्याने तुमचा इंटरफेस गोंधळलेला होतो आणि वापरकर्त्यांच्या अपेक्षा मोडल्या जातात.
ब्राउझरला त्याचे काम करू द्या
आधुनिक ब्राउझर्स हे दशकांच्या उत्क्रांती आणि मानकीकरणाचा (standardization) परिणाम आहेत. ते सुरक्षा, हिस्ट्री, प्रीफेचिंग (prefetching) आणि ॲक्सेसिबिलिटी (accessibility) तुमच्या हाताने लिहिलेल्या JavaScript पेक्षा कितीतरी पटीने चांगल्या प्रकारे हाताळतात.
एक अस्सल ॲंकर टॅग आपोआप ब्राउझर हिस्ट्री स्टॅक अपडेट करतो. तो नेटिव्ह कॉन्टेक्स्ट मेनू सोबत काम करतो. जेव्हा वापरकर्ता त्यावर होव्हर (hover) करतो किंवा फोकस करतो, तेव्हा तो ब्राउझरच्या इन-बिल्ट प्रीफेचिंग अल्गोरिदममध्ये सहभागी होतो, ज्यामुळे तुम्ही एक ओळ कोड न लिहिताही तुमचे ॲप अधिक वेगवान वाटते. तो लिंक्स उघडण्यासाठी वापरकर्त्याच्या आवडीनिवडींचा आदर करतो. तो पासवर्ड मॅनेजर्स, ट्रान्सलेशन टूल्स आणि रीडर मोडसोबत सहकार्य करतो.
जेव्हा तुम्ही त्याऐवजी JavaScript नेव्हिगेशन फंक्शन वापरता, तेव्हा तुम्ही या सर्व गोष्टींचा त्याग करता. तुम्ही केवळ फीचर्स गमावत नाही; तर तुम्ही वापरकर्त्यांना इंटरनेटवरील इतर सर्व साइट्सवर त्यांनी तयार केलेल्या सवयी सोडण्यास भाग पाडता. हा केवळ तांत्रिक निर्णय नाही. हा एक 'hostile user experience' (वापरकर्त्यासाठी प्रतिकूल अनुभव) आहे.
तुमचे फ्रेमवर्क प्रत्यक्षात काय रेंडर करते ते तपासा
React Router, Vue Router, Next.js Link components, SvelteKit. ही साधने क्लायंट-साइड राउटिंग (client-side routing) सहज ทำให้ वाटतात. पण ॲब्स्ट्रॅक्शनमुळे (abstraction) चुका होऊ शकतात.
तुमचा DOM तपासा. ब्राउझरचे डेव्हलपर टूल्स उघडा आणि तुमचे फ्रेमवर्क जे घटक (elements) तयार करते ते पहा. अंतिम HTML मध्ये <Link> घटक हा वैध href ॲट्रिब्युटसह खऱ्या <a टॅगप्रमाणे रेंडर झाला पाहिजे. जर तो span, div किंवा योग्य href शिवाय इतर काही म्हणून रेंडर होत असेल, तर तुमचे ॲब्स्ट्रॅक्शन तुम्हाला फसवले आहे. तो घटक सुधारा. डिफॉल्ट बदलून टाका. passHref प्रॉप किंवा फ्रेमवर्कच्या समकक्ष (equivalent) पर्यायाचा वापर करा. पडताळणीशिवाय फ्रेमवर्कवर विश्वास ठेवू नका.
हे 'hydration mismatches' साठी देखील महत्त्वाचे आहे. जर सर्व्हरने लिंक रेंडर केली आणि क्लायंटने त्याचे रूपांतर नॉन-लिंकमध्ये केले, तर तुम्ही असे ॲक्सेसिबिलिटी बग्स निर्माण करता जे शोधणे कठीण असते, कारण तुमचा सोर्स कोडमध्ये HTML बरोबर दिसतो पण लाईव्ह DOM मध्ये तो चुकीचा असतो.
बनावट डेस्टिनेशन्सवर बंदी घाला
एक अशी पद्धत आहे जी संपण्याचे नाव घेत नाही: href="javascript:void(0)". जेव्हा डेव्हलपर्सना एखादी गोष्ट लिंकसारखी दिसावी पण बटनसारखी वागावी असे वाटते, तेव्हा ते याचा वापर करतात; सहसा बटनला स्टाईल करायची नसल्यामुळे किंवा जुन्या कोडबेसमुळे (codebase) ते करावे लागते.
थांबा. हे URL नाही. हे ब्राउझरला कोणतेही गंतव्य स्थान (destination) देत नाही. यामुळे हिस्ट्री स्टॅक (history stack) न वापरता येण्याजोग्या स्थितींनी भरून जातो. यामुळे ब्राउझर हिस्ट्री आणि ॲक्सेसिबिलिटी (accessibility) बिघडते. हे एक सापळा आहे. जर तुम्हाला नेव्हिगेशनशिवाय क्लिकचे वर्तन हवे असेल, तर तुम्हाला <button> ची गरज आहे. तुम्हाला हवे तसे त्याचे स्टाईलिंग करा. घटक (element) बटण आहे की लिंक, याने CSS ला काहीही फरक पडत नाही. पण तुमच्या वापरकर्त्यांना फरक पडतो.
वापरकर्ता कुठे जात आहे हे स्पष्ट करणारा मजकूर लिहा
तुमच्या लिंकमधील शब्द महत्त्वाचे असतात. स्क्रीन रीडर वापरकर्ते अनेकदा पेजवरील सर्व लिंक्सची यादी पटकन तपासण्यासाठी शोधतात. जर तुमच्या सर्व लिंक्स "Read more" किंवा "Click here" अशा असतील, तर ती यादी निरुपयोगी गोंधळ ठरते.
नेमकेपणाने लिहा. यांची तुलना करा:
- वाईट:
<a href="/security/api-guide">Read more</a> - चांगले:
<a href="/security/api-guide">Read the API security guide</a>
दुसरी लिंक वापरकर्त्याला ते नक्की काय शोधणार आहेत हे सांगते. ती सर्च इंजिन्सना गंतव्य पेजबद्दल संदर्भ देते. यामुळे तुमची लिंक लिस्ट नेव्हिगेट करण्यायोग्य बनते. वर्णनात्मक लिंक टेक्स्ट (Descriptive link text) हे ॲक्सेसिबिलिटीमध्ये मिळवता येणारे सर्वात सोपे आणि प्रभावी फायदे पैकी एक आहे.
गांभीर्याने चाचणी करा
जर तुम्ही त्याची पडताळणी केली नाही, तर आर्किटेक्चरचा काहीही अर्थ उरत नाही.
पहिले, तुमच्या कीबोर्ड फ्लोची (keyboard flow) चाचणी करा. तुमचा माऊस काढून टाका. तुमच्या साइटवरील प्रत्येक इंटरअॅक्टिव्ह घटकावर (interactive element) 'Tab' की वापरून जा. प्रत्येक खऱ्या लिंकला एक दृश्यमान 'focus outline' दिसली पाहिजे; ती तुमच्या बॅकग्राउंडमध्ये हरवून जाणारी एखादी मंद चमक नसावी, तर एक स्पष्ट रिंग असावी जी थकलेल्या डोळ्यांनाही सहज दिसेल. 'Enter' दाबा. त्याने लिंक सक्रिय झाली पाहिजे. जर 'Tab' ने एखादा घटक वगळला किंवा 'Enter' दाबल्याने काहीच झाले नाही, तर तुमच्या कोडमध्ये बग (bug) आहे.
दुसरे, तुमच्या सर्व्हर लेव्हलवर तुमच्या रूट्सची (routes) चाचणी करा. क्लायंट-साइड राउटिंग (Client-side routing) हे केवळ वरवरचे असते. जर एखाद्या वापरकर्त्याने /dashboard/reports बुकमार्क केले आणि उद्या परत आला, किंवा रिफ्रेश केले, तर तुमच्या सर्व्हरला ते पेज कसे दाखवायचे हे माहित असणे आवश्यक आहे. अज्ञात पाथसाठी (unknown paths) तुमच्या ॲप्लिकेशन शेलवर (application shell) फॉलबॅक करण्यासाठी किंवा थेट योग्य HTML सर्व्ह करण्यासाठी तुमच्या रिव्हर्स प्रॉक्सीला (reverse proxy) किंवा सर्व्हर फ्रेमवर्कला कॉन्फिगर करा. रिफ्रेश केल्यावर येणारी 404 एरर ही किरकोळ चूक नाही. तो एक मोडलेला विश्वास आहे.
JavaScript हा एक शक्तिशाली स्तर आहे