ऑटोमेटेड एक्सेसिबिलिटी टेस्टिंग

Automated rules क्या तय कर सकते हैं — और किसके लिए इंसान चाहिए

Rule किसी सवाल को तब तय कर सकता है जब जवाब पूरी तरह DOM, accessibility tree और computed styles में मौजूद हो। अर्थ, गुणवत्ता या अनुभव के सवाल वह तय नहीं कर सकता। कई WCAG success criteria दोनों को मिलाते हैं: टूल देख सकता है कि alt attribute मौजूद है (1.1.1 का हिस्सा), पर यह नहीं कि टेक्स्ट image के समकक्ष है या नहीं। किसी भी प्रकाशित दावे से सावधान रहें कि टूल WCAG का एक तय हिस्सा कवर करते हैं; ज़रूरी यह जानना है कि आपकी कौन-सी checks निर्णायक हैं और कौन-सी सिर्फ़ सवाल उठाती हैं।

• आम तौर पर तय होने योग्य: missing alt attribute; बिना accessible name का form field या button; <html> पर lang न होना; ग़लत या ग़लत-वर्तनी वाले ARIA roles, states और properties; ज़रूरी ARIA children या parents का न होना; ठोस background पर सादे टेक्स्ट का contrast; viewport meta tag से zoom बंद होना; ख़ाली headings और links।
• आंशिक रूप से तय होने योग्य (टूल flag करे, इंसान पुष्टि करे): images या gradients पर टेक्स्ट का contrast; image decorative है या नहीं; heading संरचना समझदार है या नहीं; target size जहाँ spacing अपवाद लागू हो सकते हैं; live region सही समय पर announce करता है या नहीं।
• मानवीय निर्णय चाहिए: alt text और labels की गुणवत्ता; सार्थक focus order और reading order; errors मददगार ढंग से बताई गई हैं या नहीं (3.3.3); static attributes से आगे कस्टम widgets की कीबोर्ड operability; captions और audio description की सटीकता; motion आवश्यक है या नहीं; cognitive load और सरल भाषा; और क्या पूरा काम screen reader से हो सकता है।

ACT rules: टेस्ट की साझा परिभाषा

दो टूल एक ही पेज के लिए अलग नतीजे दे सकते हैं क्योंकि वे criterion को अलग ढंग से समझते हैं। Accessibility Conformance Testing (ACT) rules इसी को हल करते हैं: हर rule किसी WCAG या ARIA आवश्यकता के हिस्से के लिए सटीक, दस्तावेज़ित टेस्ट प्रक्रिया है, जिसमें applicability, expectations, assumptions और test cases हैं। W3C उन्हें “All ACT Rules” पेज पर सूचीबद्ध करता है; उन्हें ACT Rules Community Group और Accessibility Guidelines Working Group की ACT Task Force विकसित करते हैं, और वे informative हैं — conformance तय करने के लिए आवश्यक नहीं।

Rules proposed या approved चिह्नित होते हैं; approved rule को कम से कम एक टूल ने लागू किया है और संबंधित W3C working group ने review किया है। Implementations हर टूल के लिए सूचीबद्ध होते हैं और automated, semi-automated, manual या linter-आधारित हो सकते हैं। Rule titles के उदाहरण: “Image has non-empty accessible name” और “HTML page has lang attribute”। टेस्टर के लिए ACT rules उपयोगी निर्णायक हैं: जब किसी टूल के नतीजे पर विवाद हो, उसे rule की expectations और test cases से मिलाएँ।

Engines और टूल, तटस्थ विवरण के साथ

ज़्यादातर टूल एक rules engine और उसे चलाने का तरीका हैं। नीचे कौन-सा engine है, यह जानने से समझ आता है कि दो टूल अक्सर सहमत क्यों होते हैं।

• axe-core — open-source JavaScript एक्सेसिबिलिटी rules engine जो browser context में चलता है। यह violations, passes, incomplete नतीजे (जिन्हें मानवीय review चाहिए) और inapplicable rules लौटाता है, और rules को WCAG स्तर से tag करता है। कई integrations इसे wrap करते हैं।
• Lighthouse accessibility audit — Google के Lighthouse का हिस्सा; इसकी एक्सेसिबिलिटी checks axe-core पर आधारित हैं और यह weighted score देता है। 100 score का मतलब है audited rules पास हुए, यह नहीं कि पेज conform करता है।
• Browser devtools accessibility panels — चुने गए element का accessibility tree, computed name, role, states और contrast जानकारी दिखाते हैं। Automated findings के manual सत्यापन के लिए अनिवार्य।
• pa11y — URLs पर automated एक्सेसिबिलिटी checks चलाने का open-source command-line टूल, जिसे अक्सर CI में script किया जाता है।
• Test-framework integrations — community और vendor packages Playwright, Cypress, Jest और ऐसे frameworks में एक्सेसिबिलिटी assertions जोड़ते हैं; static linters (जैसे JSX के लिए) कुछ render होने से पहले ही source code में कुछ समस्याएँ पकड़ते हैं।
• Mobile — Android, TalkBack के साथ manual testing और अपने testing frameworks व Accessibility Scanner app से automated checks का दस्तावेज़ देता है; Apple का XCTest हाल के Xcode versions में accessibility audit समर्थन देता है।
• चुनाव — W3C की Web Accessibility Evaluation Tools List से टूल guideline, प्रकार और वातावरण के अनुसार फ़िल्टर किए जा सकते हैं; W3C स्पष्ट कहता है कि वह किसी विशेष product का समर्थन नहीं करता।

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

