Agent actions के लिए VoiceOver approval cards

Approval card कोई सजावटी रुकावट नहीं, बल्कि सुरक्षा से जुड़ा फैसला है। अगर VoiceOver उपयोगकर्ता buttons तक पहुंचने से पहले requesting process, वास्तविक destination, action और scope नहीं पहचान सकता, तो card उससे सहमति तो मांग रही है, लेकिन वह सहमति देने के लिए जरूरी तथ्य नहीं दे रही।

मैंने teams को किसी prompt को सिर्फ इसलिए "accessible" कहते देखा है क्योंकि VoiceOver Approve button तक पहुंच गया। यह बहुत कम मानक है और खतरनाक भी। कोई व्यक्ति ऐसा control सक्रिय कर सकता है जिसे वह समझता ही नहीं। Agent actions में इस गलती का असर गंभीर हो सकता है: एक approval stored credential के तहत request भेज सकता है या किसी ऐसी machine पर SSH session खोल सकता है जिसे agent के अपने वर्णन पर भरोसा नहीं किया जा सकता।

Card को controls देने से पहले फैसला साफ बताना चाहिए

पहली उपयोगी आवाज को यह बताना चाहिए कि फैसला किस बारे में है, और उसे लेने के लिए जरूरी हर तथ्य Approve और Deny से पहले आना चाहिए। अच्छी card पहले VoiceOver को छोटा-सा summary देती है और फिर details को स्थिर क्रम में दिखाती है। उपयोगकर्ता को ऐसे visual arrangement में कुछ ढूंढने के लिए मजबूर नहीं किया जाता जो spacing, badges या color दिखाई देने पर ही समझ में आता हो।

यह क्रम रखें:

1. Card क्यों दिखाई दी: कोई नया agent process authorization मांग रहा है, या protected credential को इस call के लिए confirmation चाहिए।
2. कौन मांग रहा है: process name, जरूरत होने पर executable path और उसकी code-signing authority।
3. वह कहां कार्रवाई करना चाहता है: protocol और concrete destination।
4. वह क्या करना चाहता है: HTTP method और request shape, या SSH command और target।
5. फैसले से क्या अनुमति मिलेगी: यह call, process के बंद होने तक चल रहा यह process, या protected credential का एक इस्तेमाल।

यह sequence उस फैसले से मेल खाता है जो कोई सावधान operator लेता है। Provenance बताता है कि कौन पूछ रहा है। Destination बताता है कि असर कहां पड़ेगा। Action बताता है कि क्या बदलेगा। Scope बताता है कि अनुमति कितनी देर तक रहेगी। इस पूरी कड़ी से पहले buttons रखने पर card एक reflex test बन जाती है।

शुरुआती summary इतनी छोटी रखें कि उसे एक बार में सुना जा सके। उदाहरण के लिए:

Authorization requested. Signed process: Acme Development, agent-helper.
HTTPS request to api.example.net. POST /v1/releases.
This approval allows this process until it exits.

Summary के तुरंत बाद, controls से पहले expanded detail आनी चाहिए। इसे unlabeled disclosure triangle के पीछे न छिपाएं और host जानने के लिए उपयोगकर्ता को अलग view में जाने पर मजबूर न करें। छोटी card कम असर वाले fields को collapse कर सकती है, लेकिन destination या operation को खुद collapse नहीं कर सकती।

W3C की WAI-ARIA Authoring Practices modal dialog को ऐसी सीमित interaction बताती है जिसमें label, सही focus handling और उसे बंद करने का स्पष्ट तरीका हो। यह सलाह तब भी लागू होती है जब application web ARIA के बजाय native macOS controls इस्तेमाल करती हो। ऐसा modal prompt जो सिर्फ अपना title सुनाता है, pattern के सबसे संकरे हिस्से को पूरा करता है, लेकिन वास्तविक फैसले में विफल रहता है।

Process identity सबूत है, अनुमति-पत्र नहीं

Process signature उपयोगकर्ता को बताता है कि access मांगने वाले code को किसने बनाया या sign किया। इससे यह साबित नहीं होता कि request उचित है। इसे card की शुरुआत में रखे जाने वाले सबूत की तरह लें और फिर request के बाकी हिस्से को उस identity से भ्रमित करना असंभव बनाएं।

