Figma से एक्सेसिबल HTML तक: एक प्रैक्टिकल गाइड

तुरंत जवाब: Figma-to-HTML वर्कफ़्लो में accessibility कोई एक सेटिंग नहीं है जिसे आप ऑन कर दें — यह कुछ खास फ़ैसलों का मामला है: स्टाइल किए हुए <div> की बजाय असली सिमैंटिक एलिमेंट्स, ऐसा हेडिंग ऑर्डर जो कंटेंट स्ट्रक्चर से मेल खाता हो (Figma में हेडिंग लेवल का कोई नेटिव कॉन्सेप्ट नहीं है), लेबल किए हुए फॉर्म फ़ील्ड्स और आइकन-ओनली बटन, विज़िबल फ़ोकस स्टेट्स, पर्याप्त कलर कंट्रास्ट, और ARIA का इस्तेमाल कम से कम — सिर्फ़ वहीं जहाँ सिमैंटिक HTML खुद इंटरैक्शन को एक्सप्रेस नहीं कर सकता। ऑटोमेटेड आउटपुट आपको ज़्यादातर रास्ता तय करा देता है; उसके बाद भी एक छोटा मैन्युअल पास वह पकड़ लेता है जो एक डिज़ाइन फ़ाइल कैरी नहीं कर सकती।

Figma-to-HTML ट्रांसलेशन में accessibility कहाँ छूट जाती है

एक Figma फ़ाइल यह बताती है कि डिज़ाइन दिखने में कैसा है। यह नहीं बताती कि स्क्रीन रीडर को क्या अनाउंस करना चाहिए, अगला फ़ोकस किस एलिमेंट को मिलना चाहिए, या क्या कोई कलर पेयर low vision वाले किसी व्यक्ति के लिए पढ़ने लायक है। यही गैप कन्वर्ज़न के दौरान accessibility के टूटने की असल वजह है — लापरवाही नहीं, बल्कि यह तथ्य कि accessibility को जिस जानकारी की ज़रूरत होती है, वह डिज़ाइन फ़ाइल में होती ही नहीं। पिक्सेल-परफ़ेक्ट विज़ुअल मैच भी accessibility फ़ेल्योर हो सकता है, अगर उसके नीचे का मार्कअप बिना structure, बिना labels और बिना keyboard support वाले जेनेरिक <div> हों।

इसका फ़िक्स कोई एक ऑटोमेटेड पास नहीं है। यह समझने की बात है कि accessibility के कौन-से हिस्से एक अच्छा कन्वर्टर सिर्फ़ विज़ुअल-ओनली मार्कअप की बजाय असली structure जनरेट करके पहले ही सही कर देता है, और कौन-से हिस्सों को हमेशा एक सोच-समझकर लिया गया फ़ैसला चाहिए होता है — किसी डिज़ाइनर, डेवलपर, या दोनों की तरफ़ से — क्योंकि डिज़ाइन फ़ाइल वाक़ई वह जानकारी कैरी नहीं करती।

Figma डिज़ाइन के फ़ैसले जो accessibility को प्रभावित करते हैं

कुछ आम Figma आदतें आगे चलकर accessibility की समस्याएँ पैदा करती हैं, किसी भी कन्वर्ज़न टूल के इस्तेमाल में आने से पहले ही:

