ARIA और विजेट पैटर्न

यह क्यों ज़रूरी है

आधुनिक web applications में custom widgets उन जगहों में हैं जहाँ accessibility सबसे आसानी से टूटती है, क्योंकि native element जो कुछ मुफ़्त देता है, वह सब हाथ से दोबारा बनाना पड़ता है: role, name, state, focus की हलचल और हर key। ऐसा dialog जिससे focus पीछे के पेज पर निकल जाए, ऐसे tabs जिनकी selected state कभी न बदले, या ऐसा combobox जिसका highlighted option कभी announce न हो, कीबोर्ड या स्क्रीन रीडर user को payment या form पूरा करने से रोक सकता है। ये WCAG 2.2 के 4.1.2 Name, Role, Value, 2.1.1 Keyboard और 2.4.3 Focus Order जैसे success criteria में failures हैं, तीनों Level A।

ग़लत ARIA बिना ARIA से भी बुरा हो सकता है: role एक व्यवहार का वादा करता है, और जब वह व्यवहार न हो तो user गुमराह होता है। Tester के लिए patterns "tabs accessible नहीं हैं" जैसी धुँधली finding को सटीक, जाँचने लायक expectations में बदल देते हैं जिन पर developer काम कर सके, और असली WCAG failures को किसी convention से हटने वाली बातों से अलग करने में मदद करते हैं।

ARIA एक पैराग्राफ़ में, और पहला नियम

Screen reader testing guide ARIA को विस्तार से समझाता है; यह वह छोटा सार है जिस पर यह lesson टिका है। Roles बताते हैं कि element क्या है (tab, dialog, menu, combobox)। States वे स्थितियाँ हैं जो user के काम करते समय बदलती हैं (aria-expanded, aria-selected, aria-checked)। Properties ज़्यादा स्थिर विशेषताएँ और संबंध हैं (aria-label, aria-labelledby, aria-controls, aria-haspopup)। Accessible name अब भी वैसे ही compute होता है जैसा वह guide बताता है, जिसमें aria-labelledby और aria-label को प्राथमिकता मिलती है। कुछ roles का अर्थ सिर्फ़ अपने context में है: tab एक tablist के अंदर, option एक listbox के अंदर, और menuitem एक menu के अंदर होता है।

ARIA के इस्तेमाल का पहला नियम: अगर किसी native HTML element या attribute में ज़रूरी semantics और व्यवहार पहले से हैं, तो ARIA जोड़ने की बजाय वही इस्तेमाल करें। <button>, <div role="button"> से बेहतर है क्योंकि वह focus लेता है और Enter व Space ख़ुद सँभालता है; <details> और <summary> तैयार disclosure देते हैं; showModal() से खुला <dialog> बाक़ी पेज को inert कर देता है। इसलिए किसी भी custom widget के review में पहला सवाल यही है कि क्या उसे ARIA की ज़रूरत है भी। Tabs, menu buttons और custom list वाले comboboxes का कोई पूरा native विकल्प नहीं है, इसीलिए testers के लिए उनके patterns अहम हैं।

APG pattern page कैसे पढ़ें

हर APG pattern page एक जैसे हिस्सों से बना है, और हर हिस्सा एक तरह के test में बदलता है। Product खोलने से पहले expected results लिख लें।

उदाहरण के लिए, Tabs pattern की Right Arrow वाली entry एक कीबोर्ड test बन जाती है: किसी tab पर focus रखें, Right Arrow दबाएँ, अगले tab पर focus की उम्मीद करें, और आख़िरी tab पर उम्मीद करें कि focus घूमकर पहले tab पर आए। उसका roles वाला हिस्सा tree check बन जाता है: हर tab एक tablist के अंदर tab है, और सिर्फ़ उसी tab पर aria-selected="true" है जिसका panel दिख रहा है।

