एक्सेसिबिलिटी टेस्टिंग

एक्सेसिबिलिटी टेस्टिंग क्या है और क्यों ज़रूरी है

एक्सेसिबिलिटी यह है कि अलग-अलग क्षमताओं वाले ज़्यादा से ज़्यादा लोग किसी प्रोडक्ट को कितना इस्तेमाल कर पाते हैं। इससे जुड़े लोग कोई छोटा समूह नहीं हैं: दृष्टिहीन और कम दृष्टि वाले यूज़र जो स्क्रीन रीडर या मैग्निफ़िकेशन पर निर्भर हैं, बधिर और कम सुनने वाले यूज़र जिन्हें कैप्शन और ट्रांसक्रिप्ट चाहिए, मोटर दिव्यांगता वाले लोग जो कीबोर्ड, switch device या वॉइस कंट्रोल इस्तेमाल करते हैं, और संज्ञानात्मक, सीखने से जुड़ी या न्यूरोलॉजिकल दिव्यांगता वाले लोग जिन्हें अनुमानित लेआउट और साफ़ भाषा चाहिए। अस्थायी और परिस्थितिजन्य सीमाएँ — टूटी कलाई, फ़ोन पर तेज़ धूप, शोर भरा कमरा — बाकी सबको भी कुछ समय के लिए उसी स्थिति में ला देती हैं।

QA टीम के लिए एक्सेसिबिलिटी security या performance जैसी एक quality attribute है: इसे acceptance criteria में लिखा जा सकता है, इसके लिए डिज़ाइन किया जा सकता है, टेस्ट, माप और regression में ट्रैक किया जा सकता है। यह उन्हीं तरीकों से फ़ेल होती है जिनसे दूसरी quality attributes होती हैं — छूटी requirements, देर से पता चलना और regression coverage की कमी — और उसी अनुशासन से ठीक होती है।

कई जगह यह कानूनी और कॉन्ट्रैक्ट का मामला भी है। कई देशों के नियम और सरकारी खरीद नियम WCAG का हवाला देते हैं, और यूरोप में harmonised मानक EN 301 549 वेब कंटेंट के लिए WCAG पर आधारित है और सॉफ़्टवेयर, दस्तावेज़ों व हार्डवेयर की आवश्यकताएँ जोड़ता है। सटीक दायित्व देश, सेक्टर और प्रोडक्ट के प्रकार के हिसाब से बदलते हैं, इसलिए कानूनी सवाल अपनी legal या compliance टीम पर छोड़ें और WCAG को वह तकनीकी पैमाना मानें जिसके विरुद्ध आपके टेस्ट लिखे जाते हैं।

देर से पता चलना महँगा पड़ता है। कीबोर्ड सपोर्ट या सही semantics के बिना बना custom dropdown अक्सर patch नहीं, दोबारा बनाना पड़ता है, और लॉन्च से दो हफ़्ते पहले का audit ऐसे दर्जनों कंपोनेंट एक साथ पकड़ता है। यही सबसे बड़ा कारण है कि एक्सेसिबिलिटी को अंत में एक audit की बजाय लगातार, हर story के साथ टेस्ट किया जाए।

WCAG 2.2 की संरचना

WCAG 2.2 एक W3C Recommendation है (यहाँ जिस संस्करण का हवाला है वह 12 दिसंबर 2024 का है)। इसकी normative requirements तीन परतों में हैं (WCAG की अपनी "layers of guidance" में चौथी परत sufficient और advisory techniques की है, लेकिन वह informative है, बाध्यकारी नहीं)। चार सिद्धांत बताते हैं कि कंटेंट कैसा होना चाहिए; उनके नीचे 13 guidelines लक्ष्य बताती हैं; और guidelines के नीचे टेस्ट करने योग्य success criteria (SC) वह हैं जिनके विरुद्ध आप असल में टेस्ट और रिपोर्ट करते हैं। हर success criterion का एक नंबर, नाम और लेवल होता है — जैसे SC 2.1.1 Keyboard (Level A) या SC 1.4.3 Contrast (Minimum) (Level AA)। W3C हर criterion के लिए informative "Understanding WCAG 2.2" दस्तावेज़ और techniques व आम failures की सूची वाला Quick Reference भी प्रकाशित करता है; छोटे normative टेक्स्ट के पीछे का उद्देश्य, अपवाद और edge case टेस्टर को वहीं मिलते हैं।