Identity field का spoken form स्थिर होना चाहिए। Signing authority से शुरुआत करें, क्योंकि कई helper processes के file names मिलते-जुलते हों तो इससे operator को अर्थपूर्ण आधार मिलता है। उसके बाद process name दें। Path तभी शामिल करें जब वह ambiguity दूर करता हो, जैसे local development build और installed build का नाम एक जैसा हो। लंबा path details region में रखें, जहां VoiceOver उसे line by line पढ़ सके।

"trusted agent" या हरे "verified" badge जैसी अस्पष्ट भाषा से बचें। ऐसे वाक्यांश कई अलग-अलग दावों को एक भरोसा जगाने वाले visual cue में समेट देते हैं। किसी process की signature valid हो सकती है, फिर भी उसका prompt malformed हो सकता है, instruction source compromised हो सकता है या request गलत account को target कर सकती है। Users को provenance चाहिए, interface का बनाया हुआ कोई verdict नहीं।

Request summary इस तरह हो सकती है:

Requesting process
Signing authority: Example Software LLC
Process: deploy-helper
Details: /Applications/Deploy Helper.app/Contents/MacOS/deploy-helper

इस content को एक labeled group के रूप में दिखाएं, जिसके children भी इसी क्रम में हों। Signing authority को subtitle, badge और accessibility hint में दोहराएं नहीं। दोहराव VoiceOver output को थका देता है और उपयोगकर्ता उसी phrase को छोड़ना शुरू कर देता है जिस पर आप चाहते थे कि उसका ध्यान जाए।

यहां एक और जाल है: process name बदला जा सकता है। कोई attacker executable का नाम "release-agent" रखकर उम्मीद कर सकता है कि इंसान आगे पढ़ेगा ही नहीं। Signing authority की नकल करना कठिन है, लेकिन वह भी destination को authorize नहीं करती। Card को identity को request की guarantee की तरह कभी नहीं पेश करना चाहिए। "requested by" या "signed by" कहें, फिर action को अलग sentences में बताएं।

Unsigned local development processes के लिए वह स्थिति साफ शब्दों में बताएं। "personal build" जैसी euphemism न इस्तेमाल करें। अगर product request की अनुमति देता है, तो user तय कर सकता है कि unsigned process को session grant मिलना चाहिए या नहीं। यह condition छिपाने से friction खत्म नहीं होती, वह सिर्फ गलती के बाद सामने आती है।

Destination का ऐसा नाम जरूरी है जिसे users जांच सकें

Card को destination को specific endpoint या host के रूप में बोलना चाहिए, क्योंकि categories और icons यह नहीं बता सकते कि credentials कहां जाएंगे। HTTP और SSH के लिए summary अलग होगी, लेकिन किसी भी approval control से पहले दोनों में concrete remote side होनी चाहिए।

HTTP के लिए protocol, host, method और ऐसा path पढ़ें जिसमें consequence साफ रहे। POST api.example.net/v1/releases "Release service" से कहीं ज्यादा बताता है। अगर port आम port से अलग है, तो उसे शामिल करें। अगर request redirect के बाद जाती है, तो सिर्फ original host बताकर final host को बाद के surprise के लिए न छोड़ें। Consent मांगने से पहले destination resolve करें, या remote host बदलने पर फिर से पूछें।

SSH के लिए host या alias, privilege पर असर पड़ने पर user और command पढ़ें। [email protected]: systemctl restart worker ऐसा फैसला देता है जिसे कोई व्यक्ति ले सकता है। "SSH command" ऐसा नहीं करता। अगर alias configuration file के जरिए expand होता है, तो primary summary में resolved host दें और details में alias भी रखें। लोग अक्सर nickname को पहले और असली machine को बाद में पहचानते हैं, इसलिए दोनों मिलना चाहिए।

DNS के साथ भी यही सावधानी रखें। Hostname users के लिए सही-facing identity है। IP address, खासकर किसी संदिग्ध या असामान्य request में, अतिरिक्त जानकारी दे सकता है, लेकिन उसे hostname की जगह न रखें और हर approval को memory contest न बनाएं। अगर system target resolve नहीं कर सकता, तो prompt को साफ कहना चाहिए कि वह इसे resolve नहीं कर सकता। पुराने cached label से झूठा भरोसा न पैदा करें।