Unit, component, E2E tests और CI में checks चलाना

Checks को उस सबसे निचले स्तर पर रखें जो समस्या देख सके, फिर ऊपर व्यापक scans जोड़ें। Component और unit tests design-system component के हर variant में missing names और ग़लत ARIA पकड़ लेते हैं, पेज बनने से बहुत पहले। ध्यान दें कि jsdom जैसे DOM emulations layout की गणना नहीं करते, और axe-core का documentation बताता है कि उसका color-contrast rule JSDOM में काम नहीं करता, इसलिए contrast और layout rules को असली browser चाहिए। Elements को role और accessible name से query करना (Testing Library दस्तावेज़ की सुझाई प्राथमिकता) अपने आप में हल्की एक्सेसिबिलिटी check है: अगर test बटन को उसके नाम से नहीं ढूँढ पाता, तो screen reader भी नहीं ढूँढेगा।

End-to-end tests असली browsers में चलते हैं और पेजों को उन states में scan कर सकते हैं जो यूज़र देखते हैं — login के बाद, dialog खुला होने पर, validation errors दिखने पर। Playwright दस्तावेज़ इस पैटर्न को axe-आधारित package के साथ बताता है; Cypress के समकक्ष community plugins हैं। CI में हर pull request पर उन पेजों और components के लिए scans चलाएँ जिन्हें बदलाव छूता है, और पूरी साइट पर एक व्यापक scheduled scan।

// Example: Playwright + @axe-core/playwright, scanning a page in an error state
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('checkout form with errors has no WCAG A/AA violations', async ({ page }) => {
  await page.goto('/checkout');
  await page.getByRole('button', { name: 'Pay now' }).click(); // trigger validation
  await expect(page.getByRole('alert')).toBeVisible();

  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa'])
    .exclude('#third-party-chat') // documented exclusion, tracked separately
    .analyze();

  expect(results.violations).toEqual([]);
});

सिर्फ़ URLs नहीं, states को scan करें

Engine वही जाँचता है जो उसके चलने के क्षण render हुआ है। Load पर scan किया गया पेज क्लिक पर खुलने वाले menu, modal, error summary, empty state, dark theme या 320 px layout के बारे में कुछ नहीं बताता। उन states को दिखाने वाले interactions को script करें और हर एक के बाद scan करें। अगर आप दोनों themes देते हैं तो दोनों शामिल करें, कम से कम एक संकरा viewport, और अलग direction वाली हर locale — अरबी right-to-left पेज में उसके अंग्रेज़ी जुड़वाँ से अलग defects हो सकते हैं।

नतीजों का triage: false positives और false negatives

हर finding को तब तक परिकल्पना मानें जब तक devtools या assistive technology से सत्यापित न हो। False positives होते हैं — ग़लत background layer के सामने मापा गया contrast, flag हुआ hidden element, या कोई वैध ARIA pattern जिसे engine model नहीं करता। False negatives कहीं ज़्यादा आम और अदृश्य हैं: “image123” जैसा अर्थहीन alt, ग़लत फ़ील्ड का नाम बताने वाला label, सही roles वाला पर बिना कीबोर्ड समर्थन का कस्टम dropdown — ये सब rules पास कर जाते हैं।

Findings को पेज के बजाय rule और component के अनुसार group करें: साझा button component में एक missing name सैकड़ों एक जैसे नतीजे दे सकता है। हर group को WCAG success criterion से जोड़ें, severity यूज़र के काम पर असर के अनुसार तय करें (रुका हुआ checkout सजावटी icon से ऊपर है), और incomplete या needs review चिह्नित items को नज़रअंदाज़ करने के बजाय किसी इंसान को भेजें। ध्यान दें कि WCAG 2.2 ने 4.1.1 Parsing हटा दिया है, इसलिए duplicate ids जैसी markup-validity findings अपने आप में WCAG 2.2 failures नहीं हैं — जब तक वे कुछ और न तोड़ें, जैसे ग़लत element की ओर इशारा करता label या aria-labelledby।

आज़माएँ: AI बग गंभीरता सुझाव

Legacy issues का baseline, उन्हें छिपाए बिना