• Perceivable — जानकारी ऐसे रूप में प्रस्तुत हो जिसे यूज़र देख, सुन या किसी और इंद्रिय से ग्रहण (perceive) कर सके: टेक्स्ट विकल्प (1.1.1 Non-text Content), मीडिया के लिए कैप्शन, ऐसी संरचना जो सिर्फ़ दिखने में नहीं बल्कि प्रोग्राम से भी उपलब्ध हो (1.3.1 Info and Relationships), पर्याप्त कंट्रास्ट (1.4.3 Contrast (Minimum)) और ज़ूम करने पर reflow होने वाला कंटेंट (1.4.10 Reflow)।
• Operable — हर फ़ंक्शन यूज़र के इनपुट साधन से चले: कीबोर्ड (2.1.1 Keyboard, 2.1.2 No Keyboard Trap), पर्याप्त समय, दौरे पैदा कर सकने वाली फ़्लैशिंग नहीं, नेविगेशन सहायता (2.4.1 Bypass Blocks, 2.4.3 Focus Order, 2.4.7 Focus Visible) और जटिल gestures के विकल्प (2.5.1 Pointer Gestures)।
• Understandable — टेक्स्ट पढ़ने योग्य और इंटरफ़ेस अनुमानित हो: पेज की भाषा घोषित हो (3.1.1 Language of Page), फ़ोकस और इनपुट से अचानक context न बदले (3.2.1 On Focus, 3.2.2 On Input), और एरर में मदद मिले (3.3.1 Error Identification, 3.3.2 Labels or Instructions)।
• Robust — कंटेंट मौजूदा और भविष्य के user agents, जिनमें assistive technology भी है, के साथ काम करे: हर UI कंपोनेंट अपना name, role और value उजागर करे (4.1.2 Name, Role, Value), और status messages फ़ोकस हिलाए बिना announce हो सकें (4.1.3 Status Messages)।

लेवल और conformance का मतलब

लेवल संचयी हैं। Level A न्यूनतम है; Level AA में सभी A और AA criteria शामिल हैं और ज़्यादातर संस्थाएँ, कॉन्ट्रैक्ट और नियम इसी को लक्ष्य बनाते हैं; Level AAA सबसे ऊँचा है, और WCAG ख़ुद पूरी साइटों के लिए AAA को सामान्य नीति के रूप में अनिवार्य करने की सलाह नहीं देता, क्योंकि कुछ कंटेंट हर AAA criterion पूरा नहीं कर सकता। जब तक कॉन्ट्रैक्ट कुछ और न कहे, WCAG 2.2 Level AA के विरुद्ध टेस्ट करें।

WCAG 2.2 ने WCAG 2.1 में नौ नए success criteria जोड़े — जिनमें 2.4.11 Focus Not Obscured (Minimum), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 3.2.6 Consistent Help, 3.3.7 Redundant Entry और 3.3.8 Accessible Authentication (Minimum) शामिल हैं — और 4.1.1 Parsing को obsolete और removed के रूप में सूचीबद्ध किया। अगर कोई पुराना test plan या टूल रिपोर्ट अब भी 4.1.1 findings देती है, तो markup की समस्या तभी रखें जब वह किसी दूसरे criterion, जैसे 4.1.2, को फ़ेल करती हो।

Conformance claim पेजों के बारे में बयान है, किसी कंपनी या टीम के बारे में नहीं। WCAG 2.2 पाँच conformance requirements तय करता है: चुना गया लेवल पूरी तरह पूरा हो; conformance पूरे पेजों पर लागू हो, पेज के हिस्सों पर नहीं; जब पेज किसी प्रोसेस का एक चरण हो तो complete process के सभी पेज conform करें; सिर्फ़ accessibility-supported तरीकों से टेक्नोलॉजी इस्तेमाल हो; और जिन टेक्नोलॉजी पर निर्भरता नहीं है वे बाकी पेज में बाधा न डालें (non-interference)।

