React और Flutter UI रिव्यू के लिए एक्सेसिबिलिटी प्रॉम्प्ट

लोग क्या मिस कर देते हैं जब वे UI को एक्सेसिबल बनाने की कोशिश करते हैं

अधिकांश एक्सेसिबिलिटी समस्याएँ बड़े रीडिज़ाइन की वजह से नहीं होतीं। ये छोटे-छोटे विवरण होते हैं जो तय करते हैं कि कोई आपकी UI का उपयोग कर पाएगा या नहीं।

आमतौर पर सबसे पहले क्या टूटता है, यह काफी हद तक एक जैसा होता है। पेज ठीक दिख सकता है, एक त्वरित विजुअल चेक पास कर सकता है, और फिर भी कीबोर्ड या स्क्रीन रीडर के साथ उपयोग करने में मुश्किल हो सकता है।

यहाँ वे शुरुआती स्थान हैं जहाँ UI अक्सर फेल होते हैं:

• कीबोर्ड एक्सेस: आप प्रमुख कंट्रोल तक नहीं पहुंच पाते, या किसी मोडल में फंस जाते हैं
• फोकस ऑर्डर और फोकस स्टेट्स: फोकस इधर-उधर कूदता है, या आप नहीं देख पाते कि आप कहाँ हैं
• लेबल और नाम: इनपुट्स और बटन के अस्पष्ट या गुम नाम होते हैं
• घोषणाएँ: डायनामिक अपडेट्स होते हैं लेकिन स्क्रीन रीडर को सूचित नहीं किया जाता
• कंट्रास्ट और स्पष्टता: टेक्स्ट, आइकन और एरर स्टेट्स पढ़ने में कठिन होते हैं

मुश्किल हिस्सा यह है कि regressions बहुत आसानी से आ जाते हैं। एक “छोटा” बदलाव—जैसे बटन को आइकन से बदलना, कार्ड को जेस्चर हैंडलर में रैप करना, या एक कस्टम ड्रॉपडाउन जोड़ना—कीबोर्ड समर्थन हटा सकता है, फोकस ऑर्डर तोड़ सकता है, या किसी लेबल को गायब कर सकता है बिना किसी के नोटिस के।

एक आम परिदृश्य: एक React फॉर्म में एक नया “clear” आइकन इनपुट के अंदर जोड़ दिया जाता है। यह मददगार लगता है, पर आइकन फोकस करने योग्य नहीं है, उसका कोई नाम नहीं है, और वह क्लिक इवेंट्स ले लेता है। अब कीबोर्ड यूज़र्स इसे सक्रिय नहीं कर सकते, और स्क्रीन रीडर यूज़र्स एक अनलेबल्ड कंट्रोल सुनते हैं।

यह पोस्ट आपको दो चीज़ें देती है: कॉपी करने योग्य प्रॉम्प्ट जो आप अपने UI कोड (React और Flutter) के साथ उपयोग कर सकते हैं, और एक दोहराने योग्य रिव्यू फ्लो जो आप मिनटों में चला सकते हैं। लक्ष्य दिन एक पर परिपूर्णता नहीं है—बल्कि उन समस्याओं को पकड़ना है जो असल यूज़र्स को ब्लॉक करती हैं।

यदि आप प्रोडक्ट स्क्रीन बनाते हैं पर एक्सेसिबिलिटी स्पेशलिस्ट नहीं हैं, तो यह आपके लिए है। यह उन टीमों के लिए भी फिट बैठता है जो vibe-coding टूल्स जैसे Koder.ai इस्तेमाल करती हैं, जहाँ UI बदलते तेज़ी से बनते हैं और आपको जल्दी, संगत चेक चाहिए होते हैं। यदि आप एक व्यावहारिक शुरुआत चाहते हैं, तो ये React और Flutter UI रिव्यू के लिए एक्सेसिबिलिटी प्रॉम्प्ट हर बार रीयूज़ करने के लिए डिज़ाइन किए गए हैं।

वे 5 चेक जो ज्यादातर मुद्दों को जल्दी पकड़ते हैं

यदि आपके पास किसी स्क्रीन की समीक्षा के लिए केवल 15 मिनट हैं, तो ये चेक उन समस्याओं को ढूँढते हैं जो सबसे अक्सर यूज़र्स को ब्लॉक करती हैं। ये React और Flutter दोनों पर काम करते हैं, और ये समीक्षा फ्लोज़ में अच्छे से फिट होते हैं।

1) क्या आप इसे सिर्फ कीबोर्ड से उपयोग कर सकते हैं?

पेज पर बिना माउस के नेविगेट करने की कोशिश करें। Tab और Shift+Tab से मूव करें, Enter और Space से सक्रिय करें, और जहाँ कोई विजेट मेनू, टैब, या लिस्ट जैसा दिखे वहाँ एरो कीज़ इस्तेमाल करें।