Destinations को अलग दिखाने के लिए red production label, warning triangle या left-hand column पर निर्भर न रहें। ये devices sighted scanning में मदद कर सकते हैं, लेकिन meaning अपने भीतर नहीं रख सकते। अगर environment name के लिए आपके पास विश्वसनीय source है, तो उसे text में दें और host को भी बोलें। Environment labels बदल सकते हैं। Hosts user को बताते हैं कि connection कहां जा रहा है।

एक संक्षिप्त accessible representation ऐसी दिखती है:

Destination
Protocol: HTTPS
Host: billing.example.net
Request: PATCH /v2/subscriptions/4821
Credential: billing-service token

Credential label destination और action के बाद आना चाहिए, उनसे पहले नहीं। User को यह पता होना चाहिए कि credential क्या करेगा, फिर तय करना चाहिए कि उसे इस्तेमाल किया जाए या नहीं। Token value को कभी न बोलें, accessibility-only label में भी नहीं। Assistive technology user interface का हिस्सा है, secrets के लिए कोई private side channel नहीं।

Redaction को approval या denial का कारण बचाए रखना चाहिए

Redaction का काम secret material हटाना है, request के फैसले को बदलने वाले हिस्से नहीं। Teams अक्सर इसका उलटा कर देती हैं। वे हर parameter छिपा देती हैं और मानती हैं कि privacy बचा ली, जबकि approval card इतनी अस्पष्ट हो जाती है कि खराब action रोक ही नहीं सकती।

Bearer tokens, passwords, private key material, cookies, authorization headers, signed URLs और उन fields की पूरी values हमेशा छिपाएं जिनमें personal या financial data हो सकता है। Token के केवल बीच के हिस्से को mask करना आम तौर पर दिखावा है। Partial secret attacker को credential का मिलान करने या उसे दोबारा बनाने में मदद कर सकता है, और designers को logs में भी जरूरत से ज्यादा जानकारी दिखाने के लिए उकसा सकता है।

Structure बचाए रखें। HTTP request के लिए method, host, path, content type, उपयोगी scale मिलने पर body size और sensitive fields के names दिखाएं। Command के लिए executable, arguments, target files या services और redacted arguments का स्पष्ट marker दिखाएं। कोई user यह तय कर रहा हो कि invoice भेजनी है या नहीं, तो उसे सुनना चाहिए कि request में recipient, amount और currency हैं; recipient का address या amount की actual value बताने की जरूरत नहीं, अगर policy उन्हें sensitive मानती है।

इन दो spoken summaries की तुलना करें:

POST request with protected details.

POST api.example.net/v1/payouts.
JSON fields: destination account redacted, amount redacted, currency visible.
This call uses the finance credential.

दूसरा version secret values उजागर नहीं करता, लेकिन यह बताता है कि agent payout करने की कोशिश कर रहा है, कोई harmless status check नहीं। Consent screen का उद्देश्य यही अंतर दिखाना है।

Approval prompt के भीतर "show secret" button न बनाएं। User को अधिक context की जरूरत हो सकती है, लेकिन उसका उत्तर vault boundaries से निकलने का आसान रास्ता नहीं, बल्कि सुरक्षित representation है। अगर operator को सचमुच protected value देखनी हो, तो उसे अलग और जानबूझकर authenticated workflow में भेजें, जिसके access rules साफ हों। Approval card decision surface रहे, secret browser न बने।

Redaction को copy, accessibility output और audit projection में भी कायम रहना चाहिए। Visible label में "token redacted" लिखा हो लेकिन element की accessibility value में original header मौजूद हो, तो VoiceOver exfiltration path बन जाता है। Field के हर रूप की जांच करें: visible text, accessibility label, accessibility value, help text, copy-to-clipboard behavior और journal entry।

Dialog का accessibility tree भी फैसले जैसा होना चाहिए

VoiceOver designer की आंखों के रास्ते के बजाय accessibility semantics का पालन करता है। Accessibility tree को फैसले के उसी क्रम में बनाएं और फिर screen reader से verify करें। यह मानकर न चलें कि visual stack traversal तय कर देगा।

एक वास्तविक dialog या alert container इस्तेमाल करें, जिसका concise accessible title "Approval required." जैसा हो। Dialog खुलते ही focus उसके भीतर ले जाएं। Initial focus decision summary या पहले identity field पर होना चाहिए, Approve पर नहीं। अगर system focus सीधे default button पर ले जाता है, तो वह uninformed click का तेज रास्ता बनाता है और user को dialog समझने के लिए उलटे क्रम में जाना पड़ता है।

