TypeScript और Accessibility: ऐसा कोड कैसे लिखें जो सभी के लिए सुलभ हो

Accessibility केवल "टिक मार्क" के लिए नहीं, बल्कि लोगों के लिए क्यों है

आइए ईमानदार रहें: जब हम "accessibility" (या a11y) सुनते हैं, तो हममें से कई लोग आवश्यकताओं की अंतहीन सूची, उबाऊ जाँच और "यह विकलांग लोगों के लिए है" वाक्यांश की कल्पना करते हैं। लेकिन सच्चाई यह है कि सुलभता हर किसी के लिए है। क्या आपने कभी एक हाथ से फोन पकड़कर पिज्जा ऑर्डर करने की कोशिश की है? या खराब इंटरनेट वाले मेट्रो में बैठे हैं, जहाँ साइट लोड होने में घंटों लग जाते हैं? ये सुलभता की समस्याएँ हैं।

इस लेख में हम बात करेंगे कि कैसे TypeScript सुलभ वेब एप्लिकेशन बनाने में आपका सबसे अच्छा दोस्त बन सकता है। केवल "टैग जोड़ना" नहीं, बल्कि एक ऐसी आर्किटेक्चर बनाना जहाँ समावेशिता कोई फीचर नहीं, बल्कि एक नींव है।

TypeScript a11y त्रुटियों से ढाल के रूप में

बहुत से लोग सोचते हैं कि TypeScript केवल डेटा प्रकार और बग से सुरक्षा के लिए है। लेकिन वास्तव में, सख्त टाइपिंग सुलभता के मामलों में भी बचा सकती है। आइए उदाहरणों के साथ समझते हैं।

ARIA विशेषताओं की टाइपिंग

सबसे आम समस्याओं में से एक ARIA विशेषताओं के गलत मान हैं। क्या आपने कभी div पर role="button" लिखा है? और फिर tabindex जोड़ना भूल गए? TypeScript इसे कंपाइलेशन के समय पकड़ सकता है।

// बुरा: कोई सुरक्षा नहीं\nfunction createButton(label: string) {\n  return `<div role="button">${label}</div>`;\n}\n\n// अच्छा: ARIA को टाइप करना\ntype AriaRole = 'button' | 'navigation' | 'alert' | 'dialog';\n\ninterface AriaAttributes {\n  role: AriaRole;\n  'aria-label'?: string;\n  'aria-expanded'?: boolean;\n  tabIndex?: number;\n}\n\nfunction createAccessibleButton(label: string, aria: AriaAttributes) {\n  // अब TypeScript जाँचेगा कि भूमिका मान्य है\n  return {\n    tag: 'div',\n    attrs: aria,\n    content: label\n  };\n}\n\n// त्रुटि! 'btn' AriaRole प्रकार में शामिल नहीं है\n// createAccessibleButton('मुझे दबाएँ', { role: 'btn' });

अंतर महसूस कर रहे हैं? TypeScript आपको गलती से role="btutton" लिखने नहीं देगा या अनिवार्य विशेषता को भूलने नहीं देगा। यह एक निजी सहायक की तरह है जो फुसफुसाता है: "अरे, क्या आपको यकीन है कि यह सुलभ है?"

फोकस स्थितियों की सख्त जाँच

एक और दर्द फोकस प्रबंधन है। विशेष रूप से SPA में, जहाँ पेज रीलोड नहीं होता है। TypeScript सुरक्षित रैपर बनाने में मदद करता है।

// निर्धारित करें कि कौन से तत्व फोकस प्राप्त कर सकते हैं\ntype FocusableElement = HTMLInputElement | HTMLButtonElement | HTMLAnchorElement | HTMLSelectElement | HTMLTextAreaElement;\n\nfunction safelySetFocus(element: FocusableElement | null): void {\n  if (element && document.contains(element)) {\n    element.focus();\n  } else {\n    console.warn('तत्व DOM में नहीं मिला या फोकस प्राप्त नहीं कर सकता');\n  }\n}\n\n// उपयोग\nconst modal = document.querySelector('.modal__close-btn');\nsafelySetFocus(modal as FocusableElement | null);

ध्यान दें: हम केवल .focus() कॉल नहीं कर रहे हैं, बल्कि जाँच रहे हैं कि तत्व मौजूद है और फोकस किया जा सकता है या नहीं। यह उन त्रुटियों को रोकता है जो स्क्रीन रीडर उपयोगकर्ता को शून्य में छोड़ सकती हैं।

a11y को आधार बनाकर आर्किटेक्चर बनाना

अब हम अधिक उन्नत चीजों की ओर बढ़ते हैं। कैसे सुनिश्चित करें कि accessibility आपके प्रोजेक्ट की आर्किटेक्चर में शामिल हो, न कि रिलीज़ से पहले "जल्दी में" जोड़ी गई हो?

कंपोनेंट्स के लिए टाइप किए गए प्रॉप्स

अपने सभी कंपोनेंट्स के लिए एक बेस इंटरफ़ेस बनाएँ। यह सुलभता के लिए संविधान की तरह है।

// सभी UI कंपोनेंट्स के लिए बेस इंटरफ़ेस\ninterface AccessibleComponentProps {\n  id?: string;\n  className?: string;\n  ariaLabel?: string;\n  ariaDescribedby?: string;\n  role?: string;\n  tabIndex?: number;\n  isDisabled?: boolean;\n  onClick?: () => void;\n  onKeyDown?: (e: React.KeyboardEvent) => void;\n}\n\n// बटन का विशिष्ट कंपोनेंट\ninterface ButtonProps extends AccessibleComponentProps {\n  variant