इनमें से दो सीधे test design को आकार देते हैं। "Full pages" का मतलब है कि किसी पेज पर compliant फ़ॉर्म हो लेकिन cookie banner inaccessible हो, तो पेज conforming नहीं है। "Complete processes" का मतलब है कि checkout, registration या लोन आवेदन तभी पास है जब हर चरण पास हो — पेमेंट पेज, OTP स्क्रीन और confirmation चरण सहित। मूल्यांकन का scope तय करते समय सिर्फ़ URL नहीं, प्रोसेस की सूची बनाएँ। और conformance एक snapshot है: मार्च में conform करने वाला पेज अप्रैल में नया date picker आने के बाद फ़ेल हो सकता है, इसलिए एक्सेसिबिलिटी को भी बाकी quality attributes की तरह regression coverage चाहिए।

पाँच व्यावहारिक उप-क्षेत्र

WCAG सिद्धांत के हिसाब से व्यवस्थित है, लेकिन टेस्टर तकनीक के हिसाब से काम करते हैं। पाँच उप-क्षेत्र रोज़ के ज़्यादातर काम को कवर करते हैं, और इस टॉपिक में हर एक की अपनी गाइड है।

• कीबोर्ड एक्सेसिबिलिटी — हर फ़ंक्शन Tab, Shift+Tab, Enter, Space, arrow keys और Escape से पहुँचने और चलाने योग्य; तार्किक focus order; ऐसा visible focus indicator जो sticky header के पीछे न छिपे; कोई keyboard trap नहीं; skip links; फ़ोकस सँभालने वाले modal dialog। यह सबसे तेज़ और ऊँची वैल्यू वाली जाँच है, और स्क्रीन रीडर, switch और वॉइस कंट्रोल यूज़र इसी नींव पर निर्भर हैं।
• स्क्रीन रीडर टेस्टिंग — पेज के semantics assistive technology तक पहुँचते हैं या नहीं: accessible names, roles और states, headings और landmarks, अर्थपूर्ण link text, ARIA का सही इस्तेमाल और announce होने वाले status messages, जिन्हें असली स्क्रीन रीडर-ब्राउज़र जोड़ियों से जाँचा जाता है, जैसे Windows पर NVDA या JAWS, macOS और iOS पर VoiceOver, और Android पर TalkBack।
• Accessible फ़ॉर्म — दिखने वाले labels और निर्देश, संबंधित फ़ील्ड का समूह, required फ़ील्ड का संकेत, error identification और सुझाव, कानूनी व वित्तीय सबमिशन में error prevention, input purpose के लिए autocomplete और accessible authentication। फ़ॉर्म ही वह जगह है जहाँ एक्सेसिबिलिटी failures सबसे ज़्यादा ट्रांज़ैक्शन पूरी तरह रोक देते हैं।
• विज़ुअल एक्सेसिबिलिटी — टेक्स्ट और non-text कंट्रास्ट, रंग का इस्तेमाल, resize और reflow, text spacing, orientation, target size, hover या focus पर दिखने वाला कंटेंट, motion और flashing, और images के टेक्स्ट विकल्प।
• ऑटोमेटेड एक्सेसिबिलिटी टेस्टिंग — axe-core जैसे rule engine और Lighthouse जैसे audit, जो ब्राउज़र में, component और end-to-end टेस्ट में और CI में चलकर हर बदलाव पर मशीन से पकड़ी जा सकने वाली failures पकड़ते हैं, और विवेक वाले फ़ैसले इंसानों पर छोड़ते हैं।

मैनुअल और ऑटोमेटेड टेस्टिंग: कौन क्या पकड़ता है

