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

कीबोर्ड पर कौन निर्भर है और कौन-से criteria लागू होते हैं

बहुत से लोग कभी माउस इस्तेमाल नहीं करते: दृष्टिहीन यूज़र कीबोर्ड से चलने वाले स्क्रीन रीडर से नेविगेट करते हैं; कंपन या सीमित हाथ की गतिविधि वाले लोग कीबोर्ड, switch device या keystrokes की नकल करने वाला वॉइस कंट्रोल इस्तेमाल करते हैं; कुछ लोग बस इसे पसंद करते हैं। फ़ोन और टैबलेट पर external keyboard और switch access भी यही focus मॉडल इस्तेमाल करते हैं। अगर किसी चीज़ तक कीबोर्ड से पहुँचा नहीं जा सकता, तो ये सभी यूज़र उससे वंचित रह जाते हैं।

ये WCAG 2.2 success criteria कीबोर्ड टेस्ट का मूल हैं:

• 2.1.1 Keyboard (A) — सारी functionality कीबोर्ड इंटरफ़ेस से चलाई जा सके, अलग-अलग keystrokes के लिए ख़ास timing की ज़रूरत के बिना (freehand drawing जैसे path पर निर्भर इनपुट अपवाद हैं)।
• 2.1.2 No Keyboard Trap (A) — अगर कीबोर्ड से फ़ोकस किसी कंपोनेंट में जा सकता है, तो कीबोर्ड से बाहर भी आ सके; अगर कोई non-standard key चाहिए, तो यूज़र को बताया जाए।
• 2.1.4 Character Key Shortcuts (A) — एक अक्षर वाले shortcuts बंद या remap किए जा सकें, या सिर्फ़ तब काम करें जब संबंधित कंपोनेंट पर फ़ोकस हो।
• 2.4.1 Bypass Blocks (A) — कई पेजों पर दोहराए जाने वाले blocks को छोड़ने का तरीका हो, जैसे skip link।
• 2.4.3 Focus Order (A) — फ़ोकस ऐसे क्रम में चले जो अर्थ और operability बनाए रखे।
• 2.4.7 Focus Visible (AA) — कीबोर्ड फ़ोकस का दिखने वाला indicator हो।
• 2.4.11 Focus Not Obscured (Minimum) (AA) — फ़ोकस वाला कंपोनेंट sticky header या banner जैसे author के बनाए कंटेंट से पूरी तरह न छिपे।
• 3.2.1 On Focus (A) — सिर्फ़ फ़ोकस मिलने से context न बदले।
• संबंधित: tooltips और popovers के लिए 1.4.13 Content on Hover or Focus (AA), और AAA criteria 2.1.3 Keyboard (No Exception), 2.4.12 Focus Not Obscured (Enhanced) और 2.4.13 Focus Appearance।

कीबोर्ड टेस्ट सेशन कैसे चलाएँ

माउस को पहुँच से दूर रखें और फ़ोकस ब्राउज़र के address bar में रखकर शुरू करें, ताकि पहला Tab पेज के पहले element पर जाए। पेज पर दोनों दिशाओं में चलें और हर कंट्रोल चलाएँ। ज़रूरी keys:

• Tab और Shift+Tab — अगले और पिछले focusable element पर जाना।
• Enter — links और buttons चलाना, फ़ॉर्म सबमिट करना। Space — buttons चलाना, checkbox टॉगल करना, कुछ selects खोलना।
• Arrow keys — composite widgets के अंदर चलना: radio groups, tabs, menus, listboxes, sliders, grids।
• Escape — dialogs, menus, popovers और tooltips बंद करना।
• Home, End, Page Up, Page Down — lists, sliders और लंबे widgets में कूदना, जहाँ pattern इन्हें परिभाषित करता है।

Focus order, visible focus और focus not obscured