Native macOS controls पहले से उस behavior का बड़ा हिस्सा देते हैं जिसे custom views को फिर से बनाना पड़ता है। जहां संभव हो surface को native रखें: facts के लिए static text, optional detail के लिए standard disclosure control, किसी साफ तौर पर समझाए गए option को user बदल सकता हो तभी checkbox और अलग labels वाले साधारण buttons। तब accessibility inspector के पास interface से मेल खाता tree देने का बेहतर मौका होता है।

Intended order एक simple outline की तरह पढ़ी जा सके:

Dialog: Approval required
  Summary: New agent process requests authorization
  Group: Requesting process
    Static text: Signing authority, Example Software LLC
    Static text: Process, deploy-helper
  Group: Destination
    Static text: HTTPS, api.example.net
  Group: Requested action
    Static text: POST /v1/releases
  Group: Scope
    Static text: Approval lasts until this process exits
  Disclosure button: More redacted details, collapsed
  Button: Deny request
  Button: Approve this process

यह acceptance artifact है, हर sentence को एक ही accessibility label में भरने का सुझाव नहीं। Groups user को landmarks देते हैं। हर group के भीतर static text उन्हें लौटकर आने की जगह देता है। Details control collapsed हो या expanded, order स्थिर रहना चाहिए।

Buttons को पूरे नाम दें। जब एक से अधिक approval prompts काम में बाधा डाल सकते हों, तो "Approve" कमजोर label है। "Approve this process" और "Deny request" तब भी स्पष्ट रहते हैं जब VoiceOver उन्हें अकेले पढ़ता है। अगर card single-call approval और session approval दोनों देती है, तो यह अंतर button text या उससे तुरंत पहले की accessible description में बताएं। अलग visual captions वाले दो buttons का label "Allow" होना design error है।

Apple की macOS accessibility guidance apps से labels, roles, values और descriptions देने को कहती है, ताकि control का purpose समझ में आए। यहां "purpose" शब्द महत्वपूर्ण है। "Target" नाम के field में label, role और value हो सकते हैं, फिर भी user को अनुमान लगाना पड़ सकता है कि वह host, account, file या command का नाम है। ऐसे labels चुनें जिनमें छूटा हुआ noun भी हो: "SSH host," "HTTP request," "Credential used" और "Approval duration."

Dialog खुलने पर text की दीवार न सुनाएं। VoiceOver users को साफ starting point चाहिए, ऐसा paragraph नहीं जिसे रोककर item जांचना मुश्किल हो। Short summary को title region में या उसके तुरंत बाद रखें, फिर सामान्य reading commands से facts traverse करने दें। Denied request या process exit पर खत्म होने वाली approval जैसी महत्वपूर्ण changes को एक बार, सरल भाषा में announce करें।

Warning का अर्थ color और layout पर निर्भर नहीं हो सकता

Approval card तभी basic accessibility test पास करती है जब कोई व्यक्ति spoken order और keyboard controls से वही फैसला ले सके जो उसे देखकर ले सकता है। यह test केवल color contrast failures नहीं पकड़ता। इससे columns, icon placement, default focus और visual grouping से जुड़ी छिपी धारणाएं भी सामने आती हैं।

यह exercise ऐसे tester के साथ करें जो नियमित रूप से VoiceOver इस्तेमाल करता हो, केवल उस developer के साथ नहीं जिसे हर element की जगह पता हो। नया agent process शुरू करें। VoiceOver चालू करें। Pointer को controls से दूर रखें। Tester से approval या denial से पहले चार सवालों के जवाब मांगें: किसने request की, यह कहां action करेगी, क्या करेगी और approval कितनी देर चलेगी।

फिर उनसे यह sequence पूरा करने को कहें:

1. किसी sighted व्यक्ति की मदद के बिना incoming approval खोजें।
2. Process identity, destination, action और scope को क्रम से पढ़ें।
3. Details expand करके पहचानें कि interface ने कौन-सी values redact की हैं।
4. Request deny करें, फिर नई request trigger करके approve करें।
5. हर choice के बाद क्या हुआ और recorded action कहां मिलेगा, यह confirm करें।