• About This Pattern: widget किसलिए है। Widget को उसके व्यवहार से पहचानें, रूप से नहीं: buttons की एक row जो उसी जगह panels बदलती है, tabs है; "Show more" button एक disclosure है; और नीचे खुलने वाली site links की list navigation है, menu नहीं।
• Keyboard Interaction: हर key के लिए एक entry, और हर entry expected result वाला एक test step। "(Optional)" लिखी keys, जैसे tabs में Home और End, ज़रूरी नहीं हैं, लेकिन अगर product उन्हें implement करता है तो उन्हें बताए अनुसार काम करना चाहिए।
• WAI-ARIA Roles, States, and Properties: roles और कौन किसके अंदर होगा, runtime पर बदलने वाली states, और हिस्सों को नाम देने व जोड़ने वाली properties। हर line accessibility tree में एक check है। शर्तें ध्यान से पढ़ें: "if the tab list has a visible label" ही तय करता है कि aria-labelledby लगेगा या aria-label।
• Examples: चलते हुए demos, हर एक के साथ keyboard support table और roles, properties, states व tabindex values की table। tabindex column बताता है कि example कौन-सी focus technique इस्तेमाल करता है।
• Pattern जो विकल्प खुले छोड़ता है: tabs का automatic या manual activation, horizontal या vertical orientation। Team से पूछें कि उन्होंने कौन-सा variant चुना और उसे test basis में दर्ज करें; वरना आप defect और design decision में फ़र्क नहीं कर पाएँगे।

<div भाग 1:1role="tablist" भाग 2:2aria-label="Order details">
  <button भाग 3:3role="tab" id="t1" भाग 4:4aria-selected="true"
          भाग 5:5aria-controls="p1" भाग 6:6tabindex="0">Items</button>
  <button भाग 3:3role="tab" id="t2" भाग 4:4aria-selected="false"
          भाग 5:5aria-controls="p2" भाग 6:6tabindex="-1">Delivery</button>
</div>
<div भाग 7:7role="tabpanel" id="p1" भाग 8:8aria-labelledby="t1"
     भाग 9:9tabindex="0">…</div>
<div भाग 7:7role="tabpanel" id="p2" भाग 8:8aria-labelledby="t2"
     भाग 9:9tabindex="0" भाग 10:10hidden>…</div>

पाँच patterns को शुरू से अंत तक verify करना

हर pattern को तीन passes में verify करें, क्योंकि हर pass अलग defects पकड़ता है। पहले browser के DevTools में accessibility tree: हर interaction से पहले और बाद role, name और states। फिर सिर्फ़ कीबोर्ड: pattern की हर key, दिखने वाला focus indicator, और widget खुलने या बंद होने पर focus कहाँ पहुँचता है। आख़िर में स्क्रीन रीडर: focus आने पर क्या announce होता है और क्या हर state change announce होता है। कोई widget tree में सही दिखकर भी कीबोर्ड में fail हो सकता है, या दोनों pass करके भी ठीक से announce न हो, क्योंकि स्क्रीन रीडर किसी role को अलग-अलग तरह support करते हैं।

• Modal dialog। Tree: role dialog, जिसका नाम उसके दिखने वाले title से आता है, custom dialog पर aria-modal="true" के साथ, या showModal() से खुला native <dialog>। कीबोर्ड: खुलते ही focus dialog के अंदर जाता है, Tab और Shift+Tab उसी के अंदर घूमते हैं, Escape उसे बंद करता है, और focus उस control पर लौटता है जिसने उसे खोला था। स्क्रीन रीडर: खुलने पर dialog का role और name announce होते हैं, और arrow keys से पढ़ते हुए पीछे का पेज नहीं पढ़ा जाता।
• Disclosure और accordion। Tree: एक button जिसका aria-expanded दिख रही स्थिति से मेल खाता है; accordion में हर header button एक heading के अंदर होता है। कीबोर्ड: Enter और Space section खोलते और बंद करते हैं, और बंद content तक Tab नहीं पहुँचता। स्क्रीन रीडर: button दबाने पर "collapsed" बदलकर "expanded" हो जाता है।
• Tabs। Tree: नाम वाली tablist; aria-controls और aria-selected वाले tab elements; aria-labelledby से अपने tab का नाम पाने वाले tabpanel elements, और inactive panels छिपे हुए। कीबोर्ड: tab list एक Tab stop है जो active tab पर रुकता है; Left और Right Arrow tabs के बीच चलते हैं और किनारों पर घूम जाते हैं; अगला Tab panel में जाता है, जो ख़ुद tabindex="0" लेता है अगर उसके content की शुरुआत में कुछ focusable न हो। Right-to-left layout में वही arrow direction जाँचें जो आपकी team ने दर्ज की है। स्क्रीन रीडर: हर tab अपना name, role और selected state बोलता है, आम तौर पर अपनी position के साथ, जैसे 2 of 3।
• Menu button। Tree: aria-haspopup वाला button, जिस पर menu खुले रहने तक aria-expanded="true" रहता है, और जो menuitem elements वाला menu खोलता है। कीबोर्ड: Enter या Space menu को पहले item पर खोलता है (Down Arrow भी खोल सकता है), Up और Down Arrow चलते हैं, Enter item चलाकर menu बंद करता है, Escape menu बंद करके focus button पर लौटाता है। स्क्रीन रीडर: button बताता है कि वह menu खोलता है, और हर item menu item के रूप में announce होता है।
• Combobox। Tree: input का role combobox, उसके label से name, list की स्थिति से मेल खाता aria-expanded, option elements वाली listbox की ओर इशारा करता aria-controls, और highlighted option की id पर set aria-activedescendant, जिस option पर aria-selected="true" होता है। कीबोर्ड: typing options को filter करती है, Down Arrow options में चलता है जबकि focus input में ही रहता है, Enter option स्वीकार करता है, Escape list बंद करता है। स्क्रीन रीडर: चलते समय हर highlighted option पढ़ा जाता है, और typing चलती रहती है।