Focus order लेआउट के reading order का पालन करे: left-to-right पेज में ऊपर-बाएँ से नीचे-दाएँ, अरबी right-to-left पेज में ऊपर-दाएँ से। क्रम तब टूटता है जब DOM order दृश्य क्रम से अलग हो (CSS grid या flex से reordering, absolutely positioned panels) या जब authors positive tabindex इस्तेमाल करें, जो elements को बाकी सब से आगे खींच लेता है। tabindex="0" custom कंट्रोल को स्वाभाविक क्रम में जोड़ता है और tabindex="-1" element को सिर्फ़ script से focusable बनाता है; positive values लगभग हमेशा डिफ़ेक्ट होती हैं।

Focus indicator हर focusable element पर और हर background पर दिखना चाहिए। Failure का सबसे आम कारण global "outline: none" है जिसका कोई replacement style नहीं। टेक्स्ट के अंदर links, रंगीन banners में buttons, cards और डार्क footer में inputs जाँचें। WCAG 2.2 AA सिर्फ़ इतना माँगता है कि indicator दिखे; AAA criterion 2.4.13 Focus Appearance आकार और कंट्रास्ट की requirements जोड़ता है, जो अच्छा डिज़ाइन लक्ष्य है।

अंत में जाँचें कि फ़ोकस कभी पूरी तरह न छिपे। Sticky headers और footers, cookie banners, chat launchers और bottom sheets पेज scroll होने पर अक्सर फ़ोकस वाले element को ढक देते हैं, जो 2.4.11 Focus Not Obscured (Minimum) फ़ेल करता है। लंबे पेजों पर सभी sticky elements के साथ Tab करें, 200% ज़ूम पर भी, जहाँ वे viewport का ज़्यादा हिस्सा ढकते हैं।

Keyboard traps और bypass blocks

Keyboard trap वह जगह है जहाँ फ़ोकस जा तो सकता है पर निकल नहीं सकता। आम संदिग्ध हैं: iframes में embedded third-party कंटेंट (maps, video players, payment fields), Tab को indentation के लिए पकड़ने वाले rich-text editors, custom date pickers, और dialogs की focus-management scripts जो dialog बंद होने के बाद भी फ़ोकस वापस खींचती रहती हैं। हर एक में Tab से जाएँ, फिर Tab, Shift+Tab और Escape से निकलने की कोशिश करें। अगर निकलने के लिए कुछ असामान्य चाहिए, तो कंपोनेंट को यूज़र को बताना होगा कि कैसे।

Bypass blocks संभावना नहीं, मेहनत के बारे में है। अगर कीबोर्ड यूज़र को हर पेज पर navigation पार करने के लिए चालीस बार Tab दबाना पड़े, तो पेज operable हो सकता है पर usable नहीं। WCAG 2.4.1 दोहराए जाने वाले blocks को छोड़ने का तरीका माँगता है। पहले focusable element के रूप में "Skip to main content" link कीबोर्ड यूज़र्स के लिए सबसे सीधा तरीका है; landmarks और headings स्क्रीन रीडर यूज़र्स की भी मदद करते हैं। जाँचें कि skip link फ़ोकस पर दिखता है, और उसे चलाने से सच में फ़ोकस हिलता है — सिर्फ़ scroll position नहीं — ताकि अगला Tab main content के पहले कंट्रोल पर जाए।

Custom widgets और अपेक्षित key patterns

Native HTML कंट्रोल — button, href वाला a, input, select, textarea, details — में कीबोर्ड व्यवहार पहले से होता है। div और span से बने custom widgets में कुछ नहीं होता जब तक डेवलपर न जोड़ें, और ARIA roles भी इसे नहीं जोड़ते। W3C का ARIA Authoring Practices Guide (APG) हर आम pattern के लिए वह कीबोर्ड interaction बताता है जिसकी यूज़र अपेक्षा करते हैं; इसे अपने टेस्ट केस में expected result के रूप में इस्तेमाल करें। Composite widgets में पूरा widget आमतौर पर एक Tab stop होता है और arrow keys उसके अंदर चलती हैं।