एक तेज संकेत: यदि आप किसी मोडल में फंस जाते हैं, या किसी प्रमुख कंट्रोल (जैसे “Close”) तक नहीं पहुँच पाते, तो कुछ गड़बड़ है।

2) क्या फोकस ऑर्डर समझदारी से है और फोकस दिखाई देता है?

जैसे ही आप tab करते हैं, फोकस को विज़ुअल लेआउट (ऊपर से नीचे, बाएँ से दाएँ) के अनुसार चलना चाहिए और कभी छिपे हुए एरिया पर न जाना चाहिए। फोकस स्पष्ट भी होना चाहिए। यदि डिज़ाइन सूक्ष्म आउटलाइन इस्तेमाल करता है, तो सुनिश्चित करें कि वे लाइट और डार्क दोनों बैकग्राउंड पर दिखाई दें।

3) क्या कंट्रोल्स के स्पष्ट नाम हैं?

एक स्क्रीन रीडर को हर इंटरैक्टिव एलिमेंट के लिए उपयोगी नाम announce करना चाहिए। सिर्फ “Button” काफी नहीं है। आइकन को एक्सेसिबल लेबल चाहिए, और फ़ॉर्म फ़ील्ड्स का लेबल तब भी जुड़ा रहना चाहिए जब placeholder गायब हो जाए।

4) क्या कंट्रास्ट और टेक्स्ट साइज ठीक हैं?

छोटे टेक्स्ट, डिसेबल्ड टेक्स्ट, और रंगीन बटनों पर टेक्स्ट चेक करें। ज़ूम भी टेस्ट करें: फ़ॉन्ट साइज बढ़ाएँ और सुनिश्चित करें कि लेआउट ओवरलैप न करे या प्रमुख कंटेंट कट न हो।

5) क्या बदलाव स्पष्ट रूप से announce होते हैं?

जब कुछ बदलता है (त्रुटि, लोडिंग, सफलता), तो यूज़र्स को अनुमान नहीं लगाना चाहिए। फ़ील्ड के पास इनलाइन एरर टेक्स्ट का उपयोग करें, फ़ॉर्म त्रुटियों की घोषणा करें, और लोडिंग स्टेट्स को स्पष्ट बनाएं।

यदि आप Koder.ai में स्क्रीन बनाते हैं, तो उससे कहें: “इस पेज के लिए कीबोर्ड-ओनली फ्लो, फोकस ऑर्डर, और स्क्रीन रीडर लेबल सत्यापित करें,” और फिर ऊपर दिए गए स्टेप्स का उपयोग कर परिणाम की समीक्षा करें।

UI बदलने से पहले अपना रिव्यू स्कोप सेट करें

जब आप यह तय कर लें कि आप क्या रिव्यू कर रहे हैं और “पर्याप्त” का क्या अर्थ है, तो एक्सेसिबिलिटी का काम तेज़ होता है। एक तंग स्कोप भी React और Flutter UI समीक्षाओं के लिए एक्सेसिबिलिटी प्रॉम्प्ट्स को अधिक उपयोगी बनाता है, क्योंकि मॉडल असली स्क्रीन और असली इंटरैक्शन्स पर ध्यान दे सकता है।

जिन जर्नीज़ का चयन करें जो मायने रखती हैं

पूरा प्रोडक्ट न चुनें—2 से 4 महत्वपूर्ण यूजर जर्नीज़ से शुरू करें। अच्छे विकल्प वे होते हैं जिन्हें पूरा किए बिना यूज़र्स वैल्यू नहीं पा सकते या जो फेल होने पर यूज़र को लॉक कर सकते हैं।

अधिकतर ऐप्स के लिए, यह कुछ इस तरह होगा: लॉगिन, एक प्राथमिक "क्रिएट या खरीद" फ्लो (चेकआउट, बुकिंग, सबमिट), और एक अकाउंट एरिया जैसे सेटिंग्स या प्रोफ़ाइल।

फिर हर जर्नी की सटीक स्क्रीनें लिखें (भले ही सिर्फ 5 से 8 स्क्रीन हों)। "बीच के" स्टेट्स भी शामिल करें: एरर मैसेज, खाली स्टेट्स, लोडिंग स्टेट्स, और कन्फ़र्मेशन डायलॉग्स। यहीं अक्सर फोकस और स्क्रीन रीडर आउटपुट टूटते हैं।

एक ठोस उदाहरण: यदि आप Koder.ai में एक छोटा CRM स्क्रीन बना रहे हैं, तो इसे scope करें: “sign in -> open Contacts -> add contact -> save -> see success message.” यह single flow फ़ॉर्म्स, वैलिडेशन, डायलॉग्स और घोषणाओं को छूता है।

तय करें कि “पास” का क्या मतलब है