• सिर्फ़ कलर को एक सिग्नल की तरह इस्तेमाल करना। एक ज़रूरी फ़ॉर्म फ़ील्ड जो लाल रंग से मार्क किया गया हो, या एक डिसेबल्ड बटन जो उसी कलर का बस हल्का शेड हो — दोनों उस व्यक्ति के लिए अदृश्य हैं जो इन रंगों में फ़र्क़ नहीं कर सकता। इस फ़र्क़ के लिए एक दूसरा सिग्नल चाहिए (एक आइकन, एक लेबल, एक पैटर्न), सिर्फ़ कलर शिफ्ट नहीं।
• टेक्स्ट को इमेज में बेक करना। एक फ़्लैटन्ड PNG के तौर पर एक्सपोर्ट की गई हेडलाइन दिखने में एक असली टेक्स्ट लेयर जैसी ही लग सकती है, लेकिन इसे स्क्रीन रीडर पढ़ नहीं सकता, ब्राउज़र रीसाइज़ नहीं कर सकता, या कोई क्रॉलर इंडेक्स नहीं कर सकता।
• कोई विज़ुअल फ़ोकस स्टेट डिज़ाइन न होना। ज़्यादातर Figma कॉम्पोनेंट सेट्स में एक डिफ़ॉल्ट, hover और कभी-कभी एक disabled स्टेट होता है — फ़ोकस स्टेट (कीबोर्ड से पेज में टैब करते यूज़र्स के लिए) अक्सर डिज़ाइन ही नहीं किया जाता, इसलिए कन्वर्ज़न के पास कैरी करने के लिए कुछ होता ही नहीं।
• आइकन-ओनली बटन, जिनका फ़ाइल में कहीं भी कोई accessible name न हो। एक ट्रैश आइकन जिसका मतलब "delete" है, विज़ुअली तो साफ़ है। लेकिन Figma लेयर में कुछ भी किसी कन्वर्टर — या स्क्रीन रीडर — को यह नहीं बताता कि आइकन का मतलब क्या है, जब तक लेयर को खुद ही मतलब भरा नाम न दिया गया हो।
• असंगत हेडिंग साइज़ेज़। Figma में किसी CMS या वर्ड प्रोसेसर की तरह कोई "Heading 2" एलिमेंट नहीं होता — टेक्स्ट लेयर्स बस टेक्स्ट होती हैं, जिन्हें एक खास साइज़ जैसा दिखने के लिए स्टाइल किया गया होता है। अलग-अलग फ़्रेम्स में विज़ुअली मिलती-जुलती दो हेडिंग्स असली कंटेंट हायरार्की में बिल्कुल अलग-अलग लेवल दर्शा सकती हैं।

इनमें से कोई भी कन्वर्ज़न बग नहीं है। ये ऐसे फ़ैसले हैं जो पाइपलाइन में कहीं न कहीं लेने ही पड़ते हैं, और यह पहले से जान लेना बेहतर है, बजाय यह मान लेने के कि कोई टूल इन्हें ख़ुद-ब-ख़ुद समझ लेगा।

सिमैंटिक HTML और लैंडमार्क्स

यह accessibility का वह हिस्सा है जिसे एक अच्छे Figma-to-code कन्वर्टर को डिफ़ॉल्ट रूप से सही करना चाहिए: बिना लेबल वाले <div> से बने पूरे पेज की बजाय असली <header>, <nav>, <main>, <article>, <section>, <aside> और <footer> एलिमेंट्स। लैंडमार्क्स इसलिए मायने रखते हैं क्योंकि इन्हीं की मदद से स्क्रीन रीडर यूज़र पूरे पेज में लीनियर तरीके से टैब करने की बजाय सीधे "main content" या "navigation" पर जंप कर पाता है। MarkupGen के आउटपुट का structure कैसा दिखता है यह जानने के लिए Figma to Semantic HTML देखें, और सिमैंटिक मार्कअप व crawlability के बीच के ओवरलैप के लिए Is Figma-to-HTML Output SEO-Ready? देखें — दोनों समस्याओं की जड़ एक ही है और फ़िक्स भी ज़्यादातर एक जैसा ही है।

हेडिंग हायरार्की

हर पेज पर एक <h1>, और हेडिंग्स क्रम में नीचे उतरनी चाहिए — एक <h3> उस सेक्शन के अंदर होनी चाहिए जिसमें पहले से एक <h2> मौजूद हो, न कि सीधे वहाँ पहुँच जाए क्योंकि डिज़ाइन में कोई टेक्स्ट लेयर उस साइज़ की दिख रही थी। जैसा ऊपर बताया गया, Figma में हेडिंग लेवल का कोई नेटिव कॉन्सेप्ट नहीं है, इसलिए बड़े साइज़ में स्टाइल की गई टेक्स्ट लेयर अपने-आप <h1> नहीं बन जाती — चाहे मार्कअप किसी भी टूल ने जनरेट किया हो, यह एक मैन्युअल चेक के लायक है, क्योंकि यह कंटेंट की असली स्ट्रक्चर को समझने पर निर्भर करता है, सिर्फ़ उसके विज़ुअल साइज़ पर नहीं।

Buttons बनाम Links

कन्वर्टेड मार्कअप में यह सबसे आम accessibility गलतियों में से एक है, और Figma का कॉम्पोनेंट structure इसे आपके लिए ख़ुद-ब-ख़ुद हल नहीं करता: <button> मौजूदा पेज पर किसी एक्शन के लिए है (सबमिट करना, मॉडल खोलना, कोई आइटम डिलीट करना); <a href> किसी दूसरे पेज या व्यू पर नेविगेशन के लिए है। एक जैसी स्टाइल वाली pill शेप्स से भरी डिज़ाइन फ़ाइल यह कोई संकेत नहीं देती कि कौन-सी क्या है — यह एक सिमैंटिक फ़ैसला है, विज़ुअल नहीं, और यह सीधे कीबोर्ड बिहेवियर (बटन और लिंक डिफ़ॉल्ट रूप से अलग-अलग की पर रिस्पॉन्ड करते हैं) और स्क्रीन रीडर क्या अनाउंस करता है, दोनों को प्रभावित करता है।

