प्रॉम्प्ट और दायरा
जापानी kana, पारंपरिक चीनी Zhuyin और Pinyin के लिए एक कंटेंट कंपोनेंट डिज़ाइन करें। आप ruby मार्कअप की संरचना कैसे करेंगे, लेयर्ड एनोटेशन का समर्थन कैसे करेंगे, खोज और कॉपी को कैसे संभालेंगे, CSS Ruby उपलब्ध न होने पर फ़ॉलबैक कैसे देंगे और स्क्रीन-रीडर जोखिमों का आकलन कैसे करेंगे?
W3C ने 4 जून 2026 को HTML Ruby Markup Extensions Candidate Recommendation Snapshot प्रकाशित किया। यह HTML ruby संरचना को संशोधित करता है, rb और rtc को मानक तत्वों (conforming elements) के रूप में पुनर्स्थापित करता है, और बेस, एनोटेशन, कंटेनर तथा मल्टीपल एनोटेशन स्तरों के लिए सेमेंटिक इकाइयों को परिभाषित करता है। यह कोई ट्रांसलेशन कंपोनेंट नहीं है और स्क्रीन-रीडर स्पीच की हर रणनीति को तय नहीं करता है; सेमेंटिक मार्कअप, लेआउट और सहायक-तकनीक (assistive-technology) व्यवहार को अलग-अलग रखें।
इंटरव्यूअर क्या मूल्यांकन करता है
इंटरव्यूअर संरचित बेस-टू-एनोटेशन पेयरिंग, इंटरलीव्ड (interleaved) और टैब्युलर (tabular) मार्कअप के बीच एक तर्कसंगत चयन, और उच्चारण को छवियों में डालने के बजाय CSS Ruby Layout के उपयोग का मूल्यांकन करना चाहता है। भाषा विशेषताओं (language attributes), सर्च और कॉपी, rp फ़ॉलबैक, SSR/हाइड्रेशन निरंतरता, XSS सुरक्षा और स्क्रीन-रीडर टेस्टिंग की सीमाओं को कवर करें।
उत्तर देने से पहले स्पष्ट करने वाले प्रश्न
- क्या कंटेंट स्रोत बेस/एनोटेशन जोड़े प्रदान करता है, या कंपोनेंट को उन्हें विभाजित (segment) और जनरेट करना होगा?
- क्या एक बेस में कई भाषा या एनोटेशन स्तर हो सकते हैं, जैसे एक साथ Zhuyin और Pinyin?
- यदि Ruby लेआउट अनुपलब्ध है, तो क्या उत्पाद को इनलाइन कोष्ठक दिखाने चाहिए, एनोटेशन छिपाने चाहिए या रॉ संरचना को बनाए रखना चाहिए?
- सर्च, क्लिपबोर्ड कॉपी और टेक्स्ट-टू-स्पीच में से प्रत्येक को क्या बनाए रखना चाहिए?
- क्या उपयोगकर्ता कंटेंट सबमिट कर सकते हैं, और कौन से HTML तत्व, विशेषताएं, URL और CSP नियम अनुमत हैं?
30-सेकंड का उत्तर ढांचा
“मैं बेस रेंज, एनोटेशन रेंज, भाषाओं और प्रेजेंटेशन नीति को मॉडल करूँगा, फिर सेमेंटिक ruby, rb, rt, rtc और rp उत्सर्जित करूँगा। इंटरलीव्ड मार्कअप सरल जोड़ों को संभालता है; स्पष्ट कंटेनर या टैब्युलर मार्कअप अंतर्निहित (implicit) पेयरिंग पर निर्भर किए बिना मल्टी-कैरेक्टर और लेयर्ड एनोटेशन को संभालते हैं। CSS Ruby की स्थिति और फ़ॉलबैक स्टाइलिंग को नियंत्रित करता है; Ruby लेआउट अनुपलब्ध होने पर rp दृश्यमान इनलाइन सामग्री प्रदान करता है। सर्च और कॉपी उत्पाद सेमेंटिक्स का पालन करते हैं और वास्तविक ब्राउज़रों में परीक्षण किए जाते हैं। स्क्रीन-रीडर आउटपुट का विनिर्देश द्वारा वादा किए जाने के बजाय परीक्षण किया जाता है। उपयोगकर्ता सामग्री को रेंडर करने से पहले सैनिटाइज़ किया जाता है।”
चरण-दर-चरण गहन विश्लेषण
1. एनोटेशन डेटा मॉडल को परिभाषित करें
प्रत्येक सेगमेंट में एक बेस रेंज, एक या अधिक एनोटेशन रेंज, भाषा टैग और प्रेजेंटेशन नीति होती है। जापानी भाषा kana का उपयोग कर सकती है; पारंपरिक चीनी Zhuyin या लैटिन Pinyin का उपयोग कर सकती है। एक बेस के कई rtc स्तर हो सकते हैं, लेकिन डिफ़ॉल्ट स्तर स्पष्ट होना चाहिए। मॉडल को रेंडरिंग से अलग रखें ताकि सेगमेंटेशन नियम कंपोनेंट्स में न फैलें।
2. सेमेंटिक मार्कअप चुनें
ruby समग्र कंटेनर है, rb एक बेस इकाई है, rt एनोटेशन टेक्स्ट है, rtc एक एनोटेशन कंटेनर है, और rp फ़ॉलबैक प्रेजेंटेशन है। सरल मामले अंतर्निहित बेस इकाइयों का उपयोग कर सकते हैं, लेकिन जटिल मल्टी-कैरेक्टर पेयरिंग को स्पष्ट rb का उपयोग करना चाहिए ताकि DOM, कॉपी व्यवहार और लेआउट अनुमानित बने रहें।
3. मल्टी-कैरेक्टर और लेयर्ड पेयरिंग को संभालें
इंटरलीव्ड मार्कअप सरल वन-टू-वन एनोटेशन के लिए काम करता है। टैब्युलर मार्कअप कई rb इकाइयों को सूचीबद्ध करता है जिसके बाद उनकी संबंधित rt इकाइयाँ होती हैं, जो संयुक्त शब्दों और लेयर्ड रीडिंग को बेहतर ढंग से दर्शाती हैं। rtc के साथ लगातार rt तत्वों को समूहीकृत करें; प्रत्येक भाषा लेयर पर lang सेट करें। वास्तविक उच्चारण को CSS pseudo-elements में न डालें क्योंकि सर्च, कॉपी और सहायक तकनीकें इसे विश्वसनीय रूप से नहीं देख सकती हैं।
<ruby lang="zh-TW">
<rb>美</rb><rtc><rt>ㄇㄟˇ</rt></rtc>
<rtc lang="zh-Latn"><rt>měi</rt></rtc>
</ruby>4. प्रोग्रेसिव लेआउट एन्हांसमेंट के लिए CSS का उपयोग करें
HTML संरचना प्रदान करता है; CSS Ruby Annotation Layout ruby-position, फ़ॉन्ट आकार, लाइन हाइट और अलाइनमेंट को नियंत्रित करता है। डिफ़ॉल्ट सेटिंग्स को एनोटेशन द्वारा बेस को ढकने से रोकना चाहिए और टेक्स्ट ज़ूम की अनुमति देनी चाहिए। जब Ruby लेआउट अनुपलब्ध हो, तो rp कोष्ठक या अन्य इनलाइन संकेत दिखा सकता है; display: none के साथ सभी एनोटेशन टेक्स्ट को न छिपाएँ।
5. सर्च, कॉपी और निष्कर्षण (extraction) डिज़ाइन करें
विनिर्देश सर्च और कॉपी इंटरैक्शन पर चर्चा करता है, लेकिन कार्यान्वयन के लिए अभी भी वास्तविक ब्राउज़र परीक्षणों की आवश्यकता है। परिभाषित करें कि क्या कॉपी में बेस, बेस प्लस एनोटेशन, या एक संरचित निर्यात शामिल है। सर्च को बेस और एनोटेशन दोनों को बिना शब्द खोए खोजना चाहिए क्योंकि एनोटेशन DOM को बाधित करते हैं। सर्वर इंडेक्स संरचित फ़ील्ड संग्रहीत कर सकते हैं; क्लाइंट को रेंडर किए गए HTML पर regex के साथ जोड़ों का अनुमान नहीं लगाना चाहिए।
6. सहायक तकनीक और अंतर्राष्ट्रीयकरण का आकलन करें
Ruby बच्चों, गैर-मूल भाषियों और पढ़ने में कठिनाई वाले लोगों की मदद कर सकता है, लेकिन स्क्रीन रीडर अलग-अलग अनुमान (heuristics) का उपयोग कर सकते हैं। सटीक lang मान सेट करें, सार्थक टेक्स्ट क्रम बनाए रखें, और स्क्रीन रीडर, कीबोर्ड नेविगेशन, ज़ूम और हाई कंट्रास्ट का परीक्षण करें। यह दावा न करें कि विनिर्देश टेक्स्ट-टू-स्पीच को पूरी तरह हल करता है; ज्ञात अंतरों और फ़ॉलबैक का दस्तावेजीकरण करें।
7. सुरक्षा, प्रदर्शन और अनुकूलता सत्यापित करें
उपयोगकर्ता द्वारा प्रदान किए गए बेस और एनोटेशन को तत्व और विशेषता अनुमति सूची (allowlist) के साथ सैनिटाइज़ करें; स्क्रिप्ट, इवेंट विशेषताओं और खतरनाक URL को अस्वीकार करें। एनोटेशन फ़्लिकर या टेक्स्ट के पुन: क्रमीकरण को रोकने के लिए SSR और हाइड्रेशन को एक ही पेयरिंग एल्गोरिदम साझा करना चाहिए। लंबे दस्तावेज़ों के लिए संरचित नोड्स और वृद्धिशील (incremental) रेंडरिंग का उपयोग करें, असुरक्षित HTML के बजाय डेटा मॉडल को कैश करें, और WPT तथा एक ब्राउज़र मैट्रिक्स के साथ परीक्षण करें।
उच्च गुणवत्ता वाला नमूना उत्तर
सेमेंटिक ruby मार्कअप उत्सर्जित करने से पहले मैं बेस रेंज, एनोटेशन स्तरों, भाषाओं और प्रेजेंटेशन नीति को मॉडल करूँगा। सरल जोड़े इंटरलीव्ड संरचना का उपयोग कर सकते हैं; मल्टी-कैरेक्टर और लेयर्ड एनोटेशन प्रत्येक भाषा लेयर पर lang के साथ स्पष्ट rb और rtc का उपयोग करते हैं। CSS Ruby Layout स्थिति, आकार और लाइन हाइट को नियंत्रित करता है, जबकि rp Ruby लेआउट अनुपलब्ध होने पर इनलाइन फ़ॉलबैक प्रदान करता है। कॉपी डिफ़ॉल्ट रूप से बेस टेक्स्ट पर होती है, सर्च बेस और एनोटेशन दोनों को इंडेक्स करता है, और सटीक व्यवहार का वास्तविक ब्राउज़रों में परीक्षण किया जाता है। क्योंकि इस विनिर्देश द्वारा सहायक-तकनीक स्पीच पूरी तरह से एकीकृत नहीं है, मैं स्क्रीन रीडर, कीबोर्ड, ज़ूम और हाई कंट्रास्ट का परीक्षण करूँगा और अंतरों का दस्तावेजीकरण करूँगा। इनपुट को सैनिटाइज़ किया जाता है, SSR और क्लाइंट एक ही डेटा मॉडल और पेयरिंग एल्गोरिदम का उपयोग करते हैं, और WPT प्लस एक ब्राउज़र मैट्रिक्स संरचना, लेआउट, सर्च, कॉपी और सुरक्षा को सत्यापित करते हैं।
सामान्य गलतियाँ
- केवल CSS pseudo-elements के साथ उच्चारण प्रदर्शित करना → सर्च और सहायक तकनीकें टेक्स्ट खो देती हैं → सेमेंटिक Ruby मार्कअप का उपयोग करें।
- प्रत्येक वर्ण को एक इंटरलीव्ड नोड के रूप में हार्ड-कोड करना → संयुक्त और लेयर्ड रीडिंग नाजुक (brittle) हो जाती हैं → संरचित पेयरिंग और
rtcका उपयोग करें। rpको अनिवार्य दृश्यमान विराम चिह्न मानना → समर्थित ब्राउज़र डुप्लिकेट सामग्री दिखाते हैं → इसे केवल फ़ॉलबैक प्रेजेंटेशन में दिखाएं।langको अनदेखा करना → स्पीच और फ़ॉन्ट चयन गलत हो जाता है → बेस और एनोटेशन लेयर्स को सटीक रूप से टैग करें।- समान स्क्रीन-रीडर क्रम का वादा करना → विनिर्देश पूर्ण TTS व्यवहार को परिभाषित नहीं करता है → डिवाइसों का परीक्षण करें और अंतरों का दस्तावेजीकरण करें।
- उपयोगकर्ता HTML को सीधे रेंडर करना → स्क्रिप्ट इंजेक्शन संभव है → तत्वों, विशेषताओं और URL को सैनिटाइज़ करें।
अनुवर्ती प्रश्न और उत्तर
आपको अंतर्निहित बेस के बजाय rb का उपयोग कब करना चाहिए?
सरल एकल-लेयर एनोटेशन के लिए अंतर्निहित बेस ठीक हैं। संयुक्त शब्दों, टैब्युलर मार्कअप, या उन अनुप्रयोगों के लिए स्पष्ट rb का उपयोग करें जिन्हें पेयरिंग, कॉपी और डिबगिंग के लिए एक स्थिर DOM की आवश्यकता होती है।
क्या होगा यदि एक बेस में kana और रोमनीकरण दोनों हों?
एकाधिक rtc लेयर्स या एक स्पष्ट एनोटेशन कंटेनर का उपयोग करें और प्रत्येक पर lang सेट करें। उत्पाद को एक डिफ़ॉल्ट लेयर और स्विचिंग नीति चुननी होगी; CSS को सेमेंटिक्स तय नहीं करना चाहिए।
Ruby लेआउट अनुपलब्ध होने पर फ़ॉलबैक क्या है?
टेक्स्ट संरचना को बनाए रखें और कोष्ठक या इनलाइन सेपरेटर के लिए rp का उपयोग करें ताकि बेस और एनोटेशन पढ़ने योग्य बने रहें। सामग्री को छिपाएँ नहीं या इसे गैर-चयन योग्य छवि से न बदलें।
आप कॉपी व्यवहार को कैसे परिभाषित करते हैं?
उत्पाद लक्ष्यों के अनुसार बेस, बेस-प्लस-एनोटेशन, या संरचित निर्यात चुनें, फिर Chromium, Firefox, Safari और मोबाइल पर परीक्षण करें। DOM क्रम स्वचालित रूप से उपयोगकर्ता का वांछित स्ट्रिंग नहीं होता है।
आप कैसे दिखाते हैं कि एनोटेशन सुलभ (accessible) बने हुए हैं?
नो-एनोटेशन, सिंगल-लेयर, मल्टी-लेयर और फ़ॉलबैक मोड में भाषा टैग, फ़ोकस क्रम, ज़ूम, कीबोर्ड संचालन और स्क्रीन-रीडर आउटपुट की जाँच करें। ज्ञात सहायक-तकनीक अंतरों को प्रकाशित करें।