व्यावहारिक रहें। WCAG AA जैसी अपेक्षाओं का लक्ष्य रखें, पर उसे सरल चेक्स में ट्रांसलेट करें जिन्हें आप जल्दी लागू कर सकें: कीबोर्ड एंड-टू-एंड काम करे, फोकस दिखाई दे और तार्किक हो, नाम और लेबल समझदार हों, और कंट्रास्ट पढ़ने योग्य हो।

सरल पास/फेल नोट फॉर्मेट का उपयोग करें ताकि बहस में समय न बर्बाद हो। हर स्क्रीन के लिए कैप्चर करें:

• Check: (keyboard, focus order, labels, contrast, announcements)
• Result: Pass या Fail
• Evidence: एक वाक्य में क्या हुआ इसका वर्णन
• Fix guess: क्या बदलने की ज़रूरत है (component, prop, styling)
• Retest: फ़िक्स के बाद क्या आज़माना है

यह रिव्यू React और Flutter दोनों पर सुसंगत रखता है और यह किसी और को बिना दोहराए समस्या देने में आसान बनाता है।

React कंपोनेंट्स के लिए कॉपी करने योग्य प्रॉम्प्ट्स (कीबोर्ड, लेबल, रोल्स)

जब आप एक्सेसिबिलिटी रिव्यू पूछते हैं, तो सबसे तेज़ जीतें स्पेसिफिक होने से मिलती हैं: कौन सा कंपोनेंट, कौन सी यूज़र क्रिया, और "अच्छा" कैसा दिखता है। ये प्रॉम्प्ट तभी सबसे अच्छे काम करते हैं जब आप कंपोनेंट कोड और एक छोटा वर्णन पेस्ट करें कि UI क्या करना चाहिए।

यदि आप चैट-आधारित बिल्डर जैसे Koder.ai का उपयोग कर रहे हैं, तो स्क्रीन या कंपोनेंट जनरेट करने के तुरंत बाद प्रॉम्प्ट जोड़ें ताकि मुद्दे पूरे ऐप में फैलने से पहले ठीक हो जाएँ।

Review this React component for keyboard navigation issues. 
- Can every interactive element be reached with Tab and activated with Enter/Space?
- List the exact problems you see in the code.
- Propose fixes with small code edits.

Check focus order and focus visibility.
- Describe the expected focus order for a keyboard-only user.
- Point out where focus could get lost (modals, menus, drawers).
- Tell me exactly where to add :focus-visible styles (which elements, which CSS).

Find missing accessible names.
- Identify inputs, buttons, and icons without clear labels.
- Suggest label + htmlFor, aria-label, aria-labelledby, or visible text.
- If there is helper/error text, connect it with aria-describedby.

Identify interactive elements that are not buttons/links.
- Find div/span with onClick, custom dropdowns, and clickable cards.
- Suggest correct semantics (button/a) or add role, tabIndex, and keyboard handlers.

List screen reader announcements that will be confusing.
- Predict what a screen reader will announce for key controls.
- Rewrite UI text to be shorter and clearer.
- Suggest aria-live usage for status changes (loading, errors, saved).

प्रॉम्प्ट भेजने से पहले ये विवरण शामिल करें ताकि आप सामान्य सलाह नहीं बल्कि इस्तेमाल योग्य फिक्स पाएं:

• कंपोनेंट क्या है (उदाहरण: “login form”, “pricing toggle”, “settings modal”).
• कीबोर्ड पाथ जो यूज़र्स को फॉलो करनी चाहिए (स्टार्ट पॉइंट और एंड पॉइंट).
• कोई UI लाइब्रेरी जो उपयोग हो रही है (MUI, Chakra, Radix, custom components).
• टेस्ट करने के लिए स्टेट्स (loading, error, disabled, empty results).
• एक ठोस यूजर लक्ष्य (उदाहरण: “change plan and confirm”).

Flutter विगेट्स के लिए कॉपी करने योग्य प्रॉम्प्ट्स (Semantics, फोकस, जेस्चर्स)

यदि आप सुसंगत परिणाम चाहते हैं, तो एक विगेट स्निपेट (या पूरी स्क्रीन) पेस्ट करें और खास चेक माँगें। ये प्रॉम्प्ट तब सबसे अच्छे काम करते हैं जब आप विगेट ट्री, स्क्रीन तक पहुँचने का तरीका, और कोई कस्टम जेस्चर्स शामिल करें।

ऐसे प्रॉम्प्ट्स जो आप रिव्यू में पेस्ट कर सकते हैं

Review this Flutter widget tree for keyboard navigation and focus traversal.
Call out focus traps, missing focus order, and places where Tab/Shift+Tab will feel confusing.
Suggest exact widget changes (Focus, FocusTraversalGroup, Shortcuts, Actions).

Check this screen for missing Semantics labels, hints, and tap targets.
Point to the exact widgets that need Semantics(label/hint), tooltip, or exclusion.
Also flag controls under 48x48 logical pixels and suggest fixes.