फ़ॉर्म्स और लेबल्स

हर इनपुट को एक असली, प्रोग्रामेटिकली एसोसिएटेड <label> चाहिए — न कि उसकी जगह खड़ा हुआ कोई placeholder। Placeholder टेक्स्ट यूज़र के टाइप करना शुरू करते ही गायब हो जाता है, डिफ़ॉल्ट रूप से इसका कंट्रास्ट बेहद ख़राब होता है, और यह सभी स्क्रीन रीडर्स द्वारा लेबल के विकल्प के तौर पर भरोसेमंद तरीके से पढ़ा नहीं जाता। अगर डिज़ाइन कारणों से किसी फ़ॉर्म को लेबल-रहित दिखना ज़रूरी है, तो मार्कअप से लेबल पूरी तरह हटाने की बजाय एक विज़ुअली-हिडन लेबल इस्तेमाल करें। एरर मैसेजेस को उनके फ़ील्ड के साथ एसोसिएट होना चाहिए (आमतौर पर aria-describedby के ज़रिए), न कि सिर्फ़ पास में रख दिया जाए और सिर्फ़ कलर से समस्या का संकेत दिया जाए।

इमेजेज़ और alt टेक्स्ट

एक्सपोर्ट की गई इमेजेज़ को मतलब भरे alt attributes चाहिए, खाली स्ट्रिंग या फ़ाइलनेम नहीं। यह एक ऐसा एरिया है जहाँ मैन्युअल पास वाक़ई ज़रूरी है: एक डेकोरेटिव बैकग्राउंड इमेज किसलिए है, बनाम एक प्रोडक्ट फ़ोटो को किस तरह डिस्क्राइब करने की ज़रूरत है — यह हमेशा सिर्फ़ Figma फ़्रेम से साफ़ नहीं होता — डिज़ाइन फ़ाइल इरादा कैरी नहीं करती, सिर्फ़ पिक्सेल्स करती है। पूरी तरह डेकोरेटिव इमेजेज़ को एक खाली alt="" मिलना चाहिए (ताकि स्क्रीन रीडर्स उन्हें स्किप कर दें), जबकि मतलब भरी इमेजेज़ को एक असली डिस्क्रिप्शन चाहिए कि वे क्या दर्शाती हैं, सिर्फ़ यह नहीं कि वे क्या दिखती हैं।

कीबोर्ड नेविगेशन

हर इंटरैक्टिव एलिमेंट — links, buttons, form fields — सिर्फ़ कीबोर्ड से ही पहुँचने और ऑपरेट करने लायक होना चाहिए, ऐसे क्रम में जो विज़ुअल रीडिंग ऑर्डर से मेल खाता हो। यहीं पर Auto Layout वाक़ई मदद करता है: क्योंकि Auto Layout का structure absolutely positioned फ़्रैगमेंट्स की बजाय एक लॉजिकल DOM ऑर्डर में कैरी होता है, tab order अक्सर अपने-आप रीडिंग ऑर्डर को फॉलो करता है, न कि उस तरह अप्रत्याशित रूप से इधर-उधर कूदता है जैसा free-form, absolutely-positioned लेआउट्स के साथ हो सकता है।

फ़ोकस स्टेट्स

चूँकि Figma कॉम्पोनेंट सेट्स में शायद ही कभी कोई डिज़ाइन किया गया फ़ोकस स्टेट शामिल होता है, यह आमतौर पर कन्वर्टेड पेज में सबसे आम accessibility गैप होता है: एक कीबोर्ड यूज़र इंटरफ़ेस में टैब करता है और विज़ुअली यह नहीं बता पाता कि वह कहाँ है। कम से कम, ब्राउज़र के डिफ़ॉल्ट फ़ोकस आउटलाइन (outline: none) को उसकी जगह उतना ही विज़िबल कुछ रखे बिना न हटाएँ — यह एक आम, आसानी से शिप हो जाने वाली गलती है, जो ऐसे डिज़ाइन से मेल खाने के नाम पर की जाती है जिसमें इसका ध्यान कभी रखा ही नहीं गया था।

कलर कंट्रास्ट