Actual spoken sequence record करें, जिसमें repeated labels, skipped fields और focus jumps भी शामिल हों। Visual walkthrough खराब accessibility order को छोड़ सकता है, क्योंकि reviewer intended arrangement देखता है और अनजाने में gaps भर देता है। Speech recordings और written transcripts defect को नजरअंदाज करना कठिन बना देते हैं।

इन cases की अलग-अलग जांच करें:

• Signed agent process पहली session approval मांगता है।
• Unsigned local process वही request करता है।
• Session approval पहले से मौजूद होने के बाद protected credential को call के लिए confirmation चाहिए।
• Request में redacted headers या body fields हैं।
• दो requests एक-दूसरे के करीब आती हैं और denial के बाद पहली card गायब हो जाती है।

आखिरी case एक आम failure दिखाता है। Developers एक reusable view लेकर उसके labels को वहीं update कर देते हैं। Sighted व्यक्ति card बदलते हुए देख लेता है। VoiceOver button पर focus बनाए रख सकता है, जबकि उसके पीछे process, host और action बदल चुके होते हैं। Materially अलग request को fresh summary और fresh focus event वाले नए dialog की तरह लें। Existing Approve button को चुपचाप अलग अर्थ लेने न दें।

Reduced-motion settings और large text की भी जांच करें। ये settings सीधे VoiceOver semantics नहीं बदलतीं, लेकिन अक्सर alternate layout code चलाती हैं। अगर compact layout scope text को buttons के नीचे ले जाए या जगह बचाने के लिए label हटा दे, तो users ठीक उसी समय information खो देते हैं जब उनका setup interface से अधिक सहूलियत की मांग करता है।

Session approval की सीमा साफ दिखाई देनी चाहिए

Session grant तभी सुरक्षित है जब व्यक्ति ठीक-ठीक बता सके कि उसे कौन-सा running process मिला और grant कब खत्म होगा। "Remember my choice" agent के लिए गलत भाषा है, क्योंकि यह स्थायी preference जैसा सुनाई देता है, जबकि वास्तविक फैसला एक process lifetime से बंधा होना चाहिए।

Card में सीमा साफ लिखें: "This approval allows calls from this process until it exits." इसे action description के बाद रखें, जहां यह स्वाभाविक अगला सवाल हल करती है। Process बंद होकर replacement launch हो, तो card फिर दिखाएं। नए process का display name वही हो सकता है, लेकिन उसने पुराना decision अर्जित नहीं किया है।

Sallyport का per-session authorization यह काम default रूप से करता है और उसकी approval card process की code-signing authority से शुरुआत करती है। यह उपयोगी starting point है, लेकिन VoiceOver इस्तेमाल करने वाले व्यक्ति के लिए destination, action और duration भी उतने ही स्पष्ट होने चाहिए।

Per-call approval का काम अलग है। इसे उन individual credentials के लिए रखें जिनके हर इस्तेमाल का अपना असर हो, जैसे payment action, production deletion या service state बदलने वाली SSH command। Confirmation में यह बात साफ लिखी हो: "This credential requires approval for every use." इस condition को settings screen में छिपाकर user को extra prompt से surprise न करें।

हर decision को एक बड़े "allow this agent" switch के पीछे रखने वाली लोकप्रिय सलाह से बचें। यह इसलिए पसंद आती है क्योंकि autonomous work चलता रहता है। लेकिन इससे identity, target और duration एक ऐसे वादे में मिल जाते हैं कि agent ठीक व्यवहार करेगा। Agent किसी दूसरी instruction का पालन करे या किसी दूसरी service तक पहुंचे, तो इस वादे का कोई उपयोगी security meaning नहीं रह जाता। सीमित session grant और जरूरत के अनुसार per-call confirmation इंसान से वास्तविक request पर फैसला करवाते हैं।

Vault gate इस choice से बाहर होना चाहिए। Vault locked होने पर system को action सीधे रोक देना चाहिए, ऐसी approval card नहीं दिखानी चाहिए जिससे लगे कि click lock को override कर सकता है। जहां product support करता हो, वहां Touch ID action unlock या confirm कर सकती है, लेकिन spoken interface को बताना होगा कि कौन-सी घटना हुई। "Approved" और "vault unlocked" अलग state changes हैं और इन्हें कभी एक अस्पष्ट announcement में न मिलाएं।