Find custom gestures that break accessibility (GestureDetector/Listener).
Replace them with accessible widgets or add keyboard + semantics support.
If a gesture is required, describe how a keyboard user triggers the same action.

Audit error messages and validation on this form.
What should be announced to a screen reader, and when?
Suggest how to expose errors via Semantics and focus movement after submit.

Propose a consistent focus highlight style across screens.
It should be obvious on dark/light themes and work with keyboard navigation.
Show a small code example using FocusTheme/ThemeData.

असिस्टेंट द्वारा सुझाए जाने वाले त्वरित फिक्स

उम्मीद रखें कि उत्तर कुछ ठोस पैटर्न का उल्लेख करेंगे:

• मुख्य कंटेंट को FocusTraversalGroup में रैप करें और जहाँ ज़रूरी हो FocusTraversalOrder सेट करें।
• सम्मिलित कंट्रोल्स के लिए Semantics (या MergeSemantics) का उपयोग करें और डुप्लीकेट लेबल्स से बचें।
• कच्चे GestureDetector के बजाय InkWell, IconButton, ListTile, SwitchListTile जैसी सुविधाजनक विजेट्स पसंद करें।
• गैर-टेक्स्ट इनपुट्स के लिए Shortcuts + Actions जोड़ें (उदाहरण: Enter से सक्रिय करें, Escape से बंद करें)।

कस्टम कार्ड को बटन जैसा व्यवहार करवाने का एक न्यूनतम उदाहरण:

Semantics(
  button: true,
  label: 'Add payment method',
  hint: 'Opens the add card screen',
  child: Focus(
    child: InkWell(
      onTap: onPressed,
      child: Card(child: child),
    ),
  ),
)

चरण-दर-चरण: एक सरल कीबोर्ड और फोकस रिव्यू फ्लो

एक तेज़ कीबोर्ड और फोकस रिव्यू उन समस्याओं को पकड़ता है जो स्क्रीन रीडर्स और स्विच डिवाइसेज़ को भी प्रभावित करती हैं। इसे एक वास्तविक पेज फ्लो पर करें (सिर्फ एक बटन नहीं), और चलते हुए नोट रखें ताकि आप बाद में उसी पाथ को दोबारा चेक कर सकें।

5-स्टेप फ्लो

सबसे पहले एक “हैप्पी पाथ” चुनें जो यूज़र लेगा, जैसे साइन इन करना, सेटिंग्स स्क्रीन खोलना, और सेव करना।

1. पूरे फ्लो को सिर्फ कीबोर्ड से करें। माउस को अलग रखें। Tab और Shift+Tab से मूव करें, Enter और Space से सक्रिय करें, और जहाँ जरूरी हो एरो कीज़ का प्रयोग करें। यदि कुछ क्लिक या स्वाइप माँगता है, उसे मार्क करें।
2. सुनिश्चित करें कि फोकस हमेशा स्पष्ट हो। हर बार जब फोकस मूव करे, आपको तुरंत दिखना चाहिए कि यह कहाँ है। पतली आउटलाइन जो डार्क बैकग्राउंड पर गायब हो जाती है, CSS द्वारा हटाई गई फोकस रिंग, या Flutter विजेट्स जो “एक्टिव” दिखते हैं पर फोकस नहीं दिखाते, इन पर ध्यान दें।
3. ऑर्डर यह देखें कि वह जो आप देखते हैं उससे मेल खाता है। फोकस को विजुअल लेआउट और रीडिंग ऑर्डर के अनुसार चलना चाहिए। आम चेतावनियाँ: फुटर पर कूद जाना, साइडबार में फंस जाना, या किसी फ़ील्ड को स्किप कर देना क्योंकि वह फोकस करने योग्य नहीं है।
4. ओवरलेज़ को स्ट्रेस-टेस्ट करें। मेन्यू, डायलॉग और ड्रॉअर खोलें। फोकस को ओवरले के अंदर आना चाहिए, खुला रहने पर अंदर ही रहना चाहिए, और बंद होने पर एक समझदारी भरी जगह पर लौटना चाहिए। Escape से ओवरले को बंद होना चाहिए जहाँ उपयुक्त हो।
5. हर बदलाव के बाद री-टेस्ट करें। एक मुद्दा ठीक करें, फिर वही पाथ दोबारा चलाएँ। देखें क्या बेहतर हुआ और क्या खराब हुआ—खासकर फोकस ऑर्डर में परिवर्तन और नए “डेड एंड्स”।

चलते हुए क्या रिकॉर्ड करें

साधारण रखें: पेज का नाम, आपने क्या दबाया, क्या हुआ, और आप क्या अपेक्षा कर रहे थे। यह छोटा लॉग यह सुनिश्चित करने में आसान बनाता है कि React रिफैक्टर या Flutter विगेट स्वैप ने कीबोर्ड एक्सेस चुपचाप तोड़ा नहीं है।

स्क्रीन रीडर-फ्रेंडली नाम, लेबल और घोषणाएँ