ऑटोमेटेड checker उपयोगी भी हैं और सीमित भी। वे भरोसे से वही स्थितियाँ पकड़ते हैं जो कोड और computed styles से तय हो सकती हैं: बिना alt attribute की image, बिना accessible name का फ़ॉर्म कंट्रोल, किसी role पर अनुमति न पाने वाला ARIA attribute, मौजूद न होने वाले id का रेफ़रेंस, कंट्रास्ट सीमा से नीचे सादा टेक्स्ट। वे यह तय नहीं कर सकते कि alt text image का सही वर्णन करता है या नहीं, focus order तर्कसंगत है या नहीं, heading अपने सेक्शन को बताती है या नहीं, error message मदद करता है या नहीं, या कोई custom widget स्क्रीन रीडर से सच में चलता है या नहीं। W3C का evaluation overview कहता है कि सिर्फ़ टूल यह तय नहीं कर सकते कि साइट accessible है; कोई टूल प्रोडक्ट की कितनी समस्याएँ पकड़ता है यह प्रोडक्ट और टूल पर निर्भर है, और यह हमेशा तस्वीर का एक हिस्सा ही होता है।

W3C के Accessibility Conformance Testing (ACT) rules टूल-निरपेक्ष फ़ॉर्मेट में बताते हैं कि WCAG और ARIA के ख़ास पहलुओं को कैसे टेस्ट करें। कुछ rules पूरी तरह automate हो सकते हैं और कुछ में इंसानी फ़ैसला चाहिए; टूल की तुलना करते समय यह पूछना कि कौन-सा टूल कौन-से ACT rules लागू करता है, हेडलाइन नंबरों की तुलना से ज़्यादा उपयोगी है। प्रयास का एक व्यावहारिक बँटवारा:

• ऑटोमेटेड, हर बदलाव पर — मुख्य पेजों और कंपोनेंट का rule-engine स्कैन, CI में।
• मैनुअल, हर story पर — कीबोर्ड पास, छोटा स्क्रीन रीडर पास, ज़ूम और reflow, और बदले गए UI में हर नई चीज़ का कंट्रास्ट।
• विशेषज्ञ मूल्यांकन, हर रिलीज़ या तिमाही — representative sample का संरचित WCAG मूल्यांकन (नीचे WCAG-EM देखें)।
• दिव्यांग यूज़र्स के साथ टेस्टिंग, समय-समय पर — यह जानने का एकमात्र तरीका कि प्रोडक्ट व्यवहार में इस्तेमाल करने योग्य है, सिर्फ़ कागज़ पर conformant नहीं।

आज़माएँ: HTML एक्सेसिबिलिटी चेकर

WCAG-EM से प्रोडक्ट का मूल्यांकन

WCAG Evaluation Methodology (WCAG-EM) 2.0, जिसे W3C ने जुलाई 2026 में Group Note के रूप में प्रकाशित किया, बताती है कि कोई डिजिटल प्रोडक्ट WCAG 2 के कितना अनुरूप है, इसका मूल्यांकन कैसे करें। यह एक प्रक्रिया है, टूल नहीं, और वेबसाइट, वेब एप्लिकेशन या ऐप स्क्रीनों के सेट पर काम करती है। इसके पाँच चरण test plan से सीधे मेल खाते हैं:

• 1. मूल्यांकन का scope तय करें — प्रोडक्ट और उसके हिस्से, conformance target (आमतौर पर WCAG 2.2 Level AA), accessibility support baseline (वे ब्राउज़र और assistive technologies जिनके साथ प्रोडक्ट को काम करना है) और कोई अतिरिक्त requirements।
• 2. प्रोडक्ट को एक्सप्लोर करें — आम views, ज़रूरी functionality, पेज या स्क्रीन के प्रकारों की विविधता, और जिन technologies पर निर्भरता है उन्हें पहचानें।
• 3. Representative sample चुनें — चरण 2 में मिली चीज़ों को कवर करने वाला structured sample, कुछ randomly चुने samples, और हर complete process।
• 4. Sample का मूल्यांकन करें — हर sample और हर complete process को target के criteria के विरुद्ध जाँचें, फिर structured और random नतीजों की तुलना करें; अगर random samples नई तरह की failures दिखाते हैं, तो structured sample से कुछ छूटा है।
• 5. नतीजे रिपोर्ट करें — हर चरण का परिणाम दर्ज करें; वैकल्पिक रूप से evaluation specifics, evaluation statement, aggregated score और machine-readable reports जोड़ें।

स्प्रिंट में एक्सेसिबिलिटी