आज़माएँ: HTML फ़ॉर्मेटर आज़माएँ: टेस्ट केस जनरेटर

Roving tabindex और aria-activedescendant

Tabs, menus, listboxes और grids जैसे composite widgets एक Tab stop होते हैं, और उनके अंदर arrow keys चलती हैं। APG इसे बनाने के दो तरीके बताता है। Roving tabindex में मौजूदा item पर tabindex="0" और बाक़ी हर item पर tabindex="-1" होता है; हर arrow key पर script 0 को नए item पर ले जाती है और उस पर focus() call करती है। DOM focus सच में हिलता है, browser item को view में scroll करता है, और user Tab से बाहर जाकर लौटे तो focus उसी item पर आता है जिसे उसने छोड़ा था।

aria-activedescendant में DOM focus एक ही element पर रहता है (container, या combobox का input) और script attribute को active item की id पर set करती है, जिसे assistive technology focused मान लेती है। Visual focus बनाना और item को view में scroll करना script को ख़ुद करना होता है, क्योंकि browser इनमें से कुछ नहीं करता। Combobox को यही technique चाहिए ताकि user options में चलते हुए typing जारी रख सके।

दोनों में फ़र्क करने के लिए Chrome या Edge DevTools का Elements panel खोलें और arrow keys दबाएँ: देखें कौन-सा attribute बदलता है। फिर document.activeElement को live expression के रूप में जोड़ें (Console के ऊपर eye icon से), जो लगातार दिखाता रहता है कि DOM focus असल में कहाँ है। हर technique पहचानने लायक तरीकों से टूटती है:

• Roving: कई items पर tabindex="0" रह जाता है, इसलिए Tab panel पर जाने की बजाय हर tab से गुज़रता है; या re-render के बाद किसी item पर 0 नहीं रहता और widget तक Tab से पहुँचा ही नहीं जा सकता (2.1.1)।
• Roving: arrow key highlight तो हिलाती है पर focus() कभी call नहीं होता, इसलिए focus indicator और स्क्रीन रीडर पुराने item पर ही रहते हैं।
• Roving: 0 पहले item पर ही रह जाता है, इसलिए Shift+Tab से लौटने पर focus ऐसे tab पर आता है जो selected नहीं है।
• Active descendant: attribute ऐसी id की ओर इशारा करता है जो अब मौजूद नहीं, आम तौर पर list filter होकर दोबारा बनने के बाद; highlight हिलता है पर स्क्रीन रीडर कुछ नहीं बोलता।
• Active descendant: attribute बदलता है पर कोई highlight नहीं बनता, इसलिए देख सकने वाले कीबोर्ड users नहीं जान पाते कि वे कहाँ हैं (आम तौर पर 2.4.7 Focus Visible के तहत report होता है); या active option view से बाहर scroll हुआ रहता है।
• Active descendant: जिस element की ओर इशारा है उसका option या menuitem role नहीं है, या वह widget और उसकी controlled list से बाहर है, इसलिए वह सादे text की तरह पढ़ा जाता है या बिल्कुल नहीं।