स्क्रीन रीडर्स आपकी UI को “नहीं देखते” — वे नाम, रोल, और छोटे संदेशों पर निर्भर करते हैं जो बताते हैं कि क्या बदला। अगर नाम गुम या अस्पष्ट है, तो ऐप अनुमान लगाने जैसा बन जाता है।

फ़ॉर्म फ़ील्ड्स से शुरू करें। हर इनपुट को एक असली लेबल चाहिए जो तब भी सही रहे जब फ़ील्ड भरी हो। प्लेसहोल्डर संकेत होते हैं, लेबल नहीं, और अक्सर जैसे ही यूज़र टाइप करता है गायब हो जाते हैं।

आइकन-ओनली एक्शन्स एक और सामान्य चूक हैं। ट्रैश आइकन, पेंसिल, या तीन-डॉट मेन्यू को एक अर्थपूर्ण नाम चाहिए जो परिणाम बताए, न कि सिर्फ आकृति। “Delete project” “Button” या “Trash” से बेहतर है।

हैडिंग्स और सेक्शन लेबल्स मायने रखते हैं क्योंकि वे पेज का आउटलाइन बन जाते हैं। स्क्रीन रीडर यूज़र हैडिंग्स से कूद कर “Billing” या “Team members” जैसे सेक्शन ढूँढते हैं, इसलिए ये लेबल्स उस सेक्शन की सामग्री से मेल खाने चाहिए।

एरर मैसेज्स को स्पष्ट और actionable रखें। “Invalid input” पर्याप्त नहीं है। बताएं कि क्या गलत हुआ और अगला कदम क्या है, जैसे “Password must be at least 12 characters” या “Email address is missing the @ sign”。

कॉपी करने योग्य रिव्यू प्रॉम्प्ट्स (React और Flutter)

इन प्रॉम्प्ट्स का उपयोग स्क्रीन की समीक्षा करते समय करें (या जब आप Koder.ai जैसे टूल से कंपोनेंट अपडेट करवाना चाहें):

• “इस स्क्रीन की जाँच करें और सुनिश्चित करें कि हर टेक्स्ट इनपुट का एक दिखने वाला लेबल है, और एक्सेसिबल नाम उससे मेल खाता है (React: label + htmlFor, aria-labelledby; Flutter: InputDecoration.labelText)।”
• “आइकन-ओनली बटन्स ढूँढें और हर एक को एक अर्थपूर्ण नाम दें जो क्रिया बताये (React: aria-label; Flutter: Tooltip या Semantics(label: ...)).”
• “हैडिंग्स चेक करें: React में सही हेडिंग लेवल्स का उपयोग करें, और Flutter में स्पष्ट सेक्शन टाइटल्स ताकि स्ट्रक्चर सही पढ़े।”
• “वैलीडेशन एरर्स को फिर से लिखें ताकि वे क्या हुआ और कैसे ठीक करें बताएँ, और सुनिश्चित करें कि एरर दिखाई देने पर announce हो।

डायनामिक अपडेट्स की घोषणाएँ

कई स्क्रीन बिना पेज रीलोड के बदलती हैं: प्रोफ़ाइल सेव करना, आइटम जोड़ना, रिज़ल्ट्स लोड करना। सुनिश्चित करें कि इन अपडेट्स की घोषणाएँ हों।

React के लिए, aria-live रीजन पसंद करें ("polite" सामान्य संदेशों के लिए, "assertive" गंभीर त्रुटियों के लिए)। Flutter में, Semantics और स्टेटस संदेशों को दिखाएँ (उदा. एक बैनर या SnackBar) ताकि वे पढ़े जाएँ, सिर्फ दिखाई न दें। एक तेज़ जाँच: “Save” ट्रिगर करें, और पुष्टि करें कि आप एक छोटा संदेश सुनते हैं जैसे “Changes saved” बिना फोकस को बंटाए।

कंट्रास्ट और विज़ुअल स्पष्टता चेक जो लंबे समय नहीं लेते

यदि आप उन जगहों पर ध्यान दें जहाँ लोग वास्तव में संघर्ष करते हैं—छोटा टेक्स्ट, आइकन, फोकस रिंग्स, और स्टेट कलर्स—तो आप मिनटों में अधिकांश कंट्रास्ट समस्याएँ पकड़ सकते हैं। यह React और Flutter UI रिव्यू के एक्सेसिबिलिटी प्रॉम्प्ट्स का व्यावहारिक हिस्सा है क्योंकि इसे वेरिफ़ाई करना आसान है और फिक्स भी आसान है।

10-मिनट कंट्रास्ट पास

एक स्क्रीन को 100% ज़ूम पर और फिर 200% पर स्कैन करके शुरू करें। यदि कुछ पढ़ने में कठिन हो जाता है, तो अक्सर यह कंट्रास्ट, वजन, या स्पेसिंग की समस्या होती है, न कि यूज़र की।

