React और Flutter UI रिव्यू के लिए एक्सेसिबिलिटी प्रॉम्प्ट: कीबोर्ड, फोकस ऑर्डर, लेबल, कंट्रास्ट और स्क्रीन रीडर के लिए कॉपी करने योग्य प्रॉम्प्ट और सरल समीक्षा कदम।

अधिकांश एक्सेसिबिलिटी समस्याएँ बड़े रीडिज़ाइन की वजह से नहीं होतीं। ये छोटे-छोटे विवरण होते हैं जो तय करते हैं कि कोई आपकी UI का उपयोग कर पाएगा या नहीं।
आमतौर पर सबसे पहले क्या टूटता है, यह काफी हद तक एक जैसा होता है। पेज ठीक दिख सकता है, एक त्वरित विजुअल चेक पास कर सकता है, और फिर भी कीबोर्ड या स्क्रीन रीडर के साथ उपयोग करने में मुश्किल हो सकता है।
यहाँ वे शुरुआती स्थान हैं जहाँ UI अक्सर फेल होते हैं:
मुश्किल हिस्सा यह है कि regressions बहुत आसानी से आ जाते हैं। एक “छोटा” बदलाव—जैसे बटन को आइकन से बदलना, कार्ड को जेस्चर हैंडलर में रैप करना, या एक कस्टम ड्रॉपडाउन जोड़ना—कीबोर्ड समर्थन हटा सकता है, फोकस ऑर्डर तोड़ सकता है, या किसी लेबल को गायब कर सकता है बिना किसी के नोटिस के।
एक आम परिदृश्य: एक React फॉर्म में एक नया “clear” आइकन इनपुट के अंदर जोड़ दिया जाता है। यह मददगार लगता है, पर आइकन फोकस करने योग्य नहीं है, उसका कोई नाम नहीं है, और वह क्लिक इवेंट्स ले लेता है। अब कीबोर्ड यूज़र्स इसे सक्रिय नहीं कर सकते, और स्क्रीन रीडर यूज़र्स एक अनलेबल्ड कंट्रोल सुनते हैं।
यह पोस्ट आपको दो चीज़ें देती है: कॉपी करने योग्य प्रॉम्प्ट जो आप अपने UI कोड (React और Flutter) के साथ उपयोग कर सकते हैं, और एक दोहराने योग्य रिव्यू फ्लो जो आप मिनटों में चला सकते हैं। लक्ष्य दिन एक पर परिपूर्णता नहीं है—बल्कि उन समस्याओं को पकड़ना है जो असल यूज़र्स को ब्लॉक करती हैं।
यदि आप प्रोडक्ट स्क्रीन बनाते हैं पर एक्सेसिबिलिटी स्पेशलिस्ट नहीं हैं, तो यह आपके लिए है। यह उन टीमों के लिए भी फिट बैठता है जो vibe-coding टूल्स जैसे Koder.ai इस्तेमाल करती हैं, जहाँ UI बदलते तेज़ी से बनते हैं और आपको जल्दी, संगत चेक चाहिए होते हैं। यदि आप एक व्यावहारिक शुरुआत चाहते हैं, तो ये React और Flutter UI रिव्यू के लिए एक्सेसिबिलिटी प्रॉम्प्ट हर बार रीयूज़ करने के लिए डिज़ाइन किए गए हैं।
यदि आपके पास किसी स्क्रीन की समीक्षा के लिए केवल 15 मिनट हैं, तो ये चेक उन समस्याओं को ढूँढते हैं जो सबसे अक्सर यूज़र्स को ब्लॉक करती हैं। ये React और Flutter दोनों पर काम करते हैं, और ये समीक्षा फ्लोज़ में अच्छे से फिट होते हैं।
पेज पर बिना माउस के नेविगेट करने की कोशिश करें। Tab और Shift+Tab से मूव करें, Enter और Space से सक्रिय करें, और जहाँ कोई विजेट मेनू, टैब, या लिस्ट जैसा दिखे वहाँ एरो कीज़ इस्तेमाल करें।
एक तेज संकेत: यदि आप किसी मोडल में फंस जाते हैं, या किसी प्रमुख कंट्रोल (जैसे “Close”) तक नहीं पहुँच पाते, तो कुछ गड़बड़ है।
जैसे ही आप tab करते हैं, फोकस को विज़ुअल लेआउट (ऊपर से नीचे, बाएँ से दाएँ) के अनुसार चलना चाहिए और कभी छिपे हुए एरिया पर न जाना चाहिए। फोकस स्पष्ट भी होना चाहिए। यदि डिज़ाइन सूक्ष्म आउटलाइन इस्तेमाल करता है, तो सुनिश्चित करें कि वे लाइट और डार्क दोनों बैकग्राउंड पर दिखाई दें।
एक स्क्रीन रीडर को हर इंटरैक्टिव एलिमेंट के लिए उपयोगी नाम announce करना चाहिए। सिर्फ “Button” काफी नहीं है। आइकन को एक्सेसिबल लेबल चाहिए, और फ़ॉर्म फ़ील्ड्स का लेबल तब भी जुड़ा रहना चाहिए जब placeholder गायब हो जाए।
छोटे टेक्स्ट, डिसेबल्ड टेक्स्ट, और रंगीन बटनों पर टेक्स्ट चेक करें। ज़ूम भी टेस्ट करें: फ़ॉन्ट साइज बढ़ाएँ और सुनिश्चित करें कि लेआउट ओवरलैप न करे या प्रमुख कंटेंट कट न हो।
जब कुछ बदलता है (त्रुटि, लोडिंग, सफलता), तो यूज़र्स को अनुमान नहीं लगाना चाहिए। फ़ील्ड के पास इनलाइन एरर टेक्स्ट का उपयोग करें, फ़ॉर्म त्रुटियों की घोषणा करें, और लोडिंग स्टेट्स को स्पष्ट बनाएं।
यदि आप Koder.ai में स्क्रीन बनाते हैं, तो उससे कहें: “इस पेज के लिए कीबोर्ड-ओनली फ्लो, फोकस ऑर्डर, और स्क्रीन रीडर लेबल सत्यापित करें,” और फिर ऊपर दिए गए स्टेप्स का उपयोग कर परिणाम की समीक्षा करें।
जब आप यह तय कर लें कि आप क्या रिव्यू कर रहे हैं और “पर्याप्त” का क्या अर्थ है, तो एक्सेसिबिलिटी का काम तेज़ होता है। एक तंग स्कोप भी 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 जैसी अपेक्षाओं का लक्ष्य रखें, पर उसे सरल चेक्स में ट्रांसलेट करें जिन्हें आप जल्दी लागू कर सकें: कीबोर्ड एंड-टू-एंड काम करे, फोकस दिखाई दे और तार्किक हो, नाम और लेबल समझदार हों, और कंट्रास्ट पढ़ने योग्य हो।
सरल पास/फेल नोट फॉर्मेट का उपयोग करें ताकि बहस में समय न बर्बाद हो। हर स्क्रीन के लिए कैप्चर करें:
यह रिव्यू React और Flutter दोनों पर सुसंगत रखता है और यह किसी और को बिना दोहराए समस्या देने में आसान बनाता है।
जब आप एक्सेसिबिलिटी रिव्यू पूछते हैं, तो सबसे तेज़ जीतें स्पेसिफिक होने से मिलती हैं: कौन सा कंपोनेंट, कौन सी यूज़र क्रिया, और "अच्छा" कैसा दिखता है। ये प्रॉम्प्ट तभी सबसे अच्छे काम करते हैं जब आप कंपोनेंट कोड और एक छोटा वर्णन पेस्ट करें कि 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).
प्रॉम्प्ट भेजने से पहले ये विवरण शामिल करें ताकि आप सामान्य सलाह नहीं बल्कि इस्तेमाल योग्य फिक्स पाएं:
यदि आप सुसंगत परिणाम चाहते हैं, तो एक विगेट स्निपेट (या पूरी स्क्रीन) पेस्ट करें और खास चेक माँगें। ये प्रॉम्प्ट तब सबसे अच्छे काम करते हैं जब आप विगेट ट्री, स्क्रीन तक पहुँचने का तरीका, और कोई कस्टम जेस्चर्स शामिल करें।
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),
),
),
)
एक तेज़ कीबोर्ड और फोकस रिव्यू उन समस्याओं को पकड़ता है जो स्क्रीन रीडर्स और स्विच डिवाइसेज़ को भी प्रभावित करती हैं। इसे एक वास्तविक पेज फ्लो पर करें (सिर्फ एक बटन नहीं), और चलते हुए नोट रखें ताकि आप बाद में उसी पाथ को दोबारा चेक कर सकें।
सबसे पहले एक “हैप्पी पाथ” चुनें जो यूज़र लेगा, जैसे साइन इन करना, सेटिंग्स स्क्रीन खोलना, और सेव करना।
साधारण रखें: पेज का नाम, आपने क्या दबाया, क्या हुआ, और आप क्या अपेक्षा कर रहे थे। यह छोटा लॉग यह सुनिश्चित करने में आसान बनाता है कि 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”。
इन प्रॉम्प्ट्स का उपयोग स्क्रीन की समीक्षा करते समय करें (या जब आप Koder.ai जैसे टूल से कंपोनेंट अपडेट करवाना चाहें):
कई स्क्रीन बिना पेज रीलोड के बदलती हैं: प्रोफ़ाइल सेव करना, आइटम जोड़ना, रिज़ल्ट्स लोड करना। सुनिश्चित करें कि इन अपडेट्स की घोषणाएँ हों।
React के लिए, aria-live रीजन पसंद करें ("polite" सामान्य संदेशों के लिए, "assertive" गंभीर त्रुटियों के लिए)। Flutter में, Semantics और स्टेटस संदेशों को दिखाएँ (उदा. एक बैनर या SnackBar) ताकि वे पढ़े जाएँ, सिर्फ दिखाई न दें। एक तेज़ जाँच: “Save” ट्रिगर करें, और पुष्टि करें कि आप एक छोटा संदेश सुनते हैं जैसे “Changes saved” बिना फोकस को बंटाए।
यदि आप उन जगहों पर ध्यान दें जहाँ लोग वास्तव में संघर्ष करते हैं—छोटा टेक्स्ट, आइकन, फोकस रिंग्स, और स्टेट कलर्स—तो आप मिनटों में अधिकांश कंट्रास्ट समस्याएँ पकड़ सकते हैं। यह React और Flutter UI रिव्यू के एक्सेसिबिलिटी प्रॉम्प्ट्स का व्यावहारिक हिस्सा है क्योंकि इसे वेरिफ़ाई करना आसान है और फिक्स भी आसान है।
एक स्क्रीन को 100% ज़ूम पर और फिर 200% पर स्कैन करके शुरू करें। यदि कुछ पढ़ने में कठिन हो जाता है, तो अक्सर यह कंट्रास्ट, वजन, या स्पेसिंग की समस्या होती है, न कि यूज़र की।
पहले ये पाँच जगहें चेक करें:
एक जल्दी नियम: अगर आपको तिरछा देखकर पढ़ने में मुश्किल हो रही हो, तो आपके यूज़र्स को भी होगी। यदि आप रंग जोड़ी के बारे में सुनिश्चित नहीं हैं, तो अस्थायी रूप से टेक्स्ट को शुद्ध काले या शुद्ध सफेद में बदलकर देखें—यदि पठनीयता कूदती है, तो कंट्रास्ट कम था।
फोकस विजिबिलिटी अक्सर छूटी रहती है। सुनिश्चित करें कि फोकस आउटलाइन पर्याप्त मोटी है और बैकग्राउंड के समान रंग न हो। यदि किसी सूची में “चयनित” स्टेट है, तो वह ग्रेस्केल में भी अलग दिखना चाहिए—उदाहरण के तौर पर आइकन, अंडरलाइन, या स्पष्ट बॉर्डर जोड़कर।
मोबाइल पर विज़ुअल स्पष्टता टच के बारे में भी है। बटन और आइकन-ओनली एक्शन्स के पास पर्याप्त टैप टारगेट और स्पेसिंग होने चाहिए ताकि यूज़र्स गलत कंट्रोल न दबाएँ।
एक तेज़ थीम स्वीप करें: डार्क मोड टॉगल करें, और यदि ऐप हाई कंट्रास्ट समर्थन करता है तो उसे भी जाँचें। सतहों, डिवाइडर्स, और फोकस रिंग्स पर टेक्स्ट फिर से चेक करें। एक आम बग यह है कि डार्क मोड में फोकस रिंग गायब हो जाता है या एक इनएक्टिव आइकन बैकग्राउंड के लगभग समान रंग का हो जाता है।
यदि आप Koder.ai जैसे टूल में तेज़ी से UI जनरेट कर रहे हैं, तो एक अतिरिक्त रिव्यू स्टेप जोड़ें: "पहले लेआउट के बाद कंट्रास्ट और फोकस रिंग पास" माँगें, विज़ुअल पॉलिशिंग से पहले।
अधिकांश एक्सेसिबिलिटी बग़ बार-बार रिपीट होते हैं क्योंकि वे छोटे UI ट्वीक की तरह लगते हैं, न कि प्रोडक्ट बिहेवियर। जब आप React और Flutter UI रिव्यू के लिए एक्सेसिबिलिटी प्रॉम्प्ट्स चलाते हैं, तो सबसे पहले इन पैटर्न्स पर ध्यान दें।
प्लेसहोल्डर टेक्स्ट लेबल नहीं है। प्लेसहोल्डर जैसे ही कोई टाइप करता है गायब हो जाता है, और कई स्क्रीन रीडर्स इसे फ़ील्ड का नाम नहीं मानते। वास्तविक दृश्य लेबल (या एक स्पष्ट एक्सेसिबल नाम) का उपयोग करें ताकि फ़ील्ड खाली, भरी, और एरर्स दिखने पर समझ में आए।
फोकस स्टाइल्स को इसलिए हटा दिया जाता है क्योंकि “वे भद्दे लगते हैं।” यह अक्सर कीबोर्ड यूज़र्स को खो देता है। यदि आप डिफ़ॉल्ट आउटलाइन बदल रहे हैं, तो उसे कुछ समान स्पष्टता वाला बदल दें: एक मजबूत रिंग, पृष्ठभूमि परिवर्तन, और पृष्ठभूमि के मुकाबले पर्याप्त कंट्रास्ट।
एक और बार-बार वाला दोष फेक बटन होते हैं। React में div के साथ onClick इस्तेमाल करना और Flutter में Container के साथ GestureDetector का इस्तेमाल करना लुभावना होता है। उचित semantics के बिना कीबोर्ड सपोर्ट और स्क्रीन रीडर्स प्रभावित होते हैं। नेटिव कंट्रोल्स (button, a, TextButton, ElevatedButton) आपको फोकस, रोल, डिसेबल्ड स्टेट, और सक्रियण व्यवहार मुफ्त में देते हैं।
डायलॉग और फ़ॉर्म फोकस बग सूक्ष्म परंतु कष्टप्रद होते हैं। मोडल बंद करने या फॉर्म सेव करने के बाद अक्सर फोकस पेज के शीर्ष पर कूद जाता है या गायब हो जाता है। यह इसलिए होता है क्योंकि फोकस उस कंट्रोल पर वापस नहीं रखा गया जिसने डायलॉग खोला था, या सेव एक्शन स्क्रीन को रेंडर कर देता है और फोकस ड्रॉप हो जाता है। यूज़र्स को फिर से वे स्थान खोजने के लिए शुरुआत करनी पड़ती है।
ARIA (या Flutter Semantics) का ओवरयूज़ भी चीज़ें तोड़ सकता है। हर जगह रोल्स और लेबल्स जोड़ने से नेटिव एलिमेंट जो पहले से प्रदान कर रहे हैं उनके साथ टकराव हो सकता है, जिससे डबल घोषणाएँ या गलत नाम मिल सकता है।
एक तेज़ “दोहराए जाने वाले मुद्दे” चेक जो आप किसी स्क्रीन की समीक्षा करते समय माँग सकते हैं:
यदि आप चैट से UI जेनरेट करते हैं (उदा. Koder.ai), तो इन्हें अपने प्रॉम्प्ट में एक्सेप्टेंस क्राइटेरिया के रूप में शामिल करें ताकि पहला ड्राफ्ट ही आम ट्रैप्स से बच सके।
एक सरल Settings स्क्रीन की कल्पना करें: एक प्रोफ़ाइल फ़ॉर्म (Name, Email), दो टॉगल्स (Email notifications, Dark mode), एक “Save changes” बटन, और सेव के बाद एक टोस्ट जो दिखाई देता है।
कीबोर्ड से शुरू करें। अपेक्षित फोकस ऑर्डर विजुअल ऑर्डर से मेल खाना चाहिए, ऊपर से नीचे, बाएं से दाएं। Tabbing को कभी टोस्ट एरिया, फुटर, या छिपे मेन्यू में नहीं कूदना चाहिए।
एक त्वरित पास जो अधिकांश React और Flutter UI रिव्यू प्रॉम्प्ट्स के लिए काम करता है:
अब देखें कि स्क्रीन रीडर क्या 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 होना चाहिए जब आप यह कारण भी बताते हों।
कंट्रास्ट के लिए, सामान्य टेक्स्ट, प्लेसहोल्डर टेक्स्ट, और एरर मैसेजेज़ चेक करें। फोकस रिंग भी दोनों लाइट और डार्क बैकग्राउंड पर आसान से दिखनी चाहिए। एरर स्टेट्स सिर्फ लाल रंग पर निर्भर नहीं होने चाहिए। एक आइकन, स्पष्ट टेक्स्ट, या दोनों जोड़ें।
जो आप पाते हैं उसे एक छोटे फिक्स लिस्ट में बदल दें:
यदि आप Koder.ai में बना रहे हैं, तो इस स्क्रीन का वर्णन और आपकी खोजें चैट में पेस्ट करें और उससे React या Flutter UI को अपेक्षित कीबोर्ड और स्क्रीन रीडर व्यवहार के अनुसार अपडेट करने को कहें।
यदि आप चाहते हैं कि React और Flutter UI रिव्यू के लिए ये एक्सेसिबिलिटी प्रॉम्प्ट्स लम्बे समय में फल दें, तो इन्हें एक दोहराने वाली आदत की तरह रखें, न कि एक बार का क्लीन-अप। लक्ष्य हर बार एक छोटा सेट चेक्स चलाना है जब आप नई स्क्रीन या कंपोनेंट जोड़ते हैं।
UI चेंजेस के लिए एक एकल “definition of done” रखें। कुछ भी शिप होने से पहले कीबोर्ड, फोकस, नाम, और कंट्रास्ट का एक त्वरित पास करें। अक्सर करने पर यह मिनटों में हो जाता है।
यहाँ एक त्वरित चेकलिस्ट है जिसे आप लगभग किसी भी UI पर चला सकते हैं:
अपने बेहतरीन प्रॉम्प्ट्स को टेम्पलेट के रूप में सहेजें। एक आसान तरीका है कि हर चेंज रिक्वेस्ट के अंत में एक “React review prompt” और एक “Flutter review prompt” रखें जिसे आप पेस्ट कर सकें। फिर एक छोटा सा लाइन जोड़ें जो नए कंपोनेंट और किसी खास बिहेवियर (modal, stepper, infinite scroll वाली लिस्ट) का वर्णन करे।
हर नए कंपोनेंट पर रिलीज़ से पहले वही चेक्स दोहराएँ, भले ही यह एक दोहराव जैसा लगे। एक्सेसिबिलिटी समस्याएँ अक्सर छोटे एडिट्स से आती हैं: नया आइकन-ओनली बटन, कस्टम ड्रॉपडाउन, टोस्ट मैसेज, या डायलॉग में फोकस ट्रैप।
यदि आप Koder.ai के साथ बनाते हैं, तो प्रॉम्प्ट्स चैट में पेस्ट करें और विशिष्ट फिक्स माँगें, सामान्य सुधार नहीं। फिर प्लानिंग मोड का उपयोग करके प्रभाव की समीक्षा करें इससे पहले कि आप बदलाव लागू करें। एक्सेसिबिलिटी पास से पहले एक स्नैपशॉट लें, और यदि कोई फिक्स लेआउट या बिहेवियर तोड़ता है तो रॉलबैक का उपयोग करें। इससे फोकस ऑर्डर और semantics पर iterating करना सुरक्षित बनता है।
एक बार आपकी एक्सेसिबिलिटी पास संतोषजनक हो जाए, आप इसे एक रिलीज़ गेट की तरह ट्रीट कर सकते हैं: अपने रेपो वर्कफ़्लो के लिए सोर्स कोड एक्सपोर्ट करें, या ऐप को डिप्लॉय और होस्ट करें और कस्टम डोमेन कनेक्ट करें जब आप परिणाम से खुश हों।