Worked example: order tabs टेस्ट करना और defects लिखना

एक order page पर तीन tabs हैं: Items, Delivery और Payment। Refinement में team ने automatic activation वाला APG Tabs pattern चुना, इसलिए वही test basis है। तीनों passes से चार findings निकलती हैं, और हर एक को report करने से पहले classify किया जाता है।

एक उपयोगी ARIA defect component और pattern variant का नाम लेता है, exact key sequence देता है, expected और actual role, name या state वैसे लिखता है जैसे tree दिखाता है और स्क्रीन रीडर announce करता है, और WCAG criterion तभी cite करता है जब product सच में उसमें fail हो। नीचे चारों findings classify की हुई हैं, फिर दूसरी finding की report:

• Tree: container एक सादा <div> है, इसलिए तीनों tabs ऐसे generic node के नीचे हैं जिसका न tablist role है न नाम। WAI-ARIA के अनुसार tab को tablist के अंदर होना चाहिए; users को दिखने वाला grouping उजागर नहीं है, जो 1.3.1 Info and Relationships में fail है, वही criterion जिससे W3C का ACT rule "ARIA required context role" इसे जोड़ता है।
• Tree और स्क्रीन रीडर: Right Arrow से Delivery पर जाने के बाद Delivery panel दिखता है, पर aria-selected="true" Items पर ही रहता है, और स्क्रीन रीडर Delivery को selected नहीं बताता। स्क्रीन पर दिखने वाली state उजागर state नहीं है: 4.1.2 failure, severity Major, क्योंकि दृष्टिहीन user नहीं जान पाता कि वह कौन-सा panel पढ़ रहा है।
• कीबोर्ड: हर tab पर tabindex="0" है, इसलिए Tab panel तक पहुँचने से पहले तीनों tabs से गुज़रता है, और Payment पर Right Arrow घूमकर Items पर जाने की बजाय कुछ नहीं करता। फिर भी हर tab कीबोर्ड से चलता है, इसलिए 2.1.1 पूरा होता है: इसे APG keyboard interaction से deviation के रूप में, severity Minor, बिना WCAG criterion के report करें।
• Tree: panels का role tabpanel है पर aria-labelledby नहीं, इसलिए user panel में बिना यह सुने पहुँचता है कि वह किस tab का है। WAI-ARIA 1.2 में tabpanel के लिए name ज़रूरी है, इसलिए इसे pattern और WAI-ARIA के आधार पर severity Minor के साथ report करें।

Title:     Order tabs: "Delivery" पर जाने के बाद भी selected state "Items" पर रहती है
Component: Order details tabs, /orders/1042 · APG Tabs, automatic activation
Env:       Windows 11 · Firefox · NVDA (versions attachment में)
Steps:     1. Tab से "Items" tab पर जाएँ।  2. Right Arrow दबाएँ।
Expected:  Focus, panel और selection "Delivery" पर जाएँ:
           Delivery पर aria-selected="true" और Items पर "false";
           स्क्रीन रीडर Delivery को selected tab बताए।
Actual:    Delivery panel दिखता है, पर aria-selected="true" Items पर ही रहता है;
           NVDA selected state announce नहीं करता।
Criterion: WCAG 2.2 4.1.2 Name, Role, Value (Level A)
Severity:  Major
Evidence:  पहले और बाद के accessibility pane screenshots; DOM snippet

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

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

संदर्भ

• ARIA Authoring Practices Guide (APG)W3C Web Accessibility Initiative (WAI)आम विजेट (tabs, menus, dialogs, comboboxes) के पैटर्न, अपेक्षित कीबोर्ड इंटरैक्शन और ARIA उपयोग के साथ — वह संदर्भ जिससे टेस्टर कस्टम कंपोनेंट की तुलना करते हैं।
• Accessible Rich Internet Applications (WAI-ARIA) 1.2W3C · 2023W3C Recommendation जो ARIA roles, states और properties परिभाषित करती है — कस्टम विजेट अपना अर्थ सहायक तकनीक को कैसे बताते हैं।
• 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 की व्याख्या: उद्देश्य, किसे लाभ, उदाहरण और तकनीकें (नॉर्मेटिव नहीं)।