पहले ये पाँच जगहें चेक करें:

• बॉडी टेक्स्ट, कैप्शन, और हेल्पर टेक्स्ट (खासकर सफेद पर हल्का ग्रे)
• डिसेबल्ड स्टेट्स (डिसेबल्ड दिखना चाहिए पर पढ़ने योग्य भी होना चाहिए)
• बिना लेबल वाले आइकन (फीका आइकन कई यूज़र्स के लिए लगभग अदृश्य है)
• फोकस इंडिकेटर्स (रिंग/आउटलाइन बैकग्राउंड से अलग दिखनी चाहिए)
• एरर और सक्सेस मैसेज (सिर्फ रंग पर निर्भर न रहें—टेक्स्ट और आइकन भी शामिल करें)

एक जल्दी नियम: अगर आपको तिरछा देखकर पढ़ने में मुश्किल हो रही हो, तो आपके यूज़र्स को भी होगी। यदि आप रंग जोड़ी के बारे में सुनिश्चित नहीं हैं, तो अस्थायी रूप से टेक्स्ट को शुद्ध काले या शुद्ध सफेद में बदलकर देखें—यदि पठनीयता कूदती है, तो कंट्रास्ट कम था।

फोकस विजिबिलिटी अक्सर छूटी रहती है। सुनिश्चित करें कि फोकस आउटलाइन पर्याप्त मोटी है और बैकग्राउंड के समान रंग न हो। यदि किसी सूची में “चयनित” स्टेट है, तो वह ग्रेस्केल में भी अलग दिखना चाहिए—उदाहरण के तौर पर आइकन, अंडरलाइन, या स्पष्ट बॉर्डर जोड़कर।

मोबाइल स्पष्टता: टारगेट और थीम्स

मोबाइल पर विज़ुअल स्पष्टता टच के बारे में भी है। बटन और आइकन-ओनली एक्शन्स के पास पर्याप्त टैप टारगेट और स्पेसिंग होने चाहिए ताकि यूज़र्स गलत कंट्रोल न दबाएँ।

एक तेज़ थीम स्वीप करें: डार्क मोड टॉगल करें, और यदि ऐप हाई कंट्रास्ट समर्थन करता है तो उसे भी जाँचें। सतहों, डिवाइडर्स, और फोकस रिंग्स पर टेक्स्ट फिर से चेक करें। एक आम बग यह है कि डार्क मोड में फोकस रिंग गायब हो जाता है या एक इनएक्टिव आइकन बैकग्राउंड के लगभग समान रंग का हो जाता है।

यदि आप Koder.ai जैसे टूल में तेज़ी से UI जनरेट कर रहे हैं, तो एक अतिरिक्त रिव्यू स्टेप जोड़ें: "पहले लेआउट के बाद कंट्रास्ट और फोकस रिंग पास" माँगें, विज़ुअल पॉलिशिंग से पहले।

बार-बार आने वाली सामान्य गलतियाँ

अधिकांश एक्सेसिबिलिटी बग़ बार-बार रिपीट होते हैं क्योंकि वे छोटे UI ट्वीक की तरह लगते हैं, न कि प्रोडक्ट बिहेवियर। जब आप React और Flutter UI रिव्यू के लिए एक्सेसिबिलिटी प्रॉम्प्ट्स चलाते हैं, तो सबसे पहले इन पैटर्न्स पर ध्यान दें।

प्लेसहोल्डर टेक्स्ट लेबल नहीं है। प्लेसहोल्डर जैसे ही कोई टाइप करता है गायब हो जाता है, और कई स्क्रीन रीडर्स इसे फ़ील्ड का नाम नहीं मानते। वास्तविक दृश्य लेबल (या एक स्पष्ट एक्सेसिबल नाम) का उपयोग करें ताकि फ़ील्ड खाली, भरी, और एरर्स दिखने पर समझ में आए।

फोकस स्टाइल्स को इसलिए हटा दिया जाता है क्योंकि “वे भद्दे लगते हैं।” यह अक्सर कीबोर्ड यूज़र्स को खो देता है। यदि आप डिफ़ॉल्ट आउटलाइन बदल रहे हैं, तो उसे कुछ समान स्पष्टता वाला बदल दें: एक मजबूत रिंग, पृष्ठभूमि परिवर्तन, और पृष्ठभूमि के मुकाबले पर्याप्त कंट्रास्ट।

एक और बार-बार वाला दोष फेक बटन होते हैं। React में div के साथ onClick इस्तेमाल करना और Flutter में Container के साथ GestureDetector का इस्तेमाल करना लुभावना होता है। उचित semantics के बिना कीबोर्ड सपोर्ट और स्क्रीन रीडर्स प्रभावित होते हैं। नेटिव कंट्रोल्स (button, a, TextButton, ElevatedButton) आपको फोकस, रोल, डिसेबल्ड स्टेट, और सक्रियण व्यवहार मुफ्त में देते हैं।