• Button — Enter और Space से चलता है। सिर्फ़ click पर प्रतिक्रिया देने वाला div फ़ेल है।
• Checkbox — Space टॉगल करता है। Radio group — Tab चुने हुए विकल्प पर group में प्रवेश करता है; arrow keys चलती और चुनती हैं।
• Tabs — Tab फ़ोकस को tab list में active tab पर ले जाता है; Left और Right arrows tabs के बीच चलते हैं; फिर Tab panel में जाता है।
• Menu button — Enter या Space मेन्यू खोलकर पहले item पर फ़ोकस करता है (Down Arrow भी खोल सकता है); arrows चलते हैं; Escape बंद करके फ़ोकस button पर लौटाता है।
• Combobox और listbox — Down Arrow विकल्प खोलता या उनमें चलता है; Enter चुनता है; Escape popup बंद करता है।
• Slider — arrow keys वैल्यू एक step बदलती हैं; Home और End न्यूनतम और अधिकतम पर ले जाते हैं।
• Right-to-left लेआउट — APG horizontal arrow keys का काम (अगले tab या slider की ज़्यादा वैल्यू के लिए Right Arrow) बताता है, पर right-to-left लेआउट की बात नहीं करता, इसलिए RTL के लिए अलग नियम तय नहीं करता। Mirrored अरबी लेआउट में यह टॉपिक (एक्सेसिबिलिटी टेस्टिंग पिलर और RTL टेस्टिंग गाइड देखें) यही expected result मानता है कि horizontal arrows दृश्य दिशा का पालन करें: अगला tab बाईं ओर होता है, इसलिए Left Arrow उस पर जाता है, और जिस mirrored slider का न्यूनतम मान दाईं ओर है उसमें Left Arrow वैल्यू बढ़ाता है। Up और Down Arrow, Home और End का अर्थ नहीं बदलता। यह नियम design specification में लिखें और जाँचें कि हर widget इसे एक ही तरह लागू करे।
• Disclosure और accordion — Enter या Space सेक्शन खोलता और बंद करता है।
• Dialog (modal) — Tab और Shift+Tab dialog के अंदर रहते हैं; Escape उसे बंद करता है।

Modal dialogs, menus और dynamic कंटेंट

ज़्यादातर single-page applications focus management में ही फ़ेल होती हैं। Modal dialog खुलने पर फ़ोकस उसके अंदर जाना चाहिए — पहले फ़ील्ड पर, पहले actionable element पर, या लंबे कंटेंट में dialog heading पर। खुले रहने तक Tab dialog के अंदर घूमे और पीछे का पेज पहुँच से बाहर रहे। बंद होने पर फ़ोकस उसी element पर लौटना चाहिए जिसने उसे खोला था, ताकि यूज़र वहीं से आगे बढ़े। showModal() से खुलने वाला native dialog element इसका बड़ा हिस्सा सँभालता है; custom dialogs को यह script में करना होता है।

यही नियम यूज़र के हर बदलाव पर लागू करें: row delete करने के बाद फ़ोकस पड़ोसी row या status message पर जाए, डॉक्यूमेंट के शुरू में नहीं; client-side route change के बाद फ़ोकस नए पेज की heading या main region पर जाए; कीबोर्ड से खुले menus और popovers Escape से बंद हों और फ़ोकस अपने trigger पर लौटाएँ। Hover पर दिखने वाला कंटेंट कीबोर्ड फ़ोकस पर भी दिखे और फ़ोकस हिलाए बिना बंद किया जा सके (1.4.13 Content on Hover or Focus)।

कीबोर्ड टेस्ट केस

Scope में हर पेज प्रकार और हर complete process के लिए इन्हें चलाएँ। हर लाइन अपने expected result के साथ एक टेस्ट केस है; failures को success criterion के साथ दर्ज करें।