Audit records से बाद में पूरा फैसला समझ में आना चाहिए

अगर operator बाद में यह नहीं बता सकता कि उसने कौन-सी request approve की, उसके बाद कौन-सा action हुआ और record बदला है या नहीं, तो approval flow अधूरा है। Immediate card consent संभालती है। Audit trail उस बाद में आने वाले सवाल को संभालती है, अक्सर तब जब किसी को याद नहीं रहता कि screen पर क्या दिखा था।

Session event और individual action event को अलग रखें। Session record में agent run, उसका authorization decision और revocation या exit की पहचान होनी चाहिए। Activity record में हर HTTP या SSH call, उसका destination, operation, result और approval view में इस्तेमाल हुए वही redaction rules होने चाहिए। दोनों को एक अस्पष्ट "agent allowed" entry में मिलाने से consent और consequence का संबंध खो जाता है।

Hash-chained encrypted journal के लिए verification एक अलग और inspectable act होनी चाहिए। Expected shape सरल है:

$ sp audit verify
Verifying encrypted audit log...
Chain verified: 184 records
Result: valid

Exact record count बदलता रहेगा, लेकिन command को operator को बताना चाहिए कि verification सफल हुई या विफल, और broken chain मिलने पर उसे साफ तौर पर fail होना चाहिए। Ciphertext पर verification महत्वपूर्ण है, क्योंकि reviewer audit evidence पढ़ने के लिए vault unlock किए बिना log integrity जांच सकता है। इससे यह साबित नहीं होता कि approved action समझदारी भरा था। यह साबित होता है कि सुरक्षित रखा गया sequence चुपचाप बदला नहीं गया।

Approval card और journals को एक ही event vocabulary से बनाएं। Card में "HTTPS request to billing.example.net" लिखा हो और journal में उसे "remote operation 12" कहा जाए, तो user decision को record से मिला नहीं पाएगा। Destination, action, process identity, scope और redaction categories को दोबारा इस्तेमाल करें, भले हर surface उन्हें अलग detail level पर दिखाए।

VoiceOver users को record तक उतना ही सीधा रास्ता दें। Approval या denial के बाद result announce करें और संबंधित session या activity entry तक पहुंचने का labeled route दें। Action हुआ, इसका proof colored status dot पर न छोड़ें। "Request denied. Activity record available" सुनने वाला user interface को याद से दोबारा बनाए बिना बाद में outcome जांच सकता है।

Accessibility regressions security test suite का हिस्सा हैं

Spoken approval sequence को security contract की तरह लें और card, action channel या identity model बदलने पर हर बार test करें। ऐसा snapshot जो title और दो buttons की मौजूदगी की पुष्टि करता है, वह destination के controls के नीचे चले जाने या accessibility value से redacted field leak होने को नहीं पकड़ पाएगा।

जानबूझकर कठिन requests वाला छोटा fixture set रखें: लंबी signing authority, unsigned process, internationalized hostname, nonstandard port, अलग host पर redirect, SSH alias और sensitive field names वाला body। हर fixture से expected accessibility outline और expected journal representation बननी चाहिए। Designer visual layout बदले, तो काम पूरा मानने से पहले इन outputs की तुलना करें।

एक व्यावहारिक review चार सीधे सवाल पूछती है। क्या VoiceOver user executable और signer पहचान सकता है? क्या वह final remote destination पहचान सकता है? क्या वह इस call और इस process lifetime का अंतर समझ सकता है? क्या वह बाद में साफ result सुनते हुए approve या deny कर सकता है? अगर किसी जवाब के लिए color, spacing या icon देखना जरूरी है, तो prompt में अभी भी security defect है।

पहला test उस credential पर करें जिसका असर सबसे बड़ा हो और उस request पर जो आपका product सबसे कम सहयोगी तरीके से स्वीकार करता हो। किसी परिचित host को भेजी जाने वाली friendly GET हर approval card को अच्छा दिखाती है। Design की असली परीक्षा तब होती है जब कोई अपरिचित signed process real service में बदलाव करने की मांग करे और उसके body के कुछ हिस्से redacted हों। वहीं wording, order और focus behavior तय करते हैं कि व्यक्ति अपने नियंत्रण का इस्तेमाल कर पाएगा या gate पर बस click करता रह जाएगा।