Figma आपको कोई भी दो कलर चुनने देता है, भले ही वे साथ में पढ़ने लायक हों या न हों, इसलिए इसके लिए एक मान लेने की बजाय एक साफ़ चेक ज़रूरी है। WCAG AA नॉर्मल बॉडी टेक्स्ट के लिए कम से कम 4.5:1 कंट्रास्ट और large टेक्स्ट (18px+ bold, या 24px+ regular) के साथ-साथ आइकन और input borders जैसे मतलब भरे UI कॉम्पोनेंट्स के लिए 3:1 माँगता है। कन्वर्ज़न से पहले डिज़ाइन के असली कलर पेयर्स को एक कंट्रास्ट चेकर से गुज़ारें — बाद में जनरेट हुए मार्कअप में इसे ढूँढ-ढूँढकर ठीक करने से कहीं सस्ता है Figma में एक टोकन ठीक कर देना।

ARIA — कब यह मदद करता है, और कब यह नुकसान करता है

ARIA का पहला नियम आज भी सही है: बुरे ARIA से बेहतर है कोई ARIA न हो। एक नेटिव <button> में पहले से ही सही role होता है, यह focusable होता है, और डिफ़ॉल्ट रूप से Enter और Space पर रिस्पॉन्ड करता है — इसमें role="button" जोड़ने से कोई फ़ायदा नहीं होता, और इससे एलिमेंट के असली सिमैंटिक्स से टकराव का ख़तरा रहता है। ARIA अपनी जगह ख़ासतौर पर वहीं बनाता है जहाँ सिमैंटिक HTML खुद इंटरैक्शन को एक्सप्रेस नहीं कर सकता:

• इसे इस्तेमाल करें: बिना किसी विज़िबल टेक्स्ट वाले आइकन-ओनली बटन पर aria-label (एक ट्रैश आइकन जिसका मतलब "delete" है), किसी collapsible सेक्शन को कंट्रोल करने वाले टॉगल पर aria-expanded, बिना पेज रीलोड के अपडेट होने वाले किसी रीजन पर aria-live="polite" (एक फ़ॉर्म वैलिडेशन मैसेज, एक कार्ट काउंट)।
• इसे इस्तेमाल न करें: ऐसे एलिमेंट्स में ARIA roles जोड़ना जिनमें पहले से सही नेटिव सिमैंटिक्स हैं, डेकोरेटिव ARIA जो पहले से विज़िबल और अनाउंस्ड चीज़ को दोहराता है, या ऐसी किसी भी चीज़ पर aria-live="assertive" जो वाक़ई अर्जेंट न हो — यह स्क्रीन रीडर आउटपुट में रुकावट डालता है और आसानी से ओवरयूज़ हो जाता है।

रेस्पॉन्सिव accessibility

Accessibility समस्याएँ सिर्फ़ इसलिए सभी breakpoints पर ठीक नहीं रहतीं क्योंकि उन्हें एक साइज़ पर ठीक कर दिया गया था। लेआउट्स के कंप्रेस होने पर भी, मोबाइल पर टच टारगेट्स को कम से कम लगभग 44×44px बना रहना चाहिए — एक बटन जो डेस्कटॉप पर आराम से क्लिक करने लायक है, Auto Layout की resizing constraints के उसे छोटा करने पर टैप के लिए भरोसेमंद तौर पर बहुत छोटा हो सकता है। संकरी widths पर टेक्स्ट को क्लिप या ओवरलैप होने की बजाय रीफ़्लो करना चाहिए, और कंटेंट का क्रम breakpoints के बीच इस तरह उलझाने वाले ढंग से नहीं बदलना चाहिए कि वह लॉजिकल रीडिंग ऑर्डर टूट जाए जिस पर स्क्रीन रीडर निर्भर करता है।

आम Figma-to-HTML accessibility गलतियाँ

• हर क्लिक करने लायक एलिमेंट को असली <button> या <a> की बजाय <div onclick> में कन्वर्ट कर देना।
• बिना aria-label वाले आइकन-ओनली बटन, क्योंकि Figma लेयर का नाम बस "Icon 4" रखा गया था।
• किसी स्टेट (error, disabled, selected) को बताने का सिर्फ़ कलर को इकलौता ज़रिया बनाना।
• फ़ोकस स्टेट्स पर outline: none लगाना और उसकी जगह कुछ भी विज़िबल न रखना।
• फ़ॉर्म फ़ील्ड पर placeholder टेक्स्ट को इकलौते लेबल की तरह इस्तेमाल करना।
• डेकोरेटिव इमेजेज़ को खाली alt="" की बजाय alt टेक्स्ट के तौर पर फ़ाइलनेम दे देना।
• हेडिंग लेवल्स को असली कंटेंट स्ट्रक्चर की बजाय डिज़ाइन में फ़ॉन्ट साइज़ के आधार पर चुनना।