डायलॉग और फ़ॉर्म फोकस बग सूक्ष्म परंतु कष्टप्रद होते हैं। मोडल बंद करने या फॉर्म सेव करने के बाद अक्सर फोकस पेज के शीर्ष पर कूद जाता है या गायब हो जाता है। यह इसलिए होता है क्योंकि फोकस उस कंट्रोल पर वापस नहीं रखा गया जिसने डायलॉग खोला था, या सेव एक्शन स्क्रीन को रेंडर कर देता है और फोकस ड्रॉप हो जाता है। यूज़र्स को फिर से वे स्थान खोजने के लिए शुरुआत करनी पड़ती है।

ARIA (या Flutter Semantics) का ओवरयूज़ भी चीज़ें तोड़ सकता है। हर जगह रोल्स और लेबल्स जोड़ने से नेटिव एलिमेंट जो पहले से प्रदान कर रहे हैं उनके साथ टकराव हो सकता है, जिससे डबल घोषणाएँ या गलत नाम मिल सकता है।

एक तेज़ “दोहराए जाने वाले मुद्दे” चेक जो आप किसी स्क्रीन की समीक्षा करते समय माँग सकते हैं:

• पुष्टि करें कि हर इनपुट का एक स्थायी लेबल है, सिर्फ प्लेसहोल्डर नहीं
• पुष्टि करें कि हर इंटरैक्टिव एलिमेंट एक वास्तविक कंट्रोल है और सही रोल है
• पुष्टि करें कि फोकस हमेशा दिखाई देता है और बिना रिप्लेसमेंट के हटाया नहीं जाता
• पुष्टि करें कि डायलॉग्स, टोस्ट्स, और सेव के बाद फोकस ट्रिगर पर लौटता है
• पुष्टि करें कि ARIA/Semantics सिर्फ वही जोड़ता है जो नेटिव कंट्रोल नहीं दे पाते

यदि आप चैट से UI जेनरेट करते हैं (उदा. Koder.ai), तो इन्हें अपने प्रॉम्प्ट में एक्सेप्टेंस क्राइटेरिया के रूप में शामिल करें ताकि पहला ड्राफ्ट ही आम ट्रैप्स से बच सके।

उदाहरण वॉक-थ्रू: एक स्क्रीन, एंड-टू-एंड

एक सरल Settings स्क्रीन की कल्पना करें: एक प्रोफ़ाइल फ़ॉर्म (Name, Email), दो टॉगल्स (Email notifications, Dark mode), एक “Save changes” बटन, और सेव के बाद एक टोस्ट जो दिखाई देता है।

कीबोर्ड से शुरू करें। अपेक्षित फोकस ऑर्डर विजुअल ऑर्डर से मेल खाना चाहिए, ऊपर से नीचे, बाएं से दाएं। Tabbing को कभी टोस्ट एरिया, फुटर, या छिपे मेन्यू में नहीं कूदना चाहिए।

एक त्वरित पास जो अधिकांश React और Flutter UI रिव्यू प्रॉम्प्ट्स के लिए काम करता है:

• ऊपर से Tab दबाएँ: फोकस Name पर आए, फिर Email, फिर Email notifications टॉगल, फिर Dark mode टॉगल, फिर Save changes।
• Shift+Tab करके वापस जाएँ और पुष्टि करें कि यह साफ़-सुथरे ढंग से उल्टा हो जाता है।
• टॉगल्स पर Space से टॉगल होना चाहिए। एरो कीज़ फोकस को ट्रैप न करें।
• Save changes पर Enter से सबमिट होना चाहिए, और सबमिट के बाद फोकस गायब नहीं होना चाहिए।
• जब टोस्ट दिखाई दे, तो फोकस वहीं रहना चाहिए जहाँ वह था जब तक टोस्ट में कोई कार्रवाई आवश्यक न हो (जैसे “Undo”)।

अब देखें कि स्क्रीन रीडर क्या announce करता है। हर कंट्रोल को एक स्पष्ट नाम, रोल, और स्थिति चाहिए। उदाहरण: “Name, text field, required” और “Email notifications, switch, on”。 यदि Email फ़ील्ड में त्रुटि है, तो उसे फ़ील्ड में प्रवेश करते समय और जब त्रुटि दिखाई दे तब announce किया जाना चाहिए (उदा.: “Email, text field, invalid, Enter a valid email address”)। Save बटन को “Save changes, button” के रूप में पढ़ना चाहिए और वह केवल तभी disabled होना चाहिए जब आप यह कारण भी बताते हों।

कंट्रास्ट के लिए, सामान्य टेक्स्ट, प्लेसहोल्डर टेक्स्ट, और एरर मैसेजेज़ चेक करें। फोकस रिंग भी दोनों लाइट और डार्क बैकग्राउंड पर आसान से दिखनी चाहिए। एरर स्टेट्स सिर्फ लाल रंग पर निर्भर नहीं होने चाहिए। एक आइकन, स्पष्ट टेक्स्ट, या दोनों जोड़ें।