परिपक्व product पर zero-violations gate चालू करने से आम तौर पर हर build फ़ेल होता है। Baseline gate को उपयोगी बनाता है: मौजूदा violations रिकॉर्ड करें (rule id और component या selector जैसा स्थिर target), build केवल उन findings पर फ़ेल करें जो baseline में नहीं हैं, और baseline फ़ाइल को pull requests में code की तरह review करें। हर baselined item किसी backlog ticket से जुड़ा हो ताकि वह ठीक हो, भूला न जाए; baseline सिर्फ़ छोटा होना चाहिए। पूरे rules बंद करने से बचें — ऊपर के उदाहरण की तरह किसी ख़ास क्षेत्र को कारण और owner के साथ exclude करें।

{
  "generated": "2026-09-28",
  "known": [
    { "rule": "color-contrast", "target": ".legacy-footer a", "ticket": "A11Y-214" },
    { "rule": "label", "target": "#old-search input", "ticket": "A11Y-219" }
  ]
}

Automated नतीजों की ईमानदार रिपोर्टिंग

उपयोगी रिपोर्ट scope (पेज, states, viewports, themes, locales), engine और ruleset version, लक्षित WCAG version और स्तर, success criterion और severity के अनुसार गिनती, नए बनाम baselined issues, और स्पष्ट रूप से यह बताती है कि क्या automated रूप से टेस्ट नहीं हुआ। साफ़ automated run को कभी “WCAG compliant” न कहें। अलग-अलग defects manual defects की तरह ही लिखें — component, दिखने वाली विफलता, criterion, प्रभावित यूज़र्स — और rule दस्तावेज़ का link दें।

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

Automation, manual testing और WCAG-EM sampling को जोड़ना

टिकाऊ कार्यक्रम तरीकों की परतें बनाता है: हर बदलाव पर automated rules; हर feature पर कीबोर्ड, दृश्य प्रस्तुति और फ़ॉर्म की manual checks; मुख्य journeys की screen readers और zoom से assistive-technology टेस्टिंग; और जहाँ संभव हो, विकलांगता वाले लोगों के साथ sessions, जिन्हें W3C की evaluation guidance पूरे विकास में प्रोत्साहित करती है।

पूरी साइट के औपचारिक मूल्यांकन के लिए W3C की WCAG Evaluation Methodology (WCAG-EM 2.0) ढाँचा देती है: evaluation scope तय करना, product को explore करना, प्रतिनिधि sample चुनना, sample का मूल्यांकन करना, और findings रिपोर्ट करना। Sample एक structured चयन — आम views, आवश्यक functionality, अलग-अलग प्रकार के content और तकनीकें, और हर complete process का हर पेज — को randomly चुने गए सेट के साथ जोड़ता है। Automated scans पूरी साइट explore करने और वह sample चुनने के लिए उपयुक्त हैं; फिर sample का मूल्यांकन हर लागू success criterion के सामने होता है, ज़्यादातर हाथ से।

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

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

संदर्भ

• Evaluating Web Accessibility OverviewW3C Web Accessibility Initiative (WAI)एक्सेसिबिलिटी मूल्यांकन के लिए W3C का प्रवेश-पृष्ठ: शुरू से और पूरे विकास में मूल्यांकन क्यों, और मैनुअल जाँच, टूल व यूज़र भागीदारी कैसे साथ काम करते हैं।
• All ACT RulesW3C Web Accessibility Initiative (WAI)Accessibility Conformance Testing (ACT) नियम: WCAG और ARIA आवश्यकताओं के सटीक, दस्तावेज़ित टेस्ट तरीके, ताकि ऑटोमेटेड और मैनुअल नतीजे एक जैसे हों।
• Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024W3C की Recommendation जो सुलभ वेब कंटेंट के लिए टेस्ट करने योग्य success criteria तय करती है — चार सिद्धांतों और तीन conformance स्तरों (A, AA, AAA) में व्यवस्थित।
• WCAG Evaluation Methodology (WCAG-EM) 2.0W3C · 2026पूरी वेबसाइट को WCAG के सामने जाँचने की W3C पद्धति: दायरा तय करना, खोजबीन, प्रतिनिधि सैंपल चुनना, ऑडिट और रिपोर्ट।
• Web Accessibility Evaluation Tools ListW3C Web Accessibility Initiative (WAI)एक्सेसिबिलिटी मूल्यांकन टूल की प्रकार, guideline और वातावरण के अनुसार फ़िल्टर करने योग्य सूची — W3C इन्हें बिना समर्थन के सूचीबद्ध करता है।
• Playwright DocumentationMicrosoft (Playwright)Playwright का आधिकारिक दस्तावेज़ — Chromium, WebKit और Firefox चलाने वाला end-to-end टेस्ट फ़्रेमवर्क।
• Cypress DocumentationCypress.ioCypress से ब्राउज़र में एंड-टू-एंड और कंपोनेंट टेस्टिंग का आधिकारिक दस्तावेज़।
• About Queries — Testing LibraryTesting Libraryक्वेरी प्रकार और उनकी प्राथमिकता — role और label पहले, टेक्स्ट बाद में, test id आख़िर में — ताकि टेस्ट एलिमेंट वैसे ढूँढें जैसे यूज़र और सहायक तकनीक।