एक्सेसिबिलिटी सबसे सस्ती तब पड़ती है जब वह अलग फ़ेज़ नहीं, हर story की विशेषता हो। स्प्रिंट टीम के लिए WCAG-EM स्वाभाविक रूप से छोटा हो जाता है: scope रिलीज़ है, sample बदली गई स्क्रीनें और उनसे जुड़े प्रोसेस हैं, और रिपोर्ट linked defects के साथ फ़ेल हुए criteria की सूची है। एक व्यावहारिक flow:

• Refinement — UI वाली हर story में एक्सेसिबिलिटी acceptance criteria जोड़ें: कीबोर्ड से संचालन, कंट्रोल के नाम, announce होने वाले errors और status, नए रंगों का कंट्रास्ट। success criterion नंबर लिखें।
• डिज़ाइन review — कोड बनने से पहले कंट्रास्ट, focus styles, target size, reading और focus order जाँचें, और यह कि कोई जानकारी सिर्फ़ रंग से न दी जाए।
• डेवलपमेंट — native HTML elements को प्राथमिकता दें, custom widgets के लिए ARIA Authoring Practices के patterns अपनाएँ, और ऑटोमेटेड checker लोकली और component टेस्ट में चलाएँ।
• Story टेस्टिंग — टेस्टर कीबोर्ड पास, एक तय जोड़ी पर स्क्रीन रीडर smoke पास, 200% ज़ूम और 400% पर reflow करता है, और ऑटोमेटेड नतीजे देखता है।
• Regression — क्रिटिकल journeys (login, search, checkout, मुख्य फ़ॉर्म) के लिए छोटा एक्सेसिबिलिटी regression suite रखें, हर रिलीज़ पर चलाएँ, और समय के साथ स्क्रीन रीडर जोड़ियाँ बदलते रहें।
• Definition of done — जब तक story में Level A या AA की खुली failures हैं, वह done नहीं है, जब तक टीम ने उन्हें स्पष्ट रूप से स्वीकार, टिकट और शेड्यूल न किया हो।
• नीचे दी गई definition of done चेकलिस्ट (अंग्रेज़ी में, ताकि सीधे कॉपी हो सके) के बिंदु — हर नया फ़ंक्शन सिर्फ़ कीबोर्ड से चले (Tab, Shift+Tab, Enter, Space, arrows, Esc); focus order reading order के अनुसार हो और हर focusable element पर फ़ोकस दिखे; फ़ोकस वाला element sticky header, footer या banner के पीछे पूरी तरह न छिपे; हर कंट्रोल का accessible name उसका दिखने वाला label शामिल करे; headings और landmarks दृश्य संरचना दिखाएँ; errors, toasts और loading states announce हों (status / alert); टेक्स्ट कंट्रास्ट कम से कम 4.5:1 (बड़ा टेक्स्ट कम से कम 3:1), UI components और graphics कम से कम 3:1; 200% टेक्स्ट साइज़ पर इस्तेमाल योग्य और 400% ज़ूम पर horizontal scrolling के बिना reflow; हर locale में lang और dir सही (अरबी: lang="ar" dir="rtl"); ऑटोमेटेड स्कैन में कोई नया violation नहीं; और तय जोड़ी (जैसे NVDA + Firefox) पर स्क्रीन रीडर smoke पास।

Accessibility definition of done (story with UI)

[ ] Every new function works with keyboard only (Tab, Shift+Tab, Enter, Space, arrows, Esc)
[ ] Focus order follows reading order; focus is visible on every focusable element
[ ] Focused element is never fully hidden by a sticky header, footer or banner
[ ] Every control has an accessible name that contains its visible label
[ ] Headings and landmarks reflect the visual structure
[ ] Errors, toasts and loading states are announced (status / alert)
[ ] Text contrast >= 4.5:1 (large text >= 3:1); UI components and graphics >= 3:1
[ ] Usable at 200% text size; reflows at 400% zoom without horizontal scrolling
[ ] lang and dir correct in every locale (Arabic: lang="ar" dir="rtl")
[ ] Automated scan: no new violations
[ ] Screen reader smoke pass on the agreed pairing (for example NVDA + Firefox)