• KB-01 — Address bar से पहला Tab ऐसे skip link पर जाता है जो फ़ोकस पर दिखने लगता है।
• KB-02 — Skip link चलाने पर फ़ोकस main पर जाता है; अगला Tab main के पहले कंट्रोल तक पहुँचता है।
• KB-03 — Tab हर interactive element तक पहुँचता है; कोई non-interactive element Tab stop नहीं है।
• KB-04 — Shift+Tab क्रम को ठीक उल्टा चलाता है।
• KB-05 — Focus order reading order से मेल खाता है (LTR और RTL दोनों लेआउट जाँचें)।
• KB-06 — हर stop पर और हर background पर focus indicator दिखता है।
• KB-07 — कोई फ़ोकस वाला element sticky header, footer, cookie banner या chat widget से पूरी तरह नहीं छिपता।
• KB-08 — Buttons Enter और Space से चलते हैं; links Enter से।
• KB-09 — Custom widgets APG keys का पालन करते हैं (tabs: arrows; menu: Enter/Space, Esc; slider: arrows, Home/End)।
• KB-10 — Modal: खुलने पर फ़ोकस अंदर जाता है, Tab अंदर ही घूमता है, Esc बंद करता है, और फ़ोकस trigger पर लौटता है।
• KB-11 — कोई trap नहीं: फ़ोकस हर widget, iframe, video player और editor से बाहर आ सकता है।
• KB-12 — Hover पर दिखने वाले tooltips और popovers फ़ोकस पर भी दिखते हैं और Esc से बंद होते हैं।
• KB-13 — सिर्फ़ फ़ोकस से कभी submit, navigation या context change नहीं होता।
• KB-14 — एक-key shortcuts बंद या remap किए जा सकते हैं, या सिर्फ़ तब चलते हैं जब कंपोनेंट पर फ़ोकस हो।
• KB-15 — Delete, add या route change के बाद फ़ोकस किसी समझदार element पर जाता है, document body पर नहीं।
• KB-16 — हर complete process (जैसे checkout) सिर्फ़ कीबोर्ड से पूरा हो सकता है।

KB-01  First Tab from the address bar lands on a skip link that becomes visible on focus
KB-02  Activating the skip link moves focus to main; next Tab reaches the first control in main
KB-03  Tab reaches every interactive element; nothing non-interactive is a Tab stop
KB-04  Shift+Tab reverses the order exactly
KB-05  Focus order matches the reading order (check LTR and RTL layouts)
KB-06  Focus indicator visible on every stop, on every background
KB-07  No focused element is fully hidden by sticky header, footer, cookie banner or chat widget
KB-08  Buttons activate with Enter and Space; links with Enter
KB-09  Custom widgets follow APG keys (tabs: arrows; menu: Enter/Space, Esc; slider: arrows, Home/End)
KB-10  Modal: focus moves in on open, Tab cycles inside, Esc closes, focus returns to the trigger
KB-11  No trap: focus can leave every widget, iframe, video player and editor
KB-12  Tooltips and popovers shown on hover also show on focus and close with Esc
KB-13  Focus alone never submits, navigates or changes context
KB-14  Single-key shortcuts can be turned off or remapped, or work only when the component has focus
KB-15  After delete, add or route change, focus lands on a sensible element, not the document body
KB-16  Each complete process (e.g. checkout) can be finished with the keyboard only

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

डिफ़ेक्ट के उदाहरण

बग टाइटल के रूप में, हर एक किस criterion को फ़ेल करता है उसके साथ। रिपोर्ट में ब्राउज़र, सटीक key sequence और फ़ोकस कहाँ पहुँचा, यह लिखें।