पहले / बाद में: एक आइकन-ओनली बटन

पहले — विज़ुअली सही, लेकिन accessible नहीं:

<div class="icon-btn" onclick="deleteItem()">
  <svg><!-- trash icon --></svg>
</div>

बाद में — वही विज़ुअल रिज़ल्ट, लेकिन वाक़ई इस्तेमाल करने लायक:

<button type="button" class="icon-btn" aria-label="Delete item" onclick="deleteItem()">
  <svg aria-hidden="true"><!-- trash icon --></svg>
</button>

फ़र्क़ विज़ुअल बिल्कुल भी नहीं है — यह एक असली <button> एलिमेंट है (focusable, keyboard-operable, स्क्रीन रीडर द्वारा सही तरीके से अनाउंस्ड), एक aria-label जो आइकन को एक accessible name देता है, और डेकोरेटिव SVG पर aria-hidden="true" ताकि यह दो बार अनाउंस न हो।

प्रैक्टिकल accessibility चेकलिस्ट

• हर पेज पर एक <h1>; हेडिंग्स क्रम में नीचे उतरें, फ़ॉन्ट साइज़ के हिसाब से नहीं
• असली landmark एलिमेंट्स (header, nav, main, footer) मौजूद हों
• हर क्लिक करने लायक एक्शन एक <button> हो; हर नेविगेशन लिंक एक <a href> हो
• हर फ़ॉर्म इनपुट में एक असली, एसोसिएटेड <label> हो — सिर्फ़ placeholder नहीं
• मतलब भरी इमेजेज़ में डिस्क्रिप्टिव alt टेक्स्ट हो; डेकोरेटिव इमेजेज़ में alt="" हो
• हर इंटरैक्टिव एलिमेंट पर फ़ोकस स्टेट्स विज़िबल हों
• Tab order विज़ुअल रीडिंग ऑर्डर से मेल खाता हो
• टेक्स्ट और UI कॉम्पोनेंट कंट्रास्ट WCAG AA (4.5:1 / 3:1) को पूरा करता हो
• कलर कभी भी स्टेट या मतलब का इकलौता सिग्नल न हो
• ARIA का इस्तेमाल सिर्फ़ वहीं हो जहाँ सिमैंटिक HTML इंटरैक्शन को एक्सप्रेस नहीं कर सकता
• मोबाइल breakpoints पर टच टारगेट्स इस्तेमाल करने लायक रहें
• संकरी widths पर लेआउट बिना टेक्स्ट क्लिप या ओवरलैप हुए रीफ़्लो हो

प्रोडक्शन से पहले जनरेट हुए कोड को कैसे रिव्यू करें

MarkupGen का आउटपुट किसी opt-in सेटिंग की बजाय डिफ़ॉल्ट रूप से सिमैंटिक एलिमेंट्स और एक असली हेडिंग स्ट्रक्चर को तरजीह देता है, और Auto Layout का structure एक लॉजिकल DOM ऑर्डर में कैरी होना ही सबसे पहली जगह सही tab order को मुमकिन बनाने की मुख्य वजह है। हर एक्सपोर्ट को मिलने वाला ऑटोमेटिक AI क्वालिटी स्कोर वाक़ई एक उपयोगी पहला सिग्नल है — लेकिन यह साफ़ तौर पर एक विज़ुअल-मैच स्कोर है, जो रेंडर्ड प्रीव्यू को ओरिजिनल डिज़ाइन से कंपेयर करता है। यह ARIA की सटीकता, कंट्रास्ट रेशियोज़ या कीबोर्ड बिहेवियर ऑडिट नहीं करता, क्योंकि इनमें से कुछ भी स्क्रीनशॉट कंपैरिज़न में विज़िबल नहीं होता। ऊपर दी गई चेकलिस्ट को उस मैन्युअल पास की तरह लें जो एक हाई विज़ुअल स्कोर के बाद आता है, उसकी जगह नहीं — कोड रिव्यू पर लागू होने वाले इसी सिद्धांत के लिए How to Evaluate AI-Generated HTML Before You Ship It देखें।

अपने डिज़ाइन पर आज़माएँ

यह देखने का सबसे तेज़ तरीका कि किसी डिज़ाइन को accessibility पास की कहाँ ज़रूरत है, यही है कि उसे कन्वर्ट करें और असली मार्कअप खोलकर देखें। MarkupGen फ्री में आज़माएँ, या इस गाइड के आधार वाले end-to-end वर्कफ़्लो के लिए पूरी Figma-to-HTML conversion गाइड से शुरू करें।