आज़माएँ: AI QA चेकलिस्ट जनरेटर

आम एक्सेसिबिलिटी डिफ़ेक्ट और उन्हें कैसे रिपोर्ट करें

अलग-अलग प्रोडक्ट में वही failures बार-बार दिखती हैं। बग टाइटल के रूप में, हर एक किस criterion को फ़ेल करता है उसके साथ:

• "Country dropdown कीबोर्ड से खुलता या बदलता नहीं" — 2.1.1 Keyboard।
• "Edit address dialog बंद करने के बाद फ़ोकस पेज के सबसे ऊपर लौट जाता है" — 2.4.3 Focus Order।
• "Primary buttons पर कोई visible focus indicator नहीं (global CSS में outline हटाया गया)" — 2.4.7 Focus Visible।
• "सिर्फ़ icon वाला delete बटन बिना नाम के button के रूप में announce होता है" — 4.1.2 Name, Role, Value।
• "सेक्शन टाइटल styled paragraphs हैं; स्क्रीन रीडर की headings सूची खाली है" — 1.3.1 Info and Relationships।
• "Item added to cart toast स्क्रीन रीडर announce नहीं करते" — 4.1.3 Status Messages।
• "सफ़ेद पर ग्रे helper text का कंट्रास्ट अनुपात 2.9:1 है" — 1.4.3 Contrast (Minimum)।
• "अरबी पेज lang=en घोषित करता है; स्क्रीन रीडर अरबी टेक्स्ट अंग्रेज़ी आवाज़ में पढ़ता है" — 3.1.1 Language of Page।

आज़माएँ: AI बग टाइटल जनरेटर आज़माएँ: AI बग विवरण जनरेटर

डिफ़ेक्ट रिपोर्टिंग और CI में ऑटोमेशन

एक्सेसिबिलिटी बग रिपोर्ट में वह सब चाहिए जो किसी भी बग रिपोर्ट में होता है (बग रिपोर्ट लिखने की गाइड संरचना और severity बनाम priority कवर करती है), साथ में चार चीज़ें: success criterion और उसका लेवल; assistive technology, ब्राउज़र और OS, वर्ज़न सहित; सटीक key sequence या सुना गया सटीक announcement; और यूज़र पर असर। "स्क्रीन रीडर यूज़र checkout पूरा नहीं कर सकते" — यही वाक्य priority तय करता है। किसी मुख्य journey को रोकने वाली Level A failure को आमतौर पर release blocker माना जाता है।

ऑटोमेटेड जाँचें pipeline में उसी वजह से होनी चाहिए जिस वजह से unit टेस्ट होते हैं: वे जानी-पहचानी regressions को सस्ते में रोकती हैं। आम patterns हैं: मौजूदा end-to-end टेस्ट के अंदर rule engine चलाना (जैसे Playwright, Cypress या Selenium के साथ axe-core), टेस्ट एनवायरनमेंट में deploy के बाद URLs की सूची स्कैन करना, और मुख्य पेजों पर Lighthouse accessibility audit चलाना। Gate उसी पर रखें जो टूल तय कर सकते हैं: नए violations पर build फ़ेल करें, ज्ञात issues का टिकट सहित baseline रखें ताकि pipeline हमेशा लाल न रहे, और टूल अपडेट होने पर rule set की समीक्षा करें। हरी pipeline को कभी "accessible" न कहें — इसका मतलब सिर्फ़ इतना है कि ऑटोमेटेड rules को कुछ नहीं मिला। ऑटोमेटेड एक्सेसिबिलिटी टेस्टिंग गाइड टूल integration, rule चयन और triage को विस्तार से कवर करती है।

बहुभाषी और right-to-left एक्सेसिबिलिटी