• "Date picker arrow keys से नहीं चलता; तारीख़ सिर्फ़ माउस से चुनी जा सकती है" — 2.1.1 Keyboard।
• "Custom Accept terms checkbox (div) Space से टॉगल नहीं होता" — 2.1.1 Keyboard।
• "Branches पेज पर embedded map iframe में Tab फ़ोकस अटक जाता है" — 2.1.2 No Keyboard Trap।
• "न skip link, न landmarks; search results तक पहुँचने में 42 बार Tab" — 2.4.1 Bypass Blocks।
• "Newsletter फ़ील्ड पर positive tabindex से पहला Tab skip link और header से पहले सीधे footer पर जाता है" — 2.4.3 Focus Order।
• "Filters drawer बंद करने के बाद फ़ोकस डॉक्यूमेंट की शुरुआत पर चला जाता है" — 2.4.3 Focus Order।
• "सभी links से focus ring हटाया गया (outline: 0), कोई विकल्प नहीं" — 2.4.7 Focus Visible।
• "200% ज़ूम पर sticky cookie banner फ़ोकस वाले Pay now बटन को ढक देता है" — 2.4.11 Focus Not Obscured (Minimum)।
• "Language selector पर फ़ोकस होते ही पेज अरबी में reload हो जाता है" — 3.2.1 On Focus।

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

क्या automate किया जा सकता है

Rule engines कुछ कीबोर्ड समस्याएँ static रूप से पकड़ते हैं — positive tabindex, focusable न होने वाले interactive roles, कीबोर्ड access के बिना scrollable regions — लेकिन क्रम या visibility का फ़ैसला नहीं कर सकते। Browser automation इस कमी का हिस्सा भरता है: Playwright, Cypress या Selenium टेस्ट keys दबाकर assert कर सकता है कि फ़ोकस किस element पर है, जिससे dialogs और route changes में focus-management regressions पकड़ना सस्ता हो जाता है। क्रम, visibility और छिपे फ़ोकस के लिए मैनुअल पास रखें, इन्हें आँखें चाहिए।

test("edit address dialog returns focus to its trigger", async ({ page }) => {
  await page.goto("/account/addresses");
  const edit = page.getByRole("button", { name: "Edit address" });
  await edit.focus();
  await page.keyboard.press("Enter");
  await expect(page.getByRole("dialog", { name: "Edit address" })).toBeVisible();
  await expect(page.getByRole("textbox", { name: "Street" })).toBeFocused();
  await page.keyboard.press("Escape");
  await expect(page.getByRole("dialog")).toBeHidden();
  await expect(edit).toBeFocused();
});

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

संदर्भ

• 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 की व्याख्या: उद्देश्य, किसे लाभ, उदाहरण और तकनीकें (नॉर्मेटिव नहीं)।
• ARIA Authoring Practices Guide (APG)W3C Web Accessibility Initiative (WAI)आम विजेट (tabs, menus, dialogs, comboboxes) के पैटर्न, अपेक्षित कीबोर्ड इंटरैक्शन और ARIA उपयोग के साथ — वह संदर्भ जिससे टेस्टर कस्टम कंपोनेंट की तुलना करते हैं।
• Easy Checks – A First Review of Web AccessibilityW3C Web Accessibility Initiative (WAI)पूरे मूल्यांकन से पहले कोई भी कर सके ऐसी शुरुआती जाँचें — पेज टाइटल, टेक्स्ट विकल्प, हेडिंग, कंट्रास्ट, टेक्स्ट रीसाइज़, कीबोर्ड एक्सेस।
• Accessibility — MDNMDN Web Docs (Mozilla)सुलभ वेब पेज बनाने और जाँचने की व्यावहारिक गाइड: सिमैंटिक HTML, ARIA, कीबोर्ड सपोर्ट और टेस्टिंग।
• Playwright DocumentationMicrosoft (Playwright)Playwright का आधिकारिक दस्तावेज़ — Chromium, WebKit और Firefox चलाने वाला end-to-end टेस्ट फ़्रेमवर्क।