जो आप पाते हैं उसे एक छोटे फिक्स लिस्ट में बदल दें:

• फोकस ऑर्डर ठीक करें ताकि यह लेआउट से मैच करे।
• टॉगल्स और आइकन के लिए गायब एक्सेसिबल नाम जोड़ें।
• एरर को फ़ील्ड के साथ announce करें (सिर्फ़ बैनर के रूप में नहीं)।
• फोकस स्टाइल और कम-कॉन्ट्रास्ट प्लेसहोल्डर/एरर टेक्स्ट सुधारें।
• टोस्ट को नॉन-ब्लॉकिंग बनाएं, या केवल तभी फोकस करने योग्य रखें जब उसमें एक्शन हो।

यदि आप Koder.ai में बना रहे हैं, तो इस स्क्रीन का वर्णन और आपकी खोजें चैट में पेस्ट करें और उससे React या Flutter UI को अपेक्षित कीबोर्ड और स्क्रीन रीडर व्यवहार के अनुसार अपडेट करने को कहें।

अगले कदम: इस चेकलिस्ट को रीयूज़ करें और अपने वर्कफ़्लो में शामिल करें

यदि आप चाहते हैं कि React और Flutter UI रिव्यू के लिए ये एक्सेसिबिलिटी प्रॉम्प्ट्स लम्बे समय में फल दें, तो इन्हें एक दोहराने वाली आदत की तरह रखें, न कि एक बार का क्लीन-अप। लक्ष्य हर बार एक छोटा सेट चेक्स चलाना है जब आप नई स्क्रीन या कंपोनेंट जोड़ते हैं।

UI चेंजेस के लिए एक एकल “definition of done” रखें। कुछ भी शिप होने से पहले कीबोर्ड, फोकस, नाम, और कंट्रास्ट का एक त्वरित पास करें। अक्सर करने पर यह मिनटों में हो जाता है।

यहाँ एक त्वरित चेकलिस्ट है जिसे आप लगभग किसी भी UI पर चला सकते हैं:

• Keyboard: क्या आप हर इंटरैक्टिव एलिमेंट तक पहुँच सकते हैं और बिना माउस के उपयोग कर सकते हैं?
• Focus: क्या फोकस दिखाई देता है, और क्या यह तार्किक ऑर्डर में मूव करता है?
• Labels: क्या हर फ़ील्ड और बटन का स्पष्ट नाम है (आइकन्स सहित)?
• Announcements: क्या स्टेट चेंजेज़ announce होते हैं (errors, loading, success)?
• Contrast: क्या टेक्स्ट पढ़ने योग्य है और डिसेबल्ड स्टेट्स समझने योग्य हैं?

अपने बेहतरीन प्रॉम्प्ट्स को टेम्पलेट के रूप में सहेजें। एक आसान तरीका है कि हर चेंज रिक्वेस्ट के अंत में एक “React review prompt” और एक “Flutter review prompt” रखें जिसे आप पेस्ट कर सकें। फिर एक छोटा सा लाइन जोड़ें जो नए कंपोनेंट और किसी खास बिहेवियर (modal, stepper, infinite scroll वाली लिस्ट) का वर्णन करे।

हर नए कंपोनेंट पर रिलीज़ से पहले वही चेक्स दोहराएँ, भले ही यह एक दोहराव जैसा लगे। एक्सेसिबिलिटी समस्याएँ अक्सर छोटे एडिट्स से आती हैं: नया आइकन-ओनली बटन, कस्टम ड्रॉपडाउन, टोस्ट मैसेज, या डायलॉग में फोकस ट्रैप।

यदि आप Koder.ai के साथ बनाते हैं, तो प्रॉम्प्ट्स चैट में पेस्ट करें और विशिष्ट फिक्स माँगें, सामान्य सुधार नहीं। फिर प्लानिंग मोड का उपयोग करके प्रभाव की समीक्षा करें इससे पहले कि आप बदलाव लागू करें। एक्सेसिबिलिटी पास से पहले एक स्नैपशॉट लें, और यदि कोई फिक्स लेआउट या बिहेवियर तोड़ता है तो रॉलबैक का उपयोग करें। इससे फोकस ऑर्डर और semantics पर iterating करना सुरक्षित बनता है।

एक बार आपकी एक्सेसिबिलिटी पास संतोषजनक हो जाए, आप इसे एक रिलीज़ गेट की तरह ट्रीट कर सकते हैं: अपने रेपो वर्कफ़्लो के लिए सोर्स कोड एक्सपोर्ट करें, या ऐप को डिप्लॉय और होस्ट करें और कस्टम डोमेन कनेक्ट करें जब आप परिणाम से खुश हों।