अरबी और अंग्रेज़ी दोनों में इस्तेमाल होने वाले प्रोडक्ट — जो सऊदी अरब और खाड़ी देशों में आम हैं — को ऐसी जाँचें चाहिए जो एक-भाषा वाले test plan में छूट जाती हैं। स्क्रीन रीडर सही उच्चारण नियम लोड करने के लिए पेज की घोषित भाषा का इस्तेमाल करते हैं, इसलिए html element पर lang attribute पेज की भाषा से मेल खाना चाहिए (3.1.1 Language of Page), और दूसरी भाषा के अंश — जैसे अरबी टेक्स्ट के अंदर अंग्रेज़ी प्रोडक्ट नाम — पर अपना lang होना चाहिए (3.1.2 Language of Parts)। ग़लत lang ऐसी आवाज़ पैदा करता है जिसे समझना बहुत मुश्किल होता है, भले ही बाकी हर जाँच पास हो। हिंदी-अंग्रेज़ी मिश्रित पेजों पर भी यही सिद्धांत लागू होता है।

दूसरी चिंता दिशा है। dir attribute (अरबी पेजों में html element पर dir="rtl") आधार दिशा तय करता है; लेआउट mirror होता है, और focus order को तब भी reading order का पालन करना चाहिए, जो अरबी में दाएँ से बाएँ है। जाँचें कि Tab mirrored लेआउट में तार्किक क्रम से चलता है, sliders, carousels और tab lists में arrow keys mirrored लेआउट के अनुरूप व्यवहार करती हैं, दिशा बताने वाले icons जहाँ चाहिए वहाँ mirror हैं, और अरबी-लैटिन मिश्रित strings — order नंबर, ईमेल पते, फ़ोन नंबर — सही क्रम में दिखते और पढ़े जाते हैं। RTL टेस्टिंग गाइड bidirectional टेक्स्ट और लेआउट mirroring को विस्तार से कवर करती है।

आज़माएँ: बहुभाषी टेस्ट डेटा जनरेटर आज़माएँ: अरबी टेस्ट डेटा जनरेटर

अक्सर पूछे जाने वाले सवाल

संदर्भ

• Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024W3C की Recommendation जो सुलभ वेब कंटेंट के लिए टेस्ट करने योग्य success criteria तय करती है — चार सिद्धांतों और तीन conformance स्तरों (A, AA, AAA) में व्यवस्थित।
• Understanding WCAG 2.2W3C Web Accessibility Initiative (WAI)WCAG 2.2 की हर guideline और success criterion की व्याख्या: उद्देश्य, किसे लाभ, उदाहरण और तकनीकें (नॉर्मेटिव नहीं)।
• WCAG Evaluation Methodology (WCAG-EM) 2.0W3C · 2026पूरी वेबसाइट को WCAG के सामने जाँचने की W3C पद्धति: दायरा तय करना, खोजबीन, प्रतिनिधि सैंपल चुनना, ऑडिट और रिपोर्ट।
• Evaluating Web Accessibility OverviewW3C Web Accessibility Initiative (WAI)एक्सेसिबिलिटी मूल्यांकन के लिए W3C का प्रवेश-पृष्ठ: शुरू से और पूरे विकास में मूल्यांकन क्यों, और मैनुअल जाँच, टूल व यूज़र भागीदारी कैसे साथ काम करते हैं।
• All ACT RulesW3C Web Accessibility Initiative (WAI)Accessibility Conformance Testing (ACT) नियम: WCAG और ARIA आवश्यकताओं के सटीक, दस्तावेज़ित टेस्ट तरीके, ताकि ऑटोमेटेड और मैनुअल नतीजे एक जैसे हों।
• How to Meet WCAG (Quick Reference)W3C Web Accessibility Initiative (WAI)WCAG 2.2 के हर success criterion की फ़िल्टर करने योग्य सूची, पर्याप्त तकनीकों और आम विफलताओं के साथ।
• EN 301 549 V4.1.1 (2026-09) — Accessibility requirements for ICT products and servicesETSI / CEN / CENELEC · 2026ICT के लिए यूरोपीय harmonised एक्सेसिबिलिटी मानक, जो वेब कंटेंट के लिए WCAG पर आधारित है और सॉफ़्टवेयर, दस्तावेज़ व हार्डवेयर की आवश्यकताएँ जोड़ता है।
• Structural markup and right-to-left text in HTMLW3Chtml और संरचनात्मक एलिमेंट पर dir एट्रिब्यूट से base direction कैसे सेट करें, और इसके लिए केवल CSS पर क्यों न निर्भर रहें।